Adding soft-disable support for IFWI/ME12

[dt-zero]

Based on the work of @davidmartinzeus

---

IMPORTANT: If you are new here, please read my comment at #282 (comment)

[dt-zero]

On Intel Cannonlake H (300) Series chipsets such as QM370, Q370, B360, H370, H310, Z390, C242, C246, HM370, CM246 and QMS380 with Intel ME 12, the High Assurance Platform bit has been moved to PCHSTRP32.

My testing board is an ASROCK H370M-ITX/ac. With this patch, I get the usual good signs of ME disablement. ME disappeared from the PCI bus and the OEM bios shows ME version 0.0.0.0.

This patch is the very definition of bare minimum. A proper implementation would consist of parsing the CSE Partition Layout Table to locate the Boot Partition Descriptor Table and then finding a type 2 entry (FTPR). (Like how @platomav 's wonderful MEAnalyzer does)

Other than that, we would probably benefit from a cleaner way of tracking the HAP bit and matching that to specific chipsets. I think the best option there involves parsing the MFS and checking the "008"/"Home Directory" partition's "bup/bup_sku/plat_n_sku", which holds an SKU identifier inside the BIOS image. My current understanding is that any SKU identifier corresponds to a set PCH strap layout and hence a HAP bit position in the rom.

[craigacgomez]

I can confirm that this works on Clevo/Sager P95XER series notebooks (Tested with a P955ER) with ME12.

Original BIOS backup (using Intel FPT)

python ./me_cleaner.py -c ORIGINAL_BIOS.bin
Full image detected
Found FPT header at 0x2000
Found 7 partition(s)
Found FTPR header: FTPR partition spans from 0x88000 to 0x88000
Found FTPR manifest at 0x88250
ME/TXE firmware version 12.0.40.1433 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is NOT SET
Checking the FTPR RSA signature... VALID

Applying me_cleaner with this pull request #282

python ./me_cleaner.py -s -O PATCHED_BIOS.bin ORIGINAL_BIOS.bin
Full image detected
Found FPT header at 0x2000
Found 7 partition(s)
Found FTPR header: FTPR partition spans from 0x88000 to 0x88000
Found FTPR manifest at 0x88250
ME/TXE firmware version 12.0.40.1433 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is NOT SET
Setting the HAP bit in PCHSTRP32 to disable Intel ME...
Checking the FTPR RSA signature... VALID
Done! Good luck!

Backup after flashing me_cleaner patched BIOS (patched BIOS flashed using Intel FPT, backup using Intel FPT)

python ./me_cleaner.py -c NEW_BACKUP.bin
Full image detected
Found FPT header at 0x2000
Found 7 partition(s)
Found FTPR header: FTPR partition spans from 0x88000 to 0x88000
Found FTPR manifest at 0x88250
ME/TXE firmware version 12.0.40.1433 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is SET
Checking the FTPR RSA signature... VALID

Output of Intel CSME MEInfo after flashing me_cleaner patched BIOS

sudo ./MEInfo
Intel (R) MEInfo Version: 12.0.40.1433
Copyright (C) 2005 - 2019, Intel Corporation. All rights reserved.


Error 198: ME disabled.

[Espionage724]

Per #3 (comment), this PR was required and works fine for me on a Coffee Lake system.

[roema]

Hi!

I have a brand new Lenovo E490 with ME 12.0.1427.35

• Whiskey Lake
• i7-8565U
• tested with -s and -s

The bios chip is very easy to access. So i have created a dump with flashrom.

After flashing the patched image.
lspci shows:

• 00:16.0 Communication controller: Intel Corporation Device (rev 30) 0x9de0

Intelmetool say on the first device 0x9de0:

MEI found: [8086:9de0] Device 9de0

ME Status   : 0xa0000245
ME Status 2 : 0xf10506

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : ROM Phase
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State    : (null)

ME: Extend Register not valid

ME: Firmware Version 12.0.1427.35 (code) 12.0.1427.35 (recovery) 12.0.1427.35 (fitc)

ME Capability: Full Network manageability                 : OFF
ME Capability: Regular Network manageability              : OFF
ME Capability: Manageability                              : OFF
ME Capability: Small business technology                  : OFF
ME Capability: Level III manageability                    : OFF
ME Capability: IntelR Anti-Theft (AT)                     : OFF
ME Capability: IntelR Capability Licensing Service (CLS)  : ON
ME Capability: IntelR Power Sharing Technology (MPC)      : OFF
ME Capability: ICC Over Clocking                          : OFF
ME Capability: Protected Audio Video Path (PAVP)          : ON
ME Capability: IPV6                                       : OFF
ME Capability: KVM Remote Control (KVM)                   : OFF
ME Capability: Outbreak Containment Heuristic (OCH)       : OFF
ME Capability: Virtual LAN (VLAN)                         : ON
ME Capability: TLS                                        : OFF
ME Capability: Wireless LAN (WLAN)                        : OFF

Laptop is working normaly, no shutdown after 30 mins. 

I think, ME12 is ignoring the HAP Bit.

[dt-zero]

Hi @roema ! :)
I think it is unlikely that any ME versions lack the HAP bit behaviour. I'm suspecting that the Whiskey Lake PCH layout is different. Can you send me your original BIOS dump?

