LUKS1 header with magic bytes and a version field, followed by key slots that each hold an encrypted copy of the master key.
01Location
Start of the encrypted device: LUKS header (phdr), then key material sections
02Questions it answers
Is the device a LUKS1 container, and what does its version field say?
How many key slots are present, and which ones hold an encrypted copy of the master key?
Is the header intact, or has it been overwritten or damaged?
03Format and versions
Format
Magic LUKS followed by 0xBA 0xBE at offset 0 (6 bytes); version as a 2-byte big-endian integer at offset 6; each key slot has a key material section after the header.
Applies to
Covers the LUKS1 on-disk format only. LUKS2 uses a different header with a JSON area that this source does not describe.
04Key fields
Field
What it tells you
Magic
Six bytes at offset 0: the letters LUKS, followed by 0xBA and 0xBE.
version
Two-byte big-endian field at offset 6 that states the LUKS version.
Key material section
Area after the header, associated with a key slot; it stores an encrypted copy of the master key.
05Examination workflow
Read the first bytes of the device from the image and check the magic value and version field before any other step.
List each key slot and note whether its key material section is present, without trying to open any slot.
Hash the header bytes and keep the original image unchanged before any decryption attempt.
06Interpretation pitfalls
The source says a key slot stores an encrypted copy of the master key; it does not state that the master key is never stored in plaintext. Do not infer more.
This record does not describe LUKS2; a LUKS2 volume needs its own specification.
The header shows that a device is LUKS-encrypted; it does not show which passphrase or key was used, or whether the device is still in use.
Contact us about examination services related to this page, support for expert witnesses, or collaboration. Please do not attach evidence files or personal data to your email.