recovering LUKS partition

[BinaryMn]

I've been trying to resize (grow) a LUKS partition on, in my case, /dev/sda7. Help suggested in another thread on this forum resulted in cryptsetup no longer recognizing the partition as a LUKS device. In essence, I've lost everything currently.

All I did was delete the partition with fdisk, then recreate the partition with the same start cylinder with the end cylinder being a little farther down the drive because of the extra space I was adding to the partition. I haven't formatted or tried putting another filesystem over where I had the LUKS partition.

I've tried recreating the partition with fdisk using the original start and end cylinders, but the block size is different and still isn't being recognized as a LUKS device. I'm currently running testdisk for the third time hoping it'll find the missing partition.

Please help.

[frostschutz]

What does hexdump on the partition in question give you? For LUKS it should look similar to this:

hexdump -C -n 512 /dev/sdb13
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  78 74 73 2d 70 6c 61 69  |........xts-plai|
00000030  6e 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |n...............|
00000040  00 00 00 00 00 00 00 00  73 68 61 32 35 36 00 00  |........sha256..|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

If it doesn't look like that (starting with LUKS followed by the cipher names) then the partition is not in the same start place, or the LUKS header was overwritten. Without LUKS header the chances of rescue are zero so you better find it...

You can obtain possible byte positions of the LUKS header using grep on main the disk device:

grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdb

However since the search string is only 6 bytes this can also yield random false matches. So take a closer look at those byte positions to see if it's actually a complete header, and then see if you can create a partition that starts exactly there, or simply set up a loop device with an offset. If you can open the LUKS container, be sure to mount filesystems in there as read only, and pull a backup first before doing anything else.

[BinaryMn]

For anyone that wants to help, here's what fdisk -l looks like before I deleted the partitions. Note that sda8 is an empty partition.

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf8abaa97

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1             285       25924   205941760    5  Extended
/dev/sda2   *       25924       30402    35971072    7  HPFS/NTFS
/dev/sda3               1         285     2284544    b  W95 FAT32
Partition 3 does not end on cylinder boundary.
/dev/sda5           19151       25923    54403072    7  HPFS/NTFS
/dev/sda6           17838       19150    10546176   83  Linux
/dev/sda7             285       17582   138939392   83  Linux
/dev/sda8           17582       17837     2048000   83  Linux

This is what it looks like now.

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf8abaa97

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1             285       25924   205941760    5  Extended
/dev/sda2   *       25924       30402    35971072    7  HPFS/NTFS
/dev/sda3               1         285     2284544    b  W95 FAT32
Partition 3 does not end on cylinder boundary.
/dev/sda5           19151       25923    54403072    7  HPFS/NTFS
/dev/sda6           17838       19150    10546176   83  Linux
/dev/sda7             285       17582   138941815+  83  Linux

[BinaryMn]

What does hexdump on the partition in question give you? For LUKS it should look similar to this:

hexdump -C -n 512 /dev/sdb13
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  78 74 73 2d 70 6c 61 69  |........xts-plai|
00000030  6e 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |n...............|
00000040  00 00 00 00 00 00 00 00  73 68 61 32 35 36 00 00  |........sha256..|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

If it doesn't look like that (starting with LUKS followed by the cipher names) then the partition is not in the same start place, or the LUKS header was overwritten. Without LUKS header the chances of rescue are zero so you better find it...

You can obtain possible byte positions of the LUKS header using grep on main the disk device:

grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdb

However since the search string is only 6 bytes this can also yield random false matches. So take a closer look at those byte positions to see if it's actually a complete header, and then see if you can create a partition that starts exactly there, or simply set up a loop device with an offset. If you can open the LUKS container, be sure to mount filesystems in there as read only, and pull a backup first before doing anything else.

root@ubuntu:/home/ubuntu# hexdump -C /dev/sda7 | grep LUKS
000f8200  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|

Looks like something is still there. Thanks for the help.

[frostschutz]

Hope that's not bad news, because if the LUKS header is in the correct place but you can't open it, then there's something wrong with the header later on or your passphrase is wrong.

What error message do you get?

[BinaryMn]

Hope that's not bad news, because if the LUKS header is in the correct place but you can't open it, then there's something wrong with the header later on or your passphrase is wrong.

What error message do you get?

My header isn't in the first 512 bytes of the partition. Look at the hex address. The header is there, but in the wrong location. Maybe it's because cylinder 285 is also where an extended partition starts. However, to answer your question.

root@ubuntu:/home/ubuntu# sudo cryptsetup --verbose luksOpen /dev/sda7 sda7_crypt
Command failed with code 22: /dev/sda7 is not a LUKS device

[BinaryMn]

Making progress.

root@ubuntu:/home/ubuntu# mount -o loop,offset=0x000f8200 /dev/sda7 /media/test
mount: unknown filesystem type 'crypto_LUKS'

[frostschutz]

Eh, whoops, completely missed that in your hexdump output

So that's great news since it should work once you have it in the correct place.

So with a loop device it could be something like:

losetup -o 0xf8200 -r -f /dev/sda7
losetup -a
/dev/loop0: (/dev/sda7), offset 1016320
cryptsetup luksOpen /dev/loop0 luksrecover
mount -o ro /dev/mapper/luksrecover /mnt/recover

As for moving the partition to the correct place, try your luck with sfdisk (dump into a text file with byte/sector unit, edit a copy of the text file, and change the position accordingly, and try to restore that)

[BinaryMn]

I've been trying something like that already, but losetup isn't liking the offset. Instead of starting the offset at 0xf8200 or 0x000f8200, it keeps starting the offset at 000000f0.

Got any other ideas?

[bodhi.zazen]

All I did was delete the partition with fdisk, then recreate the partition with the same start cylinder with the end cylinder being a little farther down the drive because of the extra space I was adding to the partition. I haven't formatted or tried putting another filesystem over where I had the LUKS partition.

First, stop do not panic, and think

fdisk does not over write data, simply re-run fdisk and undo the changes you made and all should be well again.