BitLocker: How It Actually Works, How People Keep Breaking It

Intro

When Nightmare-Eclipse started disclosing Microsoft 0-days, it just so happened that I was tasked with auditing a Windows machine in my work, including its BitLocker setup. That's when I started researching the latest BitLocker bypasses and realised that, honestly, I didn't even know how BitLocker works in the first place. I mean, I know what it does, but not in depth. This led to the idea of writing a blog post. So here we are.

I know there are plenty of BitLocker articles out there, and I don't care. This one is for my own sake.

So, what is BitLocker?

BitLocker is a Full Volume Encryption (FVE) feature built into Windows. Its job is pretty straightforward, protect data at rest. If your laptop gets stolen from a car, or someone pulls the SSD out of a decommissioned server, the data on it should be useless without the keys.

The architecture, piece by piece

Most BitLocker explanations stop at "there's a key, and the TPM holds it." Let's go a bit deeper, because the attacks only make sense once you see how the parts fit together.

Here's the whole thing on one page. Don't worry if it looks like a lot, we'll walk through it.

  ===================== BOOT TIME =====================

  +---------------------+  measure & extend   +---------------------+
  |   UEFI firmware     |-------------------->|        TPM          |
  |   + Secure Boot     |      into PCRs      |  PCR 7  (SB policy) |
  +----------+----------+                     |  PCR 11 (BitLocker) |
             |                                +---------------------+
             | verifies signature                  ^          |
             v                                     |          |
  +---------------------+  1. "unseal the VMK"     |          |
  |   Boot manager      |-------(+ PIN if set)-----+          |
  |   bootmgfw.efi      |                                     |
  |   (ESP, plaintext)  |<---- 2. VMK, only if PCRs match ----+
  +----------+----------+
             |  3. reads wrapped FVEK from the FVE metadata on C:
             |  4. VMK unwraps FVEK
             |  5. extends PCR 11 ("caps" it, no more unseals)
             v
  +---------------------+
  |   winload.efi       |  loaded from the now-unlocked C: volume
  +----------+----------+
             |
             v
  ====================== RUN TIME =====================

  +-----------------------------------------------+
  |  Applications                                 |
  +-----------------------------------------------+
  |  NTFS (file system)                           |
  +-----------------------------------------------+
  |  fvevol.sys   (FVE filter driver)             |  <-- FVEK lives in RAM;
  |  decrypts on read, encrypts on write          |      every sector passes
  +-----------------------------------------------+      through here
  |  Storage stack / disk driver                  |
  +-----------------------+-----------------------+
                          |
                          v
  +-------+-----+--------------------------------+-------------+
  |  ESP  | MSR | C:  [FVE header][metadata x3]  |  Recovery   |
  | plain |     |     [ encrypted data ....... ] |  (WinRE)    |
  | text  |     |                                |  plaintext  |
  +-------+-----+--------------------------------+-------------+

A typical BitLocker protected Windows machine has a disk that looks roughly like this:

+------------------+-----+-------------------------------+---------------------+
| EFI System       | MSR | Windows (C:)                  | Recovery partition  |
| Partition (ESP)  |     | ENCRYPTED                     | (WinRE)             |
| NOT encrypted    |     |                               | NOT encrypted       |
|                  |     |                               |                     |
+------------------+-----+-------------------------------+---------------------+

Notice that only the Windows partition is encrypted. The EFI System Partition (where the boot manager and Boot Configuration Data live) has to stay readable, otherwise the firmware couldn't start anything. Same for the Recovery partition, which holds the Windows Recovery Environment (WinRE). To add, the C: drive is encrypted but a few small regions in it stay in plaintext, the volume header and three BitLocker metadata copies.