[roema]

Hi @dt-zero !!

Thanks for you message!
Yes! Here is the link E490

Thanks for your work!!

[dt-zero]

@roema Okay, I see what happened here :)

This is the Cannonlake LP variant with a different PCH strap layout. Fixing this in the general case will take some more work, but for now, we can work around this. Try this version.
I'm glad if you find my contributions useful 🎉

me_cleaner.py

[roema]

@dt-zero you are the best!
It seems to be working!

Now the device /dev/eim0 is gone and in UEFI BIOS no ME Version shown.

Thank you very much!

[beaker23]

This works on MSI B360 Gaming plus as well. I used the me_cleaner.py file from this pull request's commit.

The one posted as a text file did not work (it reported success using me_cleaner.py -c, but when flashed did not neutralize the me)

[dt-zero]

@beaker23 Glad to hear it works for you as well!

For future reference, there is Cannonlake-H series ( QM370, Q370, B360, H370, H310, Z390, C242, C246, HM370, CM246, QMS380) and Cannonlake-LP. I'm not sure which chipsets are in LP, but generally, if you have ME 12 and its not one of the H series I listed, it is probably LP. The script from the commit is for H series, the one I attached is for LP. Making one script that is compatible with both would involve (like the original message mentions) parsing the ME file system to identify the SKU or something similar. I'm not sure to what extent @corna would like to see me_cleaner modified to accommodate this so I tried to make my changes as small as possible. (Which has its ups and downs as you can see)

[dtbartle]

Commit from PR works on Z390M-ITX/AC.

[suut]

Hello @dt-zero, the me_cleaner.py for LP variant of cannonlake you posted is identical to the one from the commit, is there some kind of mix-up there ? The commit variant did nothing for me, I have the LP variant.

On another note since you seem pretty knowledgeable, what can you say about the "Temporarily disable" mode of ME ? It's an hidden option in my BIOS that I can enable and makes ME totally disappear from the PCI bus and no tool can interact with it afterwards , it's doing more than HAP/AltMeDisable on my desktop computer it seems.

[dt-zero]

Hi @suut , there is a difference between the two, its the offset in the PCH strap region. LP is offset 0x70, while Cannonlake-H is 0x80. If you have an LP board, use the python script I attached. (Not the one from the commit)

Functionality wise, the HAP bit does the same. If you successfully enable the HAP bit, the ME disappears from the PCI bus and no tool will be able to interact with it.

[suut]

Hi @suut , there is a difference between the two, its the offset in the PCH strap region. LP is offset 0x70, while Cannonlake-H is 0x80. If you have an LP board, use the python script I attached. (Not the one from the commit)

Functionality wise, the HAP bit does the same. If you successfully enable the HAP bit, the ME disappears from the PCI bus and no tool will be able to interact with it.

I meant the two files were byte-for-byte equal but I guess I mixed up downloads, thank you for your feedback, I will try again now.

On another note, how did you find the offset ? Using Intel FIT, toggling the "Reserved" setting and looking at which offset in the image the bit was toggled ? So like at byte 371 for Cannonlake-LP

[dt-zero]

I meant the two files were byte-for-byte equal but I guess I mixed up downloads, thank you for your feedback, I will try again now.

On another note, how did you find the offset ? Using Intel FIT, toggling the "Reserved" setting and looking at which offset in the image the bit was toggled ? So like at byte 371 for Cannonlake-LP

They are definitely not equal byte-for-byte or otherwise.

My understanding is that Intel (CS)ME System Tools (which include FIT) are not publicly released to end-users but only to OEMs, so naturally I would not try obtain them in any way.

However, purely theoretically, had someone done that, they could extract the platform descriptor XMLs from FIT and use grep to find a sequence of entries that had the same distribution of bits between fields as with Intel ME 11. That way, they could find out that the old entry that used to be called "reserve_hap" is now "PCH_Strap_CSME_CSE_CSME_Reserved". The same xml node would specify the offset and which bit of that entry controls the HAP mode.

[suut]

I meant the two files were byte-for-byte equal but I guess I mixed up downloads, thank you for your feedback, I will try again now.
On another note, how did you find the offset ? Using Intel FIT, toggling the "Reserved" setting and looking at which offset in the image the bit was toggled ? So like at byte 371 for Cannonlake-LP
So
They are definitely not equal byte-for-byte or otherwise.

My understanding is that Intel (CS)ME System Tools (which include FIT) are not publicly released to end-users but only to OEMs, so naturally I would not try obtain them in any way.

However, purely theoretically, had someone done that, they could extract the platform descriptor XMLs from FIT and use grep to find a sequence of entries that had the same distribution of bits between fields as with Intel ME 11. That way, they could find out that the old entry that used to be called "reserve_hap" is now "PCH_Strap_CSME_CSE_CSME_Reserved". The same xml node would specify the offset and which bit of that entry controls the HAP mode.

Oh I see, thanks for the information !

