Cracking LUKS and BitLocker full-disk encryption with hashcat

Full-disk and full-volume encryption turns a lost password into a different kind of problem than a cracked online account: there is no server to rate-limit you, but there's also no shortcut around the key derivation function guarding the volume. LUKS (Linux) and BitLocker (Windows) both reduce to the same shape of attack as any other password hash — extract the key-derivation material, feed it to hashcat or John, run a wordlist or mask — but each has its own extraction step and its own trap for picking the wrong mode.

LUKS: extract the header, don't touch the partition

A LUKS volume doesn't need to be decrypted to be attacked — only its header, which holds the PBKDF2 (LUKS1) or Argon2/PBKDF2 (LUKS2) key slots, needs to be read. Pull it with dd:

sudo dd if=/dev/sdXN of=header.luks bs=512 count=4097

Confirm what you're dealing with first — cryptsetup luksDump /dev/sdXN prints the LUKS version and KDF in use. That distinction matters because hashcat's modes split along it:

• LUKS1 → -m 14600, reading the extracted header directly:

  hashcat -m 14600 header.luks /usr/share/wordlists/rockyou.txt
  

• LUKS2 defaults to Argon2id on current cryptsetup releases and uses a different on-disk layout than LUKS1, so mode 14600 does not read it. Hashcat does support LUKS2, but the exact mode number depends on which KDF and cipher the volume was created with; rather than guess a number here, check what your installed hashcat build supports:

  hashcat --example-hashes | grep -i luks
  

  and match the entry to what luksDump reported.

Once hashcat recovers the passphrase, mount the volume normally — cracking only proves you have the password, it doesn't unlock anything itself:

sudo cryptsetup luksOpen /dev/sdXN recovered

Because LUKS's PBKDF2/Argon2 iteration counts are calibrated at setup time to take roughly a second on the original hardware, throughput is nowhere near what you'd see against a fast, unsalted hash — a short, dictionary-word passphrase is still realistic, a long random one is not. The LUKS hash page has the full identification details.

BitLocker: bitlocker2john, then pick the right prefix

BitLocker stores its key-derivation metadata (the FVE/VMK data) at a fixed location on the volume, and John the Ripper's bitlocker2john.py pulls it into the same $bitlocker$ format hashcat expects — point it at the raw device or an image:

python3 bitlocker2john.py -i /dev/sdXN > hash.txt

Before you run anything, look at the prefix — it tells you which kind of secret you're actually attacking:

A user password or PIN is a normal hashcat job:

hashcat -m 22100 hash.txt /usr/share/wordlists/rockyou.txt

For a PIN, a mask attack beats a wordlist — BitLocker PINs are typically 4–20 digits, so -a 3 -1 ?d hash.txt ?1?1?1?1?1?1 style masks cover the realistic space fast. The recovery-key hashes ($3$/$4$) encode the 48-digit key BitLocker itself generated; its keyspace is large enough that neither hashcat nor John will get through it in any useful time, so if that's what you're holding, the recovery key itself is the only way in — there's no hash to crack your way past. See the BitLocker hash page for the full prefix breakdown and tuning hashcat for real GPU throughput for getting the most out of the attack you can actually run.

Takeaways

Both formats follow the identify-extract-mode pattern used everywhere else on this site: confirm the exact variant before picking a hashcat mode, because LUKS1 vs LUKS2 and BitLocker's four prefixes are not interchangeable and feeding the wrong one into mode 14600 or 22100 just gets a rejected hash. Where the underlying secret is a human-chosen password or short PIN, a wordlist or mask attack is realistic; where it's a machine-generated recovery key, no amount of GPU time changes the keyspace math.