Solved garlin's PowerShell scripts for updating Secure Boot CA 2023

garlin said:

One workaround is to temporarily disable Secure Boot during Windows installs. Then re-enable it when you're done.

It beats the game of trying to update your images every time a new boot manager drops.

Click to expand...

yes, that's much easier than updating each usb drive all the time.
However, I noticed that on the Surface Pro 4, disabling Secure Boot also erased all Secure Boot Keys.
The UEFI on this device's very basic.

garlin said:

I'm not certain the paid Macrium users will have it any better, unless the backup vendors have some plan that resembles this:

1. When you first ask to create a recovery drive, it logs the current SVN number inside the backup software's config.

2. Every time the backup software wakes up to run, it checks the UEFI's SVN number again. If the SVN has changed from the recorded number, then inform the user that a new recovery drive is needed.

3. When the user creates a new recovery drive, log this SVN number to the software's config. Rinse and repeat.

Now because it requires new code, obviously your Macium 8 free users are stranded.

But in theory, a similar solution could be written as an outside script. You write the current SVN down into a file, and every day you check for changes. Every day, because we don't know if everyone installs their Monthly Update on the same day. When the SVN changes, alert the user and then keep nagging them until they run the script to acknowledge they've done the update.

Rinse and repeat.

Click to expand...

Not ideal, I fear that most people will leave secure boot disabled permanently for convenience.
But Macrium 8.0 Free usb drives (thanks to Garlin's script) and Rufus usb drives are easy and fast to update unlike Ventoy.

Weird question: As usual, I'm manually updating Windows, I don't think there's a way to manually update the computer's boot manager using your script... is it?
My last update was in February, using the preview Update for that month. I have SVN 7.0 and the other stuff at 3.0
If there is, that would rock!
Thanks in advance X3

garlin said:

I'm not certain the paid Macrium users will have it any better

Click to expand...

We do not, at least for now. Maybe that will change. Hope springs eternal.

DarkShadowMD said:

Weird question: As usual, I'm manually updating Windows, I don't think there's a way to manually update the computer's boot manager using your script... is it?
If there is, that would rock!
Thanks in advance X3

Click to expand...

When the update script runs, it will check if your Windows boot manager (in the EFI partition) doesn't match the current version in the \Windows\Boot folders and copies the right version over.

There's a sanity check to make sure it doesn't copy the CA 2023-signed boot file, if your UEFI doesn't have a KEK CA 2023 and Windows UEFI CA 2023 cert already installed in Secure Boot mode. If you need to update a bootable USB drive, leave it plugged in and run the update script with the -BootMedia option.

UPDATE: 2026-04-21

EMERGENCY HOTFIX for Update_UEFI-CA2023.ps1 script, due to April 2026's Monthly Update pushing a bad DBXUpdate2024.bin file.

In order to ban the PCA 2011 certificate, the normal procedure is to append DBXUpdate2024.bin to the DBX variable. This should add the PCA 2011 cert and 3 SVN's (all marked as 2.0).

Instead, the April 2026 version of DBXUpdate2024.bin contains PCA 2011 and 3 SVN's (marked 5.0 for Windows BootMgr). But this file cannot be analyzed by Matthew Graeber's or Ry Auscitte's scripts for reading DBX files. Furthermore, my update script fails when applying the file, due to a wrong signature.

This strongly leads me to the conclusion, MS inadvertantly pushed a corrupted file to the SecureBootUpdates folder.

I have filed a high priority bug report on the Secure Boot Objects GitHub. While we're waiting for MS's response, I've temporarily changed the update script to bypass the SecureBootUpdates folder's version of the file, and instead download an older copy from the GitHub repo.

IF YOU WANT TO PERFORM THE REVOCATION, BUT HAVE NOT STARTED, PLEASE DOWNLOAD THE LATEST ZIP FILE FROM POST #1.
garlin's PowerShell scripts for updating Secure Boot CA 2023

IF YOU HAVE ALREADY REVOKED THE PCA 2011 CERT, NO ACTION IS REQUIRED. YOU ARE NOT AFFECTED.
I KNOW SOME OF YOU WON'T READ THE PREVIOUS LINE. READ IT TWICE.

Hey Garlin is Get-SecureBootSVN still bugged? Because my dads pc is showing

FirmwareSVN : 5.0

While my other 2 pcs have gone from 2.0 - 8.0

Hi,

Here are the steps to update your USB drives for Rufus & Ventoy with Windows 10 22H2 ISO updated October 2025 for Windows Boot Mgr SVN 8.0 and don't want to disable Secure Boot.
Of course, this should work with Windows 11 too!
IMPORTANT: Remember to update your Windows bootable media to use the PCA2023 signed boot manager:
Updating Windows bootable media to use the PCA2023 signed boot manager - Microsoft Support


1) Rufus 4.13

Open Powershell as administrator and type the following commands :
mountvol s: /s
copy S:\EFI\Boot\bootx64.efi c:\bootx64.efi
mountvol s: /d
Overwrite the bootx64.efi file on USB "DriveLetter:\efi\boot\bootx64.efi" with the updated file from c:\bootx64.efi.
IMPORTANT: Replace DriveLetter with the letter matching the partition where the ISO's been extracted not the partition containing a Rufus folder and an EFI folder. Overwriting bootx64.efi on that partition will make your USB drive unbootable.


2) Ventoy 1.1.11

