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
