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

Dirtyflash said:

....I might go so far as to say it's overkill for everyday users. ....

Click to expand...

Wannagofast said:

I installed it last Sunday, and spent the entire day trying to sort out booting from usb drives.
.....
I'll be skipping that SkuSiPolicy.p7b step for now as well.

Click to expand...

There are three possibilities:

• Don't activate SkuSiPoilicy.p7b at all. That resolves all (some) trouble with different boot media, but leaves the first step after the UEFI chain (winload.efi / winresume.efi) at least partitally unprotected.
• Activate SkuSIPolicy.p7b on the main system. Disable Windows secure boot before booting from all other media than the installed 'main' system and enabling Windows secure boot again before starting the main system again.
• Activate SkuSiPoilicy.p7b and update all boot media
  This would include exchanging the bootloader to a 2023 certified one which in case of secure boot anyway would be necessary.
  In addition one would have to update all wim- files on the media with latest service- pack- for a windows boot media there a boot.wim and sources.wim (with winre.wim), for PE solutions there's normally a boot.wim:
  • Mount the wim- file with DISM (as administrator)
  • Dism /Mount-Wim /WimFile:*dir of wimfilw\abc.wim* /index:*d* /MountDir:*empty directory of your choice*
  • Dism /Add-Package /Image:*mountdir* /PackagePath:*path to latest cumulative update.msu/cab*
  • Dism /Unmount-Image /MountDir:*mountdir* /Commit
    (For an install media the installed WInre.wim in the recovery partition still would'nt boot, but MS has own updates for winre, so that should be possible to do after an installation.)

In any case after a fresh installation: Creat a recovery USB stick from this machine. This stick will give you the possiblity to repair things and might restore a missing NVRAM entry just by booting it, in addition it provides a command line. If you want to use it on a system with SkuSiPolicy activated you might need to manually copy SkuSiPolicy.p7b in \EFI\Mictrosoft\Boot\

I'd say one has to understand how it works and has to have a plan when the main system isn't booting any longer and one needs other boot media. I assume I'd go for the second solution, simply disable secure boot when not booting from the main system.
This involves some dangers, too, in the 'unprotected' phase, but there's some protection left when normally working with the system.

garlin said:

.......
If you dig up the Memory Integrity docs, they mention it's possible to enable protections without an UEFI lock.
Enable memory integrity

This might prevent the "lock out" condition, but the rest of the docs don't bother mentioning anything about the UEFI lock. Or how you could check (from Windows). None of this is super clear, and you shouldn't have to be working as a Windows security researcher to understand this!

Click to expand...

The UEFI lock here hasn't anything to do with 'locking' the boot sequence or avoiding it, UEFI lock disables the possibility to disable these settings remotely via distribution of a changed GPO, for example. An quite understandable explanation one can find in the GPOs:



Disabling UEFI lock for Credential Guard
Disabling UEFI Lock for VBS (couldn't find a MS link, but the procedure seems to be the same as for removing Credential guard with UEFI lock in the MS document:

Dirtyflash said:

If you're trying to append just the 2023 KEK, then you'll want to, " Select an UEFI File as Trusted for Executing ". By selecting " Restore Secure Boot to Factory Setting ", you'll wipe out everything you've already done and will have to start all over from the beginning as it will restore the key/certs to what is in BIOS version. Every OEM BIOS is a little different, but you'll find by selecting either of the aforementioned choices, it will disable Secure Boot, otherwise you wouldn't be able to update the keys/certs. Once you're done successfully updating, depending on the device, it will turn Secure Boot back on by itself.

If you find you're unable to fully update the certs/keys manually because the device is unsupported, there's always the Mosby option.

Click to expand...

garlin said:

I suspect you have one of the "problem" firmwares which is too old, and can't be handled by a PowerShell script. Please reset the certs back to factory defaults. Because this is a really old PC, I would disable Secure Boot and leaving it alone. Don't want to risk making your PC unbootable.

Windows will eventually complain about your lack of updated certs, but will continue to work with Secure Boot disabled.

Click to expand...

Hi,
I made up my mind and decided to try Mosby as I was unable to update the keys manually and my 10 year old Acer Aspire PC couldn't be handled by a PowerShell script.

Mosby did the job! I checked my BIOS, Secure Boot is enabled and Secure Boot Mode is "Custom" no longer "General", I guess it's normal since the Keys have been updated and are no longer the factory defaults.



Thanks Dirtyflash for suggesting it. Thanks garlin for your time, and trying to solve my problematic BIOS. But your script did work with an Asus netbook PC which has a Supported BIOS.

Nicolast said:

Hi,
I made up my mind and decided to try Mosby as I was unable to update the keys manually and my 10 year old Acer Aspire PC couldn't be handled by a PowerShell script.

Mosby did the job! I checked my BIOS, Secure Boot is enabled and Secure Boot Mode is "Custom" no longer "General", I guess it's normal since the Keys have been updated and are no longer the factory defaults.

View attachment 164521

Thanks Dirtyflash for suggesting it. Thanks garlin for your time, and trying to solve my problematic BIOS. But your script did work with an Asus netbook PC which has a Supported BIOS.

Click to expand...

Thanks for posting your experience and I'm glad it worked for you. The developer of Mosby will likely see your post and feel their many hours of unpaid efforts with the new v3.0 version have been worthwhile and made a difference to others. Combined with garlin's scripts and knowledge, we've made incredible progress in preparing for the upcoming certificate and security implementations. We can be thankful for their contributions, ' one small miracle at a time '. Think of all the e-waste they've saved from landfills.

parttimewindows said:

If you indeed read all pages you probably have seen that I posted a similar (or identical?) error for my Dell.

Clearing/Deleting all keys in Custom Mode to let the script install the Microsoft certificates did the trick for me.

Hope this helps!

Click to expand...

Hello again, I reset all keys as you recommend, but after I failed to import any PK and PK certs manually from EFI\certs.
Dell Firmware said: "Error importing key: Please make sure that the key is signed and formatted properly".
I tried with the extensions DER, CER, CRT > same result.
Any run of the given script gives the result: "Please follow the readme_UEFI.txt instruction, for installing the PK cert from BIOS".

After I tried Mosby with all keyes reset as well. The result look better, but the certs are also have some issues.
After Mosby I run the update script and check script again, see the result below.
The most problematic text is "Secure Boot: OFF". However in BIOS can read: Secure Boot ON

PS C:\ca2023> powershell -nop -ep bypass -noexit -f .\Check_UEFI-CA2023.ps1
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell A victory that endures

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

UEFI is in Setup Mode (NO CERTS)
Windows BootMgr SVN 7.0

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.

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


REQUIRED ACTION
===============

Run the command:
Update_UEFI-CA2023.ps1 -Revoke

Finish the UEFI steps to manually add the Platform Key (PK) cert, if the script provided instructions.

Finish the UEFI steps to manually add the [KEK CA 2023] cert, if the script provided instructions.

I tried to manually add, but same issue as I wrote at the first sentences in this comment.

Seems that better to leave the notebook as "problematic BIOS" and use without SecureBoot on? (and no TPM?)

Any thoughts?
Prior thanks

Pali said:

After I tried Mosby with all keyes reset as well. The result look better, but the certs are also have some issues.
After Mosby I run the update script and check script again, see the result below.
The most problematic text is "Secure Boot: OFF". However in BIOS can read: Secure Boot ON

PS C:\ca2023> powershell -nop -ep bypass -noexit -f .\Check_UEFI-CA2023.ps1
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell A victory that endures

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

UEFI is in Setup Mode (NO CERTS)
Windows BootMgr SVN 7.0

Click to expand...

This looks like one of those problem BIOS'es that doesn't return the correct results from PowerShell. I don't know if Secure Boot is actually being enforced.

You can try by downloading an older Windows 11 ISO (like 21H2), and see if it can boot from USB. If you get an UEFI security violation (doesn't boot), then Secure Boot may be working even though the script (and presumably Windows) can't tell what's going on.

garlin said:

This looks like one of those problem BIOS'es that doesn't return the correct results from PowerShell. I don't know if Secure Boot is actually being enforced.

You can try by downloading an older Windows 11 ISO (like 21H2), and see if it can boot from USB. If you get an UEFI security violation (doesn't boot), then Secure Boot may be working even though the script (and presumably Windows) can't tell what's going on.

Click to expand...

Hello. Unfortunatelly, this notebook is only for Win10 by design, so I installed from a Win10 22H2 ISO. But can only boot if I leave in Custom mode (Setup). If I switch back to normal boot (Secure Boot customization is killed), then Windows Boot Loader does not allow to boot.
I'm intended to use them longer under Win 10 Pro, as ESU license is available to run 1-year term. If it works, then we may extend for another year in October 2026.
I know, that these notebooks are rather old; from year 2017, but very stable hardware. We have a 50 pcs fleet.
So, if we could replace all of them for a new model, then will be fine. But now it's quite bad timing. RAM price increases, etc...
What I can do is to Switch off SecureBoot at all, suspend Bitlocker enforcment on those PCs, which are managed from Intune.
Regards,
Pal

I have run the Update_UEFI-CA2023 script on my Acemagic S1 whilst the Bios was in setup mode. It appears to have worked as Check_UEFI-CA2023 reports:
Windows 11 25H2 (26200.7922)

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

BIOS Firmware
-------------
Default string Default string
Version: 5.26
Date: 2023-09-27

Factory Default UEFI PK Cert
----------------------------
DO NOT TRUST - AMI Test PK

UEFI PK Cert
------------
Windows OEM Devices PK

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011

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

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

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

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
bootmgfw.efi File version: 26100.30227

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

Disk 0: SkuSiPolicy.p7b (for VBS) is NOT PRESENT.


REQUIRED ACTION
===============

To revoke the [PCA 2011] cert, run the commands, run the commands:

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

To install SkuSiPolicy.p7b, run the command:
Update_UEFI-CA2023.ps1 -SkuSiPolicy

I did not run Update_UEFI-CA2023 with the revoke switch.

I see that:
Factory Default UEFI PK Cert
----------------------------
DO NOT TRUST - AMI Test PK

is still present. Need I worry about this? I presume this is baked into the firmware that resides in the CMOS?
In which case it is always going to be there unless the manufacturer release an updated Bios with the tool to update it?

SaliesBuzz said:

REQUIRED ACTION
===============

To revoke the [PCA 2011] cert, run the commands, run the commands:

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

Click to expand...

Is the first command run from Powershell, or from CMD?

SaliesBuzz said:

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

Click to expand...

SaliesBuzz said:

I did not run Update_UEFI-CA2023 with the revoke switch.

Click to expand...

This part is good. You've completed the first half of the update process (adding the CA 2023 certs, without banning CA 2011). This is allowed by Windows for now, with MS expected to switch to mandatory revocation in the 2nd half of the year.

SaliesBuzz said:

I see that:
Factory Default UEFI PK Cert
----------------------------
DO NOT TRUST - AMI Test PK

is still present. Need I worry about this? I presume this is baked into the firmware that resides in the CMOS?
In which case it is always going to be there unless the manufacturer release an updated Bios with the tool to update it?

Click to expand...

When reports of PC makers using the AMI Test PK was confirmed, AMI instructed those OEM's to immediately stop doing that and re-release their BIOS with a properly signed OEM PK. Some of them did, others never bothered.

Windows OEM Devices PK was designed by MS as a workaround for the orphaned BIOS'es, so you didn't have the compromised Test PK.

Having it as the factory PK isn't going to be a problem, unless you repeat the process of clearing all the keys in Setup Mode, or deleting the PK if your BIOS supports manual key enrollment. Will this be a problem? Most likely there are no more firmware updates for your PC, so the chances of a factory reset are fairly low.

If that happens, you can disable Secure Boot in BIOS, and repeat the process you just followed.

Anibor_11 said:

Is the first command run from Powershell, or from CMD?

Click to expand...

You can run the "reg add" from inside PS, it's considered as an external command.

garlin said:

You can run the "reg add" from inside PS, it's considered as an external command.

Click to expand...

OK, thanks.

garlin said:

This part is good. You've completed the first half of the update process (adding the CA 2023 certs, without banning CA 2011). This is allowed by Windows for now, with MS expected to switch to mandatory revocation in the 2nd half of the year.


When reports of PC makers using the AMI Test PK was confirmed, AMI instructed those OEM's to immediately stop doing that and re-release their BIOS with a properly signed OEM PK. Some of them did, others never bothered.

Windows OEM Devices PK was designed by MS as a workaround for the orphaned BIOS'es, so you didn't have the compromised Test PK.

Having it as the factory PK isn't going to be a problem, unless you repeat the process of clearing all the keys in Setup Mode, or deleting the PK if your BIOS supports manual key enrollment. Will this be a problem? Most likely there are no more firmware updates for your PC, so the chances of a factory reset are fairly low.

If that happens, you can disable Secure Boot in BIOS, and repeat the process you just followed.

Click to expand...

Thank you so much for your speedy reply!
I have exactly the same situation on a Nipogi Mini PC as well, that I have managed to update using your PS1 script.
I have used the WilyOldBuzzard_Update_UEFI-CA2023 on the Acemagic as it seems to avoid the Bitlocker hang whilst running the script.
I will leave the 2011 Certificates for the moment and revoke them sometime in May, using the method described under "Required Action"
Does the "\Microsoft\Windows\PI\Secure-Boot-Update" refer to something I should see in Windows Explorer? I have no Microsoft\Windows folder off the root on my C:\ Drive.

SaliesBuzz said:

Does the "\Microsoft\Windows\PI\Secure-Boot-Update" refer to something I should see in Windows Explorer? I have no Microsoft\Windows folder off the root on my C:\ Drive.

Click to expand...

No, that's a Windows scheduled task. Scheduled tasks are organized in separate internal folders (which you don't need to look inside).

When referring to a specific task, you can't simply use "Secure-Boot-Update", you have to use its full pathname "\Microsoft\Windows\PI\Secure-Boot-Update". Yeah, it's annoying...

Hi @garlin - first of all i want to THANK YOU for this amazing work.
I am updating the Secure Boot certificates on some HP ZBook Power G11 laptops, which are recent models with full support from Microsoft and HP. I have installed the latest Microsoft updates and the latest available BIOS.

Now: I run your script check_uefi.bat, which tells me that I need to execute a series of commands to install [UEFI CA 2023] (bitlocker off >> regkey add >> sch task). I execute them, but after restarting the machine, if I run the check_uefi script again I get the same message.
Do you have any idea what the problem might be?

epud80 said:

Now: I run your script check_uefi.bat, which tells me that I need to execute a series of commands to install [UEFI CA 2023] (bitlocker off >> regkey add >> sch task). I execute them, but after restarting the machine, if I run the check_uefi script again I get the same message.
Do you have any idea what the problem might be?

Click to expand...

Can you copy/paste the full output of the script? That's most helpful in figuring out where the process is stuck.

Sure - here it is. In the meantime, i discovered that this particular PC is w11 23H2. But i have the exact same issue with two 25H2, so i don't think this is the root cause.


PS C:\SSB\GARLIN_v2> .\Check-UEFI.bat
Windows PowerShell
Copyright (C) Microsoft Corporation. Tutti i diritti riservati.

Installa la versione più recente di PowerShell per nuove funzionalità e miglioramenti. Windows PowerShell update message FAQ - PowerShell

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

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

UEFI DB Certs
-------------
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Windows UEFI CA 2023

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 7.0

EFI Files
---------
Disk 1: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.

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

Disk 1: SkuSiPolicy.p7b (for VBS) is CURRENT.


REQUIRED ACTION
===============

To install [UEFI CA 2023] certs, run the commands:

manage-bde -Protectors -Disable C: -RebootCount 1
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5000 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

It looks like the Windows scheduled task is "confused", since there are partial updates. Can you run my update script instead?

After it's done, please re-run the Check-UEFI.bat.

Ok good - if i run update-uefi.bat it says that "pwsh is not recognized..."

OK. Run this command but replace the folder path to the update script: