I am working with an Intel Apollo Lake Atom E3950 embedded system. My goal is to downgrade the Trusted Execution Engine (TXE) from the current version 3.1.76.2356 (VCN/SVN 69) to 3.0.1.1107 (VCN/SVN 1).
My ultimate objective is to utilize the INTEL-SA-00086 vulnerability to bypass/disable BootGuard, Secure Boot, and Measured Boot, which are currently active on this hardware.
My Problem:
I am flashing directly via an external SPI programmer. Here is the behavior I’m seeing:
-
If I patch in TXE version with the same SVN (69 - eg. 3.1.75.2351**)**, the system boots perfectly.
-
If I patch in TXE v3.0.1.1107 (SVN 1), the system is brick-like and fails to POST.
My Workflow:
-
Followed the guide: [Guide] Clean Dumped Intel ME/TXE Regions with Data Initialization.
-
Used Intel Flash Image Tool to decompose the original flash.
-
Replaced the TXE binary with the target version (3.0.1.1107).
-
Manually copied the SMIP region in HxD from the original dump to the new build to preserve signatures hand hardware config
-
Flashed the resulting image back to the SPI chip.
I was under the impression that Apollo Lake does not have the same hardware-enforced Anti-Rollback mechanisms (like Field Programmable Fuses) that prevent TXE downgrades in the same way modern Core-i platforms do?
Is there any other lock on Apollo Lake that enforces SVN checks even when flashing via SPI that I am missing?
I have uploaded the original working dump and both patched versions (the working SVN 69 and the non-working SVN 1) for analysis here:
Any insight into why the boot process hangs on the lower SVN would be greatly appreciated.