Hi everybody,
Me and Federico Amedeo Izzo (federico.izzo42@gmail.com) started looking into our Intel ME firmwares after reading the thread "Experiments with disabling the ME on Sandy Bridge x230" started by Trammell Hudson.
We have two Thinkpad X220 (Sandy Bridge) and a X201 (Nehalem), and we obtained the following results:
* Sandy Bridge accepts an Intel ME firmware with just the FTPR partition, both with and without a valid FPT (the partition table of the Intel ME image). The system doesn't power off after 30 minutes, and the ME reports a successful initialization (see attached cbmem). To be extra safe we wrote a small Python script that removes all the non-fundamental partitions and creates a new FPT with a single partition entry (following the structure in [1] and some hints from Igor Skochinsky).
* Sandy Bridge boots successfully without a good FPT (but with a valid FTPR), so it probably has a "backup" on-chip FPT. The system boots fine and doesn't power itself off after 30 minutes, even if the cbmem entry "ME: FW Partition Table" has the value "BAD" (that, we suppose, means: "I found a broken partition table, I'm using the fallback one").
* According to Trammell Hudson's tests, this behaviour is the same in Ivy Bridge (the thread's subject says "Sandy Bridge" but his cbmem confirms that his device is actually an Ivy Bridge)
* Nehalem (on our X201) seems to lack a "backup" on-chip FPT, as removing the FPT partition bricks the device. Moreover using an ME image with just FPT and FTPR results in a brick, Nehalem probably needs more parts of the blob than just FPT and FTPR. Unfortunately our X201 is in a bad state and its flash is about to die, so we can't test further on Nehalem.
* We couldn't remove in any way the FTPR partition on Sandy Bridge: setting the entries number to 0, the UMA size to 0 MB, creating an invalid FPT with a bad checksum or creating a "fake" FTPR entry which points to an empty region leads to a bricked device. Apparently, no matter which trick is used, if ME can't find the FTPR partition it refuses to boot. We didn't try with a 0-sized partition, but the result is probably the same.
* Probably the UMA size can be reduced from the "stock" 16 MB or 32 MB to few MB, we'll investigate on this.
* Shrinking the "reduced" ME partition in IFD to the minimum size allowed (FTPR offset + FTPR size + 4 kB alignment) bricks the device too (but we're not sure about this, maybe we made a mistake during the image creation).
* Relocating the FTPR image doesn't work, even if the FPT entry points to the new location.
* We haven't understood yet how to remove the unneeded modules from the FTPR partition, any help is appreciated.
* The cbmem's ME entries * ME: Current Working State : Normal / Recovery * ME: Bringup Loader Failure : YES / NO * ME: Progress Phase : ROM Phase / BUP Phase seem to be interesting, and should be studied further.
Attached you can find the script we used to "clean" the ME images, the cbmem log of an untouched ME image (the 2.1 MB firmware extracted from a Acer Chromebook C710) and the cbmem log of the same image after executing the script on it (therefore with just the FPT with a single entry and the FTPR).
Some help testing the further options would be nice, in particular on the Nehalem architecture. Be careful: messing with ME may cause a hard brick, without the 30 minutes window, requiring an external programmer to unbrick your PC.
Nicola Corna Federico Amedeo Izzo