I found out why I was unable to boot from my USB drive with Ventoy with Windows 10 22H2 ISO updated October 2025 after updating the Windows Boot Mgr SVN to 8.0 from 7.0 using the registry "trick".
I managed to boot from Ventoy after updating my Windows 10 22H2 ISO to April 2026, it took over an hour for just one index!
Comparing the 2 Windows 10 ISOs, I worked out the difference between them.
Ventoy differs from Rufus, you have to format your USB drive with Ventoy & then you can copy your ISOs on the USB drive.
But you've got to edit the ISO first before copying it to your USB drive.

Open Powershell as administrator and type the following commands :
mountvol s: /s
copy S:\EFI\Boot\bootx64.efi c:\bootx64.efi
copy S:\EFI\Microsoft\Boot\bootmgr.efi c:\bootmgr.efi
mountvol s: /d
Download and run the portable version of AnyBurn Free. Choose Edit image file and choose your ISO.
Delete bootmgr.efi and replace it with the updated file, do the same for bootx64.efi in efi\boot\ , save your updated ISO.


NB: The file bootmgfw.efi in S:\EFI\Microsoft\Boot\ is the same as bootx64.efi in S:\EFI\Boot\ but with a different name.

Would like your guidance for this error:



And this output:




Thanks in advance.

neldog said:

I found this out yesterday when I checked my USB stick for the fun of it and was banned. I ran your code to fix it.

Code:

copy C:\Windows\Boot\EFI_EX\bootmgfw_EX.efi D:\EFI\Boot\bootx64.efi

Click to expand...

@garlin Will we have the same problem with a Windows Recovery Drive that was created, let's say, months ago?

JamesSmith said:

Hey Garlin is Get-SecureBootSVN still bugged? Because my dads pc is showing

FirmwareSVN : 5.0

While my other 2 pcs have gone from 2.0 - 8.0

Click to expand...

Yes. The fix won't ship until May 2026 until the earliest.

Nicolast said:

NB: The file bootmgfw.efi in S:\EFI\Microsoft\Boot\ is the same as bootx64.efi in S:\EFI\Boot\ but with a different name.

Click to expand...

Correct. They're the same file.

In some boot scenarios, the UEFI is looking for bootmgfw.exe and when it cannot find it, looks for bootx64.efi. The problem is the two files are expected to live in different folder paths.

nikki605 said:

@garlin Will we have the same problem with a Windows Recovery Drive that was created, let's say, months ago?

Click to expand...

If your SVN is now 8.0, then all your recovery drives need to have their boot files updated.

From Oct 2025 to this month's Patch Tuesday, SVN was 7.0. Any USB drive that was created or updated during those months falls under the category that the boot file needs replacement (again).

JohnSmith13 said:

Would like your guidance for this error:

Code:

Cannot convert value "System.Byte[]" to type "System.Guid". Error: "Byte array for Guid must be exactly 16 bytes long. (Parameter 'b')"

Click to expand...

JohnSmith13 said:

Code:

    SkuSiPolicy.p7b is WRONG VERSION.
Cannot convert value "System.Byte[]" to type "System.Guid". Error: "Byte array for Guid must be exactly 16 bytes long. (Parameter 'b')"

Click to expand...

That's not the latest version of the scripts. Please download the ZIP file (not the GitHub version) from post #1 in this thread.

garlin said:

If your SVN is now 8.0, then all your recovery drives need to have their boot files updated.

From Oct 2025 to this month's Patch Tuesday, SVN was 7.0. Any USB drive that was created or updated during those months falls under the category that the boot file needs replacement (again).

Click to expand...

Thanks. I thought that was going to be the case. I'll recreate my 2 recovery flash drives.

I assume I am ok ?
*******************
EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 28000.322, SVN 8.0

Registry: WindowsUEFICA2023Capable = 2
[Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

SkuSiPolicy.p7b is CURRENT.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b
Version: 3.0.0.14

STATUS REPORT
-------------
Registry: UEFICA2023Status = Updated

SUCCESS: UPDATES ARE FINISHED.
UEFI CA 2023 certs are present, PCA 2011 cert is revoked.

And Yes I had to redo all my backup USB Stuf.

garlin said:

That's not the latest version of the scripts. Please download the ZIP file (not the GitHub version) from post #1 in this thread.

Click to expand...

It most certainly is the latest version of the scripts, from the zip file, downloaded mere hours ago.
I know you don't have time to waste.
I would not have bothered you otherwise.

Klaver7 said:

SUCCESS: UPDATES ARE FINISHED.
UEFI CA 2023 certs are present, PCA 2011 cert is revoked.

Click to expand...

You're done.

JohnSmith13 said:

It most certainly is the latest version of the scripts, from the zip file, downloaded mere hours ago.
I know you don't have time to waste.
I would not have bothered you otherwise.

Click to expand...

The latest Check_DBXUpdate.bin.ps1 no longer skips over DBXUpdate2024.bin, and you would never get "exactly 16 bytes long" since that part's been replaced. So no, it's not the latest version of the ZIP file attached in Post #1.

UPDATE 2026-04-22:

MS replied and admitted they changed DBXUpdate2024.bin to a different file format. The Secure Boot scheduled task knows how to deal with it, but anyone who's writing scripts based on the "normal" format will have problems because they added extra bytes of unexpected data.

The next version of DBXUpdate2024.bin (in May) will return to the usual file format.

There's the explanation of why the scripts stopped working after April's Patch Tuesday. Workarounds have been put into the scripts, so remember to download the latest ZIP file so you don't get any errors.

I'm really the only one you can trust.