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

@DarkShadowMD
Well, having my last thoughts on the issue, not my final verdict because I miss a lot of technical details, i think that Microsoft and the scripts and whatever mess with Secure Boot variables should do a sanity check, a simple check to see if the keys/certs that is going to write at a specific space can fit or not.

It sounds simple, but I really don't know if it's feasible and if MS or a third party developer can do it or not.

Because I think in my case the powershell script tried to write a Secure Boot variable in a specific space with less capacity than the size of the variable and the result was a corrupted file (because obviously the file was written up to the point where the space provided for the specific variable was filled, not the whole file obviously).
This check is to prevent the failure before starting to write the file.

Another option would be an integrity test afterwards to check after the update if the whole file was written properly and if it didn't, it could cancel the whole procedure and revert back to the original values.

Just some thoughts regarding the issue - as a safety net that I posted above - to prevent future bricks, a developer like Garlin or MS could think and implement better ones.

Now regarding the MS vs Garlin scripts implementation and execution of Secure Boot variable updates, I really can't judge because I don't know if MS does any check before or after writing the update in order to avoid such failures.

As a last thought, I think my case was useful at least to remind or inform users of this thread that these scripts are messing with a part of the BIOS chip that if anything goes wrong and the NVRAM becomes corrupted, there is no software BIOS recovery solution, no clear CMOS settings, no jumper than can save you.

The PC is bricked and you have to seek for a costly hardware reprogramming of the BIOS chip.

And I don't know if MS is doing it differently, as I said before.

So let me understand this. you upgraded using garlins scripts or not ? and now the pc will not boot up at all

That's actually why MS collects telemetry data (high confidence/more data needed) and is constantly postponing cert push/revocation dates. Instead of MS or garlin, you should be fighting Acer, who designed their BIOS and NVRAM with no fallback mechanism which is stupid tbh.

NikosD said:

Well, having my last thoughts on the issue, not my final verdict because I miss a lot of technical details, i think that Microsoft and the scripts and whatever mess with Secure Boot variables should do a sanity check, a simple check to see if the keys/certs that is going to write at a specific space can fit or not.

Click to expand...

Garlin did mention this risk early in the thread and also mentioned there is no means of getting or guessing the size of the memory chip that manufacturer have installed on their motherboards.

As mentioned by Ozimen, it's your manufacturer you should be mad at, Lenovo in your case. I also took a gamble when updating my Lenovo L440 from 2013, I was lucky enough in that model Lenovo did not save pennies, most likely fraction of pennies, to add a few KB to the size of the memory chip that holds the NVRAM.

You also gambled, and unfortunately, yours seems it did not have enough KBs to hold the whole the data...

NikosD said:

It sounds simple, but I really don't know if it's feasible and if MS or a third party developer can do it or not.

Click to expand...

Having last thought on the issue, maybe you could reorient your career and become an engineer specialised in writing low level code in assembly or C++ that would be capable of determining the size of the memory chip that holds the NVRAM on the multiple manufacturers for computers over 10 years old and provide the service to the community freely like Garlin did with is script.

I think that more than enough memory size, what this design lacks is a properly managed "invalid settings" state. Ending up in this state (properly recognized and managed by the firmware or not) doesn't need any settings change, OS loading or program run, it can happen if the CR2032 fails (I use good quality AA and AAA batteries but in a 12 units pack there always may be one or two that don't have voltage or lose it after little time connected, I mean defective batteries), it can also be that the user left the computer off for months or years.

Is appliable the post #2623 recovery method? Fragment below:

[...]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) [...]

Click to expand...

JLArranz said:

I think that more than enough memory size, what this design lacks is a properly managed "invalid settings" state. Ending up in this state (properly recognized and managed by the firmware or not) doesn't need any settings change, OS loading or program run, it can happen if the CR2032 fails (I use good quality AA and AAA batteries but in a 12 units pack there always may be one or two that don't have voltage or lose it after little time connected, I mean defective batteries), it can also be that the user left the computer off for months or years.

Click to expand...

I agree with you, some manufacturers do plan for worst case scenario and have dual BIOS and recovery procedure that prevent this.
We all agree that it's very unfortunate for people that have computers that applying new certs and revocations can have undesirable results.

It's a gamble that each one of us most take on very old computers.

But this is becoming more of a manufacturing board design then a discussion on applying Secure Boot certificates.
Therefore, becoming off subject for this thread.

Let keep it at that, and return to the thread's subject...

@anchamp65

OK, at least we can agree that updating Secure Boot variables using the script is a gamble, a bet, a salto mortale than if anything goes wrong you lose your PC.
That kind of gamble.

Fair bet, but I'm pretty sure that most of the users of the script don't know this little information b e f o r e using the script.

I have to say that there must be h u g e warnings before running the script especially on older machines, explaining the situation and the risks.

Garlin must put this kind of info in run-time, users must know exactly the risks they take prior of updating the certs.

TY

NikosD said:

@anchamp65

OK, at least we can agree that updating Secure Boot variables using the script is a gamble, a bet, a salto mortale than if anything goes wrong you lose your PC.
That kind of gamble.

Fair bet, but I'm pretty sure that most of the users of the script don't know this little information b e f o r e using the script.

I have to say that there must be h u g e warnings before running the script especially on older machines, explaining the situation and the risks.

Garlin must put this kind of info in run-time, users must know exactly the risks they take prior of updating the certs.

TY

Click to expand...

Normal people, none technical, will not even try this because they have no understanding of what this is talking about.
So it's safe to assume that people looking at this thread and using these scripts have a minimum of knowledge on computers.
Then, it's for each one to take the gamble on old computers., period. <-- with the info you provided, you clearly fall in this category
And if someone does not have a minimum of knowledge and still uses the scripts provided here, it's their fault if they mess up their computers.

Let's leave it at that and move on...

I'm starting to believe that you don't pay attention to the replies given in this thread after posting my situation and my experience of using the scripts.

Users were trying to help me unbrick and save my PC by providing solutions referring to clear CMOS settings, even Garlin provided such kind of "solution" to the problem, the developer of the script.

Are you kidding me ?

How is this even possible, users with such real and deep understanding of the issue to post replies regarding CMOS settings ?

NikosD said:

How is this even possible, users with such real and deep understanding of the issue to post replies regarding CMOS settings ?

Click to expand...

How is it even possible you're still beating this dead horse. You've already proclaimed it's impossible to recover your BIOS, exactly what more are you hoping to accomplish browbeating people that are providing a valuable service?

I've bricked a old ASUS machine just using the manufacturer's supplied BIOS update program with the proper BIOS supplied by ASUS. I've never mentioned it here before because it's really not something anyone here is going to change. In your case, according to you it's "impossible" to recover. In that situation, I'd say case closed!

NikosD said:

I'm starting to believe that you don't pay attention to the replies given in this thread after posting my situation and my experience of using the scripts.

Users were trying to help me unbrick and save my PC by providing solutions referring to clear CMOS settings, even Garlin provided such kind of "solution" to the problem, the developer of the script.

Are you kidding me ?

How is this even possible, users with such real and deep understanding of the issue to post replies regarding CMOS settings ?

Click to expand...

I'd suggest to move on and stop making it look like Garlin... or the rest of us have some blame in your situation.

You have been told to go and tell Lenovo in any case. I mean, MS is poor at handling things, but saving money on NVRAM because your design is poor is on them. Your frustration is understandable, but you made a gamble and you lost sadly.

Don't think the rest didn't risk their butt, I had to update the BIOS in 3 systems, and even with a UPS is a risky operation, and I could have ended with one or two PC's bricked. MY older Acer could also get a worse case since it doesn't even have a BIOS update and MS just pushed an update as is...

Don't you think people here are geniuses that are supposed to guess how your system is supposed to look like. It's on Lenovo, go sue them and use the money to pay a tech to recover the NVRAM.

Blaming it on us won't solve your problem.

NikosD said:

How is this even possible, users with such real and deep understanding of the issue to post replies regarding CMOS settings ?

Click to expand...

how to clear/reset CMOS Lenovo

Erasing lost or forgotten passwords (clearing CMOS)

how to clear/reset secure boot Lenovo

https://pcsupport.lenovo.com/us/en/products/desktops-and-all-in-ones/thinkcentre-m-series-desktops/thinkcentre-m700-tiny/10j0/solutions/ht509044-how-to-enable-secure-boot-on-think-branded-systems-thinkpad-thinkstation-thinkcentre

please note these are done at your own risk
then you can try to update the secure boot certs.
best of luck Steve ..

XxXxX said:

how to clear/reset CMOS Lenovo

Erasing lost or forgotten passwords (clearing CMOS)

how to clear/reset secure boot Lenovo

https://pcsupport.lenovo.com/us/en/products/desktops-and-all-in-ones/thinkcentre-m-series-desktops/thinkcentre-m700-tiny/10j0/solutions/ht509044-how-to-enable-secure-boot-on-think-branded-systems-thinkpad-thinkstation-thinkcentre

please note these are done at your own risk
then you can try to update the secure boot certs.
best of luck Steve ..

Click to expand...

You didn't hear him, he's already certified that it's impossible to recover.

As they cannot get into the BIOS at all, (they have already pulled the CMOS battery etc) I don't believe a suggestion to use the BIOS is helpful.
I also agree it would be a good idea for Garlin put a BOLD RED LETTER DISCLAIMER of the risk of using the scripts. That way you have informed risk.

Hello garlin
Somehow, after windows had installed the updated certificates and secure boot was working correctly, it became unusable. See, I had turned off secure boot a couple of weeks ago (no real reason), and then somehow something changed. This morning I noticed some weird security nonsense online (difficulty signing in on a website) I went to re-enable secure boot and the system would not boot, instead I got the dreaded secure boot violation message and straight to bios setup. I do not understand how this happened.

Just flashed the latest bios image for my system and that got secure boot to work again. And here is the output now, from your check-uefi script:

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! Windows PowerShell update message FAQ - PowerShell

Windows 11 25H2 (26200.8655)

Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) OFF

BIOS Firmware
-------------
ASUS System Product Name
Version: 2803
Date: 2025-12-08

Factory Default UEFI PK Cert
----------------------------
ASUSTeK MotherBoard PK Certificate

UEFI PK Cert
------------
ASUSTeK MotherBoard PK Certificate

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
ASUSTeK MotherBoard KEK Certificate

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
ASUSTeK MotherBoard KEK Certificate

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023
ASUSTeK MotherBoard SW Key Certificate
ASUSTeK Notebook SW Key Certificate

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023
ASUSTeK MotherBoard SW Key Certificate
ASUSTeK Notebook SW Key Certificate

Factory Default UEFI DBX Certs
------------------------------
(NONE)
EFI_CERT_SHA256_GUID Signatures: 430

UEFI DBX Certs
--------------
(NONE)
Windows BootMgr SVN is MISSING.
EFI_CERT_SHA256_GUID Signatures: 430

UEFI Variables
--------------
Credential Guard: ON

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 28000.342, SVN 9.0

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

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.


REQUIRED ACTION
===============
To REVOKE the [PCA 2011] cert, run the commands:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x282 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"


My question is, do you think windows will reinstall an update to disable the older cert or would you just use your scripts recommended action?

Disregard my question above. Windows just took care of it without my help.

It's not in big bold letters but I think that covers the scripts.



James.

Any time you're doing firmware loads to any device there is a risk of a problem.

JamesSmith said:

It's not in big bold letters but I think that covers the scripts.

View attachment 176452

James.

Click to expand...

LICENSE file is also in the zip from post #1

NVRAM: I have a series of Intel NUCs, Dell Optiplex 9020 and Dell Poweredge T340. I have found size of the NVRAM chips in the technical specifications for all. But what is still unknown is the amount of space allocated to each so called key. It's possible either of the following might be able to determine those details: Intel CSME: Drivers, Firmware and Tools for ME 16+ or Intel® Processor Diagnostic Tool .