So for other people interested by some googling we can find cnp_h_rvp.xml and cnp_lp_rvp.xml which contain the PCH straps for Cannonlake H and Cannonlake LP respectively. (I don't know if these documents are too touchy to link in here, feel free to tell me if I need to edit)

[pedrib]

@dt-zero Success! This worked on my Dell 7060 MFF (Intel Q370 / Cannon Lake). Dumped the bios via FPT, cleaned it with your me_cleaner patch using the -s for HAP bit enable, flashed it back and it works.
There's no info in the BIOS about ME, but Linux can't find anything about it using Intel and other tools, even with the mei kernel modules loaded.

sudo ./intelmetool -d -m
ME PCI device is hidden
RCBA addr: 0x00000000
Can't find ME PCI device

There's no ME device on lspci, and me_cleaner -c says:

Full image detected
Found FPT header at 0x4000
Found 7 partition(s)
Found FTPR header: FTPR partition spans from 0x168000 to 0x168000
Found FTPR manifest at 0x168268
ME/TXE firmware version 12.0.40.1433 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is SET
Checking the FTPR RSA signature... VALID

[mtaillefumier]

I tried deactivating the hap bit on the asus ws z390 pro but no luck. I get an infinite boot loop. I also tried differently recreating the bios using others tools with hap bit on, same result.

[privacyguy123]

Tried this on my machine - sound doesn't work and it takes over a minute to boot ... is this the intended outcome?

EDIT: Is it possible that ME 12 could be supported by whitelisting some more of the modules?

Intel (R) Firmware Update Utility Version: 12.0.65.1567
Copyright (C) 2005 - 2020, Intel Corporation. All rights reserved.

Checking firmware parameters...

Warning: Do not exit the process or power off the machine before the firmware update process ends.

Error 509: Mandatory partitions (FTPR / NFTP / RBEP) were not found in the Update Image.

[MattBJ]

Hey thanks for this fix, not sure if it's working correctly but I'll leave the terminal details below:

Full image detected
Found FPT header at 0x280000
Found 9 partition(s)
Found FTPR header: FTPR partition spans from 0x26000 to 0x26000
Found FTPR manifest at 0x26238
ME/TXE firmware version 14.0.34.1139 (generation 3)
WARNING Unknown public key 8e4f834644da2bef03039d69d41ecf02
Assuming Intel ME
Please report this warning to the project's maintainer!
The HAP bit is NOT SET
Checking the FTPR RSA signature... VALID

My Motherboard is: MSI MPG Z490 GAMING PLUS LGA 1200 Intel Z490 SATA 6Gb/s ATX Intel Motherboard

The SPI Flash ROM chip I'm working with: MX25L25673G

[MattBJ]

Also, upon trying to remove the ME section, I am getting this output:

Full image detected
Found FPT header at 0x280000
Found 9 partition(s)
Found FTPR header: FTPR partition spans from 0x26000 to 0x26000
Found FTPR manifest at 0x26238
ME/TXE firmware version 14.0.34.1139 (generation 3)
WARNING Unknown public key 8e4f834644da2bef03039d69d41ecf02
Assuming Intel ME
Please report this warning to the project's maintainer!
The HAP bit is NOT SET
Reading partitions list...
PSVN (0x00000f00 - 0x000001000, 0x00000100 total bytes): removed
UEP (0x0006c000 - 0x00006e000, 0x00002000 total bytes): removed
IVBP (0x00001000 - 0x000005000, 0x00004000 total bytes): removed
MFS (0x00005000 - 0x000069000, 0x00064000 total bytes): removed
UTOK (0x00069000 - 0x00006b000, 0x00002000 total bytes): removed
HVMP (0x00000ec0 - 0x000000ecc, 0x0000000c total bytes): removed
RSTR (0x00000e80 - 0x000000e98, 0x00000018 total bytes): removed
FLOG (0x0006b000 - 0x00006c000, 0x00001000 total bytes): removed
IMDP (0x00000e40 - 0x000000e80, 0x00000040 total bytes): removed
Removing partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0xbf)...
Reading FTPR modules list...
Traceback (most recent call last):
File "me_cleaner/me_cleaner.py", line 876, in <module>
check_and_remove_modules_gen3(mef, me_end,
File "me_cleaner/me_cleaner.py", line 422, in check_and_remove_modules_gen3
name = data[0x0:0xc].rstrip(b"\x00").decode("ascii")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128)

[dt-zero]

@MattBJ I fixed it for your version, attached below.

Run it with python me_cleaner.py -s orig.bin -O cleaned.bin

me_cleaner.py.txt

[MattBJ]

@dt-zero Thanks so much!! I'll have to run diff to see exactly what you fixed!

[dt-zero]

@MattBJ the PCH strap configuration is different for all these platforms, that's what I'm changing most of the time, however in your case I also added the ME14 public key to the list, just to clear the associated warning. Let me know if you achieve the desired results, cheers! 😃

[MattBJ]

