Re: How to recover partially overwritten LUKS volume?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 26, 2012 at 5:45 PM, András Korn <korn.andras@xxxxxxxxx> 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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux