[SOLVED] Recovering a deleted partition table of a LUKS encrypted flash drive

b92kvmomim · 05-17-2017, 06:43 PM

I have a flash drive encrypted with dm-crypt and LUKS. A while back I was messing around with it using testdisk and ended up deleting the partition table stored in the MBR.

AFAIK, there were two partitions stored on this USB, the LUKS partition and the encrypted partition. I've tried to relocate the partitions using testdisk, configured to search with various common CHS values, but I haven't found any partitions on the USB. This doesn't make sense to me as the partition headers shouldn't be encrypted right?

When this flash drive was working, whenever I'd plug it in to my Ubuntu machine, a GUI requesting a password to decrypt the drive would open. It doesn't anymore, which leads me to believe that because of the missing table, it's not booting to the flash drive's partition that it should be.

When I run this command,

Code:

if=/dev/sdf | hexdump -C | grep LUKS

I get the following output:

Code:

0001ea00  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|

Also, cryptsetup doesn't even recognize it as being encrypted...

Code:

sudo cryptsetup luksOpen /dev/sdb test

Code:

Device /dev/sdb is not a valid LUKS device.

I'm completely lost as to how I'm supposed to recover the partition table. Is it even possible? Do you guys have any tools/recommendations on how I should go about it?

AwesomeMachine · 05-17-2017, 06:51 PM

Give us the output of

Code:

$ fdisk -l /dev/sdf

and

Code:

$ dd if=/dev/sdf count=1 | hexdump -C

b92kvmomim · 05-17-2017, 07:12 PM

Quote:

Originally Posted by AwesomeMachine

Give us the output of

Code:

$ fdisk -l /dev/sdf

and

Code:

$ dd if=/dev/sdf count=1 | hexdump -C

Code:

Disk /dev/sdb: 977.5 MiB, 1024966656 bytes, 2001888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

For the MBR, it's loaded with a default/misconfigured TestDisk partition table.

Code:

00000000  fc 31 c0 8e d0 31 e4 8e  d8 8e c0 be 00 7c bf 00  |.1...1.......|..|
00000010  06 b9 00 01 f3 a5 be ee  07 b0 08 ea 20 06 00 00  |............ ...|
1+0 records in
1+0 records out
00000020  80 3e b3 07 ff 75 04 88  16 b3 07 80 3c 00 74 04  |.>...u......<.t.|
00000030  08 06 af 07 83 ee 10 d0  e8 73 f0 90 90 90 90 90  |.........s......|
512 bytes copied, 0.0018693 s, 274 kB/s
00000040  90 90 90 90 90 90 90 90  90 90 90 90 90 90 90 90  |................|
*
00000070  90 90 90 90 90 90 90 90  90 90 90 90 90 90 be be  |................|
00000080  07 b0 00 b9 04 00 80 3c  00 75 6e fe c0 83 c6 10  |.......<.un.....|
00000090  e2 f4 31 db b4 0e be 9d  07 8a 0e af 07 ac d0 e9  |..1.............|
000000a0  73 02 cd 10 08 c9 75 f5  b0 3a cd 10 31 c0 cd 16  |s.....u..:..1...|
000000b0  3c 00 74 f8 be 8b 07 b9  02 00 e8 ba 00 3c 0d 74  |<.t..........<.t|
000000c0  b4 3c 61 72 06 3c 7a 77  02 2c 20 88 c3 be 9d 07  |.<ar.<zw., .....|
000000d0  8a 0e af 07 ac d0 e9 73  04 38 c3 74 06 08 c9 75  |.......s.8.t...u|
000000e0  f3 eb af b8 0d 0e 31 db  cd 10 8d 84 62 00 3c 07  |......1.....b.<.|
000000f0  75 07 b0 1f a2 af 07 eb  99 31 d2 b9 01 00 3c 04  |u........1....<.|
00000100  74 11 73 f3 30 e4 b1 04  d2 e0 be be 07 01 c6 8a  |t.s.0...........|
00000110  16 b3 07 bf 05 00 56 f6  c2 80 74 31 b4 41 bb aa  |......V...t1.A..|
00000120  55 52 cd 13 5a 5e 56 72  1e 81 fb 55 aa 75 18 f6  |UR..Z^Vr...U.u..|
00000130  c1 01 74 13 8b 44 08 8b  5c 0a be 8d 07 89 44 08  |..t..D..\.....D.|
00000140  89 5c 0a b4 42 eb 0c 8a  74 01 8b 4c 02 b8 01 02  |.\..B...t..L....|
00000150  bb 00 7c 50 c6 06 8f 07  01 cd 13 58 5e 73 05 4f  |..|P.......X^s.O|
00000160  75 b4 eb 93 81 3e fe 7d  55 aa 75 f6 ea 00 7c 00  |u....>.}U.u...|.|
00000170  00 be 83 07 b9 0a 00 50  b4 0e 31 db ac cd 10 e2  |.......P..1.....|
00000180  fb 58 c3 54 65 73 74 44  69 73 6b 0d 0a 10 00 01  |.X.TestDisk.....|
00000190  00 00 7c 00 00 00 00 00  00 00 00 00 00 31 32 33  |..|..........123|
000001a0  34 46 00 00 41 4e 44 54  6d 62 72 00 02 02 02 1f  |4F..ANDTmbr.....|
000001b0  c7 00 00 80 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

syg00 · 05-17-2017, 07:30 PM

As you were "messing around" with this, the data obviously has no value, so why not just scrub it and start again ?.
Yes, I am serious. If you didn't consider it worthwhile protecting, why should anyone else ?.

