How do I know a LUKS header is corrupt?

I found this page:

https://bbs.archlinux.org/viewtopic.php?pid=1846810#p1846810

Also this page:

https://www.linuxquestions.org/questions/linux-general-1/need-help-to-recover-luks-partition-4175613302/#post5756030

More specifically,

"You can tell fairly quickly whether there is any chance of recovery. Run "hexedit -s /dev/sdx" and search for the hex string "4C 55 4B 53 BA BE" at the start of a sector. (That's the ASCII string "LUKS" followed by the hex bytes 0xBA and 0xBE.) If you don't find that within the first few megabytes of the disk, the LUKS header is gone."

All the five file systems that refuse to open have that string intact in their headers so they all seem to be not damaged. Now, why all of them won't open is a separate issue and I suspect I will never find out what happened.

Answer provided for posterity.

How to know if you're LUKS header is corrupt?

The short answer to your question is that it will tell you it's corrupted when you go to try to unlock it or the system freezes upon trying to enter the passphrase if it's the boot partition. But, in your case, it just gives you an error about the key not being "available with this passphrase" which is a bit odd.

Seeing as you've already discovered the hexedit -s <device> you may also want to try running dmsetup info <device_name>] after you've tried entering the password and see what sort of state is reported, tables are reported as present, etc. See the Man Page for DMsetup for more info.

Or try dmsetup table --showkeys <device or header file> to see if it will recognize they keyslot.

Additional Methods of Checking the LUKS header

Aside from using the cryptsetup luksHeaderBackup <device> --header-backup-file <file> for creating a header backup (even though it doesn't open, since luksDump doesn't report any corruption), you might as well try making a backup of them and then trying to restore them from those backups to see if cryptsetup will let you restore the header in that way. Aside from the aforementioned method, you can also use dd as an alternative for creating a "backup" of the header:

root@system:# dd if=<device> of=<Luksheader_filename> bs=512 count=4097

In addition to using hexedit to verify the header, you can also use the file or the strings command on the file you just created above, or even running luksDump command on the file itself by replacing the device name with the path & filename.

root@system:# file <Luksheader_filename>

root@system:# strings <Luksheader_filename> | grep -i luks LUKS

root@system:# cryptsetup luksDump <Luksheader_filename>

Similar Cases may or may not be so similar

In terms of the others and your research, the ones you've linked above, it wasn't made clear what you were doing when your computer froze and would thus be the last time you were able to access the drives. In contrast, two links involve two different reasons for their individual LUKS-encrypted drives to become inaccessible, one related to an HPA misconfiguration and the other was following a kernel upgrade which, only affected the /home volume and not the /root volume, and may actually be due to a trim/discard issue.

Perhaps a more similar occurring issue based on the broad explanation may be found here , where they even began to consider the possibility of a cosmic ray forcing a bit switch somewhere and may be a nice read for someone who may want to double check they've explored all other options.

Since it's unclear based on the information provided, whether or not these "filesystems"* as you refer to them, hold your operating system or just "content" as we'll put broadly, it would help to know if your system freezes when trying to boot if one of the LUKS encrypted volumes/partitions is your boot drive and the password doesn't work or if you're just trying to access those 5 devices from the terminal and/or from a GUI (and on what flavor of linux) that it gives you that repeated error? In which case, there may be some slight hope with the latter.

*As a point of clarification, "filesystem" would refer to how and where data is stored, so file system will usually refer to formats such as ext3, ext4, NTFS, etc. while LUKS is a disk encryption specification. Hence it doesn't give us any insight into what role those 5 LUKS 'filesystems' (presumably volumes as you mentioend) play as part of your system.

Non-header Possible Issue

The question was about how to identify and/or determine a corrupted LUKS header. Yet, without a backup of any of the headers, there would be no uncorrupted version of the header for the OP to compare. Since it may be clearer now that the situation which applies is uncertain and likely different than the linked examples, it may be worth trying:

Checking if it's a LVM issue using

root@system:# lvscan 
# or
root@system:# lvdisplay
# To check if you can still identify the LUKS filesystems as volume groups or
# supported LVM block devices.

root@system:# vgdisplay --short
# To find the Volume Group (usually fails if password won't work)

root@system:# lvs -o lv_name,lv_size -S vg_name=[name_of_volumegroup]
# To list the logical volumes identified in the volume group (if it works)

See the man page for lvscan and vgdisplay to learn more.

And, Exploring other possibilities

Unfortunately, with LUKS1 encryption, checksums were not implemented for a number of reasons, which you can learn from this presentation if desired. Otherwise, that's just to say that the only "checksum" in LUKS is the one that tells you there is no matching key slot and implies it is corrupted.

However it was noted that you had said all 5 filesystems would not open and refer to them all as volumes so it's unclear if it's all on one disk and whether or not it's an SSD drive or not, in which case, a Memory and Storage scan of the drive would be the next suggestion.

Finally, to be sure, you ran cryptsetup with sudo yes?

You may also want to try

• Using the recovery feature in gparted's GUI found regarding the partition tables and whatnot
• Giving it a scan with ddrescue
• Make sure that caps lock or number lock wasn't on (silly I know, but just a gentle reminder)
• Try some of the answers suggested here
• if there was an update before the computer freeze, try rolling back to a previous version
• Try adding a password in another keyslot

Side note

It was assumed that you attempted to open the LUKS encrypted volumes within a terminal and with sudo since no specific system or GUI was mentioned nor mention of a boot process.