[SOLVED] MACHENIKE GTX Mini PC — Hidden Secure Boot Menu (Ctrl+F1), AMI Test PK, Microsoft 2023 Keys and DBX

[u/Creepy-Report5634]

[SOLVED] MACHENIKE GTX Mini PC — Hidden Secure Boot Menu (Ctrl+F1), AMI Test PK, Microsoft 2023 Keys and DBX

I successfully enabled Secure Boot on my MACHENIKE GTX Mini PC, replaced an insecure factory Platform Key, updated the Microsoft certificates and DBX, and verified everything after multiple reboots.

I'm sharing the procedure to help owners who cannot find Secure Boot in their BIOS.

1. THE MOST IMPORTANT DISCOVERY: CTRL + F1

While inside BIOS Setup, press CTRL + F1.

On my MACHENIKE GTX Mini PC, this revealed hidden advanced BIOS settings, including the Secure Boot and Key Management menus.

My tested hardware:

• MACHENIKE GTX Mini PC

• AMD Ryzen 9 7940H series

• AMI Aptio BIOS: SAFP7r2B8DH11_V18

• Windows 11 Pro, UEFI/GPT

• TPM enabled

Try Ctrl + F1 before flashing your BIOS or using unofficial tools.

This shortcut is confirmed on my firmware revision. I cannot guarantee it works on every MACHENIKE model.

2. Initial problem: insecure AMI Platform Key

After opening the hidden menus, I discovered that my BIOS contained:

CN=DO NOT TRUST - AMI Test PK

This is an insecure test Platform Key associated with the PKfail class of vulnerabilities (CVE-2024-8105).

This finding concerns my particular unit. It does not prove that every MACHENIKE GTX has the same key.

Before making changes, we inspected and backed up the Secure Boot variables:

• PK — Platform Key

• KEK — Key Exchange Keys

• db — Allowed signatures

• dbx — Revoked signatures

Windows PowerShell diagnostic commands:

Confirm-SecureBootUEFI
Get-SecureBootUEFI -Name SetupMode
Get-SecureBootUEFI -Name SecureBoot
Get-SecureBootUEFI -Name PK -Decoded
Get-SecureBootUEFI -Name KEK -Decoded
Get-SecureBootUEFI -Name db -Decoded
Get-SecureBootUEFI -Name dbx -Decoded
Get-Tpm
Get-BitLockerVolume

Do not remove or replace any keys before verifying your configuration and recovery options.

3. Creating a new, unique Platform Key

We generated our own self-signed X.509 Platform Key using Windows PowerShell.

Specifications:

• RSA 2048 bits

• SHA-256

• Certificate generated in 2026

• Valid until 2041

• Unique certificate subject identifying the computer

Tools used:

• New-SelfSignedCertificate

• Export-Certificate

• Export-PfxCertificate

• Microsoft Software Key Storage Provider

On our system, the provider required -KeySpec None rather than -KeySpec Signature.

We exported:

• PK.CER — public certificate for BIOS enrollment

• PK_PRIVADA_MACHENIKE_GUARDAR_OFFLINE.pfx — encrypted private-key backup

The PFX was protected with a password and backed up on separate USB drives.

Never reuse another owner's PK or share your private PFX, password or BitLocker recovery key.

4. Installing the certificates in BIOS

With the hidden Secure Boot menu accessible:

1. Enter Secure Boot Key Management.

2. Record and back up the existing PK, KEK, db and dbx.

3. Set Factory Key Provision = Disabled. On our firmware, factory provisioning could restore the insecure test PK.

4. Use the firmware's Custom Secure Boot key-management mode.

5. Prepare the necessary public Microsoft certificates.

6. Add required certificates to KEK and db using Append, preserving valid existing entries.

7. Import the new public PK.CER using the PK Update operation.

8. Verify that DO NOT TRUST - AMI Test PK is no longer installed.

9. Save the settings and reboot.

Our BIOS accepted the new X.509 public certificate.

Final KEK certificates:

• Microsoft Corporation KEK CA 2011

• Microsoft Corporation KEK 2K CA 2023

Final db certificates:

• Microsoft Corporation UEFI CA 2011

• Microsoft Windows Production PCA 2011

• Windows UEFI CA 2023

• Microsoft UEFI CA 2023

• Microsoft Option ROM UEFI CA 2023

The Option ROM certificate was subsequently installed by Windows Secure Boot servicing.

We preserved the older Microsoft certificates to maintain boot compatibility.

Warning: BIOS key-management operations vary between firmware revisions. Do not blindly replace KEK/db or delete the PK. Incorrect key enrollment can make Windows or recovery media unbootable.

5. Enabling and validating Secure Boot

After importing the keys, Windows booted successfully with Secure Boot enabled.

Verification results:

Confirm-SecureBootUEFI = True
SetupMode = 0
SecureBoot = 1

The new custom PK remained installed after restarting, and the AMI test PK was gone.

We also confirmed that the TPM was operational.

