[dm-crypt] some ideas for recovery?

Arno Wagner arno at wagner.name
Thu Aug 25 21:44:42 CEST 2011


On Thu, Aug 25, 2011 at 06:54:09PM +0200, Ralf Kaestner wrote:
> On Thu, Aug 25, 2011 at 3:49 PM, Milan Broz <mbroz at redhat.com> wrote:
> >
> > You should check that keyslot area is not damaged (you have only one
> keyslot active,
> > starting at sector 8 to sector 512 (iow 0x1000 - 0x40000 - if I am not
> mistaken).

0x1000-0x3f800 actually, as it is a bit less than 256kiB.
0x3f800-0x40000 is zero (or whatever was on disk before)
and the second keyslot starts at 0x40000. This just means
non-random data in 0x3f800-0x40000 is fine.

> > There should be "ranadom data", any non-random sequence in this aread
> means that
> > it was overwritten.
> 
> Hi Milan, thanks for your fast response. I got your point. I inspected the
> whole data in a bit more detail and its interesting:
> 
> 
> 00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00
>  |LUKS....aes.....| <-- this is actually offset 64k in regards to md0 (here
> 0 @ loop1 with offset 64k)
> ...
>    <-- LUKS header data
> 00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>  |................|
> *
>    <-- end of LUKS header
> 00001000  0b f9 97 1d e4 3e b1 91  6a 96 2e 54 4a 28 50 b9
>  |.....>..j..TJ(P.| <-- so here we start with keyslot1 0x1000-0x40000
> ...
> 0002fff0  21 46 ef b6 31 51 6b d5  c9 9e d2 77 27 53 b3 6e
>  |!F..1Qk....w'S.n| <-- everything looks normal random up to here, weird
> signature afterwards up to 0x40000

Not good. 

> 00030000  00 00 fd 29 30 00 fd 29  60 00 fd 29 3d e1 00 60
>  |...)0..)`..)=..`|
> 00030010  00 00 0f 00 00 00 00 00  00 00 00 00 00 60 98 6b
>  |.............`.k|
> 00030020  03 00 fd 29 33 00 fd 29  60 06 fd 29 00 9d 00 60
>  |...)3..)`..)...`|
> 00030030  00 00 09 00 00 00 00 00  00 00 00 00 00 60 1f db
>  |.............`..|
> 00030040  06 00 fd 29 36 00 fd 29  60 0c fd 29 00 9d 00 60
>  |...)6..)`..)...`|
> 00030050  00 00 09 00 00 00 00 00  00 00 00 00 00 60 ad 25
>  |.............`.%|
> 00030060  05 00 fd 29 35 00 fd 29  60 0a fd 29 00 9d 00 60
>  |...)5..)`..)...`|
> 00030070  00 00 09 00 00 00 00 00  00 00 00 00 00 60 dd d8
>  |.............`..|
> 00030080  0c 00 fd 29 3c 00 fd 29  60 18 fd 29 00 9d 00 60
>  |...)<..)`..)...`|
> 00030090  00 00 09 00 00 00 00 00  00 00 00 00 00 60 d1 23
>  |.............`.#|
> 000300a0  0f 00 fd 29 3f 00 fd 29  60 1e fd 29 00 9d 00 60
>  |...)?..)`..)...`|
> 000300b0  00 00 09 00 00 00 00 00  00 00 00 00 00 60 a1 de
>  |.............`..|
> 000300c0  0a 00 fd 29 3a 00 fd 29  60 14 fd 29 00 9d 00 60
>  |...):..)`..)...`|
> 000300d0  00 00 09 00 00 00 00 00  00 00 00 00 00 60 13 20  |.............`.
> |
> 000300e0  09 00 fd 29 39 00 fd 29  60 12 fd 29 00 9d 00 60
>  |...)9..)`..)...`|
> 000300f0  00 00 09 00 00 00 00 00  00 00 00 00 00 60 63 dd
>  |.............`c.|
> 00030100  18 00 fd 29 28 00 fd 29  60 30 fd 29 00 9d 00 60
>  |...)(..)`0.)...`|
> 00030110  00 00 09 00 00 00 00 00  00 00 00 00 00 60 0e 2c
>  |.............`.,|
> 00030120  1b 00 fd 29 2b 00 fd 29  60 36 fd 29 00 9d 00 60
>  |...)+..)`6.)...`|
> 00030130  00 00 09 00 00 00 00 00  00 00 00 00 00 60 7e d1
>  |.............`~.|
> 00030140  1e 00 fd 29 2e 00 fd 29  60 3c fd 29 00 9d 00 60
>  |...)...)`<.)...`|
> 00030150  00 00 09 00 00 00 00 00  00 00 00 00 00 60 cc 2f
>  |.............`./|
> 00030160  1d 00 fd 29 2d 00 fd 29  60 3a fd 29 00 9d 00 60
>  |...)-..)`:.)...`|
> 00030170  00 00 09 00 00 00 00 00  00 00 00 00 00 60 bc d2
>  |.............`..|
> 00030180  14 00 fd 29 24 00 fd 29  60 28 fd 29 00 9d 00 60
>  |...)$..)`(.)...`|
> ...
>    <-- similar signature as above
> 0003ffe0  11 00 b5 3d 21 00 b5 3d  60 22 b5 3d 00 9d 00 60
>  |...=!..=`".=...`| <-- end of weird signature
> 0003fff0  00 00 09 00 00 00 00 00  00 00 00 00 00 60 88 87
>  |.............`..| <-- end of keyslot 1
> 00040000  00 00 a0 13 10 00 a0 13  20 00 a0 13 e0 5f 00 20  |........ ...._.
> |
> 00040010  00 00 05 00 00 00 00 00  00 00 00 00 00 20 07 09  |.............
> ..|
> 00040020  01 00 a0 13 11 00 a0 13  20 02 a0 13 00 80 00 20  |........ ......
> |
> 00040030  00 00 07 00 00 00 00 00  00 00 00 00 00 20 7a 92  |.............
> z.|
> 
> interestingly keyslot1 looks good up to 0x2FFFF (3x64k from start of LUKS
> header) which leaves 64k garbage at the end of keyslot1 up to 0x40000 where
> keyslot2 starts.
> However, the garbage signature changes at 0x3fff0 even before the end of
> keyslot1
> 
> So I tried to put the md0 initial 64k random data into the 64k gap area of
> keyslot1
> 
> # dd if=/dev/md0 of=/tmp/01_luksdata1 bs=64k skip=1 count=3
> # dd if=/dev/md0 of=/tmp/02_initial_64k bs=64k count=1
> # dd if=/dev/md0 of=/tmp/03_luksdata2_data bs=64k skip=5 count=100
> # cat 01_luksdata1 02_initial_64k 03_luks_leftover >04_rebuild
> # losetup -v /dev/loop1 /tmp/04_rebuild
> 
> but if does not accept my password anyways. So I assume keyslot1 is gone
> forever.

It is. A signle changes bit makes it unreadable. That is the
whole point.

> Still totally unclear to me how this could have happened.

I agree. 

First, I think the 64k offset are some additional
LVM wrapping or the like and have nothing to do with the 
corruption.

The question then becomes what is in this changed area.
It looks a bit like filesystem management data.
The offset of 0x30000 = 196kiB seems to indicate something
non-random. Could also be 128kiB offset, if the problem
was affected by the 64kiB shift.

This does not look like something from an empty FAT32
or ext2 filesystem. Maybe a 32 bit entry color-table?
Definietly some kind of table, but I have no idea 
what type.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno at wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 


More information about the dm-crypt mailing list