Once Windows is running, the real work is done by fvevol.sys, a filter driver that sits below the file system in the storage stack. NTFS asks for a sector, and fvevol decrypts it on the way up and encrypts it on the way down. Nothing on the disk is ever decrypted "in bulk". When people say a running machine's drive is "decrypted", what they really mean is unlocked. The data on disk stays encrypted the whole time, the key just sits in RAM, ready to be used.

The key hierarchy

This is the part everyone draws on a whiteboard. BitLocker uses three layers of keys, and the reason is pretty smart as you never want to re-encrypt a 1 TB drive just because you changed your PIN.

• FVEK (Full Volume Encryption Key): the key that actually encrypts your data. On modern Windows (10 version 1511 and later), fixed drives use XTS-AES by default. Removable drives still default to AES-CBC due to compatibility.
• VMK (Volume Master Key): encrypts the FVEK. This is the indirection layer.
• Key protectors: each one encrypts (wraps) the VMK in its own way. You can have several at once:
TPM-only: the VMK is sealed to the TPM. This is the default.
TPM + PIN: the TPM won't hand over the VMK until you type a PIN.
Startup key: a .BEK file on a USB stick, on its own or combined with the TPM.
Recovery password: the famous 48-digit number. This is what companies escrow to Active Directory or Entra ID.

              +-----------------------------------+
              | Your data on the C: volume        |
              +-----------------------------------+
                                ^ encrypted with
                                |
              +-----------------------------------+
              | FVEK  Full Volume Encryption Key  |
              +-----------------------------------+
                                ^ wrapped by
                                |
              +-----------------------------------+
              | VMK   Volume Master Key           |
              +-----------------------------------+
                                ^ wrapped separately by EACH protector
                                |
        +---------------+-------+-------+---------------+
        |               |               |               |
 +-------------+ +-------------+ +-------------+ +-------------+
 | TPM-only    | | TPM + PIN   | | Startup key | | Recovery    |
 | (default)   | |             | | .BEK on USB | | password    |
 |             | |             | |             | | 48 digits   |
 +-------------+ +-------------+ +-------------+ +-------------+

So, to sum up, your actual data is encrypted with the FVEK, the FVEK is wrapped by the VMK and the VMK is wrapped by one or more key protectors. Easy!

As mentioned, the indirection is the coolest part. Wanna change a PIN? Only the VMK gets rewrapped. Rotate the recovery password? Same thing. The FVEK, and your terabyte of data stay untouched.

Where the TPM comes in

If you didn't know, TPM (Trusted Platform Module) is a tamper-resistant cryptographic module, usually a dedicated chip on the motherboard, or firmware running in a protected part of the CPU (fTPM, Pluton). Here's what happens when you power on a TPM-only machine:

1. The UEFI firmware starts and, with Secure Boot on, checks that the boot manager (bootmgfw.efi on the ESP) is properly signed.
2. As the boot progresses, the firmware and then each boot stage measure the next component (firmware, boot manager, boot configuration) and extend those hashes into the TPM's Platform Configuration Registers (PCRs). Small but important detail, the TPM itself doesn't measure anything. It's a passive chip that keeps a running hash of whatever it's told.
3. The boot manager asks the TPM to unseal the VMK. The sealed blob isn't stored inside the TPM, it lives in the BitLocker metadata on disk, encrypted under a key that never leaves the TPM. The TPM loads it, but only hands the VMK back if the current PCR values match the policy it was sealed against.
4. If everything matches, the TPM hands back the VMK, no questions asked. VMK decrypts FVEK, FVEK unlocks the volume, winload.efi loads Windows from the encrypted partition, and fvevol takes over.
5. Right after the unlock, the boot manager extends PCR 11. That "caps" it, so nothing that runs later in the boot can ask the TPM for the VMK again.

If something doesn't add up (a changed Secure Boot configuration, or, with Secure Boot off, a changed boot chain), the PCRs won't match, the TPM says no, and you're staring at the blue recovery screen asking for those 48 digits.

One more thing, on modern UEFI machines with Secure Boot, BitLocker by default binds to PCR 7 (the Secure Boot policy) and PCR 11, not to the hash of every individual boot file. Which basically means that the TPM trusts any boot manager signed by Microsoft, not one specific version of it.

   Patched boot manager (2025)          Old, vulnerable boot manager (2022)
   signed via PCA 2011                  signed via PCA 2011
              |                                       |
              v                                       v
   PCR 7 = "Secure Boot on,             PCR 7 = "Secure Boot on,
            approved by PCA 2011"                approved by PCA 2011"
              |                                       |
              +------------------+--------------------+
                                 |
                                 v
                   same PCR 7, same PCR 11 at unseal
                                 |
                                 v
                   TPM: "looks fine to me"  -->  VMK

So an attacker can swap in a years old boot manager with a known bug, and as far as the TPM is concerned, nothing changed. The only way out is to stop trusting the old boot managers altogether, move to the 2023 certificates and put the old PCA 2011 into dbx (that's what KB5025885 is all about). This is exactly the trick behind Bitpixie and the BitUnlocker downgrades later on.

The side door: WinRE

The boot manager doesn't only start Windows. It can also start a recovery environment, and WinRE is part of the chain of trust too:

                         +----------------+
                         |  Boot manager  |
                         +-------+--------+
                                 |
               +-----------------+-----------------+
               v                                   v
     +--------------------+         +-------------------------------+
     |  Normal boot       |         |  Recovery boot                |
     |  winload.efi       |         |  Boot.sdi + winre.wim         |
     |  -> Windows logon  |         |  (from the recovery partition)|
     +--------------------+         +---------------+---------------+
                                                    |
                                                    v
                                    +-------------------------------+
                                    |  Boot manager checks this is  |
                                    |  a "trusted" WinRE image and  |
                                    |  unlocks C: for it            |
                                    +---------------+---------------+

PINs, lockouts and the pre-boot screen

With TPM+PIN, the TPM wants both matching PCRs and the right PIN before it lets go of the VMK. That means even a perfectly "trusted" boot, whether it's a downgraded boot manager or a tricked WinRE, gets nothing without someone typing the PIN. Your PIN is salted and stretched, then used as an authorization value for the TPM. If someone tries to brute-force it, the TPM's anti-hammering logic kicks in. Windows configures the TPM to lock after 32 failed attempts, then forget one failure every 10 minutes, so an attacker gets about six guesses an hour. Restarting the laptop doesn't reset the lock, as the counter lives in the TPM (and it only counts down while the machine is on or asleep). So, you're welcome to brute-force BitLocker, as long as you have a few decades to spare.

How BitLocker actually gets bypassed

Pretty much every real-world BitLocker bypass falls into one of three categories, plus a handful of exotic firmware and silicon tricks we'll mention later.

Here's the same boot chain from before, with the spots people actually attack:

  +----------+   +--------------+   +---------+  LPC/SPI  +-------------+
  | Firmware |-->| Boot manager |-->|   TPM   |==========>|  CPU / RAM  |
  |   [E]    |   |     [B]      |   |         |    [C]    |     [D]     |
  +----------+   +------+-------+   +----+----+           +------+------+
                        |                |                       |
                        v              [PIN]                     v
                 +--------------+   gate is here          +-------------+
                 |    WinRE     |                         |   Windows   |
                 |     [A]      |                         |             |
                 +--------------+                         +-------------+

  [A] WinRE abuse ...... YellowKey, Bitskrieg, GreatXML, BitUnlocker,
                         Push Button Decrypt, Break Out in Hives
  [B] Boot manager ..... Bitpixie, Dubious Disk, RAM Leak, keytable non-wipe,
                         downgrades to an old signed boot manager
  [C] TPM bus .......... sniffing the VMK off a discrete TPM
  [D] Memory ........... DMA, cold boot (and CrashXTS, via the hiberfile)
  [E] Firmware/silicon . unmeasured debuggers, fTPM glitching (faulTPM),
                         boot-time IOMMU disable

1. Sniffing the TPM bus

If your machine has a discrete TPM (a separate chip on the motherboard), the unsealed VMK travels in the clear over the LPC, SPI or I2C bus to the CPU. These buses are slow and their pinouts are well documented, so with a few minutes of physical access, a logic analyser (or a cheap microcontroller), you can grab the VMK during boot and decrypt the drive. Pulse Security has a great write-up on this.

Firmware TPMs (fTPM) and Microsoft Pluton live inside the CPU, so there's no exposed bus to tap. That doesn't make them invincible, though. AMD fTPMs, for example, were hit by fault-injection research.

2. Memory attacks (DMA and cold boot)

Once Windows is running, the FVEK is in RAM. So:

• DMA attacks: plug a malicious device into a DMA capable port (Thunderbolt, some PCIe, old-school FireWire/ExpressCard) and read memory directly, bypassing the OS entirely.
• Cold boot attacks: DRAM doesn't forget instantly when you cut the power, especially if you cool it down. Reboot into your own tooling fast enough and you can read what was there. F-Secure showed in 2018 that this works on modern laptops too.

Both need the key to already be in memory, a running or sleeping machine, or a TPM-only laptop the attacker can just switch on and let unlock itself.

3. Abusing trusted components

This is where all the action has been in 2025–2026. Since TPM-only trusts the boot manager and WinRE, why fight the crypto when you can trick the trusted bits? There are two main flavours:

• Boot manager downgrades: swap the up-to-date boot files for older, vulnerable ones. Remember PCR 7? Those old files are still signed by Microsoft, so the TPM is perfectly happy with them.
• WinRE abuse: mess with files on the unencrypted recovery partition so that some recovery flow ends up giving you a command prompt on the auto unlocked drive.

The greatest hits: recent BitLocker vulnerabilities

The Nightmare-Eclipse saga

Between April and June 2026, a researcher going by Nightmare-Eclipse (also Chaotic Eclipse, who later revealed it's identity as Abdelhamid Naceri) went on a bit of a rampage, dropping Windows zero-days aimed at Microsoft's own security features, mainly BitLocker and Defender. Two of them were BitLocker bypasses (YellowKey and GreatXML), and a third one, Bitskrieg, was built on top of YellowKey by Jonas Lykkegaard.

YellowKey (CVE-2026-45585)

Disclosed on 13 May 2026, YellowKey targets TPM-only systems on Windows 11 24H2, 25H2 and 26H1, plus Windows Server 2025. Older versions are safe from this one, because the feature it abuses only arrived with the 24H2 platform.

The recipe:

1. Put some specially crafted FsTx files on a USB stick (or on the EFI partition). These are logs from a filesystem transaction feature that arrived with 24H2, not to be confused with the old Transactional NTFS.
2. Plug it in, reboot into WinRE, and hold CTRL.
3. WinRE's autofstx.exe helpfully "replays" those transactions, which deletes the file that normally launches the recovery menu.
4. With that file gone, WinRE falls back to... a raw command prompt. On the already unlocked drive.

A few minutes of physical access, full read/write to everything, no password needed.

Microsoft first shipped a mitigation script that removes the abused component (autofstx.exe) from the WinRE image, then a proper fix in the June 2026 updates. TPM+PIN blocks the public exploit, which just gets stuck at the PIN prompt. But, Nightmare-Eclipse claims to have an unreleased variant that works against TPM+PIN too. So treat the PIN as a really strong mitigation, not a magic shield.

Bitskrieg

Right after YellowKey, Jonas Lykkegaard published Bitskrieg in early June 2026. It worked even with Microsoft's YellowKey mitigation script applied. The point is that the script killed one trigger (autofstx.exe), but not the underlying design, where the recovery partition is unencrypted and the drive stays unlocked during boot until something tells the TPM to lock things down.

Instead of FsTx tricks, Bitskrieg abuses Emergency Management Services (EMS), a legit Windows feature that exposes a management console over a serial port. You boot into WinRE, skip past the recovery key prompt and turn EMS on with a couple of bcdedit commands. A second computer hooked up over a (physical or virtual) serial cable can then connect to the Special Administration Console and get a SYSTEM shell while the drive is still unlocked.

GreatXML

Released on 11 June 2026 as Nightmare-Eclipse's next BitLocker bypass. Same spirit as YellowKey, different trick.

Windows has a legit setup file, unattend.xml, that tells the installer what to do automatically. GreatXML drops a modified one (plus a small recovery folder) onto the recovery partition and reboots into WinRE. If the machine has ever run a Microsoft Defender Offline Scan (which reboots into that same recovery environment), WinRE reads the malicious file and runs the attacker's instructions before any login or encryption check. Result? Command prompt, full access to the drive.

However, writing to the recovery partition needs admin rights, so this is more about persistence and data access than getting initial access.

BitUnlocker (CVE-2025-48804 and friends)

Some of the best BitLocker research came from Microsoft itself. In 2025, Microsoft's offensive research team STORM (Alon Leviev and Netanel Ben Simon) found four ways to break BitLocker through WinRE:

• Boot.sdi (CVE-2025-48804): WinRE loads a file called Boot.sdi at startup. The attacker appends a malicious recovery image to it and fiddles with the offset, so the integrity check validates the legit image while the boot runs the attacker's one. Command prompt, unlocked drive.
• Offline scanning: abusing the trusted tttracer.exe tool to run commands.
• ReAgent.xml: abusing SetupPlatform.exe through WinRE's config file.
• BCD manipulation: redirecting where WinRE thinks Windows lives, so the "reset this PC" feature decrypts the volume for you.

All four were patched in July 2025. But, an attacker can just load an old, unpatched boot manager, because it's still signed and trusted (PCR 7 strikes again). That downgrade only goes away once the old boot managers are revoked.

Bitpixie (CVE-2023-21563)

Older, but still very much alive. Found by Rairii back in 2022 and made famous by Thomas Lambertz's talk at 38C3 in December 2024. When Windows boots, it briefly keeps the key in memory and should wipe it once it's done. Bitpixie abuses a network boot (PXE) path where the boot manager forgets to wipe it. So the attacker PXE-boots the machine, soft-reboots into a small Linux system, scans memory, and picks up the VMK. No cracking needed. And yes, it only works against TPM-only setups.

Microsoft patched the boot manager back in January 2023, but, again, the old vulnerable boot manager is still validly signed, so you can just boot that one. Blocking the downgrade needs the Secure Boot certificate rotation and revocation.

More attacks you probably haven't heard of

The ones above got the headlines, but they're far from the only ones. If you want to go properly down the rabbit hole, Rairii (Wack0) keeps a fantastic list of public BitLocker attacks on GitHub. Here's the rest, roughly grouped.

Hardware and firmware

• Unmeasured hardware debuggers (2023): the TCG spec says the firmware has to record into PCR 7 when a hardware debugger gets enabled. Some machines don't bother for debuggers like Intel DCI. Researchers from the Brazilian Federal Police showed that you can enable the debugger (via a Secure Boot bypass, or by writing the SPI flash directly), set a breakpoint in the boot manager's TPM unseal code, and read the VMK straight out. There's no fix for affected machines. Paper (DFRWS EU 2023)
• faulTPM (2023): remember "fTPMs aren't invincible"? Researchers from TU Berlin used voltage glitching on AMD's security processor to get code execution and dump the entire fTPM state. With TPM-only that's the VMK, and with TPM+PIN the PIN suddenly becomes brute-forceable offline, since there's no anti-hammering left to stop you. A long, complex PIN still holds up, a short numeric one doesn't. Paper, code
• Boot-time IOMMU disable (2026): some UEFI firmware decides whether to turn on the IOMMU (Input-Output Memory Management Unit) based on variables stored in flash. MDSec dumped the flash, flipped those variables and wrote it back, and the TPM didn't notice a thing. With no IOMMU at boot, they used DMA to tamper with the DMAR ACPI table before the boot manager ran, booted into Safe Mode, then used DMA again to get a SYSTEM shell. So much for Kernel DMA Protection. Write-up

The boot environment

• Keytable not wiped (2022): when the boot library starts up, it creates a fresh table of BitLocker keys but doesn't wipe the old one. Load the boot manager again with an attacker chosen device and the keys are still lying around in memory. Mitigated in January 2022, properly fixed in 2023, and, you guessed it, still reachable via a downgrade.
• Dangerous association (CVE-2022-29127, CVE-2022-22048): two bugs in how legacy integrity validation checked BCD options, which let you hide options like debug from BitLocker. Fixed in May and July 2022. Disclosure
• Dubious Disk (CVE-2022-30203, CVE-2023-21560, CVE-2023-28269, CVE-2023-28249, CVE-2024-38065): a whole family of bugs giving arbitrary code execution inside the boot environment, which means you can either derive the keys yourself or dump them. Fixed piece by piece between 2022 and 2024, and downgradeable. Write-up
• RAM Leak (2026): the boot environment happily creates a ramdisk from a file on the BitLocker encrypted partition. So you can load, say, hiberfil.sys (which contains the keys) into RAM, and it stays there after the keys are wiped, ready to be dumped. Microsoft closed the report as low priority, so it's unfixed. Details and PoC

WinRE (again)

• Push Button Decrypt (CVE-2022-41099): start a "Reset this PC, remove everything" in WinRE and pull the plug at around 98%, right when it starts decrypting the drive. On the next boot you can get a shell with Shift+F10, pause BitLocker and delete the protectors, which leaves a plaintext VMK in the metadata. An earlier disk image does the rest. Fixed in November 2022, but the WinRE image had to be patched manually, so plenty of machines stayed vulnerable for ages. Analysis by SCRT
• Break Out in Hives (CVE-2024-20666) and Break Out in Hives 2 (CVE-2025-21213): a BCD element called systemdatadevice makes winload read the SYSTEM registry hive from a device of your choice. Point it at your own hive, tell Setup to launch cmd.exe, boot WinRE, and you've got a SYSTEM shell with the keys in memory. Part 1 was fixed in January 2024 (with a manually patched WinRE, again). Part 2 uses an old winload to get around that fix, and its own fix only landed in the 2023-signed boot manager, so without the KB5025885 mitigation it's still open.

The crypto (sort of)

• CrashXTS (CVE-2025-21210): XTS mode has no integrity protection, so if you can image the encrypted disk a few times, you can work out where the SYSTEM hive lives and precisely corrupt the bit that makes Windows load dumpfve.sys. The next time the machine hibernates, the hiberfile, keys and all, gets written to disk in plaintext. Since it goes after the hibernation path rather than the unlock, it doesn't care how the drive is unlocked, but it does need repeated access to the disk. Fixed in January 2025. Write-up by Maxim Suhanov

The "evil cleaner" problem

One more thing that's easy to miss. Most of the boot environment bugs above need the keys to be derivable without anyone typing anything, so TPM+PIN stops them. But if an attacker can get code execution in the boot environment at all, they can also plant a bootkit, put the laptop back, and wait for you to type the PIN. Its called the "evil cleaner" scenario (think of the classic hotel-room evil maid, but on a cleaning schedule). So a PIN protects you against a stolen laptop, not necessarily against someone who gets to it twice. That's why patching and the KB5025885 revocations matter for TPM+PIN users too.

Cheat sheet

Every attack in this post, side by side:

Thanks for reading, peace :)