Remove check for existing boot.stl. Copy providing source exists. Res…

[michaelmadell]

…ults in only requiring 2023 Certs in DB, having 2011 in DB is required for previous script.

Description

I have found that an ISO Passed through this script will still depend on the 2011 Certs in Secure Boot.
I did some testing and found that the implementation of the boot.stl file is flawed, if the boot.stl already exists, which is the case for a Golden ISO downloaded from the MSFT website, it will not be overwritten and will depend on the 2011 certs being in the DB List.
After changing that section a bit, removing the check for the destination boot.stl, causing an overwrite, results in the resulting ISO being bootable with the 2011 Certs in the DBX List, and only 2023 Certs in the DB List.

For details on how to complete these options and their meaning refer to CONTRIBUTING.md.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

1. Downloaded Windows 11 25H2 v2 ISO from MSFT Website.
2. Ran it through previous script
3. Attempted to boot installation media on a system with only the 2023 CA Certificates in the Secure Boot Database.
4. Stopped as a Secure Boot violation message
5. Removed the existing boot.stl check
6. Ran ISO through updated script
7. Attempted to boot installation media on a system with only the 2023 CA Certificates in the Secure Boot Database.
8. Booted successfully to the Windows Setup Screen

Integration Instructions

Remove the check for the destination boot.stl file in the Make2023BootableMedia.ps1 script.

[ballsop]

@michaelmadell Thanks for the submission here. Can you further clarify the ISO image (URL link) you're starting from? I'd like to make sure we're able to recreate your finding as the behavior you are observing is not currently making sense. Can you also clarify the "Secure Boot Violation" screen you are seeing? The DB/DBX state here is likely a red-herring and you're tripping over a different issue related to the boot manager binaries being used. The boot.stl handling has little to do with how boot manager is signed (especially on Windows 11+).

[michaelmadell]

The Windows 11 ISO I downloaded was called "Win11_25H2_EnglishInternational_x64_v2.iso" from the "Download Windows 11 Disk Image (ISO) for x64 devices" section at https://www.microsoft.com/en-us/software-download/windows11. I used the English International Option.

The Secure Boot violation screen is the same as that shown here:

I passed the Windows 11 ISO Through the PowerShell Script, then Flashed the Image onto a USB. I Tried DD'ing the ISO, using Rufus, and via Ventoy, all with the same results.

The secure boot state throughout testing was Enabled, and in Custom Mode.
The PK Key was loaded with our custom PK Key.
The KEK Key was the Microsoft 2023 KEK Key.
The DB Keys were:

• A Custom DB Key
• Microsoft UEFI CA 2023
• Windows UEFI CA 2023
• Microsoft Option ROM UEFI CA 2023
• Microsoft Windows Production PCA 2011
• Microsoft Corporation UEFI CA 2011

DBX was Empty

In this state the Windows 11 Boot Media would boot and install fine.

For production, we wanted to remove the 2011 Certs from the DB List.
Our DB List then looked like:

• A Custom DB Key
• Microsoft UEFI CA 2023
• Windows UEFI CA 2023
• Microsoft Option ROM UEFI CA 2023

In this state, the Windows 11 Boot Media would no longer boot, it would immediately hit the Secure Boot Violation screen

I then dug around in the PowerShell Script and removed the skip if present for the boot.stl file.
I then ran the original ISO through the Script and flashed to my USB Boot Media

With the DB List still excluding the 2011 Certs, the USB Booted and installed without issue.
The only thing that changed between it not working and it working was the forced copying of Boot.stl, as it exists at the root of the Golden ISO i downloaded.

Secure Boot was not touched between it not working and working
The system was identical, no hardware changes
The USB Drive was the same, I re-initialised it between subsequent tries to eliminate remnant files, but it still gave the same results.

Hope this helps

[ballsop]

Thank you for the extra detail @michaelmadell !

When creating the USB key, are you doing the following example flow:

.\Make2023BootableMedia.ps1 -MediaPath "Q:\MediaRefresh\Win11_25H2_English_x64_v2.iso" -TargetType USB -USBDrive E:

This will directly create a bootable USB key based on the ISO media provided.

Or are you first creating a new ISO image (-TargetType ISO), mounting it, and then copying that directly to the USB key?

The only way you will get the error screen you provided is when the UEFI firmware rejects the boot binary (bootmgfw.efi, etc). That screen is rendered by the firmware. The boot.stl file is never touched by firmware, so the error you're seeing is happening before any Microsoft boot code can execute. Therefore, the boot binaries being loaded by firmware are literally different in the pass/fail case and we're still missing something in the flow that is not yet fully understood. We will attempt to recreate this on our end and circle back.

[ballsop]

@michaelmadell

I have been unable to reproduce this issue. I downloaded the same "Win11_25H2_EnglishInternational_x64_v2.iso" you noted, and when I create new ISO media (with or without your proposed change), the resulting ISO is identical. And while boot.stl has no bearing on the error you are seeing, I also confirmed that all versions of boot.stl on the media are identical (hence why the proposed change is a no-op).

So, we're missing something here that is causing the actual boot binaries to be incorrect on the on the final USB key you created. In the failing case, if the 2023 PCA is the only one present in DB (2011 removed), then the only way you will see that Secure Boot Violation error is if the boot manager (bootx64.efi or bootmgfw.efi) on the media is still signed with 2011. Again, boot.stl has no bearing on the error seen here.

[michaelmadell]

Hi there,

I think i pinpointed an issue on my end
As you have said, the files are identical.
The system i was testing on had no dbDefault UEFI VAR, due to not having any Secure boot keys by default.
I was in custom due to having to manually add the keys.

On another system with keys installed by default by the manufacturer, the media is bootable with and without the 2011 Keys.

We received a new bios with keys in by default, with a dbDefault UEFI VAR, and in both states, the media is bootable.

I am not sure if the lack of the dbDefault UEFI VAR is the cause, and know no easy way of testing without reflashing the BIOS numerous times. and am not sure why the replacement of the boot.stl, despite being the same, resulted in it booting without 2011 keys

I apologise for any time wasted on this matter

[ballsop]

Hi there,

I think i pinpointed an issue on my end As you have said, the files are identical. The system i was testing on had no dbDefault UEFI VAR, due to not having any Secure boot keys by default. I was in custom due to having to manually add the keys.

On another system with keys installed by default by the manufacturer, the media is bootable with and without the 2011 Keys.

We received a new bios with keys in by default, with a dbDefault UEFI VAR, and in both states, the media is bootable.

I am not sure if the lack of the dbDefault UEFI VAR is the cause, and know no easy way of testing without reflashing the BIOS numerous times. and am not sure why the replacement of the boot.stl, despite being the same, resulted in it booting without 2011 keys

I apologise for any time wasted on this matter

No apology needed! I am glad it was sorted out. Note that we are still considering this proposed change regardless as it (in theory) ensures we always use the latest boot.stl, but we want to work through some of the media compositional variations to be sure it is a safe overall change.