Boothole Fixlet

Hello all,

Has anyone tried addressing the Windows Boothole vulnerability by following Microsoft’s guidance and running a few PowerShell scripts on the machines (

I created a fixlet to address this vulnerability. The SplitDB script seems to be working but the second command to run the command to update the certificates in the boot loader seems to be failing.

I’ve tried running the same commands in a “SYSTEM” powershell via psexec and they work. Just curious how other folks have skinned (or not skinned) Boothole.

The fixlet content (note, I’ve been playing around with different versions of this fixlet so there might be a few lines that don’t fit/make sense (like deleting a file that is not later used) is below:

// Download files from Cloud Storage
download as dbxupdate_x64.bin "http://SuperAwesomeCloudStorageURL/filename"
download as SplitDbxContent.ps1 "http://SuperAwesomeCloudStorageURL/filename"
download as bootHoleFix.ps1 “http://SuperAwesomeCloudStorageURL/filename

//Delete any existing files that may cause a conflict
delete "c:\temp\boot.ps1"
delete "c:\temp\signature.p7"
delete "c:\temp\content.bin"
delete "c:\temp\dbxupdate_x64.bin"
delete "c:\temp\bootHoleFix.ps1"
delete __createfile
delete __appendfile

//Check if temp folder exists
if {not exists folder “C:\temp”}
folder create "c:\temp"

//Move files to temp
move __Download\dbxupdate_x64.bin "c:\temp\dbxupdate_x64.bin"
move __Download\SplitDbxContent.ps1 "c:\temp\SplitDbxContent.ps1"
move __Download\bootHoleFix.ps1 “c:\temp\bootHoleFix.ps1”

waithidden { pathname of file ((it as string) of value “Path” of key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell” of native registry) } -ExecutionPolicy Bypass -File “c:\temp\SplitDbxContent.ps1” “c:\temp\dbxupdate_x64.bin”

waithidden { pathname of file ((it as string) of value “Path” of key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell” of native registry) } -ExecutionPolicy Bypass -File “c:\temp\bootHoleFix.ps1”

delete "c:\temp\boot.ps1"
delete "c:\temp\SplitDbxContent.ps1"
delete "c:\temp\signature.p7"
delete "c:\temp\content.bin"
delete "c:\temp\dbxupdate_x64.bin"
delete “c:\temp\bootHoleFix.ps1”

//Pending Restart
action requires restart “BootHole Fix”

1 Like

I am not really familiar with the use case you are using but just looking at the actionscript the first thing I would try is to add the line to disable the x32 redirection - by default all scripts would run in x32 mode and a lot of the PS commandlets and in fact batch commands work when ran as x64 but do not as x32. Hard to tell whether that is what you are facing since the ps1 files are not available but it certainly does not hurt to rule it out, especially since you use relevance sustitutions with “native registry” which would point to x64 branch of registry; x64 bin file; etc). Stick the following line on top of the actionscript and see what you get when you execute it:

// This would disable the redirection on all x64 OS and for any x32 OS (if you have any left in fact) it will run as default x32
action uses wow64 redirection {not x64 of operating system}


Excellent catch. I did have that added in one version but must not have really tested it out (or I had made too many other changes - always the death of testing).

Adding that at the top of the fixlet’s action script appears to have allowed it to run and remove the buggery that is boothole.



This was very helpful. Thanks for posting and working out the resolution. Since the update is specific to the machine architecture, I added the following relevance to check

x64 of operating system and exists (values “PROCESSOR_ARCHITECTURE” whose (it as string as lowercase = “ia64” OR it as string as lowercase = “amd64” OR it as string as lowercase = “64”) of keys “HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment” of registry)

1 Like

Has anyone experienced boot or other issues applying this update, or has it been straightforward. Just checking around to see what experience others have had. Thanks