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

DarkShadowMD · 2026-07-08T17:46:50-0400

NikosD said:
@garlin
@DarkShadowMD
@Asus272
@t2s50

I'm not an expert in this field but it seems that the Update powershell script doesn't reflash the BIOS — it writes to UEFI authenticated variables (KEK/DB/DBX) that live in a small NVRAM partition inside the SPI flash chip, separate from the main firmware volume.

That write is what CMOS-battery-pull and the CLR_CMOS jumper can't touch — those only reset the CMOS settings block (boot order, dates, fan curves), not the Secure Boot variable store.

The firmware's own sanity-check on boot sees a malformed Secure Boot variable and halts very early — before it even gets to POST code that would normally trigger video output or the recovery-USB key combo detection.

The BIOS Recovery via USB feature depends on a small recovery boot-block actually executing to detect and read the USB stick — if that path itself is gated behind the corrupted variable store (or if the initial POST hangs before reaching it), the recovery flow never triggers, even though you've formatted the stick and named the file correctly.

This is different from a normal "bad BIOS update" brick, where the recovery boot-block is generally safe because it's stored in a protected/write-locked region.

A raw NVRAM corruption from a botched variable write can sit outside that protected region and just wedge everything before recovery logic runs.

The corruption is inside the flash chip's variable store, not the settings CMOS keeps.

Your problem seems to rely in how your system stores the certs in fact. I've known for a fact that certs are stored in a non volatile chip, that way if the battery dies, you still can boot your OS without having Secure Boot violations.

Your GPU is less likely to be corrupted, because VBIOS is a firmware like BIOS, and you can't modify it if you don't use specialized tools, and a fresh copy of a firmware for that card. iGPUs don't really have this and rely on a very basic instruction set, they lack a firmware per say (I think), instead you update your CPU microcode, which may include updates for the iGPU... I might be wrong because there are systems with iGPUs that aren't exactly embeeded in the CPU chip (They are in the MoBo) and they could have firmware updates... still unoikely because a BIOS flash would include something for that as well...

Looks like somewhat, the chip where the certs are stored just went nuts or currupted during the update and caused this issue. There are some reprogramming interfaces that might help you recover the system if you cant use a recovery flash method...

Don't your system allow to use an emergency method to reflash your BIOS? That should make it and recover your system, if not... you will need some sort of SPI-whatever the name is interface to reprogram the BIOS and/or the NVRAM where the certs and SB variables are stored.

More than that, I'm run out of ideas... and that would mean a technician could recover your system if they have the tools.

gunrunnerjohn · 2026-07-08T17:58:06-0400

NikosD said:
@JLArranz
Thank you for your time and trouble to write the post above, but it really isn't helpful, it's chaotic and irrelevant.
With no offense it would be better if you delete it completely, if possible in this forum.

Guys, if you are not an expert on this issue please do not reply in this thread.
I have done more than everything to recover the BIOS, it's not possible.

It needs hardware reprogramming, a service with a cost of around 75€ here where I live (Greece).

Please read carefully my previous message, because if the above description of the issue is accurate, I think you should think twice to run the scripts.

In my opinion, for users with old BIOS like mine, the scripts should be b a n n e d.

There must be warnings regarding the use of the scripts, the risk is high.

You're solution is to junk the car because it got a flat tire! Hundreds if not thousands have used the update scripts without bricking the machine. Hell, if that was the benchmark, none of us would be using Windows or various other software packages!

You waltz in here like a bull in a china shop and want to sink the ship!

JLArranz · 2026-07-08T18:43:30-0400

Is this part of my previous post potentially useful?

The Lenovo ThinkCentre M700 Tiny with the latest BIOS version (FWKTBFA 2022) is prone to POST hangs (black screen and often two short beeps) if Secure Boot variables are incorrectly modified or key debug mode is enabled.On this Lenovo series (M700/M800/M900), simply disconnecting the CR2032 button battery is usually not enough to clear the NVRAM storage where the corrupted Secure Boot variables are housed. It is imperative to force a Boot Block Recovery using the physical jumper on the motherboard.Procedure to unlock the POST on the M700 TinyFollow these exact steps to force the BIOS to clear corrupt variables and rewrite factory settings: Electrical isolation: Turn off the computer, disconnect the external power cable, and remove any peripherals or USB cables. Open the chassis: Remove the rear case screw and slide the top cover forward to remove it. Locate the CMOS Jumper: Look on the motherboard for a plastic jumper that rests on three metal pins, usually labeled CLR_CMOS or CLR_PWD (near the button cell battery or RAM slots). By default, it will be placed in the standard operating position (Pins 1 and 2). Switch to recovery mode: Carefully remove the jumper and place it in the erase/recovery position (Pins 2 and 3). Ignition cycle: Only connect the power cable and turn on the equipment. The M700 Tiny will turn on automatically. It will have no video signal, but will begin to constantly emit a series of two short repetitive beeps (indicating that it has entered recovery mode and is purging NVRAM). Leave the computer on in this state for approximately 15 to 20 seconds. Forced shutdown: Press and hold the front power button for 5 seconds until the computer turns off completely. Disconnect the power cable again. Reverse jumper: Move the plastic jumper back to its original position (Pins 1 and 2). Note: If you forget this step, the device will enter a beep loop at each startup. POST Test: Replace the cover, connect the monitor and power cable. Turn on the PC. The first boot will take a little longer than usual and will display a message warning that the date and time are not set ("Error 0199" or similar). Press F1 (or Fn + F1) to enter the BIOS and load the optimized defaults.If after performing this procedure the device still has a black screen, please inform me: Does the device emit any beep code when turned on? Do you have a processor with integrated graphics installed or do you use some type of video adapter (DisplayPort to HDMI)?I can guide you through alternative methods if the NVRAM has become permanently blocked.AI responses may contain errors.

I ask this b/c this method isn't "removing the CR2032 battery", like for example:

Your descriptiion is pretty much correct. Some machines have a routine to reset the NVRAM when a jumper is set or a button pressed when starting, but the normal case is that a corrupt NVRAM can't be reset with removing the battery.

In the past I've had very slight problems "de-bricking" non UEFI motherboards with the following problem: somehow the CR2032 battery was depleted. Usually a mobo message (in that age mobos posted many many many messages, even if booting correctly, what is an advantage) complaining about the BIOS settings not being fine or with similar wording. Sometimes the output ends with something like "press F2 to get into the BIOS", sometimes it enters the BIOS itself and everything looks as at default settings (although it's wise to load defaults anyway before setting everything at your taste again), sometimes it hangs and you have to reboot to tap F2 in due time to enter the BIOS (F2 or whatever key needed).

These motherboards seem to have a (physically) extremely strong recording of the BIOS program (EEPROM?) totally independent from where the settings are (you cannot flash these BIOSes in milliseconds or nanoseconds, it usually takes more than a full minute!!!!!!!!!!!). The BIOS has a routine to display that it cannot work with what it has as settings (or maybe you have to guess it in some cases). This situation can be considered as a successful POST, although it might have beeped or not and certainly it cannot progress w/o a visit to the BIOS. A failed POST would happen if for example, instead of entering the BIOS etc, I shut down and replace the gfx card for a bricked one.

Does the BIOS program live in the same NVRAM or CMOS as the typical NVRAM or CMOS contents? Was it overwritten? I see that removing the CR2032 in such a design would delete the BIOS or part of it, otherwise I cannot see how a software problem can prevent the POST. I don't know how is this design. Does it block the POST for security? Sorry for supposing previously that the BIOS program is safe except physical failure, and the other suppositions. Once I realized this thing could be made of resistors instead of transistors (or whatever else is happening, I know the active/passive distinction etc), I called the experts.

NikosD · 2026-07-09T00:04:13-0400

garlin said:
There is a possible risk to updating the certs on some older BIOS'es, where less flash memory was allocated to storing the Secure Boot variables. It's difficult to know in advance if your PC has one of those chips. For the most part, we've only had 3 "bricked" PC's reported (including yours) after trying to clear the default keys and installing new keys.

Compared to the (I presume) hundreds of users who have successfully run the script on unsupported PC's.

I don't believe the script is the problem, as you would have likely encountered the same problem trying to apply the X509 certs or EDK2 bin files by hand.

One long-term Secure Boot engineering concern that has been reported is older chips may not have enough space to fit the full set of DBX entries, which include the revoked PCA 2011, the SVN's and all of the EFI signature hashes for banned boot files. When that space is overflowed, corruption will happen. This why MS moved to banning PCA 2011, instead of listing every obsolete version of the Windows boot manager in the EFI hash list.

A contributor on the Acer community forum has suggested some of their older PC's suffer a problem because their BIOS'es have a design limitation with space allocation.

Before this case, we didn't have any similar reports of unusable Lenovo systems. The best we can do is learn from each lesson, and I will put a check for Lenovo M700 systems.

I think your description is accurate, it's an issue of space allocation and size.

My BIOS is 8MB and the area provided for Secure Boot variables was overflowed by some keys, some DBX entries were just too big to fit - probably like PCA 2011 you mentioned that MS has banned.
The -Revoke switch did that, as you described.

My point of view that @gunrunnerjohn didn't see but it should be obvious from my previous post describing the situation, is that the procedure is of high risk due to the fact that IF a n y t h i n g goes wrong, like a small allocation space for Secure Boot variables, there is no safety net to recover the BIOS using software means.

it's technically impossible.

You have to go to a costly hardware reprogramming solution.

This is an issue for the whole concept of manually forcing Secure Boot variables update to any machine out there, by using just a powershell script forcing the update.

It's like a salto mortale...Many athletes of circus do it with success, most of the time, they jump and flip in the air without a safety net, until they fail...

You already got three bricked PCs, I think a safety net is mandatory.

Anyways, I stripped the Lenovo M700 tiny of any usable hardware and put it to a hardware cemetery.

RIP Lenovo ThinkCentre M700 Tiny, you served well.

FIREMEDIC2700 · 2026-07-09T02:45:09-0400

gunrunnerjohn said:
You're solution is to junk the car because it got a flat tire! Hundreds if not thousands have used the update scripts without bricking the machine. Hell, if that was the benchmark, none of us would be using Windows or various other software packages! You waltz in here like a bull in a china shop and want to sink the ship!

that is 100 percent correct .

garlin · 2026-07-09T02:49:44-0400

This is annoying, MS just released a newer version of the edk2-x64-secureboot-binaries.zip (v1.6.5).

In the April 2026 Monthly Update, they purged 154 DBX entries to save space in the NVRAM. But this reduction wasn't reflected into the latest EDK2 files, they still have those 154 entries! So if you wiped your DBX keys and applied the Windows version of DBXUpdate.bin, you would be using less space than the reference copy of DefaultDBX.bin for OEM's.

I don't get this repeated business of MS's right hand not listening to its left hand. :facepalm:

FIREMEDIC2700 · 2026-07-09T03:00:45-0400

Just currious has ms even started auto revoking of the certs yet ???
I guess thoses of us that revoked them mannually will never know

geekdom · 2026-07-09T06:52:02-0400

garlin said:
In the April 2026 Monthly Update, they purged 154 DBX entries to save space in the NVRAM. But this reduction wasn't reflected into the latest EDK2 files, they still have those 154 entries! So if you wiped your DBX keys and applied the Windows version of DBXUpdate.bin, you would be using less space than the reference copy of DefaultDBX.bin for OEM's.

Is there a retrofit?

garlin · 2026-07-09T10:29:59-0400

FIREMEDIC2700 said:
Just currious has ms even started auto revoking of the certs yet ???
I guess thoses of us that revoked them mannually will never know

No. MS previously committed to providing a 6-month heads up before mandatory revocation happens. 2026 is halfway gone, and still no official timeline.

The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins. When updates are released for the Enforcement Phase, they will include the following:

The “Windows Production PCA 2011” certificate will automatically be revoked by being added to the Secure Boot UEFI Forbidden List (DBX) on capable devices. These updates will be programmatically enforced after installing updates for Windows to all affected systems with no option to be disabled.

anchamp65 · 2026-07-09T10:33:01-0400

garlin said:
This is annoying, MS just released a newer version of the edk2-x64-secureboot-binaries.zip (v1.6.5).

In the April 2026 Monthly Update, they purged 154 DBX entries to save space in the NVRAM. But this reduction wasn't reflected into the latest EDK2 files, they still have those 154 entries! So if you wiped your DBX keys and applied the Windows version of DBXUpdate.bin, you would be using less space than the reference copy of DefaultDBX.bin for OEM's.

I don't get this repeated business of MS's right hand not listening to its left hand.

Way To Go Champ ! <-- for MS

But since we've updated to 2023 certs shouldn't we just let MS take care of updating the DBX from this time forward ?
I mean we could obviously use your script that uses MS ways and repos to update our computers, but MS should be taking care of future updates, even on computers that initially were having difficulty getting the updates.

garlin · 2026-07-09T10:47:08-0400

geekdom said:
Is there a retrofit?

If you have a newer (or not too old) PC, there should be enough available NVRAM. It's some older PC's that need to be concerned because they have earlier chips which have less memory to begin with.

I wouldn't recommend doing this generally, but what you can do is enter the BIOS and clear all of the DBX keys. Some BIOS'es may make this easy, and others you might have to click to delete each DBX entry over and over (didn't say this was easy). Afterwards you would run the update script with the revoke option, and it will apply the missing DBX entries from the Windows version of the DBX update files.

garlin · 2026-07-09T10:57:44-0400

anchamp65 said:
But since we've updated to 2023 certs shouldn't we just let MS take care of updating the DBX from this time forward ?
I mean we could obviously use your script that uses MS ways and repos to update our computers, but MS should be taking care of future updates, even on computers that initially were having difficulty getting the updates.

MS is responsible for the DBX. What they did is the right thing on the Windows side, but the other hand forgot to push the same changes to the public repository where MS is supposed to represent Secure Boot changes to the world (without someone needing to have Windows).

What you have on the GitHub more or less what it looked like before April 2026. I'm stumped as to why the GitHub is so far behind to recent Windows changes and so disorganized. To me, it would seem simple. Principal Secure Boot folks within MS make the top-level decisions (not lightly) on upcoming changes. Those updates should get pushed to Windows releases and the GitHub in parallel.

We're talking about changes rolled out in April... which means the Windows team knew about the changes at least in March when they planned the April Monthly Update since all non-emergency security changes can only be released on Patch Tuesday's.

Dirtyflash · 2026-07-09T13:11:49-0400

@garlin Do you know how much free space would currently be needed for any future updates to the DBX? I imagine you would have to guess, but a ballpark figure if you have an idea?

bikemanAMD · 2026-07-09T13:15:17-0400

Hello Everyone
Good Afternoon!!

Issue: Had some problems with games running on my Asus TUF A16 Gaming Laptop (FA617NT.A16.R7700)
Created the USB flash drive with Rufus thinking it would be fine with Secure Boot enabled--it did not

Went into bios turned Secure boot to disabled to finish the Windows install

Will it boot when i turn it back on Later? Or will i have more problems

As i want Secure Boot on like Desktop machine as i have a Few Games that require Secure Boot to be on, Call of Duty Warzone as an example on the Gaming Laptop, Battlefield 6 on the Desktop both require Secure Boot On

HeavyHemi · 2026-07-09T13:23:47-0400

bikemanAMD said:
Hello Everyone
Good Afternoon!!

Issue: Had some problems with games running on my Asus TUF A16 Gaming Laptop (FA617NT.A16.R7700)
Created the USB flash drive with Rufus thinking it would be fine with Secure Boot enabled--it did not

Went into bios turned Secure boot to disabled to finish the Windows install

Will it boot when i turn it back on Later? Or will i have more problems

As i want Secure Boot on like Desktop machine as i have a Few Games that require Secure Boot to be on, Call of Duty Warzone as an example on the Gaming Laptop, Battlefield 6 on the Desktop both require Secure Boot On

It should still boot fine if you did not change anything regarding secure boot in the BIOS except for enabling or disabling.

garlin · 2026-07-09T13:23:51-0400

Secure Boot is never required for Windows installation, or for booting Windows.

However some AAA games demand Secure Boot mode. They really don't care about certs, what they want is for Virtualization Based Security or Core Integrity to be enabled. This makes it easier to block cheat apps since cheating is mostly done by shady kernel drivers. With Secure Boot, it's less likely cheat code is able to properly execute. The driver signing requirements are much stricter with VBS.

You can always temporarily disable Secure Boot to install Windows. If you can't install in Secure Boot mode, it probably means you don't have a properly updated install ISO. After you have Windows installed, you can run the normal updates and confirm everything is good before enabling Secure Boot.

Some people claim having Core Integrity "makes their PC/game slow". Which may be true. But now all the AAA games require Core Integrity so while it sucks performance, it should be an even playing field since everyone has to have it. Go blame the cheaters for this sad state of affairs.

HeavyHemi · 2026-07-09T13:33:46-0400

garlin said:
Secure Boot is never required for Windows installation, or for booting Windows.

However some AAA games demand Secure Boot mode. They really don't care about certs, what they want is for Virtualization Based Security or Core Integrity to be enabled. This makes it easier to block cheat apps since cheating is mostly done by shady kernel drivers. With Secure Boot, it's less likely cheat code is able to properly execute. The driver signing requirements are much stricter with VBS.

You can always temporarily disable Secure Boot to install Windows. If you can't install in Secure Boot mode, it probably means you don't have a properly updated install ISO. After you have Windows installed, you can run the normal updates and confirm everything is good before enabling Secure Boot.

Some people claim having Core Integrity "makes their PC/game slow". Which may be true. But now all the AAA games require Core Integrity so while it sucks performance, it should be an even playing field since everyone has to have it. Go blame the cheaters for this sad state of affairs.

Hmm... I have a lot of AAA titles. None of them so far require core integrity to be enabled. My bit of searching hasn't identified one that does. TPM and secure boot are though.

bikemanAMD · 2026-07-09T13:35:27-0400

Ok Re Enabled secure boot once Windows updates finished installing

Booted fine back into Windows

Proceeds to finish driver installs, and rest of it lol

Then hopefully all works fine after all this lol

I knew i should've done this months ago instead of Cloning the external ssd to internal M.2 for the Games lol, always had problems running Need For Speed Hot Pursuit Remastered on that system

Then again it didn't wanna run recently on Desktop either lol

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

Peaceful Citizen

My Computers My Computers

At a glance

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Active member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Active member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

My Computers

My Computers

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computers

My Computer

My Computer

My Computer

My Computers