Bitlocker-2 picoCTF 2025 Solution

Description

1. Step 1

   Scan the memory image

   Observation

   I noticed the challenge provided both a disk image and a RAM dump captured while the drive was unlocked, which suggested the decrypted flag text would still reside in physical memory and could be extracted with strings and grep rather than cracking the BitLocker password.

   Mounted-disk + RAM capture means decrypted file contents are sitting in physical memory. strings memdump.mem | grep -oE 'picoCTF\{[^}]+\}' | sort -u extracts every flag-shaped token and dedupes them. There's usually one true flag plus a couple of buffer-cache copies.

   What didn't work first

   Tried: Trying to crack the BitLocker password by brute-forcing the disk image with hashcat or john.

   The challenge explicitly says not to brute-force the disk. Even if you extract the BitLocker hash correctly, cracking a strong password could take hours or forever. The RAM dump already holds the decrypted plaintext, so the disk password is irrelevant - grep the memory image directly instead.

   Tried: Running strings on the disk image (.dd file) instead of the memory dump (.mem file).

   The disk image contains encrypted sectors, so strings on it returns garbage binary noise rather than readable flag text. The key insight is that the RAM dump - not the disk - holds the decrypted contents because the drive was mounted when memory was captured. Always target the .mem file for plaintext recovery.

   Learn more

   Memory forensics exploits the fact that when an encrypted volume is mounted, the operating system keeps decrypted data in RAM. The encryption key itself, decrypted file contents, and recently accessed strings all reside in physical memory for as long as the system is running. A RAM dump captured while BitLocker is unlocked therefore contains the plaintext of whatever files were recently read - regardless of how strong the disk password is.

   This is the basis of the cold boot attack, a technique where an attacker physically cools RAM chips (slowing the decay of stored data), removes them from the running machine, and reads the contents in another system to extract encryption keys. Cold boot attacks have been demonstrated against BitLocker, FileVault, and LUKS. The defense is to power off machines completely before leaving them unattended in physically insecure environments.

   The strings tool works on memory dumps exactly as it does on executables - it scans raw bytes for printable sequences. Because RAM contains all running process memory, heap data, stack frames, and kernel buffers, it is a rich source of artifacts: passwords typed into terminals, browser history, decrypted file content, and cryptographic keys. This makes live memory acquisition a high priority in digital forensics.

2. Step 2

   Optional: use Volatility

   Observation

   I noticed the RAM dump was taken from a live Windows system with BitLocker active, which suggested that Volatility 3's windows.bitlocker plugin could extract the Full Volume Encryption Key directly from kernel memory structures as an alternative path to disk decryption.

   Volatility 3 understands kernel structures so it can pull the FVEK (Full Volume Encryption Key) directly from RAM with vol -f memdump.mem windows.bitlocker. That key plus dislocker -k unlocks the disk image even if you never recover the user password.

   What didn't work first

   Tried: Installing Volatility 2 instead of Volatility 3 and running vol.py with the same plugin names.

   Volatility 2 and Volatility 3 use completely different plugin naming conventions and profile systems. The windows.bitlocker plugin exists in Volatility 3 (and community plugins for it); in Volatility 2 the BitLocker plugin has a different name and interface. If vol.py complains about an unknown plugin or missing profile, you are likely using the wrong version - install volatility3 via pip and use the vol command instead.

   Tried: Using the FVEK recovered by Volatility directly with hashcat or as a password string.

   The FVEK is a raw binary encryption key, not a password. You pass it to dislocker with the -k flag (e.g. dislocker -k <fvek-file> -V bitlocker-2.dd) to mount the disk. Treating it as a password or trying to input it into BitLocker unlock dialogs will not work because it bypasses the password layer entirely.

   Learn more

   Volatility is the leading open-source memory forensics framework. Rather than treating a memory dump as a raw byte blob, Volatility understands Windows (and Linux/macOS) kernel structures and can reconstruct process lists, network connections, registry hives, loaded modules, and file artifacts from the dump. This structured approach is far more powerful than grep for complex investigations.

   Key Volatility plugins for BitLocker investigations include windows.bitlocker (a third-party plugin that extracts FVEK encryption keys directly from memory - install from lorelyai/volatility3-bitlocker), windows.pslist (lists running processes), and windows.filescan (finds file objects cached in memory). Recovering the Full Volume Encryption Key (FVEK) from memory allows mounting the disk even without knowing the user password.

   Autopsy is a GUI-based digital forensics platform that integrates Volatility as a plugin. It provides timeline analysis, keyword search, hash lookup, and artifact extraction in a unified interface used by law enforcement and corporate incident responders worldwide. The combination of Autopsy for disk artifacts and Volatility for memory artifacts covers most digital forensics investigations. The Volatility 3 guide walks through the plugin catalog (pslist, filescan, hashdump, bitlocker) with real picoCTF artifacts.

Flag

No password cracking is necessary because the RAM capture already contains the decrypted flag.