[dm-crypt] solved: Re: How to recover partially overwritten LUKS volume?

András Korn korn.andras at gmail.com
Mon Aug 27 11:51:59 CEST 2012


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


More information about the dm-crypt mailing list