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@xxxxxxxxxx> 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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
