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

András Korn korn.andras at gmail.com
Sun Aug 26 22:51:59 CEST 2012


On Sun, Aug 26, 2012 at 5:45 PM, András Korn <korn.andras at gmail.com> wrote:
>>> Therefore, the third keyslot should still be intact.
>>>
>>> Now, how do I get to it?
>>
>> Ah. Use the info in the FAQ and RAID geometry to extract it, and
>> place it in a file (starting with the intact header) at the correct
>> offset.
>
> O-kaaaaay... I'll try that and come back if I have specific questions.

Well. Based on the FAQ, the first keyslot should be at offset 0x1000,
and sure enough, there is some data there:

000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00  >LUKS....aes.....<
000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
000020 00 00 00 00 00 00 00 00 63 62 63 2d 65 73 73 69  >........cbc-essi<
000030 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00  >v:sha256........<
000040 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00  >........sha1....<
[...]
000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
001000 e7 82 83 cd a1 51 35 e6 60 bc bb aa d8 74 a6 31  >.....Q5.`....t.1<
001010 17 e7 f0 a8 f9 f2 b6 5e 19 db 22 69 69 ef 23 b6  >.......^.."ii.#.<

However, the 2nd key block should be at 0x21000, but there is nothing there:

0020ff0 0c 05 02 02 01 01 00 00 fe fc e6 eb 00 0d 01 01  >................<
021000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
021200 69 3b 84 eb 78 96 66 31 29 02 99 1b 9c e0 b3 2e  >i;..x.f1).......<

This is plausible as this is where the RAID superblock got written to.
To recap, this is what the RAID5 layout looks like:

D0 D1 D2 P0
D4 D5 P1 D3
D8 P2 D6 D7
P3 D9 D10 D11

0x21000 is 2x64k+4k, so we're looking at the RAID5 superblock in D2 (I
suppose it's all zeroes because mdadm zeroed it when I re-created the
array with 0.90 metadata, to avoid confusing itself with the 1.2
metadata that would've been in this superblock).

Looking further, where key slot #2 (the third one) should be, there
are also only zeroes:

040000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
050000 00 1d ff 01 00 00 02 06 01 00 ff fe fc fd fe fd  >................<

Now, 0x40000 is 4x64k, so this should be in D4, which should be intact.

This is the data I read both from the reconstructed RAID5 array as
well as from a file created by concatenating the 64k chunks from the
RAID5 disks in the correct order. I also explicitly checked the 2nd
64k block of original RAID5 drive #0, which is D4. It's all zeroes.
luksDump says keyslot 3 is in use, which is correct to the best of my
knowledge. Where is the key? This drive, the one I'm reading the
all-zero 64k chunk from, was unaffected by my mdadm --create (in all
experiments, I used a copy).

According to the FAQ, the 2nd 64k block on this drive shouldn't be all zeroes.

This is an old LUKS device (version 1). Could the offsets be different?

Andras


More information about the dm-crypt mailing list