In all likelihood there was only one partition on the device. If not, hopefully it was first. Simply allocate a partition over the entire device then try the luksopen.

b92kvmomim · 05-17-2017, 07:48 PM

Quote:

Originally Posted by syg00

As you were "messing around" with this, the data obviously has no value, so why not just scrub it and start again ?.
Yes, I am serious. If you didn't consider it worthwhile protecting, why should anyone else ?.

In all likelihood there was only one partition on the device. If not, hopefully it was first. Simply allocate a partition over the entire device then try the luksopen.

I guess I'm an idiot for not backing up an image of the drive before writing to the MBR. Didn't know what I was doing at the time. It's kind of important that I don't scrub the drive because I need to recover some deleted files on it.

Is there an easy way of allocating a partition without wiping the drive? I'll be googling around in the meantime.

syg00 · 05-17-2017, 08:28 PM

The partition table is entirely contained within that sector you printed above. It only defines the extent of the partition - so long as you only define primary partition(s) you will not affect any data on the drive. Use fdisk/[g]parted/whatever.

If you used the entire device initially (rather than a partition) for your luks container your ability to access your data is probably already gone.

rknichols · 05-17-2017, 09:38 PM

Quote:

Originally Posted by b92kvmomim

When I run this command,

Code:

if=/dev/sdf | hexdump -C | grep LUKS

I get the following output:

Code:

0001ea00  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|

Also, cryptsetup doesn't even recognize it as being encrypted...

Code:

sudo cryptsetup luksOpen /dev/sdb test

Code:

Device /dev/sdb is not a valid LUKS device.

Which device is it, "/dev/sdb" or "/dev/sdf"? Anyway, your LUKS partition starts at sector 245 (0x0001ea00 / 512). Use fdisk to create a partition starting at that sector and extending to the end of the device, and you should then be able to luksOopen partition 1 of that device.

b92kvmomim · 05-17-2017, 10:47 PM

Quote:

Originally Posted by rknichols

Which device is it, "/dev/sdb" or "/dev/sdf"? Anyway, your LUKS partition starts at sector 245 (0x0001ea00 / 512). Use fdisk to create a partition starting at that sector and extending to the end of the device, and you should then be able to luksOopen partition 1 of that device.

Woops, /dev/sdb. The /dev/sdf was copied pasted from a stackoverflow post.

I will try this out.

However, syg00 says:

Quote:

Originally Posted by syg00

The partition table is entirely contained within that sector you printed above. It only defines the extent of the partition - so long as you only define primary partition(s) you will not affect any data on the drive. Use fdisk/[g]parted/whatever.

If you used the entire device initially (rather than a partition) for your luks container your ability to access your data is probably already gone.

So it seems that in my case I did not use the entire device as my LUKS container then.

b92kvmomim · 05-17-2017, 11:05 PM

Quote:

Originally Posted by rknichols

Which device is it, "/dev/sdb" or "/dev/sdf"? Anyway, your LUKS partition starts at sector 245 (0x0001ea00 / 512). Use fdisk to create a partition starting at that sector and extending to the end of the device, and you should then be able to luksOopen partition 1 of that device.

Worked. It now prompts me to enter in the password when the USB plugs in.

However, it outputs this: Error unlocking /dev/sdc1: Command-line `cryptsetup luksOpen "/dev/sdc1" "luks-45fee85d-06c9-46c7-8c7a-39479056f3f7" ' exited with non-zero exit status 5: Device luks-45fee85d-06c9-46c7-8c7a-39479056f3f7 already exists.

I will try mounting via the command line.

EDIT:
Removed mappings and it mounts!

THANK YOU GUYS.

@rknichols, can you explain how this works? I was under the impression that there's supposed to be a LUKS partition separated from the encrypted partition. My other hard drive also encrypted with LUKS, with a screwed up partition table, has a LUKS partition separate from the encrypted one. On boot, GRUB boots into that partition, which prompts for a password, and then, from what I believe, it mounts the encrypted partition. Is this not how the flash drive is structured?

rknichols · 05-18-2017, 08:26 AM

Quote:

Originally Posted by b92kvmomim

I was under the impression that there's supposed to be a LUKS partition separated from the encrypted partition. My other hard drive also encrypted with LUKS, with a screwed up partition table, has a LUKS partition separate from the encrypted one. On boot, GRUB boots into that partition, which prompts for a password, and then, from what I believe, it mounts the encrypted partition. Is this not how the flash drive is structured?

I really don't understand what you mean. A LUKS partition is an encrypted partition. The partition has a LUKS header at the beginning, and that is followed by encrypted data (which is usually a filesystem, but could be anything). Yes, you can have an encrypted partition that is not LUKS, but you have to know what you are doing to set that up, and unlocking such a partition requires not only the key but also all the other parameters of the cipher.

The output from "lsblk -f" would be helpful.

syg00 · 05-18-2017, 08:42 AM

You define a luks container on a partition - then you mkfs. Might be confusing.
From the OP questions, I suspect a (unencrypted) /boot was defined prior to the luks container. After all, sector 245 is a bit oddball.

rknichols · 05-18-2017, 09:35 AM

Quote:

Originally Posted by syg00

After all, sector 245 is a bit oddball.

Indeed! That's why testdisk wasn't finding it. Even when you go into the "Options" menu and select "Align partitions: no", it still looks for structures only on megabyte or "cylinder" boundaries. You have to select a partition table type of "None" to get around that, and then of course you can't have it write out the partitioning it discovers. That behavior, plus testdisk's unwavering devotion to CHS geometry, are my biggest complaints about it.