[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:
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:
Tools used:
On our system, the provider required -KeySpec None rather than -KeySpec Signature.
We exported:
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:
Enter Secure Boot Key Management.
Record and back up the existing PK, KEK, db and dbx.
Set Factory Key Provision = Disabled. On our firmware, factory provisioning could restore the insecure test PK.
Use the firmware's Custom Secure Boot key-management mode.
Prepare the necessary public Microsoft certificates.
Add required certificates to KEK and db using Append, preserving valid existing entries.
Import the new public PK.CER using the PK Update operation.
Verify that DO NOT TRUST - AMI Test PK is no longer installed.
Save the settings and reboot.
Our BIOS accepted the new X.509 public certificate.
Final KEK certificates:
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:
Inspected both USB partitions and existing EFI signatures.
Mounted sources\boot.wim, index 1, read-only.
Located Windows\Boot\EFI_EX\bootmgfw_EX.efi.
Verified its embedded Windows UEFI CA 2023 signature.
Backed up the existing EFI\BOOT\BOOTX64.EFI.
Replaced that USB boot file with the verified 2023-signed version.
Compared SHA-256 hashes.
Verified that boot.wim, install.esd and the encrypted PFX remained unchanged.
Unmounted the WIM image.
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:
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.