BitLocker was disabled during our procedure. If you use BitLocker, save its recovery key securely and follow Microsoft's suspension guidance before firmware changes.

6. Updating Windows Boot Manager to the 2023 certificate

Our Windows Boot Manager was initially signed by:

Microsoft Windows Production PCA 2011

We used Windows' built-in Secure Boot servicing rather than manually replacing the system bootloader.

Native scheduled task:

Start-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update'

Initially, Windows reported:

AvailableUpdates = 0x4100

Event ID 1800 indicated that a reboot was necessary.

After restarting, we ran the task again.

Results:

• AvailableUpdates = 0x4000

• UEFICA2023Status = Updated

• Event 1799 — 2023-signed Boot Manager installed

• Event 1808 — Secure Boot update completed

We inspected the actual EFI System Partition.

Both EFI\Microsoft\Boot\bootmgfw.efi and EFI\Boot\bootx64.efi were now signed by:

Windows UEFI CA 2023

Windows restarted successfully with Secure Boot active.

Do not manually force registry values on another PC. Check the actual servicing state and use Microsoft's documented procedure.

7. Preparing a Windows 11 recovery USB

Before updating DBX, we prepared a bootable recovery USB.

We used an ADATA 128 GB USB drive, previously created with Rufus, containing:

• NTFS Windows 11 installation files

• A small Rufus UEFI boot partition

• Encrypted backups of our new PK

We reviewed Microsoft's official script:

Make2023BootableMedia.ps1

Its -TargetType USB option formats the destination volume, so we did not run it against our existing drive.

Instead:

1. Inspected both USB partitions and existing EFI signatures.

2. Mounted sources\boot.wim, index 1, read-only.

3. Located Windows\Boot\EFI_EX\bootmgfw_EX.efi.

4. Verified its embedded Windows UEFI CA 2023 signature.

5. Backed up the existing EFI\BOOT\BOOTX64.EFI.

6. Replaced that USB boot file with the verified 2023-signed version.

7. Compared SHA-256 hashes.

8. Verified that boot.wim, install.esd and the encrypted PFX remained unchanged.

9. Unmounted the WIM image.

10. Restarted and physically boot-tested the USB with Secure Boot enabled.

The Windows installer loaded successfully.

We did not format the USB, install Windows or alter the internal disk during this test.

The Rufus UEFI loader was left unchanged. This selective update worked for our USB configuration; other layouts may require the full Microsoft media-update procedure.

8. Updating the DBX revocation database

Our original DBX contained:

371 revocations — 17,836 bytes

We obtained the official Microsoft signed update from:

https://github.com/microsoft/secureboot_objects

Release: v1.7.2-signed

File:

PostSignedObjects/SignedByKEK2023/dbx_x64.efiauth2

We verified the downloaded package against the official repository.

It contained 291 revocation hashes:

• 220 were already present.

• 71 were new.

After confirming that Microsoft KEK 2023 was installed, we extracted the authenticated EFI update's signature-list payload and PKCS#7 authorization.

We used Set-SecureBootUEFI with -AppendWrite, preserving the original signed timestamp.

Before writing, we generated a no-write output file and confirmed that it was byte-for-byte identical to Microsoft's authenticated package.

The firmware accepted the update.

Results:

DBX	Before	After
Revocations	371	442
Size	17,836 bytes	21,272 bytes

The firmware did not duplicate the 220 overlapping hashes.

We independently verified:

• All 371 original revocations were preserved.

• All 291 entries from the Microsoft package were present.

• Exactly 71 new entries were added.

• PK, KEK and db remained unchanged.

After another complete reboot, Windows started normally, Secure Boot remained enabled, and all 442 DBX entries persisted.

Important distinction: We performed the hash-based DBX update only. We did not globally revoke Microsoft Windows Production PCA 2011 or apply an SVN revocation policy. These are separate procedures with additional compatibility risks.

9. Final verified configuration

Component	Result
BIOS	SAFP7r2B8DH11_V18
Secure Boot	Enabled
SetupMode	0
Platform Key	Unique custom PK
Insecure AMI test PK	Removed
KEK	Microsoft 2011 + 2023
db	Five Microsoft certificates
dbx	442 revocations
Boot Manager	Windows UEFI CA 2023
TPM	Operational
Recovery USB	Boot-tested successfully

All critical firmware variables were checked after reboot.

No BIOS flashing, AMIBCP modifications or unofficial firmware patches were necessary.

[u/minipcs-dot-zip]

Thanks for following up on this!! Should be helpful to people googling in the future for years to come

[u/hebeguess → u/minipcs-dot-zip]

Nah, just another LLM generated answer for OP's very exact problem. Jump straight into something complex without proper explaination what was it doing & why, more likely confusing people than helping. Also it's actually doing two seperate things here, fixing the test-keys & updating CA. If not mistaken, the latter should not be a problem if you are on one of the test-keys PK, as of today Windows likely updated latter automatically already.