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
  • 7
  • 1
    I think it would be far simpler to just recover from your backup. The trouble with overwriting the beginning of a drive is that's where the directory structure was. TestDisk/PhotoRec can't scavenge that data because it can't recognise anything, it's encrypted. – Tetsujin Jul 15 '21 at 15:51
  • This is the sad part - the only files I really need are the last few config files I pulled from a server that got nuked, and those weren't backed up anywhere else yet. I'm willing to jump through many hoops to recover the data. – circo Jul 15 '21 at 15:55
  • 1
    Do you get any results from `head -c 1G /dev/sda | hexdump -C | grep LUKS`? – u1686_grawity Jul 15 '21 at 16:04
  • @user1686 I've added the output of it into the question with formatting. – circo Jul 15 '21 at 16:07
  • 1
    Unfortunately it doesn't have the specific result that I was hoping for (the beginning of the actual LUKS header)... Any luck with e.g. `head -c 4G`? – u1686_grawity Jul 15 '21 at 16:10
  • Exact same output as before – circo Jul 15 '21 at 16:14
  • 1
    Sounds very much like the beginning of your `/` LUKS volume (the header storing the actual decryption keys) was in those 338 MB that you've overwritten, and your separate /boot either wasn't large enough to save you or didn't exist. – u1686_grawity Jul 15 '21 at 17:41
  • There is duplicated metadata in the LUKS2 spec, specifically for this purpose (corrupted metadata). You might want to check that out. – jrw32982 Jul 19 '21 at 21:31

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
  • 69,815
  • 22
  • 136
  • 202
Maxim Fomin
  • 86
  • 4
  • I think you missed the purpose of the 'grep'. The actual LUKS header, if it still existed, would also have the bytes `LUKS` at the beginning of a sector. – u1686_grawity Jul 15 '21 at 17:55
  • Yes, if LUKS header existed, it would have been shown. I wanted to say that 'LUKS.mod' is grub data, not LUKS header. – Maxim Fomin Jul 15 '21 at 17:57
  • For what it's worth, this kind of full disk encryption design is extremely irresponsible. Unless you have the specific goal of "failing closed" on any kind of destruction/corruption (and the appropriate backup infrastructure to make that reasonable), the **actual key** used to encrypt the data should always be something in the user's possession, that they can backup (hopefully protected by a passphrase still) offline. – R.. GitHub STOP HELPING ICE Jul 16 '21 at 00:42
  • 2
    R.., it seems you are not familiar with LUKS/cryptsetup. The actual key can be extracted with specific cryptsetup command. However, knowing master key voids the LUKS header - its single purpose (except keeping some additional technical information) is to keep master key in secret. If master key is known, the LUKS encryption essentially reduces to plain mode (user password). Regarding saving master key - it can be saved as part of LUKS header, cryptsetup has an option to backup the header which should be done in advance. The documentation of LUKS mentions it in the beginning. – Maxim Fomin Jul 16 '21 at 05:04
  • @R..GitHubSTOPHELPINGICE If actual encryption key were derived from the passphrase, then changing the passphrase would require re-encrypting the entire drive. Which would likely be a potentially dangerous (if its stopped, the drive will be encrypted with two different keys) multi-day operation (it takes a long time to re-write an entire 8TB HDD). – derobert Jul 21 '21 at 18:11
  • @derobert: It can be done incrementally, having both keys live until it finishes. – R.. GitHub STOP HELPING ICE Jul 21 '21 at 22:27
  • @MaximFomin: Clearly users who are being offered the option (or even default) to use LUKS at install time *also aren't aware* of how it works, in a way that's dangerous. – R.. GitHub STOP HELPING ICE Jul 21 '21 at 22:28
  • @R..GitHubSTOPHELPINGICE LUKS v2 (although released quite recently - in 2020) supports reencryption. Regarding user awareness - LUKS maintaners made efforts to write solid documentation, it contains in the beginning a large warning about backup, storage media and LUKS header. Resposible users at least skim documentation when they do important thing like partitioning. LUKS maintainers cannot help those users which type random commands from the web. There is simply no way to 'put idea about LUKS header backup in mind' of those users, how do not read documentation/manuals/articles in the web. – Maxim Fomin Jul 22 '21 at 05:47
  • @MaximFomin: I don't so much blame the LUKS maintainers as the distro installer that didn't make the risks clear. – R.. GitHub STOP HELPING ICE Jul 22 '21 at 23:43