Please also keep in mind that it is impossible to disable ME.
*I am not a lawyer* In america the first sale law means you are allowed to do as you please with a device you purchased as long as you are not violating any EULA but if you somehow did the impossible and figured out how to execute code on the ME core you would be breaking the law as it is also a DRM mechanism (PAVP, HDCP, intel insider etc) which is illegal to bypass.
On 03/23/2018 05:22 PM, Taiidan@gmx.com wrote:
Please also keep in mind that it is impossible to disable ME.
That is not a binary yes/no fact.
Depending of the ME version, it is possible to deactivate it. The following x230 is not a server, but an example for older ME versions.
The resulting ME is 98304 bytes, containing the ROMP and BUP modules only. The booting system complains about ME, tries to initialize it for 3 seconds and then gives up.
I know that the story is different for newer versions of ME/Servers. But that statement of saying that disabling ME is impossible is not empowering at all and not completely true.
Thierry
user@build-x230:~/Downloads/me_cleaner$ ~/Downloads/me_cleaner/me_cleaner.py -O ~/Documents/Firmwares/ME/x230t/2.65/clean_flash.rom ~/Documents/Firmwares/originals/x230t/2.65/spi2_MX25L6405D_8192.rom -S -r -t -M ~/Documents/Firmwares/ME/x230t/2.65/extracted_me Full image detected The ME/TXE region goes from 0x3000 to 0x500000 Found FPT header at 0x3010 Found 23 partition(s) Found FTPR header: FTPR partition spans from 0x180000 to 0x24a000 ME/TXE firmware version 8.1.30.1350 Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x Reading partitions list... ???? (0x000003c0 - 0x000000400, 0x00000040 total bytes): removed FOVD (0x00000400 - 0x000001000, 0x00000c00 total bytes): removed MDES (0x00001000 - 0x000002000, 0x00001000 total bytes): removed FCRS (0x00002000 - 0x000003000, 0x00001000 total bytes): removed EFFS (0x00003000 - 0x0000df000, 0x000dc000 total bytes): removed BIAL (NVRAM partition, no data, 0x0000add0 total bytes): nothing to remove BIEL (NVRAM partition, no data, 0x00003000 total bytes): nothing to remove BIIS (NVRAM partition, no data, 0x00036000 total bytes): nothing to remove NVCL (NVRAM partition, no data, 0x00010511 total bytes): nothing to remove NVCM (NVRAM partition, no data, 0x0000493f total bytes): nothing to remove NVCP (NVRAM partition, no data, 0x0000a553 total bytes): nothing to remove NVJC (NVRAM partition, no data, 0x00004000 total bytes): nothing to remove NVKR (NVRAM partition, no data, 0x0001257d total bytes): nothing to remove NVOS (NVRAM partition, no data, 0x00034af5 total bytes): nothing to remove NVSH (NVRAM partition, no data, 0x00007609 total bytes): nothing to remove NVTD (NVRAM partition, no data, 0x00001eac total bytes): nothing to remove PLDM (NVRAM partition, no data, 0x0000a000 total bytes): nothing to remove GLUT (0x000df000 - 0x0000e3000, 0x00004000 total bytes): removed LOCL (0x000e3000 - 0x0000e7000, 0x00004000 total bytes): removed WCOD (0x000e7000 - 0x000140000, 0x00059000 total bytes): removed MDMV (0x00140000 - 0x000180000, 0x00040000 total bytes): removed FTPR (0x00180000 - 0x00024a000, 0x000ca000 total bytes): NOT removed NFTP (0x0024a000 - 0x0004a4000, 0x0025a000 total bytes): removed Removing partition entries in FPT... Removing EFFS presence flag... Correcting checksum (0x7b)... Reading FTPR modules list... UPDATE (LZMA , 0x1cc4f2 - 0x1cc6b0 ): removed ROMP (Huffman, fragmented data, ~2 KiB ): NOT removed, essential BUP (Huffman, fragmented data, ~56 KiB ): NOT removed, essential KERNEL (Huffman, fragmented data, ~135 KiB ): removed POLICY (Huffman, fragmented data, ~91 KiB ): removed HOSTCOMM (LZMA , 0x1cc6b0 - 0x1d348b ): removed RSA (LZMA , 0x1d348b - 0x1d86e0 ): removed CLS (LZMA , 0x1d86e0 - 0x1dde71 ): removed TDT (LZMA , 0x1dde71 - 0x1e4556 ): removed FTCS (Huffman, fragmented data, ~18 KiB ): removed ClsPriv (LZMA , 0x1e4556 - 0x1e4937 ): removed SESSMGR (LZMA , 0x1e4937 - 0x1f3240 ): removed Relocating FTPR from 0x180000 - 0x24a000 to 0xd00 - 0xcad00... Adjusting FPT entry... Adjusting LUT start offset... Adjusting Huffman start offset... Adjusting chunks offsets... Moving data... The ME minimum size should be 98304 bytes (0x18000 bytes) The ME region can be reduced up to: 00003000:0001afff me Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME... Extracting and truncating the ME image to "/home/user/Documents/Firmwares/ME/x230t/2.65/extracted_me"... Checking the FTPR RSA signature of the extracted ME image... VALID Checking the FTPR RSA signature... VALID Done! Good luck!
*I am not a lawyer* In america the first sale law means you are allowed to do as you please with a device you purchased as long as you are not violating any EULA but if you somehow did the impossible and figured out how to execute code on the ME core you would be breaking the law as it is also a DRM mechanism (PAVP, HDCP, intel insider etc) which is illegal to bypass.
On Sun, March 25, 2018 3:21 pm, thierry.laurion@gmail.com wrote:
On 03/23/2018 05:22 PM, Taiidan@gmx.com wrote:
Please also keep in mind that it is impossible to disable ME.
That is not a binary yes/no fact.
Depending of the ME version, it is possible to deactivate it. The following x230 is not a server, but an example for older ME versions.
The resulting ME is 98304 bytes, containing the ROMP and BUP modules only. The booting system complains about ME, tries to initialize it for 3 seconds and then gives up.
I know that the story is different for newer versions of ME/Servers. But that statement of saying that disabling ME is impossible is not empowering at all and not completely true.
Might just be a matter of semantics. Can you say ME is completely "disabled" or "deactivated", even on older systems, if the system requires ROMP and BUP to function? Have those 98304 bytes of code been analyzed for weaknesses/obfuscation? (Don't actually know the answer to this one although I know there has been some progress like https://mobile.twitter.com/rootkovska/status/938458875522666497).
How about a phrase like "ME can be deactivated after initialization"- I think that evaluates to true for everyone without getting into secret opcodes/silicon. Like you said, probably can't be distilled down into a single +/- word without losing context.
-
awokd -
Taiidan＠gmx.com -
thierry.laurion＠gmail.com