Solved Finding the UEFI's DBX SVN number using PowerShell

garlin said:

The scheduled task is only written to perform exactly the steps MS intended it do. It's not a general purpose tool for adding other certs.

There are ways to append certs (if they're signed EDK binary files) to the UEFI variables from a live Windows without Mosby. I have a working script, but it can't be shared until MS fixes a really stupid mistake they've done to a reference JSON file on their GitHub.

Click to expand...

I'll look forward to seeing the script one day, I'm sure it will be welcomed and appreciated by all.

Thank you @garlin for sharing this clear-cut valuable information with us. It is much appreciated.

suatcini54 said:

Thank you @garlin for sharing this clear-cut valuable information with us. It is much appreciated.

Click to expand...

+1

Buddywh said:

But also... some systems have a setting in Secure Boot section of BIOS to allow image execution even if the Boot Manager files aren't signed or are signed by an untrusted certificate. This effectively the same as disabling Secure Boot.

MSI motherboard BIOS's (in particular) are known to ship with that as the default setting, you have to disable Allow Image Execute to get true protections of Secure Boot. But I believe there may be others.

Click to expand...

Nope, no setting like that in my HP BIOS.
Only 3 settings related to secure boot

Secure Boot on/off
Remove all keys
Load factory Default Keys

The later 2 are greyed out until Secure Boot turned off, then "Remove all Keys" becomes available and, I would assume, if you do that then "Load Factory Defaults" would become available, but I haven't been game to try that.

garlin said:

Applying SVN 7.0 prevents an older version of the boot manager from loading. 24H2 always had the right boot files (for SVN enforcement) from the start.

Click to expand...

Thankyou @garlin for the information and all your valuable input, much appreciated.

garlin said:

The scheduled task is only written to perform exactly the steps MS intended it do.

Click to expand...

Yep, I did figure that was the case. But then...there are frequently undocumented features in a lot of tools MS intended to make available but just never told us about. Seeing that, I was wondering if someone had found one out.

Brian48 said:

Nope, no setting like that in my HP BIOS.
Only 3 settings related to secure boot

Secure Boot on/off
Remove all keys
Load factory Default Keys

The later 2 are greyed out until Secure Boot turned off, then "Remove all Keys" becomes available and, I would assume, if you do that then "Load Factory Defaults" would become available, but I haven't been game to try that.

Click to expand...

This is exactly the problem, why vendors were expected to ship new firmware for all PC's.

If you had to start over (for whatever reason), a "factory reset" would result in the base firmware keys. It could be the CA 2011 keys. On new PC's, MS says it's OK to only provide the CA 2023 keys if the vendor wants that. But I presume they'll either not ship a new firmware for outdated PC's, or ship new PC's with a mix of both keys.

Mosby or the tool I'm working can just re-apply CA 2023 certs to a factory reset PC that only lists CA 2011. On the worst case, you turn off Secure Boot. Re-apply the keys, and confirm it's good. Then re-enable Secure Boot. Back to normal operations..

Brian48 said:

Thankyou @garlin for the information and all your valuable input, much appreciated.

Click to expand...

Thanks for the feedback.

Brian48 said:

Nope, no setting like that in my HP BIOS.
Only 3 settings related to secure boot

Secure Boot on/off
Remove all keys
Load factory Default Keys

The later 2 are greyed out until Secure Boot turned off, then "Remove all Keys" becomes available and, I would assume, if you do that then "Load Factory Defaults" would become available, but I haven't been game to try that.

Click to expand...

It would work as you probably suspect: it clears all keys and then reloads the default keys that shipped with the BIOS. That would remove the 2023 keys Microsoft loaded with these updates.

But clearing keys also puts it in what's called Setup Mode, when you can load a unique PK (Platform Key) and then build a chain of trust that's independent of the OEM, which is what MOSBY needs.

Mosby wants total independence on the PK trust chain. But that's not technically required. You're supposed to wait for a vendor-signed KEK (signed by the vendor's PK) to be applied. Once that's done, MS (through Windows) can handle everything from there.

At this moment, vendors are still checking in their KEK's to MS.

If your vendor has truly abandoned you, and if you're allowed key management in the UEFI menu (it depends if you have the basic UEFI "shell" or a fancy GUI like the ASUS/ASR motherboards), it's possible to read a signed .der or .crt file off a FAT32 disk device. With that certificate you can enroll the KEK CA 2023 from MS without your vendor's assistance. But it's a manual process of clicking through the menu options.

The nuclear option is MS provides the Windows OEM PK cert. You basically replace the default vendor PK with a MS one, since your vendor's abandoned you anyway. Mosby does something similar, except it's constructed as an one-stop self-signing, self-enrolling PK solution. But it's not required you stray that far, unless that's your wish because you believe in self-signing.

Self-signing and deploying UEFI certs has existed on Linux for years. But MS is hesitant to have users play around it with it.

garlin said:

But MS is hesitant to have users play around it with it.

Click to expand...

Why do you think they are? If a user self-signs their PK, then builds the chain on that by signing Microsoft's KEK and, in turn, DB certs then would it be any different from building it from an OEM's PK as far as Windows would see it?

Thank you Garlin for the tutorial and script.
I now have SVN7.

Buddywh said:

Why do you think they are? If a user self-signs their PK, then build the chain on that by signing Microsoft's KEK and, in turn, DB certs then would it be any different from building it from an OEM's PK as far as Windows would see it? I can see why they couldn't easily build the chain with their own self-signed DB certs if the Boot Manager files are maintained by Microsoft with periodic updates though.

I had not heard of the "nuclear option" or a Microsoft PK. That's interesting since I'm pretty sure Microsoft can't push that one into firmware from an scheduled task! A user would have to prepare a system the same as for using MOSBY: put it in setup mode by deleting all the keys including PK.

Click to expand...

There's no difference from the UEFI perspective. The problem is user support. An experienced user with the right guidance and tools can do this with not that much difficulty. Like the tool I'm writing, it takes the uncertainty out of the picture.

You've probably spent enough time on different user forums. How many over-inquisitive and under-experienced, or determined but not very technical people you have you seen who attempt a technical feat and either (temporarily) brick their PC or get frustrated at the whole process? Multiple that by hundreds and thousands and millions more.

The good thing is MS is respecting the UEFI community and releasing the same certs to the public, and not making it a "Windows only" path to upgrading security. The only thing they can't release is the original PK keys for obvious reasons. But on the GitHub, they've provided pre-signed certs and post-signed binary objects. This how Mosby and Linux's fwupd tool can inter-operate with MS, by taking on the published objects.

I am very much the amateur, just trying to learn and stay safe.

EB2XR6 said:

I am very much the amateur, just trying to learn and stay safe.

Click to expand...

Best way to stay safe...



With a fresh backup, you can break almost anything, software wise, and just restore from a backup.