Very nice! Congratulations. Arno On Mon, Aug 27, 2012 at 11:51:59AM +0200, Andr?s Korn wrote: > Ok, so I took to reading > http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf. > > This is what the LUKS header looks like: > > 0000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 >LUKS....aes.....< > 0000016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< > 0000032 00 00 00 00 00 00 00 00 63 62 63 2d 65 73 73 69 >........cbc-essi< > 0000048 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00 >v:sha256........< > 0000064 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 >........sha1....< > 0000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< > 0000096 00 00 00 00 00 00 00 00 00 00 04 08 00 00 00 10 >................< > 0000112 b9 68 70 a2 ac ca f7 f6 f6 8f b8 ba 33 59 3c 61 >.hp.........3Y<a< > 0000128 f3 e0 68 98 4a 42 a9 ab e0 74 0f ee 8a 98 5b f8 >..h.JB...t....[.< > 0000144 d7 80 f7 73 da a4 dd 16 5f 2e 18 48 f9 28 c7 7e >...s...._..H.(.~< > > Here is the UUID, at offset 168, as promised: > > 0000160 e9 07 5f bf 00 00 00 0a 35 38 35 32 64 36 32 36 >.._.....5852d626< > 0000176 2d 30 34 32 38 2d 34 33 38 32 2d 62 63 61 36 2d >-0428-4382-bca6-< > 0000192 63 30 34 33 35 30 35 35 39 63 65 62 00 00 00 00 >c04350559ceb....< > > These are the key slot descriptors: > > #0 (0x0ac71fe, l33t): > > 0000208 00 ac 71 f3 00 02 29 d4 58 a9 bb e9 4d 31 03 54 >..q...).X...M1.T< > [...] > > #1: > > 0000256 00 ac 71 f3 00 01 75 6c 41 fc a7 02 38 4d ff 6d >..q...ulA...8M.m< > [...] > > #2: > > 0000304 00 ac 71 f3 00 01 ac c6 cd 00 34 39 60 d3 0b d3 >..q.......49`...< > 0000320 d8 c5 b6 72 b3 a1 cd 01 77 a8 d4 84 0e bf 67 5c >...r....w.....g\< > 0000336 c2 73 b2 7e b7 ca de 75 00 00 01 08 00 00 0f a0 >.s.~...u........< > > 0x01acc6 iterations, salt is cd 00 34 39 [...] ca de 75, key material > in sector 0x108 (264). > > #3-#7 are unused: > > 0000352 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 >................< > [...] > 0000592 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< > > The phdr ends here. > > So let's see sector 264. I suppose sectors are numbered from 0? In > that case, skipping 0 yields the 0th sector, skipping 1 the 1st and so > on, so I need to skip 264 to see the 264th: > > dd if=/dev/md42 bs=512 skip=264 count=1 | od -A x -tx1z > > 000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< > * > 000200 > [...] > > Empty. > > The RAID5 array used a chunksize of 64k, which means that sectors > 0-127 were on disk 0, sectors 128-255 on disk 1, sectors 256-383 on > disk 3; disk 4 contained a parity block for these; and sectors 384-511 > were on disk 0 again. Sector 264 is at the beginning of disk3 and was > thus overwritten with a RAID superblock. > > That means that the offsets from the FAQ don't apply to my LUKS > container and that keyslot #2 has been wiped after all. > > However, in this case, keyslot #0 should still be intact. Its key > material started in sector 8 (according to luksDump), which is not > empty. The RAID superblock on disk 1 got written to 4k from its start, > which is 8 sectors, thus 128+8=136, the offset of the key material for > keyslot #1. > > By all accounts, keyslot #0 is fine after all, having been narrowly > missed by mdadm (and dumping it shows no zeroed sections). > > And indeed it is! I could luksOpen it. I had been mistyping the > passphrase all this time. :) > > Thanks! > > Andras > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
