Fix Corrupted Disk Encryption Header in 5 Steps

Yeah, that sinking feeling when your encrypted drive just won't mount. No error that makes sense, just a wall of "wrong password" or "invalid argument." I've been there too. The header got corrupted — probably from a wonky shutdown or a bad cable. Let's fix it.

The Fix — Assuming LUKS (Linux Unified Key Setup)

Most Linux encrypted drives use LUKS. If you're on Windows with VeraCrypt or BitLocker, I'll cover those after. For LUKS:

First, stop trying to mount the drive. Every failed attempt makes things worse — the kernel might write to the header area.
Check if the header still has a backup. LUKS stores a backup header at the end of the disk by default. Run:
```
sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /tmp/header_backup.img
```
Replace /dev/sdX with your disk device (like /dev/sdb). If this works, you already have a backup. If it fails, move to step 3.
If no backup, try restoring from the backup slot that LUKS keeps internally:
```
sudo cryptsetup luksHeaderRestore /dev/sdX --header-backup-file /tmp/header_backup.img
```
This only works if you previously made a backup. The reason step 2 fails often is the header is so mangled that the backup area is also corrupted — happens when the disk was written to after the corruption.
If that fails, try to recover data without the header. You can extract the raw encrypted data with dd:
```
sudo dd if=/dev/sdX of=/tmp/encrypted_data.img bs=4096
```
Then use cryptsetup luksOpen on that image. If the password works on the image but not on the original drive, the header is corrupted but the master key is still intact. You can then re-encrypt the data.
Last resort — rebuild the header using cryptsetup-reencrypt:
```
sudo cryptsetup-reencrypt --resilience=checksum /dev/sdX --header /tmp/new_header.img
```
This creates a new header and rewrites the encryption keys. But it requires the old password still works. If it doesn't, you're hosed.

Why This Works

What's actually happening here is the encryption header — a small area at the start of the disk (usually 2MB for LUKS) — stores the key slots and encryption parameters. When that gets corrupted, the system can't decipher the rest of the disk. The backup header is stored at the end of the disk, so if the corruption was only at the start, you can restore from the backup. The reason step 4 works is the dd image captures the raw encrypted data, and the header inside the image might be intact even though the disk's header area is broken — happens when the corruption is in the metadata layer (like the filesystem superblock) not the encryption header itself.

Variations for Other Encryption Tools

VeraCrypt (Windows/Linux)

VeraCrypt doesn't have a built-in header backup. But it does store a hidden backup of the header in the rescue disk you create during encryption. If you didn't make one, you're out of luck. The only option is to mount the disk as a raw device and try to recover the data with photorec or ddrescue. VeraCrypt uses a different header format — 256KB at the start. The corruption usually affects the volume header, not the data area.

BitLocker (Windows)

BitLocker headers are stored in the Windows volume (the system partition). If the header is corrupted, the recovery key (a 48-digit number) can still decrypt the disk. But BitLocker's header corruption is rare — it's usually a TPM issue or a bad USB drive. The fix for BitLocker is to boot from a recovery USB and type the recovery key. If that fails, the header is truly dead and you need to reformat.

macOS FileVault

FileVault headers are part of the Core Storage volume group. Corruption usually means the entire volume is unrecoverable. Apple doesn't provide header backup tools. The only fix is to restore from Time Machine.

Prevention — Do This Now

You don't want to be here again. Here's what to do for LUKS:

Make a header backup every time you change the password:

sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /mnt/backup/header_$(date +%Y%m%d).img

Store that backup on a different disk — preferably offline (USB stick in a drawer).
Use smartctl to check disk health before shutdowns. Bad sectors near the header area cause corruption.
If using VeraCrypt, save the rescue disk ISO to cloud storage or another machine.
For BitLocker, store the recovery key in your Microsoft account or print it out.

One more thing — if the disk has bad sectors (check with sudo smartctl -a /dev/sdX | grep -i reallocated), the header corruption might just be a symptom. Replace the disk. The header backup is useless if the disk is dying.