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

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

[András Korn]

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

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

[Arno Wagner]

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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
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 

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

[Milan Broz]

On 08/27/2012 11:51 AM, András Korn wrote:

> That means that the offsets from the FAQ don't apply to my LUKS
> container and that keyslot #2 has been wiped after all.

Not sure if it is good idea to have these in FAQ, it depends on
key size. (But there are usually only 3 variants for 128,256 and 512bits).

I wonder adding this directly to luksDump would help?

Like
	...
        Key material offset:    8
	Key slot area offset:   0x1000 - 0x21000
	...

(here with padding, perhaps it is better print used area only without padding...)

Milan
p.s.
very nice description of successful recovery, congrats :)

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

[Arno Wagner]

On Mon, Aug 27, 2012 at 12:20:28PM +0200, Milan Broz wrote:
> On 08/27/2012 11:51 AM, Andr?s Korn wrote:
> 
> > That means that the offsets from the FAQ don't apply to my LUKS
> > container and that keyslot #2 has been wiped after all.
> 
> Not sure if it is good idea to have these in FAQ, it depends on
> key size. (But there are usually only 3 variants for 128,256 and 512bits).

I use 64 in "smalles possible LUKS container", but 64 is
basically always insecure today.
 
> I wonder adding this directly to luksDump would help?
> 
> Like
> 	...
>         Key material offset:    8
> 	Key slot area offset:   0x1000 - 0x21000
> 	...
> 
> (here with padding, perhaps it is better print used area only without padding...)

Best would be to dump where everything actually is, maybe
even with sector-numbers added and total size.

Then I can do one example in the FAQ (the one already there) and 
say that padding, offsets, different key-sizes and modes (XTS), 
different versions of cryptsetup on creation, etc. can all shift 
these and refer to luksDump. That would also cover all future 
changes.

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
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