6

I accidentally ran dd bs=4M if=image.iso of=/dev/sda oflag=sync when creating a bootable drive instead of targeting the USB stick.

I am fairly certain most of the files would be fine - the iso is only ~330mb, while the drive is 500gb.

The problem is, that /dev/sda was encrypted during the installation of manjaro, so tools like photorec and the likes cannot access the files. I am also unsure how the drive being encrypted would interfere with the data being overwritten by dd.

lsblk's output shows the new partition table:

sda      8:0    0 465.8G  0 disk 
├─sda1   8:1    0   336M  0 part 
└─sda2   8:2    0   2.4M  0 part

fdisk -l shows the same thing:

Device     Boot Start    End Sectors  Size Id Type
/dev/sda1  *        0 688127  688128  336M  0 Empty
/dev/sda2        3820   8747    4928  2.4M ef EFI (FAT-12/16/32)

/dev/mapper/ has only control in it, no sign of the luks partition:

lubuntu@lubuntu:/dev/mapper$ ls 
control

Unfortunately, I don't know for sure what the old partition table was. I know that I had 12gb of swap at the end of the drive, I only used a single partition for / and didn't manually separate anything else, /dev/sda3/ was mounted to /, and I'm somewhat certain that /boot was separate by default, but that's about all that I know.

I've tried using TestDisk, but the output of deep search didn't seem to line up with what I had, and I didn't want to make things worse:

Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63
     Partition               Start        End    Size in sectors
>* FAT12                    0  60 41     0 138 54       4928 [NO NAME]
 D Linux                   38 127 26 60801  15 14  976150528
 D Linux Swap           59317 172 56 60801  80 15   23834624

The output of head -c 1G /dev/sda | hexdump -C | grep LUKS is:

# head -c 1G /dev/sda | hexdump -C | grep LUKS
00011110  0a 4c 55 4b 53 2e 4d 4f  44 3b 31 00 50 58 24 01  |.LUKS.MOD;1.PX$.|
004346a0  64 65 6e 69 65 64 00 4c  55 4b 53 ba be 00 25 73  |denied.LUKS...%s|
00b394a0  64 65 6e 69 65 64 00 4c  55 4b 53 ba be 00 25 73  |denied.LUKS...%s|

Is there any hope of recovering the data?

circo
  • 161

1 Answers1

6

There is no hope in recovering LUKS container if there is no LUKS header backup.

Frankly, the answer is contained in the first sentence, but I can provide more information to explain the situation. LUKS encryption explaining simply works the following way: some initial MB (actual size depends on LUKS version and configuration) of partition are allocated for LUKS header, and the rest of the partition - for the data (root partition, or home partition, etc). The LUKS header 'contains' the 'master' password which is used to encrypt the data. This master password is generated by LUKS (to be 'big' and 'strong') when partition is encrypted at first time. The master password is 'protected' by 'key slot password' - password which user actually types to decrypt the drive. In short, LUKS header contains master password which is protected by 'user' password. So, if LUKS header is gone, the master password is also gone, so there is no way to decrypt the data - even if you still know 'user' password.

Regarding 'LUKS.mod' output from grep - this looks like the name of grub LUKS.mod module stored in the FAT table of EFI partition. This output shows that the boot partition (which is usually unencrypted) happens to be in the first 1G of disk which you query with the command head -c 1G /dev/sda | hexdump -C | grep LUKS. This information does not help to solve the problem.

Kamil Maciorowski
  • 81,893
Maxim Fomin
  • 86
  • 4