@dt-zero I believe it worked perfectly, the modification definitely let me write the cleaned binary file. When I wrote it back to my chip it verified the success, but I won't be able to check if the configuration works until I get my PC tower in a few days (I have everything else). So fingers crossed this works! I really appreciate your work, and everybody else's here.

If I wanted to neutralize and shrink the ME section of the ROM, would I just do this:
python me_cleaner.py -S -r -t -d -O out.bin -D ifd_shrinked.bin -M me_shrinked.bin original_dump.bin
According to the neutralize and shrink section of https://github.com/corna/me_cleaner/wiki/External-flashing
Or would it somehow be different with your updated version? I'm guessing not. Also, if you happened to know, what would be the general purpose of shrinking this portion? And, also, when getting bios updates, will I always have to scrub out the ME or will that piece be unaffected throughout the life of the motherboard unless I decide to revert to my saved original copies?

Once again thank you for your time!

[jhsvip]

@MattBJ I fixed it for your version, attached below.
Run it with python me_cleaner.py -s orig.bin -O cleaned.bin
me_cleaner.py.txt

Hi @dt-zero
ASROCK B360M-HDV did not work,The me version still exist in Advanced-->>Chipset not 0.0.0.0
After dumped the moded bios the script result here:
python me_cleaner.py -s dunmped2.bin -O cleaned2.bin Full image detected Found FPT header at 0x4000 Found 8 partition(s) Found FTPR header: FTPR partition spans from 0x8e000 to 0x8e000 Found FTPR manifest at 0x8e250 ME/TXE firmware version 12.0.49.1534 (generation 4) Public key match: Intel ME, firmware versions 12.x.x.x The HAP bit is SET Setting the HAP bit in PCHSTRP32 to disable Intel ME... Checking the FTPR RSA signature... VALID Done! Good luck!
Did i do something messed up?Could u help me?

@jhsvip I suggest you double check what you've done. Since it seems alright to me from here. Your board is an H series cannonlake board, meaning it is indeed PCHSTRP32. Check if offset 0x182 in the "cleaned" image is 0x11. (0x11 = hap bit on, 0x10 = hap bit off)

Hi, I found the problem ,Me_cleaner located the hap bit address is 0x172, the real hap bit is 0x182 as you say.

[tinylabs]

@craigacgomez - Where did you find the Intel FPT tool? Have the same hw.

[craigacgomez]

