Bitlocker-1 picoCTF 2025 Solution

Description

1. Step 1

   Extract the hash

   Observation

   I noticed the disk image is a BitLocker-encrypted volume, which stores a password-verification hash in its Volume Boot Record metadata, so the necessary first step is to pull that hash out with bitlocker2john before any offline cracking attempt can begin.

   Run which bitlocker2john. If it returns a path, use that. Otherwise locate bitlocker2john.py in the John Jumbo source tree (often /opt/john/run/) and call it explicitly with python3. Save the $bitlocker$... output to hashes.txt for cracking.

   What didn't work first

   Tried: Trying to mount the .dd image directly with mount -o loop bitlocker-1.dd /mnt/test without extracting a hash first.

   Linux's mount command cannot interpret a BitLocker-encrypted volume - it sees only an unrecognized filesystem and returns an error. You must extract the password-verification hash from the volume metadata using bitlocker2john first, crack that hash to get the plaintext password, and only then use dislocker to decrypt the volume before mounting.

   Tried: Running john bitlocker-1.dd directly instead of using the bitlocker2john extraction script.

   John the Ripper does not automatically detect and parse BitLocker metadata from a raw disk image. The bitlocker2john helper script is a separate pre-processing step that reads the BitLocker Volume Boot Record, extracts the hash in the $bitlocker$ format, and writes it to a text file. Only after that extraction step can John or Hashcat be pointed at the hash file.

   Learn more

   The end-to-end flow has four layers stacked: BitLocker encrypts the volume with AES, the disk image holds the encrypted volume, bitlocker2john extracts the password-verification hash from the volume metadata, cracking the hash gives the password, and dislocker uses the password to decrypt the volume back into a readable filesystem.

   BitLocker is Microsoft's full-volume encryption feature built into Windows. It encrypts entire drive volumes using AES (typically 128-bit or 256-bit) and protects the encryption key with one of several authentication methods: a password, a PIN, a USB key, or a TPM chip. The drive image in this challenge is protected by a user-supplied password.

   bitlocker2john is a script from the John the Ripper project that parses a BitLocker-protected disk image and extracts a hash line in the $bitlocker$... format. This hash encodes the password-derived key protection record, which BitLocker stores in the Volume Boot Record metadata. The hash can then be fed to offline password crackers like John or Hashcat without mounting the actual drive.

   The .dd file extension denotes a raw disk image created by tools like dd, a byte-for-byte copy of the original storage media. Forensic investigators create these images to preserve evidence without altering the original disk. Raw images can be analyzed, mounted, and cracked just like the original media, making them central to digital forensics workflows.

2. Step 2

   Recover the password

   Observation

   I noticed the challenge description explicitly says the drive uses a weak password, and the extracted $bitlocker$ hash targets the user-password protector, which suggested a dictionary attack with hashcat mode 22100 against rockyou.txt.

   Run hashcat -m 22100 hashes.txt /usr/share/wordlists/rockyou.txt (or john --wordlist=...). bitlocker2john often emits multiple hash lines (one per protector); -m 22100 is the user-password protector. Hashcat success looks like <plaintext>:<hash> in the output. For this challenge it cracks as jacqueline.

   What didn't work first

   Tried: Using the wrong hashcat mode, such as -m 9000 (Password Safe) or -m 13400 (KeePass), because BitLocker is also a volume-encryption tool.

   Hashcat uses mode numbers to select the exact hash format, and each encryption tool produces a structurally different hash. BitLocker with a user-supplied password specifically requires mode 22100. Using the wrong mode causes hashcat to misparse the hash and report zero candidates cracked. Always check the hash prefix ($bitlocker$) against hashcat's --help list or the hashcat example-hashes wiki to confirm the correct mode.

   Tried: Running hashcat against the raw .dd file instead of the extracted hashes.txt file.

   Hashcat expects a text file containing one hash per line in the format produced by bitlocker2john. Feeding it a binary disk image causes hashcat to report an invalid hash or silently skip all input. The extraction step that produces hashes.txt is mandatory before any cracking attempt.

   Learn more

   Hashcat is the world's fastest password recovery tool, capable of leveraging GPU parallelism to test billions of hash candidates per second. Mode -m 22100 targets the BitLocker-with-user-supplied-password format. Hashcat supports dozens of attack modes: dictionary attacks (wordlist), brute-force, rule-based mutations, combinator attacks, and mask attacks.

   rockyou.txt is the most famous password wordlist in security research, containing approximately 14 million real passwords leaked from the 2009 RockYou data breach. Weak passwords like common first names appear early in the list, which is why the password "jacqueline" cracks quickly. This demonstrates why dictionary words - even uncommon ones - should never be used as encryption passwords.

   Proper BitLocker protection requires a complex, randomly generated recovery key (a 48-digit numeric code that BitLocker can generate) rather than a user-chosen password. The recovery key is stored in Active Directory or Microsoft account in enterprise environments. Using a strong random recovery key makes offline dictionary attacks computationally infeasible. The Hash Cracking guide covers hashcat mode lookups, rule-based mutation, and mask attacks for cases where rockyou alone isn't enough.

3. Step 3

   Mount with dislocker

   Observation

   I noticed we now have the plaintext password 'jacqueline', and the disk image is a BitLocker-encrypted NTFS volume, which meant we needed dislocker to handle the BitLocker decryption layer before a second loop-mount could expose the filesystem and flag.txt.

   mkdir the two mountpoints first. Point dislocker at the image with -u "jacqueline", then loop-mount the generated dislocker-file as NTFS. flag.txt sits at the root of the mounted volume.

   What didn't work first

   Tried: Trying to read flag.txt directly from /mnt/dd_image/ after dislocker finishes, without running the second mount command.

   After dislocker runs, /mnt/dd_image/ contains only a virtual file called dislocker-file - it does not expose a browsable filesystem with folders and files. The dislocker-file is itself a raw partition image of the decrypted NTFS volume. You must loop-mount that file to a second mountpoint (such as /mnt/bitlocker_data) before you can ls directories or read flag.txt.

   Tried: Omitting sudo on the dislocker or mount commands and getting a permission denied error.

   Mounting block devices and FUSE filesystems requires root privileges on Linux. Both the dislocker command and the subsequent mount -o loop command need to be prefixed with sudo. If your user is not in the sudo group, you will need to switch to root with su - or add yourself to the group before running these commands.

   Learn more

   Dislocker is an open-source Linux tool that decrypts BitLocker volumes. Given a password, recovery key, or BEK file, it decrypts the volume and presents it as a virtual FUSE filesystem containing a file called dislocker-file - which is the decrypted raw partition image. This file can then be mounted normally using the mount command with a loop device.

   The two-step mount process is necessary because dislocker operates at the encryption layer while mount operates at the filesystem layer. BitLocker wraps an NTFS (or FAT32/exFAT) filesystem, so after dislocker strips the encryption, the underlying filesystem still needs to be interpreted by the kernel's NTFS driver (provided by the ntfs-3g package on Linux).

   This workflow - extract hash, crack password, mount and read - is standard in digital forensics and incident response (DFIR). Investigators frequently encounter BitLocker-encrypted drives on seized hardware. Commercial tools like FTK and EnCase have built-in BitLocker support, while open-source workflows like this one demonstrate the same capability without licensing costs.

Flag

Remember to install dislocker and ntfs-3g if your distro lacks them.