Accidentally Restored LUKS Header on Regular Filesystem

Question

I am in really big trouble right now, so a VERY quick solution would be much appreciated. I was in an SSH session on my laptop that has LUKS encryption, and I thought I was restoring its header. But I realized later that I had actually SSH'd to my desktop and accidentally used the LUKS header backup file to restore on my desktop, which did not have any LUKS encryption. Now, I cannot boot into my filesystem at all. Is there any way I can retrieve my operating system, or at the very least my files? I also deleted tried to erase the header as soon as I realized, but it did not help, the header still remains, just all of they keys are disabled.

64-bit Kali Linux ext4 filesystem, dual-booted with Windows 10 partition The Kali Linux partition is the one that had the header accidentally overwritten.

The command I used that accidentally restored the header was: cryptsetup luksHeaderRestore /dev/sda5 --header-backup-file header.bak

Answer 1

You can probably recover almost everything, but if something goes wrong, you could find yourself worse off than you are right now.

The do-it-yourself option is to recover the filesystem from one of the backup superblocks:

1. Make a disk image of the damaged partition, and do all your work on this image. You'll need a hard drive with enough empty space to hold this disk image.
2. Use losetup to set up the image as a loopback device. This will give it a device name such as /dev/loop0.
3. Run mke2fs -n on the loopback device to figure out where the backup superblocks are. You're pretending to create a new filesystem here (the -n option), to get mke2fs to tell you where it would put things.
4. Run e2fsck -n -b <insert a superblock address here> on the loopback device with each of the backup superblock addresses in turn until you find one that works. Here, you're pretending to repair the filesystem (-n again) to see if it will work. Odds are, you'll be successful on the first try.
5. Re-run e2fsck on the loopback device, only without the -n option. This will repair the filesystem to the greatest degree possible.
6. Mount the loopback device as a filesystem, and see how bad the damage is.

Once you've done this, you've got two options: you can repeat the steps on the original filesystem, or you can copy the files you want off the image, erase the original filesytem, re-install Kali, and copy the recovered files onto it.

The safe option is to send your drive to a data-recovery company. They'll do basically the same steps as above, but since they're familiar with the procedure, they won't mess up. This will probably cost a few hundred dollars.

Answer 2

Mount has an option to try using a backup superblock (-o b=40961 for example), so a command with read-only plus one of your backup superblocks, like

mount -v -o ro,b=40961 /dev/sda5 mountpoint

might be worth a try, at least being read-only it shouldn't do any harm, and doesn't require a copy.

---

I tried creating a small (50M) ext4 filesystem, copying about 34M in 40 files to it, then overwriting the first 2M with zeros (the size of a luks backup header).

The e2fsck command (with & without trying all backup superblocks with -b) didn't recover any files. Maybe it was the small size and relatively large % that was overwritten, but even though it was now mountable, no files were there (even lost+found was empty). Another answer ( https://superuser.com/a/1044614/307834 ) says the file & directory list may have been overwritten, and evidently a backup superblock may not help.

However, Photorec was able to recover 33 of the 40 files (without filenames), 31 were identical though 2 were changed (md5 mismatch). Here's a link to step-by-step instructions. (It will show the backup superblocks too).

If you had a backup list of all the filenames and a hash (like md5 from find | md5sum or even crc32) it would be a lot easier to match the files back to their filenames. Of course, a backup of the files themselves is best - not all the system files, they can easily be downloaded & re-installed again, but just your personal data & files ($HOME?), and maybe some config files in /etc.

---

Anyway, if anyone's interested, here's some commands to create a small ext4 and break it & attempt recovery:

$ fallocate -l 50M 50

$ mke2fs -v -t ext4 -E lazy_itable_init=0,lazy_journal_init=0 50
mke2fs 1.43.4 (31-Jan-2017)
fs_types for mke2fs.conf resolution: 'ext4', 'small'
Discarding device blocks: done                            
Discard succeeded and will return 0s - skipping inode table wipe
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
12824 inodes, 51200 blocks
2560 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=33685504
7 block groups
8192 blocks per group, 8192 fragments per group
1832 inodes per group
Filesystem UUID: b42aef3d-4e2a-44c3-8bb1-967968f61e38
Superblock backups stored on blocks: 
        8193, 24577, 40961

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

$ sudo mount -v 50  /media/50
mount: /dev/loop1 mounted on /media/50.
$ cp -ar /usr/share/backgrounds /media/50/backgrounds # 40 files totaling 34M
$ sudo umount -v /media/50 
umount: /media/50 unmounted

Save an original "good" file to compare

$ cp -v 50 50-bak
'50' -> '50-bak'

Without the conv, dd just overwrites 50 with a zero filled 2M file

$ dd if=/dev/zero of=50 bs=1M count=2 conv=notrunc
2+0 records in
2+0 records out
2097152 bytes (2.1 MB, 2.0 MiB) copied, 0.00552528 s, 380 MB/s

Save a copy of the broken file, to retry later

$ cp -v 50 50-broken
'50' -> '50-broken'

Running "e2fsck 50" will "repair" the filesystem, but mounting reveals no recovered files

Get / double-check backup superblocks

$ mke2fs -n 50
mke2fs 1.43.4 (31-Jan-2017)
Creating filesystem with 51200 1k blocks and 12824 inodes
Filesystem UUID: 7a31ebab-ddc2-40a6-89f6-39ecc26578cc
Superblock backups stored on blocks: 
        8193, 24577, 40961

The e2fsck commands that should / might help:

$ e2fsck -v -b 40961 50
e2fsck 1.43.4 (31-Jan-2017)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** journal has been deleted ***

Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  Clear<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Root inode not allocated.  Allocate<y>? yes
/lost+found not found.  Create<y>? yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  +(1--1875) +1878 +(8193--8450) +(24577--24834) +(40961--41218)
Fix<y>? yes
Free blocks count wrong for group #0 (6301, counted=6314).
Fix<y>? yes
Free blocks count wrong for group #2 (4096, counted=8192).
Fix<y>? yes
Free blocks count wrong (44438, counted=48547).
Fix<y>? yes
Inode bitmap differences:  +1 +(3--10)
Fix<y>? yes
Free inodes count wrong for group #0 (1820, counted=1821).
Fix<y>? yes
Directories count wrong for group #0 (3, counted=2).
Fix<y>? yes
Free inodes count wrong (12812, counted=12813).
Fix<y>? yes
Recreate journal<y>? yes
Creating journal (4096 blocks):  Done.

*** journal has been regenerated ***

50: ***** FILE SYSTEM WAS MODIFIED *****

          11 inodes used (0.09%, out of 12824)
           0 non-contiguous files (0.0%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
        6749 blocks used (13.18%, out of 51200)
           0 bad blocks
           0 large files

           0 regular files
           0 directories
           0 character device files
           0 block device files
           0 fifos
           1 link
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
           1 file

Mounting still reveals no files recovered...
Try mounting directly with a backup superblock (-b) didn't work with any backup block

$ sudo mount -vo ro,b=40961 50 /media/50
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

# Nothing in syslog/dmesg.