> If you have trouble with interpreting hexdump data, send me the > output from > > hex /dev/<luks-partition> | head -n 150 I replied to Arno with this output off-list, as I'm not sure I grokked enough of the discussion to understand whether this amount of data contains key material that shouldn't be publicly divulged.... I guess it doesn't really matter though, since I'll probably be re-encrypting my data (if I am able to get it back).... if anybody else is willing to take a look at it, let me know and I can forward you a copy. Thanks for all the help everyone! It's very much appreciated - if I DO end up getting my data back, there will be a nice gift basket in the mail for all of you ;) On Sat, Nov 8, 2008 at 5:10 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote: > On Sat, Nov 08, 2008 at 02:56:06PM -0800, Kevin Bowen wrote: >> By 'backup header', do you mean there's a redundant copy stored >> somewhere other than the start of the device? Or are you just talking >> about backing up my damaged header? > > He means "Backing up the header". > >> I saw a mention on the list >> archives of someone suggesting implementing a redundant header copy >> stored elsewhere on the device, and the luks author saying he thought >> that was a good idea, and he'd implement it in the next version, but >> I'm not clear on whether that has already happened yet. >> >> If there *IS* a redundant, uncorrupted backup header somewhere, how do >> I find it? > > There is not. > >> Or is that what you were trying to give me directions on >> backing up before? If so, how would I go about finding my "payload >> offset", other than from luksDump? Cause luksDump doesn't work for me >> - it just errors out saying its not a valid luks device. > > Look at my other email. It is the 4 bytes starting at offset > 104 = 0x68. > > If you have trouble with interpreting hexdump data, send me the > output from > > hex /dev/<luks-partition> | head -n 150 > > and I will have a look at it for you. > >> On Sat, Nov 8, 2008 at 1:56 PM, Milan Broz <mbroz@xxxxxxxxxx> wrote: >> > Arno Wagner wrote: >> >>> Ok, revised: Look at offset 104 in the header. It lists >> >>> where the bulk data starts (in sectors). Backup everything >> >>> before. >> > >> > Keyslot is not fixed size, I think it depends on cipher key length. > > It does and I never claimed otherwise. However the start of the > bulk data is allways after the last keyslot data. > > >> > Anyway, backup of header is easy, there is unecrypted header >> > (always of the 592 bytes IIRC) and keyslot area, >> > starting at 4k offset). >> > >> > run "crytpsetup luksDump <device>", >> > remeber the "Payload offset" (in sectors). >> > >> > then backup header with >> > dd if=<device> of=<backup_file> bs=512 count=NUM >> > >> > where NUM is the payload offset above. >> > >> > (note that anyone with this backup and knowledge >> > of any passphrase in backup header can decrypt data with >> > this, even if you change passphrase later on real disk.) >> > >> > Restore - simple dd it backwards. >> > >> > I think that this should work always, header and all >> > keyslots area should be there but not more. >> > (Restoring more data than LUKS header length can >> > rewrite filesystem data with some old content.) > > Restoring more is not critical as long as the filesystem > was not successfully mounted. THis is not a "normal" > backup we are talking here, but an emergency measure > to secure the recovery attempt against mistakes. > > Arno > --- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F > ---- > Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans > > If it's in the news, don't worry about it. The very definition of > "news" is "something that hardly ever happens." -- Bruce Schneier > > --------------------------------------------------------------------- > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx > > -- Kevin Bowen kevin@xxxxxxxx --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
