10x faster 'Check UEFI PK, KEK, DB and DBX'

[jcoester]

Proposing to remove the Write-Progress bar entirely.
The improved runtime is faster than most humans should be able to read.

Show-CheckDBX with currently 431 + 278 checks:

Run	Before	After	Difference
1	12.5 s	1.7 s	- 10.8 s
2	11.4 s	1.7 s	- 9.7 s
3	10.9 s	1.6 s	- 9.3 s

[jcoester]

Proposing various changes that improve the runtime from up to 15 s to down to less than 1 s.
Goal to simplify the output, improve usability and avoid confusion.

• Check against latest DBX revocations only (Staged or GitHub)
• Refresh view by looping. No script restarting required
• Clarify SVN field to be FirmwareSVN, not the File SVN
• Simplify arch check, faster runtime and possibly less error prone
• Remove hardcoded bin file names, new expected pattern: DBXUpdate_{YYYY-MM-DD}_{Version}_{Arch}.bin

Example: Staged most recent

Example: No staged available, or secureboot_objects DBX file most recent

Tested with all archs.

amd64 (actual)
v1.6.0 (14 Okt 2025) : FAIL: 154 failures, 277 successes detected
Staged (14 Apr 2026) : SUCCESS: 278 successes detected 
----------------------------------------------------------------------
x86 (emulated)
v1.6.0 (14 Okt 2025) : FAIL: 44 failures, 0 successes detected
----------------------------------------------------------------------
arm64 (emulated)
v1.4.0 (25 Feb 2025) : FAIL: 26 failures, 0 successes detected
----------------------------------------------------------------------
arm (emulated)
v1.4.0 (25 Feb 2025) : FAIL: 110 failures, 0 successes detected

[cjee21]

Proposing to remove the Write-Progress bar entirely.
The improved runtime is faster than most humans should be able to read.

So the progress bar is actually slowing it. That code is from Microsoft (https://gist.github.com/out0xb2/f8e0bae94214889a89ac67fceb37f8c0).

Check against latest DBX revocations only (Staged or GitHub)

The one on GitHub is the authoritative one and the one picked up by OEMs and other OS for distribution so I would keep that especially that it currently has more hashes. The one shipped in Windows may be faulty seeing how Microsoft still has not clarified the removal of hashes or update the one on GitHub until now.

Refresh view by looping. No script restarting required

This is going to get complaints from people who automate the script.

Clarify SVN field to be FirmwareSVN, not the File SVN

This is not needed as that section is showing the contents of the Current DBX.

$arch = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes").OSArchitecture

Won't this throw an exception if the reg key does not exist?

Anyway, I cannot really review right now since I keep getting "504 Gateway Time-out" on GitHub. Also thinking that since we are going to change so much, maybe we should just abandon the bin files completely and just use the JSON file for everything. Microsoft generates the bin files from the JSON anyway. So the fact that the bin shipped with Windows does not match the JSON means something is wrong. The existing script is from back in the day when there is only CSV but no JSON file of all the contents.

[jcoester]

Thinking that since we are going to change so much, maybe we should just abandon the bin files completely and just use the JSON file for everything. Microsoft generates the bin files from the JSON anyway.

Fantastic idea! Ran a benchmark and checking the entire DBX against the JSON is now 50 ms instead of 10.000+ ms.

$arch = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes").OSArchitecture

Won't this throw an exception if the reg key does not exist?

Yes, thanks. Will add -ErrorAction SilentlyContinue to it. The registry value cuts the execution time by more than a second compared to Get-CimInstance -ClassName Win32_Processor, so should probably be the default option.

Will revert the other changes as you suggested - agree with checking both JSON and Staged, SVN labels as you had them and remove the loop.

[cjee21]

and for the JSON, since the JSON on GitHub is updated late usually, there is also a copy of the JSON shipped in Windows that maybe can be used. The issue is the last time I checked, the JSON in Windows has up-to-date hashes but old SVN whereas the one on GitHub now has updated SVN but not updated hash.

[cjee21]

Since new monthly update is out and contains new DBX hashes and the new signed bin file is available, I picked the speed improvement commit from this and updated the DBX check. There is no need to check Windows staged anymore since updated bin file contains all up-to-date hashes. For this PR maybe you can make it use JSON for checking instead. I am thinking to make use of the isOptional field in the JSON as well. So only flag the isOptional ones red when missing if the PCA2011 is not revoked. Need to wait for Microsoft to finalize the new updated JSON before the copy here can be updated.

[jcoester]

there is also a copy of the JSON shipped in Windows that maybe can be used

Is the FilePath known?

There is no need to check Windows staged anymore since updated bin file contains all up-to-date hashes.

Should it be kept, in case it differs in the future again? But only show if it differs.

For this PR maybe you can make it use JSON for checking instead. I am thinking to make use of the isOptional field in the JSON as well. So only flag the isOptional ones red when missing if the PCA2011 is not revoked.

Really like the isOptional idea and have the code ready. Will do a PR within the next days as I'm testing some more conceptual ideas.

[cjee21]

Is the FilePath known?

Get-SecureBootUEFI -Name DBX -Decoded can show the info of the hashes so it has to be somewhere in the powershell secureboot module directory. It may not be the same format as the public JSON though. I didn't take note of the path when I found it previously.

Should it be kept, in case it differs in the future again? But only show if it differs.

The issue is how to merge the info. Maybe just parse the JSON shipped in Windows then if there is a new hash not in the other JSON, add/merge to the check but what date.

Will do a PR within the next days as I'm testing some more conceptual ideas.

Can just force push this PR, overwriting the commits with new ones and rename the PR as needed.

[jcoester]

Get-SecureBootUEFI -Name DBX -Decoded can show the info of the hashes so it has to be somewhere in the powershell secureboot module directory. It may not be the same format as the public JSON though. I didn't take note of the path when I found it previously.

Its Join-Path (Split-Path (Get-Command Get-SecureBootUEFI).DLL -Parent) "hashes.json" then.

Also under found under following. Its the latest SVN 9.0 JSON.
"C:\Windows\System32\WindowsPowerShell\v1.0\Modules\SecureBoot\hashes.json"
"C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\SecureBoot\hashes.json"

The issue is how to merge the info. Maybe just parse the JSON shipped in Windows then if there is a new hash not in the other JSON, add/merge to the check but what date.

Can just do a background comparison of JSON vs STAGED, no? And only if they differ, add a new line with the results. Like:

Current UEFI DBX
Latest revocations  : SUCCESS: 443 successes detected.
Staged revocations  : SUCCESS: 289 successes detected. # Only show line if different
Windows Bootmgr SVN : 9.0
Windows cdboot SVN  : 3.0
Windows wdsmgfw SVN : 3.0

[cjee21]

Just that people keep asking what is staged? what's the difference? Is it fine if one of the results are red? etc... also the JSON actually does not matched the staged binaries shipped in Windows so we cannot actually call that staged. Someone probably messed up again. As you see, the staged is only 200+ hashes and that is not correct. Microsoft confirmed that no hashes are supposed to be removed.