Linux - accidentally used dd on a LUKS encrypted drive, is there a way to recover?
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?
Solution 1:
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.