2

I have an old Macbook pro that I installed Debian 10 on and encrypted it. Don't have the Luks Header file/backup. Suddenly, the password used to access it stopped working. I know that I am using the right password because I know and have saved its hashsum, so it is 100% correct. I'm using the correct keyboard layout too.

I didn't do any updates or installs or anything at all to the device. My question is, if I am not able to decrypt it (tried that via the fallback tty as well as a live arch image), does that 100% mean that the header has been corrupted?

In this answer, they mention that plaintext string between the 0x1000 and 0x20400 sectors mean that the header is corrupted. Is this true? In my hexdump, the output between sectors 0x1000 and 0x20400 DO have plaintext strings and zeroed out rows. But they mostly seem to be LUKS-related text (e.g. I'm seeing {"type": "luks2"||, "key_size": 64...........). And the zeroed out rows occur at 0x000012e0 after the string "keyslot_size": "16744448"}}. There are some other zeroed out rows before 0x20400.

Is this a corrupted header? Running the repair function outputs "No known problems detected for LUKS header".

Improve this question
1
  • The linked answer is a few years old and still talking about LUKS 1, you are using LUKS 2 so it's different. You can check cryptsetup luksDump for key material offset and length - that is where you find your random data in a LUKS 2 setup. (This kind of check is very superficial. It's also possible to corrupt in a way that can't be seen in a hexdump. Since there is no checksum for key material there is no way to know for sure.)
    – frostschutz
    Jan 1 at 21:51

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .