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.