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

I'm wondering if that's left over from my script. It creates an \EFI\Certs folder, so it's easier to manually find a cert file than browsing through multiple subfolders and scrolling past other random filenames.

After you're done installing the CA 2023 certs, \EFI\Certs and its files can be safely removed. They're not part of the normal EFI filesystem.

garlin said:

I'm wondering if that's left over from my script. It creates an \EFI\Certs folder, so it's easier to manually find a cert file than browsing through multiple subfolders and scrolling past other random filenames....

Click to expand...

That seems likely. I've only ever run your script to try and update one laptop, my System One below. For my others I've only needed to run the Check-UEFI script, they all say that they don't need a manual update, I can just let Microsoft handle it for me. None of them have that \EFI\Certs folder.

I've subsequently retired my System One from active duty due to a broken hinge, and restored its system image to my System Seven (in Other Info). That too won't need a manual update, it's already at the stage where all that's left it to revoke PCA 2011 (I'm in no hurry, I'll leave that to MS). It has however inherited that \EFI\Certs folder from the system image of System One. Should I delete it, or will it do no harm to leave it?

I dont have "Certs" on 2 machines that I used Garlin' script on to update c2023

D519D51B249349f38D79D76488950CB5.EXC = Hasleo so it seems, I deleted it.

Bree said:

That seems likely. I've only ever run your script to try and update one laptop, my System One below. For my others I've only needed to run the Check-UEFI script, they all say that they don't need a manual update, I can just let Microsoft handle it for me. None of them have that \EFI\Certs folder.

I've subsequently retired my System One from active duty due to a broken hinge, and restored its system image to my System Seven (in Other Info). That too won't need a manual update, it's already at the stage where all that's left it to revoke PCA 2011 (I'm in no hurry, I'll leave that to MS). It has however inherited that \EFI\Certs folder from the system image of System One. Should I delete it, or will it do no harm to leave it?

Click to expand...

Klaver7 said:

I dont have "Certs" on 2 machines that I used Garlin' script on to update c2023

Click to expand...

Not everyone gets a "Certs" folder created on the EFI partition.

In the best case, you already have the KEK CA 2023 installed from a recent BIOS update. Then we don't need to copy any certs to the EFI partition, everything can be updated directly from Windows. When no KEK CA 2023 is found, we can try matching your PK's thumbprint against the list of vendor-submitted KEK bin files on the MS GitHub repo. If there's a match, we can try applying the submitted KEK file from Windows.

If the previous attempt fails, the fallback is to ask the user to try manual enrollment.

Now the script creates "\EFI\Certs" (to keep the certs organized in one place, instead of randomly copying them to \EFI\Microsoft\Boot), and copies the cert files to make this task easier for the user. Normally, you're asked to copy files to a writeable FAT32 volume (because most EFI's can only natively read FAT32). By copying the files to the EFI partition, I'm saving you the time of finding a spare USB drive.

In some cases, manual enrollment is unsuccessful and we have to proceed to the nuclear option of wiping all keys. For Setup Mode, we don't need to copy files to the EFI since any UEFI without a working PK doesn't have security restrictions. We can perform the update from Windows.

Why doesn't the script clean up the folder? I figured just in case you have a situation where you needed to reset the UEFI for something, retaining the files there would make it easier to repeat the process.

Both cert files consume less than 8 KB, so they're not taking up too much disk space. You can delete them if you like. They don't interfere with the EFI's functions, which is why I created a "Certs" folder so you don't have to worry about deleting the wrong folder of files.

Just a quick question for you Garlin I did this on my Wifes laptop (system2 in my pc specs)

Because I was just curious and after I rebooted I got stuck where it said the boot manager was banned and it asked me to insert media to boot from. I can't remember exactly what it said but it mentioned " detected changes in configuration to boot" or something like that. I was stuck in a loop because every time I restarted the laptop it wanted me to provide a bootable drive. Wouldn't boot from the SSD or any usb I had.

Anyway so I was able to quickly go into the BIOS and turn Secure Boot off then I was able to load Windows. I restarted again went into BIOS turned secure boot ON and was able to boot back into windows like nothing had happened.

Strange. All is good now. I have run all your scripts and they came back perfect. I wonder what the heck happened there.

This is known as an UEFI lock. If you have a deployed SkuSiPolicy.p7b, there is a set of reg keys in Windows which controls whether enforcement is enabled. One of the risks is the reg keys can be modified by anyone with Admin privileges, so an attacker could disable enforcement by modding values.

To prevent this scenario, Windows can write authenticated variables to the UEFI (which are hidden from normal Windows) which declares enforcement will happen, regardless of what the registry calls for. When the UEFI lock is in place, deleting the SkuSiPolicy file from the EFI confuses Windows, since it's expecting to enforce policy by reading rules from a policy file that no longer exists.

This is why the script now has the UEFI Variables section to report whether DeviceGuard (SkuSiPolicy) or CredentialGuard (LSASS) are "UEFI locked".

The current guidelines instruct to you disable Secure Boot, reboot, and then delete the SkuSiPolicy. After you've removed SkuSiPolicy, shutdown and re-enable Secure Boot. I should probably expand the instructions for removing SkuSiPolicy so it's more clear.

Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates - Microsoft Support

garlin said:

This is known as an UEFI lock. If you have a deployed SkuSiPolicy.p7b, there is a set of reg keys in Windows which controls whether enforcement is enabled. One of the risks is the reg keys can be modified by anyone with Admin privileges, so an attacker could disable enforcement by modding values.

To prevent this scenario, Windows can write authenticated variables to the UEFI (which are hidden from normal Windows) which declares enforcement will happen, regardless of what the registry calls for. When the UEFI lock is in place, deleting the SkuSiPolicy file from the EFI confuses Windows, since it's expecting to enforce policy by reading rules from a policy file that no longer exists.

This is why the script now has the UEFI Variables section to report whether DeviceGuard (SkuSiPolicy) or CredentialGuard (LSASS) are "UEFI locked".

The current guidelines instruct to you disable Secure Boot, reboot, and then delete the SkuSiPolicy. After you've removed SkuSiPolicy, shutdown and re-enable Secure Boot. I should probably expand the instructions for removing SkuSiPolicy so it's more clear.

Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates - Microsoft Support

Click to expand...

Thanks for the explanation. I wasn't expecting the UEFI lock. Thanks it makes sense now.

I also ran your script and re added SkuSiPolicy policy back onto the laptop.
Script comes back clean.

I hope there's no issues from what I did.

*EDIT* I am seeing a million error logs

"Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\System32\svchost.exe) attempted to load \Device\HarddiskVolume3\Program Files\Malwarebytes\Anti-Malware\mbamsi64.dll that did not meet the Windows signing level requirements."

Chrome, Firefox a lot of applications showing this exactly around the time I removed SkuSiPolicy

Scroll down to Devices that use Secure Boot and UEFI

When I googled how to fix this issues it says disable Added LSA protection. (not a good idea)

I think I broke something.



Could this be a result of removing SkuSiPolicy with Secure Boot on? It seems to be a conflict with (LSASS)
?

garlin said:

Normally, flashing the BIOS should not change the current certs (which are stored in NVRAM).

A new BIOS can have a different set of factory default certs. But it can only go in one direction (factory certs added to NVRAM), but not in the other direction. If updating the BIOS corrupts the NVRAM, you can always reset to factory defaults and repeat the same update process you successfully performed the first time.

Click to expand...

Thank you Garlin,
Updated the BIOS, just the usual hassles with resetting the Windows PIN, also I hate how this Gigabyte Board goes back to Factory Defaults.
Certificates were good just had to re enter a reg command in terminal.