0

I had a LUKS encrypted disk, with an atypical structure. The entire disk (3tb) was encrypted such that no secondary partition exists. Example /dev/sdb without a secondary /dev/sdb1. The disk was partitioned using ext4/GPT.

Windows 10 apparently doesn't know how to handle encounters with disks of this type and decided that it could overwrite the partition table, and first 100mb, just because the system sees this drive first before it sees the intended OS drive. This was done without explicit permission.

To my question and thank you for any help afforded ahead of time.

I have a backup of the LUKS header. I can restore the header, it accepts the passphrase but the internal disk structure does not produce viable data. It fails to mount. Testdisk produces numerous results on the internal structure of the LUKS encrypted disk. An example of the log file is below.

I'd like help to know if it is possible to restore the previous partition table without damaging anymore data? I've done some reading and it seems that just rewriting the partition table by hand may not work? If I repartition the drive it removes the header, and if I replace the header it affects the partition table.

Again any help is appreciated.

Log file excerpt

Disk /dev/mapper/sda - 3000 GB / 2794 GiB - 5860529072 sectors
block_group_nr 1
recover_EXT2: part_offset problem
block_group_nr 1
recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=1/22356, s_mnt_count=16/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 732566134
recover_EXT2: part_size 5860529072
Filesystem created: Wed Mar 22 01:44:28 2017
Last mount time:    Fri Mar 24 21:46:42 2017
     Linux filesys. data            0 5860529071 5860529072 [Movies]
     ext4 blocksize=4096 Large_file Sparse_SB Backup_SB, 3000 GB / 2794 GiB
Partition not added.
Vojtech Trefny
  • 16,922
  • 6
  • 24
  • 48
zmarti66
  • 1
  • It' not clear from the description if you were using partitions or not. Anyway, you don't have to rewrite the header. you can use cryptsetup's --header option to read the header from elsewhere (from the backup) – A.B Dec 10 '20 at 12:33
  • I used the whole disk see this page for reference: https://unix.stackexchange.com/questions/558481/encrypting-whole-disk-with-luks-instead-of-one-big-encrypted-partition I used crypsetup luksHeaderRestore to restore the header. I am not able to see the data after restoring the header. Are you suggesting that I try using the header file as a detached header? – zmarti66 Dec 10 '20 at 14:42
  • Yes detached header. As you can decipher the data, consider just that you overwrote ~ 100M at the start of your filesystem with random data. I understand there are 3TB (a lot), but tests should be done on a copy, or a stacked device mapper with the base data as read-only (see: https://unix.stackexchange.com/questions/67678/gnu-linux-overlay-block-device-stackable-block-device) and never on the original damaged data. There's no need to still consider LUKS is involved anymore. – A.B Dec 10 '20 at 15:12

0 Answers0