maxsun mobo loading a weird PK
- Thread starter Cleo
- Start date
Hardware Discussions
15 Replies
2,534 Views
Share practical recommendations that address the author's needs.
Short answer
Do not enable Secure Boot with a test Platform Key loaded.
The “Do Not Trust - AMI Test PK” entry strongly suggests the board firmware includes a test key, and that is not what you want for normal Secure Boot use.
What this likely means
Secure Boot relies on trusted keys stored in firmware:
- PK = Platform Key
- KEK = Key Exchange Keys
- db = allowed signatures
- dbx = revoked signatures
A test PK is typically meant for development or validation, not for production use. If that key is actually installed, Secure Boot trust would not be in a normal vendor/Microsoft state.
What you should do
Use the lowest-risk path first:
- Do not manually select or enroll the AMI test key.
- Check whether the BIOS has an option such as:
- “Install default Secure Boot keys”
- “Restore factory keys”
- “Windows UEFI mode”
- “Standard” instead of “Custom”
- If there is more than one key set shown, choose the normal production/default/factory Microsoft/OEM key set, not anything labeled test.
- Update the BIOS from Maxsun’s official support page if a newer firmware is available and the changelog mentions Secure Boot, key updates, or UEFI fixes.
- If the only factory-key option available loads the AMI test PK, stop there and contact Maxsun support, because that is not something I can safely call normal.
Before changing anything
A few practical precautions:
- Make sure Windows is installed in UEFI mode, not Legacy/CSM mode.
- If CSM is enabled, disable it before expecting Secure Boot to work.
- If BitLocker or device encryption is enabled, back up the recovery key first.
- Do not delete existing keys unless you are prepared to recover from a boot failure.
How to verify the current state in Windows
You can check what Windows sees:
- Press Win + R, type msinfo32
- Look for:
- BIOS Mode: UEFI
- Secure Boot State: On/Off
If Secure Boot stays off even in UEFI mode, the firmware key state is probably still wrong or incomplete.
If you want a safe conclusion
If the board only offers “AMI Test PK” under factory/default keys, I would treat that as a firmware problem or at least something that needs vendor clarification, not something to “just try.”
The safest next step is to avoid that test key, update to the latest official BIOS, and if the behavior remains, contact Maxsun support or post BIOS screenshots from the Secure Boot key pages for careful review.
Check out the "O&O ShutUp10" program, as its latest version displays the secure boot status and what is recommended to do. There are other solutions in this thread:
Serious Discussion Thread 'Secure Boot certificate updates'
The first step is to check if your BIOS offers the option Restore Factory Keys or Install Default Keys.
If the BIOS shows a key marked as “AMI Test PK”, the recommended action is to update to the latest available version and then use that option to reinstall the default Secure Boot keys.
If the test key still appears as the only option after that, it looks more like a firmware issue with the motherboard rather than a configuration problem. In that case, the best approach is to contact Maxsun directly.
If the BIOS shows a key marked as “AMI Test PK”, the recommended action is to update to the latest available version and then use that option to reinstall the default Secure Boot keys.
If the test key still appears as the only option after that, it looks more like a firmware issue with the motherboard rather than a configuration problem. In that case, the best approach is to contact Maxsun directly.
The fact that restoring factory keys always brings back the AMI Test PK shows this is a firmware issue in the BIOS. Before giving up, I’d suggest two quick checks:
- Update the BIOS from Maxsun’s official site, in case a newer version already fixes this.
- Manually enroll the Microsoft key, if your BIOS has options like 'Enroll PK' or 'Key Management'.
Important note if you try Step 2:- Make sure to back up your BitLocker recovery key before touching the BIOS keys, just in case Windows triggers a recovery screen on the next boot.
- Your USB drive must be formatted in FAT32, and you will need the official Microsoft certificate file in a compatible format (like .auth or .der).
Last edited:
It's strange.The fact that restoring factory keys always brings back the AMI Test PK shows this is a firmware issue in the BIOS. Before giving up, I’d suggest two quick checks:
If you’re already on the latest BIOS and there’s no way to load external keys, then it’s clearly a firmware bug. At that point, the only workaround is to keep Secure Boot disabled and contact Maxsun support for a fix.
- Update the BIOS from Maxsun’s official site, in case a newer version already fixes this.
- Manually enroll the Microsoft key, if your BIOS has options like 'Enroll PK' or 'Key Management'.
- Make sure to back up your BitLocker recovery key before touching the BIOS keys, just in case Windows triggers a recovery screen on the next boot.
- Your USB drive must be formatted in FAT32, and you will need the official Microsoft certificate file in a compatible format (like .auth or .der).
I don't have BitLocker enabled, and it asks me to reset my PIN each time I try to enable Secure Boot.
There is no visible indication on the mobo which version it is. I tried the latest BIOS for both V2 and V3, and they
both had the exact same issue. I do recall an option to "Enroll EFI image". Is that what I want to try? The OsRecovery
Signatures dbr shows as empty.
The fact that restoring factory keys always brings back the AMI Test PK confirms that the problem comes directly from the firmware Maxsun compiled for this board. Since you already tried the latest versions for both V2 and V3 and got the same result, it’s clear this is a manufacturer oversight that hasn’t been fixed.
Regarding your doubts:
For now, the only practical solution is to keep Secure Boot disabled (Windows 11 will run fine, though note that some competitive games with anti-cheat or banking apps may require it). If Secure Boot is important for you, the best option is to contact Maxsun support for a BIOS patch, or even return the board if that’s still possible.
Regarding your doubts:
- Enroll EFI Image won’t help here: That option only authorizes a specific .efi file (like an alternative bootloader), but it does not replace the defective root key (PK). It won’t fix Windows Secure Boot.
- The PIN issue: Even if you don’t use BitLocker, Windows relies on the TPM chip to protect credentials (like your Windows Hello PIN). Every time you change something in the BIOS related to Secure Boot, the TPM detects it as a security change and asks you to reset the PIN. This is normal behavior, not a bug.
For now, the only practical solution is to keep Secure Boot disabled (Windows 11 will run fine, though note that some competitive games with anti-cheat or banking apps may require it). If Secure Boot is important for you, the best option is to contact Maxsun support for a BIOS patch, or even return the board if that’s still possible.
Let’s keep the thread on the Secure Boot issue.
From what was described so far, “Enroll EFI Image” is not the fix. That option usually whitelists a specific bootloader or EFI file, but it does not correct a bad Secure Boot key set in firmware.
What the current symptoms suggest
- Restoring factory keys reintroduces AMI Test PK
- Enabling Secure Boot then causes Windows boot to fail with an invalid signature
- Windows asks to reset the PIN after Secure Boot changes, which can happen because TPM/Windows Hello reacts to trust changes
That combination points much more toward a bad or incomplete Secure Boot key/database setup in the BIOS than a normal Windows configuration issue.
About the empty OsRecovery dbr
By itself, an empty OsRecovery database is not the main problem here. The more important issue is that the board appears to restore a test PK instead of a normal production key set.
Practical conclusion
- Do not rely on Enroll EFI Image as a fix for this specific problem
- If both V2 and V3 BIOS files behave the same way, there is not enough evidence to say there is a safe end-user fix in BIOS
- The safest workaround is to leave Secure Boot disabled for now
- If Secure Boot is required, the right next step is to contact Maxsun support or the seller and report that Restore Factory Keys installs AMI Test PK and breaks Windows boot
If you want to document it clearly for support
Include:
- Board model: Maxsun B760ITX
- Current BIOS version used
- That Load/Restore Factory Keys installs Do Not Trust - AMI Test PK
- That Windows 11 boots with Secure Boot off, but fails with invalid signature when Secure Boot is enabled
- That testing multiple BIOS versions did not change the behavior
Bottom line
Based on the symptoms shown, this looks like a firmware-side Secure Boot key problem, and Enroll EFI Image is not the proper remedy. The most sensible path is to keep Secure Boot disabled unless Maxsun provides corrected firmware.
Good choice of motherboard, Cleo
. It looks like the Erying has resolved the Secure Boot, TPM, XMP, and Resizable BAR issues.As for the drivers, if VirusTotal is flagging them, I would first check their digital signatures and make sure they were downloaded directly from the manufacturer's official website. Drivers from lesser-known manufacturers can sometimes trigger heuristic detections or false positives, although it's still worth approaching them with caution.
If you can share the VirusTotal report link or a screenshot of the detections, I'm sure some of the forum members with more experience in malware analysis and driver security will be able to provide better insight into whether these are false positives or something genuinely concerning.
Although 28/68 is still a fairly high detection rate, I took a look at the VirusTotal behavior report and found it interesting that the sandbox results don't seem particularly alarming.
There are no network connections, no dropped files, no IDS/Sigma alerts, and the sample is reported mostly as idle. Most of the observed activity looks consistent with an installer checking the system and accessing normal Windows locations.
I'm certainly not qualified to say whether the detections are false positives or not, but based on the behavior report alone, I don't see the sort of activity I would normally expect from an active trojan or a cryptocurrency miner.
That said, the detection count is still high enough that I'd remain cautious and be interested to hear what members with more malware analysis experience think about it.
⚠ I'm not an expert in malware analysis, so @Cleo, please take this with a great deal of caution.
After reanalyzing the hash on VirusTotal, it seems that EryingSetup.exe is responsible for most of the detections.
Assuming the drivers came from the official manufacturer website, one option is to extract the archive and check the individual files (.dll, .sys, .inf, etc.) on VirusTotal. This can help determine whether only the installer is flagged or if the drivers themselves are affected.
Alternatively, the drivers can be installed manually via Device Manager using the .inf files, which should allow the basic functionality even if some additional utilities are not installed.
I'm not saying the file is safe, just sharing observations in case they help identify the issue.
After reanalyzing the hash on VirusTotal, it seems that EryingSetup.exe is responsible for most of the detections.
Assuming the drivers came from the official manufacturer website, one option is to extract the archive and check the individual files (.dll, .sys, .inf, etc.) on VirusTotal. This can help determine whether only the installer is flagged or if the drivers themselves are affected.
Alternatively, the drivers can be installed manually via Device Manager using the .inf files, which should allow the basic functionality even if some additional utilities are not installed.
I'm not saying the file is safe, just sharing observations in case they help identify the issue.
Recently browsing
Members who viewed this thread in the last 5 minutes
