0

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

  • Please don’t add details to your question in comments;  edit your question to make it clearer and more complete. – Scott Nov 2 '18 at 1:06
  • Could try testdisk. Or photorec to recover files without dir. structure & probably no filenames. Did you search for how to recover ext4 overwrote first 2M? – Xen2050 Nov 2 '18 at 1:31
0

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.

  • Thanks for the help. I think the best option now is to recover the filesystem and copy the files into a new Kali install, like you said. This time I'll be sure to read STDOUT properly before overwriting parts of my partition. Can you also elaborate a bit more on using mke2fs and e2fsck? I could probably figure it out myself from the man pages, but I think it might be better to hear it from someone firsthand as well. – computer_geek64 Nov 2 '18 at 2:38
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.