@tinylabs you can get it from the Intel CSME 12 package (https://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html)

[freedominside]

Hello,
Does anyone know how to modify the me_cleaner script to flip the HAP bit again to enable Intel ME?
I used softdisable only (-s) on Intel ME v11, but I lost the original dump. Now I need to reenable it again.
Thank you!

[ElVasquito]

Hi, just tried on a Dell (don't know its exact chipset, has an i7-6500), dumped the orig FW twice (just in case) applied the original me_cleaner as well as your improved version (both made the same changes), and after burning, the machine will not post anymore. Just a shine of the power LED when the charger is plugged, then it goes off after a second and that's it. Dead. Maybe Dell is doing some special check? Attached is the orig FW, any clues appreciated!

DellFW.zip

[ElVasquito]

Worth mentioning that after reflashing the original, system starts normally :/

[melvyn2]

Worked on an Intel Core i9-9900k w/ Gigabyte Z390 Aorus Master.
Extracted firmware v f11n using flashrom, then reflashed with flashrom -p internal, result is:

 sudo intelmetool -m
Can't find ME PCI device

System still runs after 30 mins.

[Giga-Pudding]

I used flashrom with a ch341a_spi external flasher.
It worked perfectly for me, thanks alot!

[xnuken]

I can confirm this works tried it on my ROG MAXIMUS XI GENE

[DodoDude700]

@dt-zero Having some trouble using this on an Apollo Lake system (UP Squared), with the ME variant Intel seems to call CSTXE v3. This is an IFWI platform, which I guess explains "The ME region in this image has already been disabled" even though it's a stock image that the ME is clearly working when using. Using me_cleaner from your branch:

me_cleaner.py -s UPA1AM61_from_up_website.bin -O UPA1AM61_me_cleaned.bin
Full image detected
The ME region in this image has already been disabled
The HAP bit is NOT SET
Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME...
Traceback (most recent call last):
  File "/home/ethan/coreboot_for_up_squared/mecleaner_dtzero/me_cleaner/me_cleaner.py", line 915, in <module>
    pchstrp10 |= (1 << 7)
NameError: name 'pchstrp10' is not defined

For what it's worth, the other version you linked in this thread did not work either, though that's to be expected (it's not, as far as I can tell, designed for Apollo Lake, as that's not what the other user's problem was with).

I have tried setting the AltMeDisable bit in the flash descriptor with ifdtool, but this (rather expectedly) does not work - the ME is still alive and well, according to intelmetool (the version from this branch, Reddit post links to the GitHub but the GitHub has almost no info about it so linking to the Reddit post, needs to be used on this hardware, the one in coreboot master does not detect the newer ME) and Intel TXEInfo.

I hoped to try patching your branch for Apollo Lake myself, and, hypothetically speaking, were I to have extracted the contents of the Intel FIT binary for my TXE version (CSTXE System Tools v3 r12 Flash Image Tool, Linux version) using binwalk -e and then gone through all the XML-like files inside, I might have found that nothing resembling PCH_Strap_CSME_CSE_CSME_Reserved appears to be in there, and may then have uploaded an archive of the extracted files, which I may then have agreed to remove if you so desire.

Positive Technologies notes that Apollo Lake ignores the bup_not_temporary_disable flag, but they do not say that it ignores the HAP bit, which they specifically note the flag they call bup_not_temporary_disable is not the same thing as, so I strongly suspect there IS a way to set AltMeDisable/HAP on Apollo Lake - as you say, "I think it is unlikely that any ME versions lack the HAP bit behaviour".

I have attached the original BIOS dump (a raw, 16MiB whole-chip image), though it is also available from the manufacturer's website.

up_squared_original.rom.zip

UPDATE: I have noticed that ifdtool has a -p aplk "platform-specific quirks" mode for Apollo Lake. Running with this, it tells me that the image I previously disabled the ME on (seemingly ineffectively) has not had the ME disabled (when running with -p aplk, it calls it HAP bit not AltMeDisable), so I decided to try modifying the stock image again with -p aplk. I confirmed that there is only one bit difference between this second modified image and the original, so it seems like it's correctly set whatever it thinks is the HAP bit, however, when this is done to the stock BIOS, the machine refuses to boot. I'm going to consider this an improvement as opposed to doing nothing at all (as is what happens when you run without -p aplk, where the ME is obviously still alive), but obviously not usable. With Coreboot (I also have a Coreboot build for this machine) it works with or without the HAP bit, but the MEI PCI device does not appear with or without the HAP bit set, and setting it does not appear to affect anything in the Coreboot logs. As such, I still have no idea how to set the HAP bit/AltMeDisable on this machine, and the one way I think might set it properly (ifdtool -p aplk) breaks the only firmware I have for the machine that allows me to check if the ME is alive.

[dt-zero]

@DodoDude700 : You seem to have done your homework regarding what is out there, good job on that. Unfortunately, I have a pretty tough time with this one. In general, I don't see this PCH strap as part of the TXE platforms (Apollo Lake/Broxton/Gemini Lake) so I have no clue about whether or not it really exists for your device. I know this is not what you wanted to hear - sorry.
My guess on ifdtool is that it probably has no clue about the actual bit layout either and it accidentally set something that causes failure during platform init. If that is the case, I'm not surprised, it's easy to misconfigure something in that region and have an unpleasant result.

[DodoDude700]

So, I spent some time talking to the Coreboot developers about this (in the IRC). As it turns out, the Apollo Lake TXE is quite markedly different from the Management Engine's other iterations. For example, to quote developer icon:

I can have a look at the docs, but have little hope. APL's CSE is not much like the usual ME. given how this CSE works, I wonder anyway what it is exactly that you want to disable

it has to load the x86 bootblock into SRAM for instance, and then take the x86 out of reset. that's unique to APL and its relatives. I don't know if there is a "do the x86 bring up but then shut down mode"

and in response to my question about ifdtool in APL quirks mode:

looks like strap[0] bit 16 is part of a field to configure something voltage id related (SVID_RAIL3_ID). you cannot trust ifdtool btw. changes there are rarely reviewed.

As such, it does not appear that Apollo Lake (and possibly "its relatives", maybe Gemini Lake too?) really have a HAP bit, at least not one icon was aware of or one I could find.

However, talking to Coreboot developers did solve one mystery - that of the Management Engine showing up under the stock firmware but not under Coreboot. In the coreboot sources, under src/soc/intel/apollolake/cse.c, the function disable_heci1 (where HECI is Host Embedded Controlled Interface, the interface to the ME) is used to disable communications with the ME after Coreboot is done dealing with it. Commenting out the contents of this function (leave the function itself, it still gets called, you just don't want it to do anything) and recompiling, the MEI shows up under Coreboot and we're able to look into its state a little bit more. Once again, just like stock firmware, at present, the exander77 branch needs to be used.

On the stock firmware, my intelmetool output (minus the PCI device "debug spam" the exander77 branch outputs):

MEI found: [8086:5a9a] Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge

ME Status   : 0x80000255
ME Status 2 : 0xf40400

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : YES
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : ROM Phase
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State    : (null)

ME: Extend Register not valid

ME: Firmware Version 3.1.2351.75 (code) 3.1.2351.75 (recovery) 3.1.2352.75 (fitc)

ME Capability: Full Network manageability                 : OFF
ME Capability: Regular Network manageability              : OFF
ME Capability: Manageability                              : OFF
ME Capability: Small business technology                  : OFF
ME Capability: Level III manageability                    : OFF
ME Capability: IntelR Anti-Theft (AT)                     : OFF
ME Capability: IntelR Capability Licensing Service (CLS)  : ON
ME Capability: IntelR Power Sharing Technology (MPC)      : ON
ME Capability: ICC Over Clocking                          : OFF
ME Capability: Protected Audio Video Path (PAVP)          : ON
ME Capability: IPV6                                       : OFF
ME Capability: KVM Remote Control (KVM)                   : OFF
ME Capability: Outbreak Containment Heuristic (OCH)       : OFF
ME Capability: Virtual LAN (VLAN)                         : ON
ME Capability: TLS                                        : OFF
ME Capability: Wireless LAN (WLAN)                        : OFF

Despite the concerns of some of the devs I spoke to that intelmetool may not handle Apollo Lake properly, on the stock firmware, this looks like a sensible output - we see that the TXE is alive and well in a normal state, that it's on firmware version 3.1.2351.75, and that its listed capabilities match what would be expected of the Apollo Lake TXE (while lacking the features of higher-end ME variants which Apollo Lake is not supposed to support. It should also be noted that these results agree with what Intel's own TXEinfo, which definitely DOES support Apollo Lake properly, says when run on the same machine. As such, I'm willing to consider intelmetool, at least this branch, a relatively decent way to determine TXE state on Apollo Lake.

Now here comes the weird part: under Coreboot, even without any kind of HAP/AltMeDisable bit set, and even with no modifcations to the ME firmware built into the Coreboot image's IFWI, intelmetool gives me this:

MEI found: [8086:5a9a] Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge

ME Status   : 0x80003052
ME Status 2 : 0x308a0040

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : YES
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Recovery
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : Image Failure
ME: Progress Phase          : Policy Module
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State    : 0x8a

ME: Extend Register not valid

ME: has a broken implementation on your board with this firmware
ME: timeout waiting for data: expected 8, available 0
ME: GET FW VERSION message failed

This is extremely interesting. The Management Engine appears to be in an intermediate, "half-disabled" state. As with me_cleaner'd firmware, we see we see Firmware Init Complete at NO. Like "traditional", non-AltMeDisable-based, no -S/-s me_cleaner, we see Error Code at Image Failure instead of No Error (as you would expect to see with AltMeDisable). However, what's going on does NOT appear to be akin to traditional me_cleaner - whereas you would expect intelmetool on me_cleaner'd firmware to give you Progress Phase: BUP Phase and Progress Phase State: M0 kernel load, here we have Progress Phase: Policy Module, which is a state I've never seen intelmetool give me, with any modified or unmodified ME. What's even weirder, Progress Phase State is 0x8a, which intelmetool does not appear to even have a name for, and Current Working State is Recovery.

We can also see that, whereas the ME is able to return its firmware version to intelmetool under the stock firmware, here that times out and causes intelmetool to exit. Patching out the firmware version check, we get a similar error in its place when it attempts to check capabilities:

ME: has a broken implementation on your board with this firmware
ME: timeout waiting for data: expected 5, available 0
ME: GET FWCAPS message failed

Seeing this, I very much expected the 30 minute watchdog to reset the machine, as the ME is clearly in a bad state, and this is not a state I have seen documented with any technique to disable the ME, so I did not expect it to work around the watchdog. However, I have left the machine running for hours in this state and it appears stable and reliable.

As such, it appears that Coreboot on this hardware has somehow broken the Management Engine/TXE firmware or forced it into recovery mode, preventing it from initializing properly but somehow either also breaking the watchdog timer or remaining alive enough to reset it.

I thought that Intel's own TXEinfo may be more enlightening about the TXE's state, but it fails with this:

Intel(R) TXEInfo Version: 3.1.70.2340
Copyright(C) 2005 - 2019, Intel Corporation. All rights reserved.




Error 83: Communication error between application and Intel(R) TXE module (HCI client)

Error 81: Internal error (Could not determine FW features information) 

As such, I conclude that:

• The CSTXE is present and alive on the stock firmware on this board
• exander77's patched intelmetool is seemingly compatible with Apollo Lake, and gives reasonable results on it under stock firmware
• It does not appear to obey, and coreboot developers are not aware of, an AltMeDisable/HAP-like bit in the PCH straps
• Coreboot on this board, at least version 4.15 which is what I'm running, disables the HECI, which is why the ME did not show up under Coreboot for me
• Patching that out of Coreboot, the MEI device shows up and intelmetool can be used on it
• Coreboot appears, seemingly by accident (nothing in the Coreboot code for dealing with the TXE seems to allude to doing this on purpose), to break the management engine firmware or force it into recovery mode on this board and possibly on other Apollo Lake devices too
• This state is not the same as that of a working ME, or either of the two previously documented disabled ME states
• In this state, the ME either ignores, properly resets, or does not start the 30 minute reset watchdog timer
• The ME is not alive enough in this state to tell us much other than that it's in recovery and that firmware init is not complete

For my purposes, I think I'm now comfortable concluding that the Management Engine on this board is essentially disabled, albeit in a different state than other ME disable methods, which does not appear to have been documented before. Further research into this may be useful.

[joex2021]

Hello,

I need a help regarding the following issue. I Have an Asus Z590-A motherboard with intel i7 11700k and intel Me 15.0.1466.
I tried to disable ME with the me_cleaner made by @dt-zero and it didn't work, the same version worked on my old system that had ME12.
Here is me_cleaner output i get when i try both -c and -s:

Full image detected
more than one $FPT found

here I attach the bios dump.
z590_2.zip

Thanks in advance.

[helios-chad]

Hi, can you tell me if it is still possible to enable HAP on 11th gen?
I want to buy new Hardware but I can't find any information about the intel ME stuff that is not horrendously outdated.
Thx In advance.

[joex2021]

I tired to enable it with -s command and it didn't work. You can download my BIOS dump and test it. I hope that @dt-zero can help us with this issue.

[dt-zero]

Okay, so since this pull request got a lot of traffic since I opened it, let me say something now.
I love how many of you are enthusiastic about having a less proprietary and more open platform, I'm really glad to see that.

At the same time, my expectation when I opened this pull request was that it may or may not be merged but that it's going to be a reference point for @corna to help with the maintenance of the project. Since then, this grew to the size that it's taking up significant chunks of my time to keep supporting each and every one of you who reaches out on github or via email. I did this research on my own time but otherwise I'm full time working for a company (Zero IT Lab) that requires me to do a ton of other stuff during the daytime. It's becoming hard to balance that and it's unsustainable for me to dedicate significant free time to keep up with this.

I'll try to answer this set of questions that piled up until now (in my next comment), but please don't "expect" my support. Realistically speaking, since the project seems abandoned by corna, it's probably time for a fork/rewrite. It could be a company project for us, if there was financial backing to do it at reasonable market rates; but that kind of interest does not seem to be there. From my experience, most of the people who reach out to me are private individuals who do this for the enthusiastic/educational aspect. (and therefore don't want to/can't afford that kind of backing)
If that ever changes, we'll probably pick the project up; otherwise unfortunately I cannot dedicate more of my time.

[dt-zero]

@joex2021 The HAP offset for your rom is 0x196. 0x0 = Hap disabled; 0x1 = Hap enabled.
Make a copy of your bios rom and edit it like so

printf '\x01' | dd of=z590_copied.bin bs=1 seek=406 count=1 conv=notrunc

It will edit the file ("z590_copied.bin") in place and enable the HAP bit. Flash and you should be good. (No guarantees)

@helios-chad Yes, it is possible. As I showed above, we are still enabling the HAP bit on ME 15 which is more up to date. I haven't had any issues as long as you are on a consumer (CSME) platform and not TXE like @DodoDude700.

[joex2021]

@dt-zero thank you for trying help us here, I understand all what you wrote and I totally agree with you.
I have been following this project since I head about the ME dangers back in 2018 and I watched your video about intel ME, it is really sad that this great project is dying, I wish I had that advanced knowledge to help.
Can you explain lite bit more how to edit the BIOS rom? Do I need a special tool to open and edit the BIOS rom?

Thank you for your help and patience.

[dt-zero]

@joex2021 You are welcome. What I wrote is a command you can execute under a linux terminal environment to edit the BIOS rom, no special tool needed. (just paste into a terminal)
If you are not on linux, you can use WSL or something similar. Alternatively, you can use a hex editor to perform the same thing.

[joex2021]

@dt-zero Thanks again for the help. Unfortunately I couldn't test your method, I had to return that motherboard due to VRM heating problem, I ordred an Asus Z590-P instead. I will try the suggested solution when it arrives and I will report the result here.

[walliams]

@MattBJ I fixed it for your version, attached below.

Run it with python me_cleaner.py -s orig.bin -O cleaned.bin

me_cleaner.py.txt

just dropping in to say this modified me_cleaner.py script also worked like a charm on my z490 board (once I built flashrom from the latest dev build to be able to recognize the chip)

thankyou @dt-zero !

[nkalkhof]

Pull #282 works flawless on a Clevo N350TW (Schenker Dock 15 L2018). BIOS Menu shows IME FW version 0.0.0.0. No more HECI present on the PCI bus. No problems so far with Linux. Even suspend and the docking station works fine.

[Absolucy]

@dt-zero the modified me_cleaner.py doesn't work for me. my pc just bootloops with the py file in this PR, and that py file boots but doesn't disable ME:

ME Status   : 0x90000255
ME Status 2 : 0x6f10506

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : YES
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : ROM Phase
ME: Power Management Event  : Pseudo-global reset
ME: Progress Phase State    : (null)

ME: Extend Register not valid

Error mapping physical memory 0x0000000269578240 [0x2000] ERRNO=1 Operation not permitted
Could not map ME setup memory.
Do you have kernel cmdline argument 'iomem=relaxed' set ?

NOTE: iomem=relaxed is set so I dunno what intelmetool's problem is

❯ python3 me_cleaner.py -s orig.bin -O cleaned.bin
Full image detected
Found FPT header at 0x211000
Found 8 partition(s)
Found FTPR header: FTPR partition spans from 0x20000 to 0x20000
Found FTPR manifest at 0x20250
ME/TXE firmware version 12.0.70.1652 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is NOT SET
Setting the HAP bit in PCHSTRP28 to disable Intel ME...
Checking the FTPR RSA signature... VALID
Done! Good luck!

❯ python3 me_cleaner.py -c cleaned.bin 
Full image detected
Found FPT header at 0x211000
Found 8 partition(s)
Found FTPR header: FTPR partition spans from 0x20000 to 0x20000
Found FTPR manifest at 0x20250
ME/TXE firmware version 12.0.70.1652 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is SET
Checking the FTPR RSA signature... VALID

UEFI also correctly gives the ME firmware version.

Here's my firmware bins (orig.bin and cleaned.bin)
me cleaner stuff.zip

Board: MSI-Z390-A Pro
CPU: Intel Core i7 8086k

[ritalinaddict]

@Absolucy quick diff check shows

that you modified the wrong bit. I'm guessing that you used the script for LP boards, his original script should have worked.

I set it for you using dd anyway (didnt bother with anything else)
hapset.zip

also has anyone tried setting it on an alder lake board? im considering buying a new pc soon and id like to know if it still works. i'm assuming it does (in one way or another) given its original intended purpose, although with every new platform it could always change. if anyone would be willing to test or upload a dump of their rom id be interested to take a look

edit:
I looked at a few roms for z690 (alder lake) boards and the exact hap offset seems to be 0x1DE
printf "\x$(($(xxd -b -l 1 -seek 478 -p poop.bin) ^ 1))" | dd of=poop.bin bs=1 seek=478 count=1 conv=notrunc
that should work for any z690 board if anyone wants to give it a try (run it in the same folder as the rom you want to edit, and obviously change poop.bin to whatever the rom is called, if it doesnt work for you then post ur dumps and ill take a look)

[Absolucy]

@ritalinaddict Original script just bootloops...

[ritalinaddict]

@Absolucy well try using the rom I posted, it should work fine

the HAP bit should be properly set now

[zingaburga]

@ritalinaddict thanks for your Alder Lake suggestion. I tried it on an MSI PRO Z690-A DDR4 motherboard, using version 120 but unfortunately it boot loops.

I might be doing something stupid, so I'll list the steps I took:

1. Download 7D25v12 BIOS for the motherboard
2. Unzip the E7D25IMS.120 file (MD5 of which is 033f6452147c4c6b0822fcd6b91321db)
3. Open file in hex editor and go to byte 0x1DE. Existing value is 0x10
4. Update byte with the '1' bit set - new value is 0x11 and file has MD5 of bbdd9e5179fe28772934ca6a4af42601
5. Flash updated file - result is a boot loop. Flashing unmodified BIOS file works fine.

[gaivor74]

Greetings to all chat participants concerned about cleaning Intel ME.
I recently did THIS. On the motherboard Intel_Core_i9-10900K_@_ASUS_ROG_STRIX_Z490-G – everything is successful, except for fainting at the end of the process and the "stub" from the device remaining in the Manager.

Details and Details…
I used the firmware version 14.1.53.1649V1.1 offered by the native support site, processed by the utility me_cleaner.py , presented above. I flashed Intel ME with the utility MEUpdateTool_14.1.53.1649V1.1_T – before I flashed the BIOS – which is probably wrong. At the end of the process, I received a completely non–working computer - even the fans did not turn on. I came out of this state by pressing the computer power button five times, provided there is no battery, because the BIOS was not reset in any other way. After that, the BIOS started, the test signals of the motherboard passed, after which I went into the BIOS and found, against the background of everything working, the absence of a hard drive connection. It was necessary to update the BIOS with the firmware supplied with the Intel ME firmware.

It has been working fine for 2 weeks.

There is an assumption that it is necessary to reset the newly stitched BIOS to the standard settings before updating Intel ME, while it may not faint so deeply when flashing Intel ME.

Anyone who wishes can try and unsubscribe.

RUS

Приветствую всех участников чата, озабоченных очисткой Intel ME.
Недавно я сделал ЭТО. На материнской плате Intel_Core_i9-10900K_@_ASUS_ROG_STRIX_Z490-G – всё удачно, за исключением обморока в конце процесса и остающегося в Диспетчере «огрызка» от устройства.

Детали и подробности…
Использовал прошивку версии 14.1.53.1649V1.1 предлагаемую родным сайтом поддержки, обработанную утилитой me_cleaner.py, представленной выше. Прошивал Intel ME утилитой MEUpdateTool_14.1.53.1649V1.1_T – до того, как прошил БИОС – что, наверное, неправильно. По окончании процесса получил полностью не работающий комп – даже вентиляторы не включались. Вышел из этого состояния путём пятикратного нажатия кнопки включения компьютера, при условии отсутствия батарейки, ибо по-другому БИОС не сбрасывался. После этого БИОС запустился, прошли тестовые сигналы материнки, после чего зашёл в БИОС и обнаружил, на фоне всего работающего отсутствие подключения винчестера. Нужно было обновить и БИОС прошивкой, поставляемой вместе с прошивкой Intel ME.

Уже 2 недели работает нормально.

Существует предположение, что нужно перед обновлением Intel ME сбросить только что прошитый БИОС к стандартным настройкам, при этом может не упадёт в обморок настолько глубоко при прошивке Intel ME.

Кто желает, может попробовать и отписаться.