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
