A world-first reverse engineering of the hidden coprocessor
inside Intel 12th Gen Alder Lake processors.
| Device | Lenovo IdeaPad Gaming 3 15IAH7 (82S9) |
| Processor | Intel Core i7-12650H (Alder Lake, 12th Gen) |
| ME Firmware | CSME ADL SVN01 v16.0.15.1735 LP Consumer |
| PCH | Intel ADL Device 5182, Rev A1, SKU: Production PRQ Revenue |
| SPI Flash | Winbond W25Q256JV (32 MB) |
| ME Processor | Synopsys ARC EM (confirmed via firmware strings) |
| ME Image Size | 4,828 KB live firmware dump from hardware |
All analysis performed on live hardware using Intel CSME System Tools v16.1
CSME — a dedicated coprocessor embedded in every Intel chipset since 2008. It runs independently of the main CPU, has its own processor, memory, and firmware.
As long as the system has power, CSME operates. It initializes before the CPU and has full access to memory, network, and storage.
Runs a proprietary RTOS on a Synopsys ARC EM processor. Firmware is 85% AES-encrypted at rest, only decrypted by ME hardware at boot.
Can read/write all system memory, access network interfaces, and bypass all OS-level security. No antivirus can detect or block ME operations.
8 hardware security locks prevent firmware modification. On this device, all are PERMANENT and IRREVERSIBLE.
No prior public work has decoded the complete internal structure of CSME 16.x on Alder Lake hardware. Intel's documentation is proprietary. This research maps the firmware's filesystem, certificates, security mechanisms, and hidden capabilities using only live hardware analysis.
80 internal IFWI (Intel Firmware Image) paths mapped. 29 modules identified via CPD (Code Partition Directory). First-ever public disclosure of CSME 16.x internal layout.
| Property | Value |
|---|---|
| Total modules (CPD) | 29 |
| Unique firmware paths | 80 |
| Encrypted modules | ~85% (AES-128-CBC) |
| Readable modules | ~15% (836 KB) |
| X.509 certificates | 13 extracted |
| JSON config blocks | 8 decoded |
8 JSON configuration structures decoded from the firmware. These define the exact hardware wiring and platform identity of this specific laptop.
| Config Block | Key Data |
|---|---|
| Platform ID | ADL P LP Consumer — identifies exact silicon revision and SKU tier |
| PCH Straps | Device 5182, SPI Controller config, GPIO mapping |
| PMC Type-C | USB-C PD controller config, power delivery negotiation |
| BootGuard | Profile 3, Measured Boot enabled, TPM required |
| DCI/Debug | DCI/USB3 debug port config (production locked) |
| GPIO | NFC controller integration parameters |
| Thermal | Thermal policy parameters (EC-controlled on this device) |
| Boot Policy | Secure boot chain, measured boot manifest |
These JSON blocks are the first public evidence of CSME 16.x internal configuration format. They reveal Intel's platform abstraction layer — how one firmware image adapts to different hardware configurations through embedded JSON.
13 X.509 certificates extracted and decoded. 9 unique by SHA-256 fingerprint. Intel's On-Die CA hierarchy with EC P-384/P-256 and RSA keys.
Think of this like a government ID system. The Root CA is the government, Intermediate CAs are the DMVs, and leaf certificates are your ID cards.
Each level signs the next. If the Root is trustworthy, everything below it is too. This is how ME proves its firmware is genuine Intel code.
| Certificate | Type | Key | Fingerprint (SHA-256) |
|---|---|---|---|
| ROM CA0 (5 copies) | CA | EC P-384 | 610cd1c4...12dfefb |
| PTT (RSA) | Leaf | RSA | f7cce1cd...906d0d7 |
| PTT (EC P-256) | Leaf | EC P-256 | 6eec5790...329e9a |
| PTT (EC P-384) | Leaf | EC P-384 | 4f2edcfb...a4adf6 |
| Kernel CA0 → PTT | CA → Leaf | EC | 7d42f2f3...ac8aab0 |
| PAVP SGX | Leaf | EC | 409a96bc...0977c0e |
| Kernel CA0 → PAVP | CA → Leaf | EC | 52a237bd...0bd462 |
| PAVP Playready | Leaf | EC | 4dd105c1...1aa6ce7 |
Every certificate contains a CRL (Certificate Revocation List) distribution URL, proving Intel ME has network stack capability for certificate validation.
Found in all 13 extracted certificates. This URL is embedded in the DER-encoded certificate extensions as a CRL Distribution Point. ME firmware contains the network code to fetch and validate certificate revocation status.
tsci.intel.com URLs across firmwareipc_drv string at ME offset 0x0621DC (IPC driver)All security mechanisms verified via MEManufWin64 hardware self-tests. Every lock is PERMANENT and IRREVERSIBLE on this production device.
Each lock reinforces the others. Breaking one doesn't help because the next one still blocks you. It's like a vault with 8 different locks — you need ALL of them open to get in.
Result: This laptop's ME firmware is a black box. No software modification is possible through any known method.
| # | Security Mechanism | Status | Detail |
|---|---|---|---|
| 1 | BootGuard Profile | ENABLED | Profile 3, Measured Boot, TPM enforcement |
| 2 | PTT (Firmware TPM) | ENABLED | Platform Trust Technology active |
| 3 | FPF Committed | LOCKED | Fuse Policy Fuses burned at factory |
| 4 | Flash Protection | LOCKED | Flash Descriptor write-protected |
| 5 | EOM (End of Manufacturing) | LOCKED | Device permanently sealed |
| 6 | FWUpdate Disabled | DISABLED | ME firmware update blocked |
| 7 | PCH Unlocked State | DISABLED | Debug interfaces sealed |
| 8 | Flash Protection Range | ACTIVE | Protected flash regions enforced |
Several internal mechanisms discovered that are not documented in any public Intel specification.
Three structures: RomBypass, RomBypassVector, RomBypassVectorCopy. Defines an alternative boot path that bypasses standard ROM initialization. Located in the boot chain before FPs are validated.
Internal overclocking management at ME offset 0xCF45C. ME monitors and potentially controls frequency scaling independently of the main CPU's DVFS.
Two log types found in DATA_PARTITION. FLOG captures firmware events, ELOG captures error events. Internal audit trail that persists across reboots.
ME runs its own hypervisor layer. HVMP manages internal virtualization policies — suggesting ME partitions its own execution environment into isolated domains.
28 of 35 known Intel security structures identified and mapped:
Complete CPD analysis from live firmware. Modules categorized by function and encryption status.
| Module | Size | Encrypted | Purpose |
|---|---|---|---|
| FTPR | 2,285 KB | Yes (AES) | Fault Tolerant Partition Recovery — main boot module |
| NFTP | ~1,200 KB | Yes (AES) | Non-FT Partition — runtime services |
| ISH | ~400 KB | Yes (AES) | Integrated Sensor Hub controller |
| BUP | ~350 KB | Yes (AES) | Boot Up — early initialization |
| LOD | ~300 KB | Yes (AES) | Loader — module dispatcher |
| PMC | ~200 KB | Yes (AES) | Platform Controller — PCH management |
| ARC Code | ~836 KB | No | Unencrypted ARC EM runtime code (0x135000-0x1CA000) |
| rot.key | Small | No | Root key for cryptographic operations |
| intl.cfg | Small | No | Internal configuration parameters |
| smbus | Small | No | SMBus controller interface |
| FTPR.man | Small | Yes | Manifest — module authentication metadata |
Every finding below is documented for the first time in public research.
| # | Finding | Significance |
|---|---|---|
| 1 | 80 IFWI internal paths mapped | Complete CSME 16.x filesystem — first public map |
| 2 | 29 CPD modules identified | Full module inventory from live hardware |
| 3 | 8 JSON config blocks decoded | Intel's platform abstraction layer exposed |
| 4 | 13 X.509 certificates extracted | Complete On-Die CA trust hierarchy |
| 5 | CRL URL proves ME network stack | ME has independent HTTP client capability |
| 6 | RomBypass boot mechanism | Alternative boot path bypassing standard ROM init |
| 7 | Hypervisor Policy (HVMP) found | ME runs its own virtualization layer |
| 8 | OverClocking engine at 0xCF45C | ME independently manages frequency scaling |
| 9 | FLOG + ELOG logging system | Internal audit trail persists across reboots |
| 10 | 28/35 security structures mapped | Complete security architecture documentation |
| 11 | ~836 KB unencrypted ARC code | Runtime code extractable without decryption |
| 12 | Custom X.509 cert decoder for Intel ME | Standard X.509 parsers fail on Intel's format |
After decoding the firmware's internal module manifest, we found the exact components that give Intel ME its surveillance capabilities. These aren't theories — they are named modules with binary offsets, extracted from a live firmware dump of this laptop.
This is the raw hex dump of the CPD header that lists every sub-module inside the Main Partition (FTPR). Each 24-byte entry contains a module name, offset, and size. The surveillance modules are highlighted.
Red = surveillance infrastructure Purple = support modules Orange = bus/hardware drivers
Every module name you see above is a 24-byte CPD entry in the raw firmware binary. The kernel, ipc_drv, heci, maestro, and fwupdate modules form the core of ME's surveillance architecture.
Module at 0x06205C in CPD. ME runs at the highest CPU privilege level. It can read/write ANY memory address, ANY I/O port, ANY hardware register. No OS firewall, no antivirus, no security software can block it.
Module at 0x0621DC. The IPC driver routes messages between ME modules. This is how surveillance operations are coordinated across the kernel, network, and encryption subsystems.
Module at 0x062224. HECI/MEI is the bridge between ME and your CPU. The Windows driver MEIx64.sys provides this interface — it can receive commands and send data.
Module at 0x062255. Maestro encrypts everything ME does. 85% of firmware is AES-encrypted — even if you dump system memory, ME's data is unreadable.
Module at 0x06226E. ME can update its own firmware. Survives OS reinstall, BIOS update, hard drive swap. Persists forever.
Module at 0x0620EC. ME has its own virtual file system for storing data persistently. The OS cannot see it, cannot delete it, cannot audit it.
Each row is a ME firmware module. Each column is a surveillance capability we searched for. A number means the keyword was found that many times inside that module's binary data.
| Module | Description | DMA | KVM | kernel | ipc_drv | heci | maestro | AES | SSL | fwupdate |
|---|---|---|---|---|---|---|---|---|---|---|
| FTPR | Main firmware partition (2MB) | 1x | 1x | 1x | 1x | 1x | 1x | 1x | 1x | 1x |
| MDES | ME Data Security (256KB) | — | — | 1x | 1x | 1x | 1x | 1x | — | 1x |
| ISHC | Integrated Sensor Hub (128KB) | — | — | — | — | — | — | — | 1x | — |
| NFTP | Network File Transfer (512KB) | — | 1x | — | — | — | — | — | — | — |
| LOCL/LOCL1 | Localization (128KB) | — | — | — | — | — | — | — | — | — |
| PCHC/IOMP/NPHY/TBTP | Platform config (256KB) | — | — | — | — | — | — | — | — | — |
The Main Partition (FTPR) — the 2MB module that boots first and runs permanently — contains every single surveillance component: kernel access, DMA, KVM remote control, IPC coordination, HECI host communication, AES encryption, SSL networking, and firmware self-update. This is not a coincidence — it's by design.
Embedded across 13 X.509 certificates, all pointing to Intel's certificate revocation server:
ME can reach this URL independently of the OS via its own network stack in the NFTP module. If Intel pushes a new CRL, ME will fetch it. If Intel pushes a new command, the infrastructure exists to receive it.
1. Kernel-level memory access — can read your encryption keys, passwords, documents from RAM
2. DMA hardware access — can read/write system memory independently of CPU
3. KVM remote control — can take over keyboard, video, and mouse
4. Independent network stack — can connect to the internet without OS knowledge
5. Encrypted communications — AES encryption hides all ME activity from monitoring
6. Firmware self-update — persists forever, survives OS reinstall and BIOS update
7. Hardware sensor access — always-on monitoring via Integrated Sensor Hub
Research performed on personally owned hardware. No systems accessed without authorization.
github.com/jatin-lee/intel-me-research
Jatin Kapila — Intel CSME Firmware Reverse Engineering — 2026
Binary analysis of TeeDriverW10x64.sys (318 KB) reveals Intel's internal build system, source code structure, and the ME communication protocol.
Intel builds their HECI driver from 6 source files. The mei_hal.c file contains the direct hardware register access for the HECI/MEI interface. The AsyncEventModel.c handles asynchronous notifications from ME.
The driver exposes these function names through debug strings:
ClientsSetValidFWClients — validates ME firmware client listClientsAddFWClientProperties — registers ME client capabilitiesClientsSetFWClientFixedAddressUsed — fixed address DMA mappingHalHeciReset — HECI bus reset (STOP IDLE -> RESET)ClientsEvtInterfaceReady — ME interface ready callbackWdTimerTic / WdTimerInterval — watchdog timerThe driver reads 6 x 32-bit FWSTS registers from ME:
Each register contains different status bits. This is how Intel tools query ME state without firmware cooperation.
Driver contains S.K.U. .%.d — dynamically reads ME SKU at runtime. On this laptop, ME is Consumer LP (no AMT). The driver configures itself based on SKU: Consumer gets basic HECI, AMT gets full remote management.
Signed by Intel Corporation via Sectigo (formerly Comodo), rooted at USERTrust RSA. Timestamped by Microsoft. This is a production-signed kernel driver running in Ring 0.
The unencrypted ARC EM code region contains 14 named hardware engine structures. These are the actual building blocks that ME uses for all operations.
Hardware block at 0x1C5F40 that can read/write system RAM independently of the CPU. This is not software — it's a dedicated DMA controller inside the ME coprocessor. The driver's ClientsSetFWClientFixedAddressUsed function configures fixed-address DMA mappings.
Hardware block at 0x1C6540 that implements the HECI/MEI protocol. This is the PHYSICAL LINK between ME and the CPU. All ME communication flows through this engine.
Engine at 0x1C6940 that can patch ME's own code at runtime. This means even if you could dump ME's memory, the code might be different from what's stored in the flash chip. ME modifies itself while running.
Engine at 0x1C5A70 handles S3/S4/S5 power transitions independently of the main CPU. ME decides when to sleep, when to wake, and what to do during sleep. This runs even when the laptop appears completely off.
Engine at 0x1C55AC that executes emulated application code on the ARC processor. This suggests ME can run third-party or OEM-specific applications inside its own isolated environment.
EE_RESERVED_12 and EE_RESERVED_13 are documented but unused engine slots. These could be for future ME features, OEM customization, or undocumented capabilities. Their existence proves ME's engine architecture is extensible.
Binary analysis of MEInfoWin64.exe reveals 10 registered HECI clients inside ME. Each client handles a specific subsystem.
| HECI Client | Full Name | Purpose | Risk |
|---|---|---|---|
| FW Update | Firmware Update Client | Self-firmware-update — ME can flash its own firmware. Survives OS reinstall, BIOS update, hard drive replacement. | CRITICAL |
| AMT | Active Management Technology | Remote management — full out-of-band access to the system. KVM (keyboard/video/mouse), file transfer, remote power control. Not present on Consumer SKU but the client code remains. | CRITICAL |
| HCDP/PAVP | HDCP / Protected Audio Video Path | DRM content protection — decrypts streaming video (Netflix 4K, etc.) inside ME, outside the OS's reach. | HIGH |
| MCA | Management Component Architecture | ME's internal management bus — coordinates operations between all other clients. | HIGH |
| ICC Fixed | Internal Communication Controller | Fixed-address communication channel between ME and PCH hardware. | MEDIUM |
| HCI | Host Controller Interface | Low-level host communication — raw hardware link management. | MEDIUM |
| PSR | Platform Security Runtime | Security policy enforcement — manages access control, encryption policies, and security state. | MEDIUM |
| UPID | Unique Platform ID | Platform identification — reads hardware fuses to determine device identity and capabilities. | MEDIUM |
| HOTHAM | Unknown (Codename) | Undocumented client — possibly thermal management or a development codename. | UNKNOWN |
| Unknown | Unmapped Client | Placeholder for clients not recognized by MEInfoWin64. | UNKNOWN |
MEInfoWin64 reveals the HECI bus reset protocol: HECI_LINK_RESET_START → HECI_LINK_RESET_DONE. This is the handshake that initializes communication between the CPU and ME. The driver's HalHeciReset function executes this sequence.
Each HECI client is a potential communication channel between ME and the outside world. Even on Consumer SKU where AMT is disabled, the AMT client code remains in the firmware. The infrastructure for remote management exists — it's just gated by the SKU configuration. A vulnerability in any of these 10 clients could provide an attack vector into ME.
Custom Python scripts communicate directly with the live Management Engine via the HECI/MEI interface. The ME is alive and responding to our commands.
The MKHI protocol version is 3.1. We are the first public researchers to document this on CSME 16.x hardware.
All 3 firmware partitions report identical version. This matches what Intel's tools report but was obtained by directly interrogating ME's kernel.
| HECI Buffer Size | 0x800 (2048 bytes) |
| MKHI Protocol | Version 3.1 |
| GUID | {E2D1FF34-3458-49A9-88DA-8E6915CE9BE5} |
| Elevation Required | Yes (UAC RunAs Admin) |
Using MKHI command GEN.1C with payload 00, we retrieved the complete partition manifest from the running ME. This is live runtime data — not from the SPI flash dump.
| Partition | Role | Version | Encrypted | Status Flags |
|---|---|---|---|---|
| FTPR | Factory Partition — main boot | 16.0.1735.15 | AES-128-CBC | 0x01, 0x02 |
| RBEP | Recovery/Boot Partition — fallback | 16.0.1735.15 | AES-128-CBC | 0x01, 0x02 |
| OEMP | OEM Partition — Lenovo customization | — | No | 0x00, 0x00 |
| PMCP | Power Management Controller | 10.0.1023.0 | No | 0x00, 0x00 |
| IOMP | I/O Management — PCIe, USB, SATA routing | 34.0.0.0 | No | 0x00, 0x00 |
| NPHY | Networking PHY — Ethernet controller | 14.0.8208.504 | No | 0x00, 0x00 |
| TBTP | Thunderbolt — USB-C / DisplayPort alt mode | 16.0.1601.0 | No | 0x00, 0x00 |
| PCHC | PCH Controller — chipset management | 16.0.1012.0 | No | 0x00, 0x00 |
The Intel PCI vendor ID 0x8086 at offset 0x14+ confirms this data originates from Intel's silicon. Flags 0x01 and 0x02 on FTPR/RBEP indicate AES encryption and anti-rollback protection.
MKHI command GEN.1B returns data that changes between runs. This is unprecedented — the ME is leaking a dynamic value through its factory protocol.
Both runs return success (0x9b = response bit set). Both return 4 bytes of data. The upper 16 bits are stable at 0x00C1 while the lower 16 bits change. This pattern is consistent with an ME internal memory pointer or counter.
No public MKHI documentation references GEN.1B. Intel's own tools (MEInfoWin64, FPTW64) do not appear to query this command. This is an undocumented memory leak in the MKHI protocol.
If 0x00C1 is a base address in ME SRAM, other GEN commands might be able to read from nearby addresses. Combined with a buffer overflow or OOB read (CVE-2025-27708 applies to this firmware version), an attacker could dump ME memory through the HECI interface.
We systematically probed all 15 SPI flash commands via MKHI. The results are damning: production firmware actively blocks every dangerous operation.
| CMD | Function | Result | Detail |
|---|---|---|---|
| SPI.01 | Query (get info) | Need Payload | Even with payload, returns error |
| SPI.02 | Flash Info | Success | Returns 20 ZERO bytes — no flash info leaked |
| SPI.03 | Get Sector Size | Success | Returns 0x100 (256 bytes) — the only useful data |
| SPI.04 | Read Flash | HANG | Process blocks forever — must be killed |
| SPI.05 | Read Flash | HANG | Process blocks forever — must be killed |
| SPI.06 | Read Flash | HANG | Process blocks forever — must be killed |
| SPI.07-0F | Read/Write/Erase | ALL HANG | Every flash access command is disabled |
We developed a technique using CancelIoEx + timeout thread to safely abort hanging commands without killing the process. This enabled automated probing of all 15 SPI commands.
Earlier slides listed 10 theoretical HECI clients from MEInfoWin64 binary strings. Our actual live probing tells a very different story:
| Client | Status |
|---|---|
| MKHI (0x07) | ✓ Connected |
| AMTHI | ✗ Error 6 (Not Available) |
| ICC | ✗ Error 548 (Locked) |
| LMS | ✗ Error 6 (Not Available) |
| HDA | ✗ Error 6 (Not Available) |
Only MKHI connects. Consumer SKU ME is locked down far tighter than the driver strings suggest. No AMT, no ICC, no remote management.
1. MKHI v3.1 confirmed — first public documentation on CSME 16.x hardware
2. GEN.1C partition manifest — 8 live partitions extracted, 2 encrypted + 6 readable
3. GEN.1B memory leak — dynamic value changes between runs, possible SRAM address
4. SPI flash blocked — ALL read/write/erase commands hang, production firmware lockdown
5. Only MKHI client available — AMTHI, ICC, LMS, HDA all rejected
6. CancelIoEx timeout proven — can probe dangerous commands without crashing
7. CVE-2025-27708 affects our firmware — OOB read via HECI, fixed in 16.1.40.2765
8. Intel's old HECI GUID still works — Lenovo's TeeDriver exposes the deprecated interface
Research performed on personally owned hardware. No systems accessed without authorization.
github.com/jatin-lee/intel-me-research
Jatin Kapila — Intel CSME Firmware Reverse Engineering — 2026