Clarification Regarding the Script Output

[algymc]

Hi cjee21,

I've just run your Check UEFI PK, KEK, DB and DBX.cmd , and although I get a similar output (screenshot below) to your example, I'm not clear exactly what some of it means.

Specifically...

1. I note the "SUCCESS..." results in 2 DBX's - but what do they mean?

2. I've not knowingly attempted any 2011 certificates revocation yet. So all the "revoked: False" against these entries confirm that fact - Correct Y/N?

3. Will this script show "revoked: True" against all the 2011 entries once I've done a proper revocation of them, in due course.

4. Can this, or any other of your scripts, allow confirmation that all the 2011 certificates have moved to the DBX upon completion of revocation?

(Apologies in advance if I've posted in the wrong place - let me know if so).

Thanks in advance for any help,

A

[cjee21]

I note the "SUCCESS..." results in 2 DBX's - but what do they mean?

It means all the entries in the June and October DBX updates are successfully found in your current DBX. In other words, your DBX is up-to-date as at October update.

I've not knowingly attempted any 2011 certificates revocation yet. So all the "revoked: False" against these entries confirm that fact - Correct Y/N?

Yes. revoked: False means a cert with that name was not found in DBX.

Will this script show "revoked: True" against all the 2011 entries once I've done a proper revocation of them, in due course.

It should if the 2011 cert is added to the DBX as a cert. However, I did not test that part yet since I do not have any system that I want to revoke 2011 yet.

Can this, or any other of your scripts, allow confirmation that all the 2011 certificates have moved to the DBX upon completion of revocation?

Once the 2011 certs are added to official DBX updates, an updated version of this script will show it in DBX section. For example, if it is added to DBX updates in June 2026, and DBX section shows success for June 2026 then it is revoked.

Alternatively, the 2011 cert in the other sections should display revoked: True once they are added to DBX even if they are not part of official DBX updates.

Or if the certs are actually removed from DB then it will show red 'x' instead of green check. In that case it won't matter if it is in DBX as it is no longer trusted.

---

You can use the other script to check if the Windows Boot Manager has been updated to 2023 signed one and if the process of updating to 2023 and revoking 2011 has been started on your system.

[algymc]

Thank you very much for your detailed reply!

Just a few more queries, if you wouldn't mind explaining, please...

Re October DBX database(s)...
a) Is this the bunch of *.BIN files included in your ZIP download?
b) Presumably released by MS periodically?
c) And "SUCCESS" count value equals the number of matches found with the group of BIN files, and represents some kind of vulnerability?

Finally, I note with interest that you appear to be holding off 2011 revocation for the time being - is that the case, and if so why? (I was considering doing mine imminently).

Thanks in advance, again, for any response,

A

[cjee21]

Each bin file is for a specific update month. Each one contains a list of revoked hashes or certs. The contents of October bin file can be seen in dbx_info_msft_10_14_25.json, excluding 2011 cert and maybe some others that are not part of default update.

The script uses the bin files included to check the current DBX for matches. The success count counts the number of entries in that specific bin file that can be found in the current DBX. Green and no failures means all entries are found so the current DBX is up-to-date for that month.

If the current DBX does not contain the latest DBX updates, then you'll see something like this:

Current UEFI DBX (only the latest one is needed to be secure)
2023-03-14: SUCCESS: 220 successes detected
2023-05-09: FAIL: 151 failures, 220 successes detected

In this case, the May 2023 DBX update was not in the UEFI's DBX and 151 new entries was added in May 2023.

October 2025 has 431 entries compared to June with 430 entries because IGEL's bootx64.efi signed by Microsoft Corporation UEFI CA 2011 was added to DBX in October security patch (CVE-2025-47827).

