
Cracking BitLocker encryption based on CVE-2023-21563 vulnerability
Virtual machine reproduction. The local machine (attacker machine) uses Ubuntu 22.04.5 LTS system, while the victim machines are Windows 10 21H2 19041.1 and Windows 11 21H2 22000.318, both with BitLocker encryption enabled. QEMU is used as the virtual machine manager, and virt-manager is used for management. Here I use the Windows 11 virtual machine for operations.
My reproduction-related files are sourced from Syss's Github repository, with tool version adaptation and handling of some unexpected cases added on top. They can be used directly after downloading, or modified as needed. The virtual machine image files come from UUP Dump, which provides various Windows versions for download. After downloading, run the cmd or sh file to obtain the ISO image file.
The installation and usage of QEMU and virt-manager are not detailed here. However, new users should enable XML editing in virt-manager via "Edit -> Preferences -> General -> Enable XML editing" so we can directly edit the virtual machine's XML configuration file.
When creating the virtual machine, select "Local install media (ISO image or CDROM)" and choose the previously downloaded Windows 11 ISO image. Allocate appropriate resources (CPU, memory, disk space, etc.), and make sure to select "Customize configuration before install" so we can edit the configuration before installation. At this step, there might be issues with automatic OS detection; in that case, manually select "Microsoft Windows 10/11".
Now we start configuring. The most important point (because this cannot be changed later, while other settings can be modified after creation): in the Overview tab, select Firmware as "UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.ms.fd". If this is not selected, simply delete the virtual machine and recreate it—it's not troublesome.

Then go to the "Boot Options" tab and ensure "SATA CDROM 1" is checked; otherwise we cannot install the system. You can move "SATA CDROM 1" to the top of the list for simpler booting. At this point you can create the VM directly; after installing the system, we will make the remaining configuration modifications.
See "Press any key to boot from CD or DVD..."? Press any key to enter the installation interface and follow the prompts to complete the installation. If you accidentally enter the wrong page, don’t panic—select "Boot Manager", then choose "UEFI: QEMU DVD-ROM" to return to the original interface and press any key to boot.

Next, install the system; directly check "I don't have a product key" and install the Professional edition. Then you'll go through account registration and other steps; it is recommended to use offline account creation to minimize hassle. If this option is not available, open the command prompt with Shift + F10 and enter OOBE\BYPASSNRO to enable the offline account creation option.
After successfully entering the system, you can type msinfo32 in the terminal to view system information (on the physical machine, check if it is UEFI), then shut down the virtual machine and modify the configuration:
<rom enabled="no"/> to enable network boot. Example:<interface type="network">
<mac address="52:54:00:2f:53:4e"/>
<source network="default"/>
<model type="virtio"/>
<boot order="2"/>
<rom enabled="no"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
Using virtio network configuration mainly takes advantage of its "paravirtualized" network hardware, which communicates directly with the host. Meanwhile, disabling the network boot ROM is to let the UEFI firmware communicate directly with the virtio NIC via the built-in PXE protocol, avoiding unnecessary interference during the boot process, ensuring we can smoothly enter the system for subsequent configuration and testing.
Enter the virtual machine, install the virtio driver from the CD drive (this will be done automatically), and test the network connectivity briefly. Then, enable BitLocker encryption; you can create a flag file on the desktop for later verification.
If reproducing on a physical machine, simply connect the attacker and victim machines via an Ethernet cable; there is no need to configure virtio. Other configurations are essentially the same, but note that the physical machine may have multiple network interfaces, so you need to select the correct interface for configuration.
The victim machine configuration is now complete. Shut it down, and we can proceed with the vulnerability exploitation steps as outlined in the principle of the exploit.
Here we provide a reference diagram of the full attack process; you can get a general idea first, and we will implement it step by step later:

The local machine (attacker machine) must have the following packages installed:
On Ubuntu or Debian, you can install them with the following command:
sudo apt install dnsmasq libwin-hivex-perl python3-impacket
In the provided project files, execute the build.sh script to generate bitpixie-initramfs. If you need to adapt the environment locally, modify the settings in build.sh to configure the desired tools and version files, then regenerate bitpixie-initramfs.
Then, enter ifconfig in the terminal to query the local (attacker) virtual gateway. Below is an example from my local machine:
virbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.123.1 netmask 255.255.255.0 broadcast 192.168.123.255
ether 52:54:00:23:11:39 txqueuelen 1000 (Ethernet)
RX packets 46749 bytes 4384179 (4.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 67170 bytes 414459630 (414.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Use the following commands to start the TFTP server (for the PXE boot process) and the SMB server (for transferring the modified BCD file). Fill in the interface we just queried—in my case virbr0.
# Start the TFTP and the DHCP server
./start-server.sh pxe <interface>
# Start the SMB server for the transfer of the BCD file
./start-server.sh smb <interface>