Hi,
I have a problem accessing my data, I have backups but I try to understand what
happened so it does not happen again. So maybe you can help me to understand the
problem I am faced with.
I run a mdadm-software-raid6 across 4x 1TB sata disks resulting in a ~2TB
/dev/md0. This md0 is consistent and never had issues.
Unfortunately I can't remember anymore what I did above md0. I used it for years
and the cryped volume just did appear in my ubuntu gnome panel and I just had to
click on it, enter the luks passwort, then got another sudo request for mounting
the fs and the data was mounted. I will better document the createion this time
so I remember it later.
Now my initial problem was that the icon for the crypted volume did not appear
in gnome panel anymore. I don't think I lvm'ed md0 - this is because I looked
into /etc/lvm/archive+backup and found no reference to a volume group or logical
volume. I am unsure if I did put a partition table ontop md0, I assume not.
So assuming I did just run the cryptsetup create against /dev/md0 and ubuntu re-
recognized it after each boot based on the luks header - the luks header should
have been at offset 0 - right?
I inspected the md0 device and found:
- no partition table but random data
- no lvm metadata
- intact luks header at offset 65536 (0x10000)
I cant get any clue out of the first 64 byte of md0 - it just looks like random
data when I "hexdump -C" it. At least I found no ASCII data I would recognize as
something like partition table of lvm metadata.
So I created a loopback device for md0 starting at offset 0x10000 and luksDump
is able to analyze the header:
# losetup -v -o 65536 -r /dev/loop0 /dev/md0
# cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0
Version: 1
Cipher name: aes
Cipher mode: xts-plain
Hash spec: sha1
Payload offset: 4040
MK bits: 512
MK digest: 4b 00 fa c4 2b af 2e 0d 66 8f 42 34 c0 de 76 b4 31 4b a4 2f
MK salt: 4e 08 49 1d 66 11 f2 a2 d3 0b 8a 73 50 cf 8f 35
58 38 e1 1d ea a4 23 1a bc 72 50 4b e0 49 25 2c
MK iterations: 10
UUID: 2f8f3b39-6b74-4c0d-85fe-522e7850674d
Key Slot 0: ENABLED
Iterations: 299227
Salt: 69 fe 1c 07 3b 90 40 70 a7 55 85 45 9a 14 07 aa
fd d9 6d a1 14 fb aa 74 9f 3f 0b 43 17 2e b8 ee
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
However, if I use luksOpen it does not accept my password. I am 100% sure that
the password I enter is the one I used in advance to the problem to decrypt the
disk.
The md0 looks like this:
# fdisk -l /dev/md0
Disk /dev/md0: 2000.4 GB, 2000409591808 bytes
2 heads, 4 sectors/track, 488381248 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 65536 bytes / 131072 bytes
Disk identifier: 0x8539aa5e
Disk /dev/md0 doesn't contain a valid partition table
Depending on the fact that the first 64k look random and the 2nd 64k are the
luks header - I just tried to swapt block1 and block2:
# dd if=/dev/md0 of=/tmp/b1 bs=65536 count=1
# dd if=/dev/md0 of=/tmp/b2 bs=65536 skip=1 count=1
# dd if=/dev/md0 of=/tmp/b3-100 bs=65536 skip=2 count=98
# cat /tmp/b2 /tmp/b1 /tmp/b3-100 >>/tmp/b1-100_reordered
# losetup -v /dev/loop1 /tmp/b1-100_reordered
# cryptsetup luksopen /dev/loop1 data
However, this still does not work.
Would it even be enough to have 99*64k behind the luks header to decrypt the FS?
Or what exact blocks would it need to for the IV calculations or decryption?
Is there a way to randomly try to decrypt specific blocks using the luksheader +
my well known password to check if it works or not?
Can you explain why my luks header is at offset 64k and why it may reject my
password on the offsetted loopback device?
Do you have any idea what might have happened?
thanks in advance
Ralf
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