The bin files are released by Microsoft on GitHub (previously at uefi.org) as mentioned in the readme (https://github.com/microsoft/secureboot_objects/tree/main/PostSignedObjects/). They can probably be used to manually update the UEFI variables as well.

Windows updates the UEFI using bin files shipped in C:\Windows\System32\SecureBootUpdates. If you check the current dbxupdate.bin in that folder, it is the exact file as x64_DBXUpdate_2025-10-14.bin that is used by this script.

I note with interest that you appear to be holding off 2011 revocation for the time being

Yes. I plan to just let Windows deploy it automatically. I still have bootable USBs that are likely signed with 2011 cert. I need to check and update them to 2023 signed loaders before revoking if I still want to use them.

[algymc]

Once again, thank you for an excellent reply!

I followed your suggestion, and sure enough, on my system:-
your provided file x64_DBXUpdate_2025-10-14.bin = c:\Windows\System32\SecureBootUpdates\ dbxupdate.bin

Not coincidentally I suspect, it also = Rufus's recently downloaded file ddbx_x64.bin

If you dont know Rufus, it's a great little tool for creating bootable USB's for OS installers, and created by a fellow GitHub-er https://github.com/pbatard/rufus. It might help in your need to update your USBs (I have a bit of that problem too, including some installer ISOs as well).

I'm a bit annoyed I didn't see your latest version of this work when I first checked my system and instead I kept getting:-

Current UEFI DBX (only the latest one is needed to be secure)
2023-03-14 : FAIL: Check DBX failed
2023-05-09 : FAIL: Check DBX failed
2025-01-14 (v1.3.1) : FAIL: Check DBX failed
2025-06-11 (v1.5.1) : FAIL: Check DBX failed

It would have been interseting to see if the CA2023 "automated" update process I used (below) in itself made any changes to the DBX contents.

1. reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
2. Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
3. Wait... reboot... then wait some more until reg keys:-
   AvailableUpdates = 0x4000
   & Sub-key Servicing:-
   UEFICA2023Status = Updated
   WindowsUEFICA2023Capable = 0x2

A

[cjee21]

Using the old version should still show success for the older updates. Not sure what happened. Maybe due to working directory issues that was fixed that day.

0x5944 = 0x0004 | 0x0040 | 0x0100 | 0x0800 | 0x1000 | 0x4000

So you can refer to the table in the readme to see what was applied. Basically almost everything except revocations or DBX updates.

You can check your number 3 using the new Check Windows state script too.

I used Rufus before for making Ubuntu USB. Nowadays I just make Windows installer manually from official ISO just by copying the contents to a FAT32 USB. There is no need to do any MBR stuff anymore since Windows 11 is UEFI only and UEFI can boot from the USB files as long as they are in FAT32 partition. So no need to use Rufus or Media Creation Tool.

[cjee21]

Just found something interesting

https://github.com/mtniehaus/UEFIv2

Wonder if it is possible to check the SVN that Microsoft says will be updated in the firmware.

[algymc]

There's so much to learn about Windows security, and I wish I knew more, but I'm afraid SVN has not been on my radar yet...

I'd certainly be interested in a method to maintain the DBX entries independantly of Windows Updates...

But I'm going to get into real trouble with the wife if I "waste" much more time on my PC, this side of Christmas!

Thanks for your all responses, and maybe we can pick things up again a bit later?

Regards,

A

[cjee21]

https://github.com/mtniehaus/UEFIv2

Wonder if it is possible to check the SVN that Microsoft says will be updated in the firmware.

This cmdlet cannot show all variables since it is running on Windows so I tried dumping all variables from the UEFI shell. I see a 'WindowsBootChainSvn' variable that is only accessible by boot services but its GUID and content does not match what is in the json file. I cannot find any other SVN or SBAT variables so I don't know, maybe my system just hasn't updated those variables.

maybe we can pick things up again a bit later?

Sure. I'll leave this issue open in case anyone else needs clarification on the script output and also we can share our results of revoking the 2011 certs if one of us does it first.

[algymc]

Hi again,

I'm sorry I cant help you regarding the SVN stuff - I'm simply not up to speed on that and any research time will have to wait until after Christmas now.

I'll leave this issue open in case anyone else needs clarification on the script output and also we can share our results of revoking the 2011 certs if one of us does it first.

Great! And I'd be happy to share with you any progress I make on that front, but again, not likely to happen until after Christmas now.

In the mean time, if you think it might be of help/interest, these two forum threads (which I've participated in) may be worth a look.

https://www.elevenforum.com/t/secure-boot-update-howto.41997/
https://www.elevenforum.com/t/act-now-secure-boot-certificates-expire-in-june-2026.37372/page-18#post-677713

Regards.

[cjee21]

Thanks for the link. So someone there has revoked the 2011 cert using the reg key and the script correctly shows 'revoked: True' as expected. That's all I need to know regarding 2011 revocation.

https://www.elevenforum.com/t/act-now-secure-boot-certificates-expire-in-june-2026.37372/page-18#post-677189

What remains is understanding the SVN and SBAT stuff and verifying that they are updated but that is no hurry and likely cannot be checked by a script running in Windows.

[algymc]

Glad you got some use/info from the urls. I had a feeling both threads had users who had revoked, with screenshots showing "True".

Out of interest, can i ask what is your interest in SVN and SBAT? (I understand they are involved with DBX updating, but not much else yet beyond that).

(By the way, if you would prefer to continue this chat off this thread, that's OK, but I cant see how to do that on here, there's no DM/PM facility they i can find)

[cjee21]

Out of interest, can i ask what is your interest in SVN and SBAT?

Just want to study and understand how they work. Also want to find out if Windows is automatically updating those, how to verify if they are updated, will they get reset in a UEFI update or reset then requiring manual intervention to re-update, things like that. Previously wanted to consider adding checks for those to the scripts but at the moment it looks like those are only accessible by boot services.

If I understand correctly, in the future, Windows and Linux plan to use SVN and SBAT to revoke vulnerable bootloaders instead of adding them to DBX so that they can revoke themselves without a DBX update and also because UEFI space is limited. So it would be great to know about that as much as we know about DBX.

[algymc]

I'm presently interested in the UEFI vulnerability management via DBX, but not latched onto the SVN SBAT significance yet... Another TBD fire me now.

Any system that follows in the footsteps of Linux would seem to be a sensible move, from the little i know about the general pros and cons of each OS.

[cjee21]

Found out the SVN. It is stored as a fake SHA256 cert hash in the DBX:

SignatureType : EFI_CERT_SHA256_GUID
SignatureList : {@{SignatureOwner=9d132b6c-59d5-4388-ab1c-185cfcb2eb92;
                SignatureData=01612B139DD5598843AB1C185C3CB2EB92000007000000000000000000000000},
                @{SignatureOwner=9d132b6c-59d5-4388-ab1c-185cfcb2eb92;
                SignatureData=019D2EF8E827E15841A4884C18ABE2F284000003000000000000000000000000},
                @{SignatureOwner=9d132b6c-59d5-4388-ab1c-185cfcb2eb92;
                SignatureData=01C2CA99C9FE7F6F4981279E2A8A535976000003000000000000000000000000}}

Somehow Windows adds the previous version too:

SignatureType : EFI_CERT_SHA256_GUID
SignatureList : {@{SignatureOwner=9d132b6c-59d5-4388-ab1c-185cfcb2eb92;
                SignatureData=01612B139DD5598843AB1C185C3CB2EB92000002000000000000000000000000},
                @{SignatureOwner=9d132b6c-59d5-4388-ab1c-185cfcb2eb92;
                SignatureData=019D2EF8E827E15841A4884C18ABE2F284000002000000000000000000000000},
                @{SignatureOwner=9d132b6c-59d5-4388-ab1c-185cfcb2eb92;
                SignatureData=01C2CA99C9FE7F6F4981279E2A8A535976000002000000000000000000000000}}

I've added checks for it to the script but may have to be refined more. Thanks to the creator of Rufus for the information.

I have revoked 2011 cert on my system too. It is added to DBX as a x509 cert:

SignatureType : EFI_CERT_X509_GUID
SignatureList : @{SignatureOwner=77fa9abd-0359-4d32-bd60-28f4e78f784b; SignatureData=[Subject]
                  CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Issuer]
                  CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                [Serial Number]
                  61077656000000000008

                [Not Before]
                  20/10/2011 2:41:42 AM

                [Not After]
                  20/10/2026 2:51:42 AM

                [Thumbprint]
                  580A6F4CC4E4B669B9EBDC1B2B3E087B80D0678D
                }

Now that remains is if there is a way to check SBAT from within Windows.

[algymc]

Hi,

Thanks for the update - and I see you have been very busy conversing with Mr Batard...

I've done very little Secure Boot work since we last spoke, other than get all my machines up to scratch with CA2035 installation. I've not revoked any old/2011 certificates as I'm still unclear as to the consequences of all my existing boot media.

The SVN now seems to be an additional consideration (curve ball!) that needs some getting my head round. And although I've read through the chat between yourself and pbatard, I really am no wiser - I havent been a coder/programmer for many, many years and these Windows complexities are way beyond anything I ever encounter back in the day.

So for now all I can do is plan for some research time for the above, in the new year, and see what comes of it...

Meantime, I see you have updated your scripts , now, so I've just run the two checks on this, my main system - 2 screenshots below, which I hope may be useful to you.

All I see is that I have SVN 7.0 for CA2023 (as expected per pbatard?) but 3 un-SVN'd bootmanager listings in the DBX?...

So now what???

(I will try to respond if you require any simple feedback or actions from me, at this time...
I have not run any of the "apply scripts" as I dont understand the consequences, at this time).