Add soft-disable support for Intel ME 12, 14, 15 and 16

[XutaxKamay]

I haven't tested with others Intel ME for the 15 version, but I guess that should work, as the PCI device (Intel ME) is not present anymore and seems to act like it's disabled, but I'll need to do more tests with AMT to be sure.

If someone is looking at this pull request and is willing to test the soft-disable, since Intel ME 15 might have different HAP bit offsets between chipsets etc, although I'm not really sure about that, I don't have any other computers to test with.

Thanks to @dt-zero and @6d6178667269747a for previous versions of Intel ME.

If that doesn't work, try this guess:
#384 (comment)

[mkopec]

Seems to work on NovaCustom NV4x laptop (TGL-U "Premium" chipset, ME version 15.0.30.1776), the HECI device is disabled, coreboot can't find it.
S0ix suspend is broken, as expected on TGL-U with ME disabled, unfortunately.

[XutaxKamay]

That's good to know, thanks!

[EmptyIsValue]

Z690

tried twice even more, just like this
it said FTPR header not found

Z590

[XutaxKamay]

The first images in your post is about Intel ME 16, which is not supported (yet ? I have to find out).

For the one with Intel ME 15, you can ignore the RSA signature, I'm not sure yet what causes it but anyway, since the HAP bit is not located inside the Intel ME region but the Flash Descriptor (it is the first 4096 bytes at the beginning of the BIOS), it doesn't matter, you can ignore and use the new BIOS ROM and test it.

[ghost]

Also for anyone interested, as I have somewhat painfully found out, newer Gigabyte motherboards "Introduce capsule BIOS support" which includes additional safeguards against modification. Even if you correctly disable the HAP bit these motherboards will boot loop.

Some bios modders (i.e. https://winraid.level1techs.com/t/flashing-gigabyte-while-avoiding-invalid-bios-image/31185 ) have bypassed previous versions of a similar check, unfortunately that's not good enough on the "capsule BIOS" versions.

I spent a good amount of time reverse engineering the UEFI modules and it seems to me this part of the logic may be handled in System Management Mode but I wasn't able to bypass it yet 😞

[XutaxKamay]

Interesting, that seems really an anti consumer thing, I believe they added such checks because of boot-kits officially, it seems that Gigabyte had a few vulnerabilities there and there by looking now. (maybe since leaks)

I don't have a Gigabyte motherboard but it would have been fun for me to see how they do the integrity checks, SMM sounds definitely a good place to put it.

May you share more info about it? (like did you look for string references etc...)

I have heard of "capsule" BIOS before, never dealt with them, but I guess once the actual BIOS is located somewhere else than in the SPI flash, from what I can understand right now it could make things really hard to update the firmware.

I just looked a bit online, this is maybe what you're talking about ? https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/signed-capsule-update / https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/security-technologies-4th-gen-core-retail-paper.pdf

EDIT:
My english is broken

[ghost]

I have a B560-HD3, you can grab the bios from here: https://www.gigabyte.com/Motherboard/B560-HD3-rev-1x/support#support-dl-bios

F10 and up have the capsule bios. I'll write up somewhat more properly how far I got when I get a bit of time but here's a bit of a TLDR if you wanna dig in.

UEFITool or something similar gets you access to the layout.

AFDD39F1-19D7-4501-A730-CE5A27E1154B/56E14F88-234B-4C34-B204-299670447247 - $BDR struct
^ Boot Data Record file that the post previously mentions. I decompress the main code partition (LZMA) and pattern searched through, just a few modules try to find BDR by sig or UUID.

BDR layout:

0: $BDR
+[4..8]: SizeOf_BDR
+8: A5 5A
+10: bool
+11: bool
+[16..20]: RomSize
+[20..24]: BIOS region size?
+[24..28]: page size

+[28..32]: ?? maybe byte?+pad

+[32..40]: bios Tag
+[40..44]: bios version
+[44..46]: bios year
+46: bios month
+47: bios day
+[48..53]: ?
+[64..96]: Board name / "Model Name"
+[96..98]: checksum table_offset
+98: checksum table entry count
+99: checksum table flags: if not 1 we skip validation ?
+[100..101]: guid_ref table offset
+102: guid_ref table entry count
+103: guid_ref table flags
+ 128: header size
+ 132: checksum table total size
+ 136: guid_ref table total size

Past F10, the "checksum table" has the checksums zeroed out by default. I tried setting "table flags" to everything suggested in all the bios modder forums: 0, 1, 2, 0xFF, every option causes a boot loop.
However, I found a somewhat similar struct in the capsule header. ( I don't know which UEFI module parses it )

Some of the relevant modules could be FlashDriver/FlashDriverSmm, SecSMIFlash, DualBiosPlusIte5702Dxe, QFlashHandler. One of them raises an SMI and passes values to an Smm counterpart, I don't remember which rn but I'll include it when I take my time to document properly.

[XutaxKamay]

Let me know if Intel ME 16 HAP bit offset works please, I'm not really sure about this one either. :)

[EmptyIsValue]

Let me know if Intel ME 16 HAP bit offset works please, I'm not really sure about this one either. :)

is this works? tried on asus bios ATM.
if so, curious why only work on 100x version (tried 1001 & 1003), both are unofficial bioses. The 1601 is the newest, added MC for intel 13th gen? and that is official

[XutaxKamay]

Let me know if Intel ME 16 HAP bit offset works please, I'm not really sure about this one either. :)

is this works? tried on asus bios ATM.
if so, curious why only work on 100x version (tried 1001 & 1003), both are unofficial bioses. The 1601 is the newest, added MC for intel 13th gen? and that is official

If you can give me your ROM, it might be something else.

[XutaxKamay]

Let met know if it works now, I downloaded from ASUS your BIOS, should be ok. It's a dirty trick but should work for now.

[XutaxKamay]

Intel ME 13 will be also possible but I really need people that could test for me.
I think only around 1-10 flashes max we could get it.

We should be able to get the HAP bit at least on all ME versions. :)

[ghost]

Intel ME 13 will be also possible but I really need people that could test for me. I think only around 1-10 flashes max we could get it.

We should be able to get the HAP bit at least on all ME versions. :)

Unfortunately this is not as simple as "HAP bit offset"/ME version.
The HAP bit offset is connected to the "SKU" ( Stock Keeping Unit ) and may be different even when using the same "ME" generation. This is why people struggled with my original script even on the same ME version.

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. Parsing and dealing with it and all the book keeping that comes with it is a lot of fun, good luck 🥲

[mlario]

hi
I tried to use this commit to disable intelme of corebooted hp g3 chromebox (https://support.hp.com/id-en/document/c06971570 i5-10310U processor)
intelme is of version 14
coreboot was taken from mrchromebox (https://mrchromebox.tech/#fwscript)
script run well on firmware and recognized correctly v14 of intel me, and also check on modified firmware confirmed HAP bit was set
I reflashed modified firmware but intelme PCI device is still present when running lspci -vv
Could you please provide any input? Is it expected to see PCI device with HAP bit set correctly
Or something went wrong?
Reflashing firmware was not an easy task since bios chip is WSON type and I had to fully desolder it from the motherboard and replace with usual soic chip that is easy to use external clamp with
I attach modified HAP disabled and original coreboot firmware in the attachments
thanks firmware.zip

You can check with MEInfo to be sure, although I can see that the HAP offset is not the same for your board for this ME version. You have two options:

* Find the correct Intel Flash Image Tool (if you can find 14.0.40.1206 version, should be perfect for your firmware, can't build your new image with CSME System Tools v14.0.20+ r20 , you'll find it on the link below)
  Load your image with it and rebuild with 'Reserved' on Yes:
  ![image](https://user-images.githubusercontent.com/20893801/270197735-7b416c0f-8a12-4b40-bc02-723938a0e684.png)

* Second method is to try the multiples offsets below and open with the tool above and see if 'Reserved' is Yes because I'm not able yet to find why/how exactly there is different HAP offsets for ME versions. As discussed one year ago, this might depends on the chipset, SKU etc, even if same ME version, here are possible offsets for your version:

0x00
0x18
0x2C
0x30
0x4C
0x54
0x64
0x7C
0x84
0x88
0x94
0xD0
0xDC

And modify here the offset: https://github.com/XutaxKamay/me_cleaner/blob/master/me_cleaner.py#L771 Run me_cleaner and flash again the firmware. (I would start with 0x54, 0x64, 0x7C, 0x84, 0x88, 0x94)
To check if ME is disabled, you can use MEInfo from CSME System Tools, probably the best way to check if it's active or not for now. (if the PCI device is gone or it says disabled, it should have worked)
I've also seen better results with Intel ME firmware being in Configured state, not Initialized. Dumps can work but I've seen cases where it fails for some reasons.
Helpful ressource: https://winraid.level1techs.com/t/intel-converged-security-management-engine-drivers-firmware-and-tools-2-15
It will explain the difference between Configured and Initialized etc and links to these tools.
UPDATE:
Please, try 0x70 as the offset, CSME FIT informs me it should be on.
In case you don't want to do all that; here's your firmware, tell me how it goes. https://files.catbox.moe/pxdx7n.bin
This time it wasn't PCH_Strap_CSME_CSE_HAP_Mode but PCH_Strap_CSME_CSE_CSME_Reserved, seems like that varies too..

Thanks for the information
I tried pxdx7n.bin - computer starts with fan spin but no output on the screen - doesn't matter which port to use. and this is >30min already
So it did not work
Any other suggestions would be appreciated
Also out of curiosity, which offset did you use for pxdx7n.bin?
I tried all offsets you suggested (and modified me_cleaner.py 771 line for the proper offset) but none of them gave Reserved Yes in intel FIT

Try 0x70 as I said above. As for the computer booting but no screens, I would read the flash again and check coreboot log to see if there's anything booting or something you can figure out of. If there's no log, well maybe HAP isn't well supported on your board, but I haven't seen that case yet. (perhaps, I would try to get ME firwmare in Configured state)
On some computers, it might take a lot of time to boot though I heard so. Like really a lot. Now you mention it, after a ME firmware upgrade, I waited sometimes about a hour until it starts.
You could also compare dumps to see if anything happens:
diff <(xxd oldrom) <(xxd newrom)

OK, I waited 24 hours for computer to start (after flashing pxdx7n.bin) and no video output still

I read the image back and compared to original dump image (from before modifying HAP) as suggested, output is in attached file:

Apparently there is something happening during boot, but not sure what to make of it

Otherwise I tired searching for CSME 14.0.40.1206, but so far unsuccessfully

diff.txt

OK just an update in case anybody is interested

I got clean firmware build from mrchromebox - so intel me in configured and not initialized

I deactivated hap using CSME (it worked this time) - but no video out anyway, even after 24 h

I can conclude HAP method is not working with this board

mrchromebox provided build with HECI deactivated - and this worked like a charm - no PCI device present:

MrChromebox/firmware#139

[XutaxKamay]

hi
I tried to use this commit to disable intelme of corebooted hp g3 chromebox (https://support.hp.com/id-en/document/c06971570 i5-10310U processor)
intelme is of version 14
coreboot was taken from mrchromebox (https://mrchromebox.tech/#fwscript)
script run well on firmware and recognized correctly v14 of intel me, and also check on modified firmware confirmed HAP bit was set
I reflashed modified firmware but intelme PCI device is still present when running lspci -vv
Could you please provide any input? Is it expected to see PCI device with HAP bit set correctly
Or something went wrong?
Reflashing firmware was not an easy task since bios chip is WSON type and I had to fully desolder it from the motherboard and replace with usual soic chip that is easy to use external clamp with
I attach modified HAP disabled and original coreboot firmware in the attachments
thanks firmware.zip

You can check with MEInfo to be sure, although I can see that the HAP offset is not the same for your board for this ME version. You have two options:

* Find the correct Intel Flash Image Tool (if you can find 14.0.40.1206 version, should be perfect for your firmware, can't build your new image with CSME System Tools v14.0.20+ r20 , you'll find it on the link below)
  Load your image with it and rebuild with 'Reserved' on Yes:
  ![image](https://user-images.githubusercontent.com/20893801/270197735-7b416c0f-8a12-4b40-bc02-723938a0e684.png)

* Second method is to try the multiples offsets below and open with the tool above and see if 'Reserved' is Yes because I'm not able yet to find why/how exactly there is different HAP offsets for ME versions. As discussed one year ago, this might depends on the chipset, SKU etc, even if same ME version, here are possible offsets for your version:

0x00
0x18
0x2C
0x30
0x4C
0x54
0x64
0x7C
0x84
0x88
0x94
0xD0
0xDC

And modify here the offset: https://github.com/XutaxKamay/me_cleaner/blob/master/me_cleaner.py#L771 Run me_cleaner and flash again the firmware. (I would start with 0x54, 0x64, 0x7C, 0x84, 0x88, 0x94)
To check if ME is disabled, you can use MEInfo from CSME System Tools, probably the best way to check if it's active or not for now. (if the PCI device is gone or it says disabled, it should have worked)
I've also seen better results with Intel ME firmware being in Configured state, not Initialized. Dumps can work but I've seen cases where it fails for some reasons.
Helpful ressource: https://winraid.level1techs.com/t/intel-converged-security-management-engine-drivers-firmware-and-tools-2-15
It will explain the difference between Configured and Initialized etc and links to these tools.
UPDATE:
Please, try 0x70 as the offset, CSME FIT informs me it should be on.
In case you don't want to do all that; here's your firmware, tell me how it goes. https://files.catbox.moe/pxdx7n.bin
This time it wasn't PCH_Strap_CSME_CSE_HAP_Mode but PCH_Strap_CSME_CSE_CSME_Reserved, seems like that varies too..

Thanks for the information
I tried pxdx7n.bin - computer starts with fan spin but no output on the screen - doesn't matter which port to use. and this is >30min already
So it did not work
Any other suggestions would be appreciated
Also out of curiosity, which offset did you use for pxdx7n.bin?
I tried all offsets you suggested (and modified me_cleaner.py 771 line for the proper offset) but none of them gave Reserved Yes in intel FIT

Try 0x70 as I said above. As for the computer booting but no screens, I would read the flash again and check coreboot log to see if there's anything booting or something you can figure out of. If there's no log, well maybe HAP isn't well supported on your board, but I haven't seen that case yet. (perhaps, I would try to get ME firwmare in Configured state)
On some computers, it might take a lot of time to boot though I heard so. Like really a lot. Now you mention it, after a ME firmware upgrade, I waited sometimes about a hour until it starts.
You could also compare dumps to see if anything happens:
diff <(xxd oldrom) <(xxd newrom)

OK, I waited 24 hours for computer to start (after flashing pxdx7n.bin) and no video output still
I read the image back and compared to original dump image (from before modifying HAP) as suggested, output is in attached file:
Apparently there is something happening during boot, but not sure what to make of it
Otherwise I tired searching for CSME 14.0.40.1206, but so far unsuccessfully
diff.txt

OK just an update in case anybody is interested

I got clean firmware build from mrchromebox - so intel me in configured and not initialized

I deactivated hap using CSME (it worked this time) - but no video out anyway, even after 24 h

I can conclude HAP method is not working with this board

mrchromebox provided build with HECI deactivated - and this worked like a charm - no PCI device present:

MrChromebox/firmware#139

Okay, just keep in mind that it's not because that the HECI device isn't present that ME core is really inactive.

About HAP, I just looked on the issue and saw what mrchromebox said multiple times that ME is not a backdoor, and it may be really isn't in the first place like people said, in fact it does make sense since governments use these kind of computers, it would be really dangerous even for them to include those there.

Now, if HAP exists, there's a reason for it (and it's been known its in acronym) and I don't think it's paranoid to think that it can be used as an attack vector.

Even though it is becomes rarer each years, there's been security researchers across the years finding vulnerabilities in it, disclosed or not, but more in the Corporate version (so with the AMT module), but it does not limit to it.

So, yes, using HAP might not protect you from Intel backdoors (if there's any) since there's maybe not any of them in the first place, but it might at least prevent some of the vulnerabilities that could exist in ME after booting.

Just a quick reminder also that it's not rare for governments/malwares/companies/name it what ever to use vulnerabilities or any techniques to include backdoors in hardware and softwares to infiltrate into systems, and that does not only apply to ME; but to every software/hardware you use. (from kernel anti-cheats to network devices)

Now, I understand why ME exists, it solves a problem in the industry, it is a very interesting feature to manage your computer from anywhere transparently to the OS.

But what would make even more sense is to make it open to people, to offer better security and more importantly just to say that you do truly own your computer, since it is the root of trust.

If you are limited by companies and not technical knowledge that the company could provide information on, you're being encapsulated by them, even if it's legitimate for them to do so, but never for us, the consumers. (To be honest, I'm quite in a cognitive bias when I see someone wanting more corporate IoTs in their lifes)

This isn't the only firmware that runs on your computer anyway, and there's sadly too many of them.

Also, in addition to what mrchromebox said in the other issue, in fact it doesn't even matter much for the interface to be active or not. What truly matters is what the processor is doing with or/and without this interface.

Anyone who have read what ptsecurity said know that it makes ME core being stuck in a loop: https://www.ptsecurity.com/ww-en/analytics/disabling-intel-me-11-via-undocumented-mode, and that it shouldn't be able to escape it.

Now, does that mean we should rely on that information and move on?
Surely not, it needs to be verified and tested multiple times.
It may have also changed across the years and there's still a lot to explore.

I don't give too much trust to what people say, I always try to verify things by myself, you learn more this way even if they end up saying the truth.

Unfortunately, when I wanted to verify some of the things here, one really sad move is that intel oneAPI (including the debugger) is under NDA now.
The debugger was always available freely before, which could make OpenIPC configuration for the ME core more easily.
Guess they did that move exactly for ... Well, who knows. :)
Money? Yeah of course.

[mlario]

Okay, just keep in mind that it's not because that the HECI device isn't present that ME core is really inactive.

yes, I know. but HAP did not work so I have no other option

About HAP, I just looked on the issue and saw what mrchromebox said multiple times that ME is not a backdoor, and it may be really isn't in the first place like people said, in fact it does make sense since governments use these kind of computers, it would be really dangerous even for them to include those there.

I like facts. If not proven otherwise there is no firm evidence against or pro backdoor hypothesis. If backdoor option cannot be excluded than it needs to be mitigated. full stop

And it is not like there were no reports about major superstates backdooring (or not reporting vulnerabilities..) of widely used OS, firmwares on ssds etc.

Now, if HAP exists, there's a reason for it (and it's been known its in acronym) and I don't think it's paranoid to think that it can be used as an attack vector.

there were vulnerabilities reported, even used

Even though it is becomes rarer each years, there's been security researchers across the years finding vulnerabilities in it, disclosed or not, but more in the Corporate version (so with the AMT module), but it does not limit to it.

why intel me exists on consumer chips if there is no utility of it, it is supposed to be fully utilized only as amt version. why not to deactivate it if designing new silicon is expensive.

So, yes, using HAP might not protect you from Intel backdoors (if there's any) since there's maybe not any of them in the first place, but it might at least prevent some of the vulnerabilities that could exist in ME after booting.

Just a quick reminder also that it's not rare for governments/malwares/companies/name it what ever to use vulnerabilities or any techniques to include backdoors in hardware and softwares to infiltrate into systems, and that does not only apply to ME; but to every software/hardware you use. (from kernel anti-cheats to network devices)

Now, I understand why ME exists, it solves a problem in the industry, it is a very interesting feature to manage your computer from anywhere transparently to the OS.

But what would make even more sense is to make it open to people, to offer better security and more importantly just to say that you do truly own your computer, since it is the root of trust.

If you are limited by companies and not technical knowledge that the company could provide information on, you're being encapsulated by them, even if it's legitimate for them to do so, but never for us, the consumers. (To be honest, I'm quite in a cognitive bias when I see someone wanting more coporate IoTs in their lifes)

This isn't the only firmware that runs on your computer anyway, and there's sadly too many of them.

Also, in addition to what mrchromebox said in the other issue, in fact it doesn't even matter much for the interface to be active or not. What truly matters is what the processor is doing with or/and without this interface.

Anyone who have read what ptsecurity said know that it makes ME core being stuck in a loop: https://www.ptsecurity.com/ww-en/analytics/disabling-intel-me-11-via-undocumented-mode, and that it shouldn't be able to escape it.

Now, does that mean we should rely on that information and move on? Surely not, it needs to be verified and tested multiple times. It may have also changed across the years and there's still a lot to explore.

I don't give too much trust to what people say, I always try to verify things by myself, you learn more this way even if they end up saying the truth.

this is called scientific approach. operating with facts and hard evidence, if none exists - checking yourself. Somebody said something is not a prove

Unfortunately, when I wanted to verify some of the things here, one really sad move is that intel oneAPI (including the debugger) is under NDA now. The debugger was always available freely before, which could make OpenIPC configuration for the ME core more easily. Guess they did that move exactly for ... Well, who knows. :) Money? Yeah of course.

agree with what you said. until any better alternative is available mitigating vulnerabilities in closed proprietary systems would be the only approach

[XutaxKamay]

Okay, just keep in mind that it's not because that the HECI device isn't present that ME core is really inactive.

yes, I know. but HAP did not work so I have no other option

About HAP, I just looked on the issue and saw what mrchromebox said multiple times that ME is not a backdoor, and it may be really isn't in the first place like people said, in fact it does make sense since governments use these kind of computers, it would be really dangerous even for them to include those there.

I like facts. If not proven otherwise there is no firm evidence against or pro backdoor hypothesis. If backdoor option cannot be excluded than it needs to be mitigated. full stop

And it is not like there were no reports about major superstates backdooring (or not reporting vulnerabilities..) of widely used OS, firmwares on ssds etc.

Now, if HAP exists, there's a reason for it (and it's been known its in acronym) and I don't think it's paranoid to think that it can be used as an attack vector.

there were vulnerabilities reported, even used

Even though it is becomes rarer each years, there's been security researchers across the years finding vulnerabilities in it, disclosed or not, but more in the Corporate version (so with the AMT module), but it does not limit to it.

why intel me exists on consumer chips if there is no utility of it, it is supposed to be fully utilized only as amt version. why not to deactivate it if designing new silicon is expensive.

So, yes, using HAP might not protect you from Intel backdoors (if there's any) since there's maybe not any of them in the first place, but it might at least prevent some of the vulnerabilities that could exist in ME after booting.
Just a quick reminder also that it's not rare for governments/malwares/companies/name it what ever to use vulnerabilities or any techniques to include backdoors in hardware and softwares to infiltrate into systems, and that does not only apply to ME; but to every software/hardware you use. (from kernel anti-cheats to network devices)
Now, I understand why ME exists, it solves a problem in the industry, it is a very interesting feature to manage your computer from anywhere transparently to the OS.
But what would make even more sense is to make it open to people, to offer better security and more importantly just to say that you do truly own your computer, since it is the root of trust.
If you are limited by companies and not technical knowledge that the company could provide information on, you're being encapsulated by them, even if it's legitimate for them to do so, but never for us, the consumers. (To be honest, I'm quite in a cognitive bias when I see someone wanting more coporate IoTs in their lifes)
This isn't the only firmware that runs on your computer anyway, and there's sadly too many of them.
Also, in addition to what mrchromebox said in the other issue, in fact it doesn't even matter much for the interface to be active or not. What truly matters is what the processor is doing with or/and without this interface.
Anyone who have read what ptsecurity said know that it makes ME core being stuck in a loop: https://www.ptsecurity.com/ww-en/analytics/disabling-intel-me-11-via-undocumented-mode, and that it shouldn't be able to escape it.
Now, does that mean we should rely on that information and move on? Surely not, it needs to be verified and tested multiple times. It may have also changed across the years and there's still a lot to explore.
I don't give too much trust to what people say, I always try to verify things by myself, you learn more this way even if they end up saying the truth.

this is called scientific approach. operating with facts and hard evidence, if none exists - checking yourself. Somebody said something is not a prove

Unfortunately, when I wanted to verify some of the things here, one really sad move is that intel oneAPI (including the debugger) is under NDA now. The debugger was always available freely before, which could make OpenIPC configuration for the ME core more easily. Guess they did that move exactly for ... Well, who knows. :) Money? Yeah of course.

agree with what you said. until any better alternative is available mitigating vulnerabilities in closed proprietary systems would be the only approach

Yep, not a lot of them being/used in the wild but enough to be considered as a security problem anyway.

About the consumer firmware version, on why ME exists, the corporate answer would be: it is for Intel Boot Guard for securing the boot process in order to verify the initial boot block with the OEM public key inside the flash chip.

Of course, the problem is also that it isn't your key but OEM's one, and that's where the problem is really.

This is mainly why MSI/Insyde had really some troubles with their source code being leaked recently, because the private keys were leaked. (yeah what a disaster, malwares can now override your firmware, worse; now people can unlock their motherboards !)

Sometimes if you are lucky (like myself), you might get a computer in ME manufacturing mode which permits to override the hash of the OEM public key with your own hash, and fuse it inside the PCH, so you can get Intel Boot Guard the right way as it should be.

There's still some private keys in the wild and are sometimes left when you download your BIOS firmware, which you can use to revoke the OEM public key with your own. :)

EDIT: apparently, that's not how it works, that's sad, it seems that the two keys are fused from the beginning in case of a revoke, that means you can't change it anymore once it's fused for both keys.

Anyway, yep, HAP is for now the best we can have, but I'm seeking a future where we could replace the firmware with our own.

[Kaiyangshi-Ito]

When I used me_cleaner to modify my externally flashed image, it says
more than one $FPT found? How should I resolve this? Thanks.

[ilikenwf]

I should mention I've been running a cleaned coreboot on my System76 Serval WS for months now using this PR, no issues.

13th Gen Intel i9-13900HX (32) @ 5.200GHz

[ilikenwf]

I still have been unable to get the HECI hiding to stop, even with the flag disabled in the coreboot config. It may be something with the way that it's built in the system76 firmware system (since it's not vanilla coreboot) or it could be some default that I can't adjust?

If I dump the bios image internally and check with me_cleaner, the HAP is set, though...

[ilikenwf]

Looks like Dasharo is setting this bit from within their own bios builds or menus...including for 14th gen CPUs...are their offsets different than what we have here? They support up to me 18...

Also search them for "DISABLE_HAP "

https://github.com/Dasharo/coreboot/tree/master/src/soc/intel/common/block/include/intelblocks

[Ph0rk0z]

Some caution for people trying this: https://winraid.level1techs.com/t/thinkpad-t14-gen-4-attempting-to-disable-me-16-1-27-2192-cons-lp/103625/32 on new thinkpads. The chips are all now WSON8 and there is a second backup chip with copies of the FD.

[skullface101]

more than one $FPT found

I get "more than one $FPT found" !
Whats the solution?

[skullface101]

I haven't tested with others Intel ME for the 15 version, but I guess that should work, as the PCI device (Intel ME) is not present anymore and seems to act like it's disabled, but I'll need to do more tests with AMT to be sure.

If someone is looking at this pull request and is willing to test the soft-disable, since Intel ME 15 might have different HAP bit offsets between chipsets etc, although I'm not really sure about that, I don't have any other computers to test with.

Thanks to @dt-zero and @6d6178667269747a for previous versions of Intel ME.

If that doesn't work, try this guess: #384 (comment)

How can I manually do this?
I have 2 devices with Intel Me 15

I get this error "more than one $FPT found" for one of the devices

and I get this error for the update rom file

---

Full image detected
Found FPT header at 0x19c000
Found 11 partition(s)
Found FTPR header: FTPR partition spans from 0x5b000 to 0x5b000
Found FTPR manifest at 0x5b2cc
ME/TXE firmware version 15.0.21.1549 (generation 6)
Public key match: Intel ME, firmware versions 15.x.x.x
The HAP bit is NOT SET
Setting the HAP bit in PCHSTRP31 to disable Intel ME...
Checking the FTPR RSA signature... INVALID!!
The FTPR partition signature is not valid. Is the input ME/TXE image valid?

---

[skullface101]

setting reserved to yes did it!

[skullface101]

What does Enhanced HAP mode change?

[skullface101]

MEALTDISABLE

MEALTDISABLE

Where can I get these versions with -MEALTDISABLE?
@XutaxKamay

[orangecms]

Thanks, I'll look at this to extend the new tool I'm working on.

--

Note:
I am currently working on a new tool with clear data structures and parsing separated from logic, so I'm checking the PRs here to see what else I can integrate; see
https://github.com/platform-system-interface/intel_fw

[pacuro78]

@orangecms
I have tried your tool to disable me on Z590. Run three times with different dumps - 1. stock bios from Gigabyte, 2. my normal dump via FPTW64 and finally 3. dump via FPTW64 with "FW mode operation: Unsecured mode by H/W jumper". I assume 3rd dump is full region dump - correct me if I am wrong. All three attempts result in error: "no ME firmware recognized". Please see code below:
`E:>intel_fw.exe me clean -S full.rom -O unme.rom
Intel Firmware Tool 🔧
[2025-11-30T13:24:33Z INFO intel_fw] Output will be written to: unme.rom
[2025-11-30T13:24:33Z INFO intel_fw] Reading full.rom...
[2025-11-30T13:24:34Z INFO intel_fw] ME region start @ 00003000

=== Flash descriptor ===
== Configuration ==
components: 1, base: 0x00000030
regions: 1, base: 0x00000040
masters: 3, base: 0x00000080
ICH8/PCH straps: 101, base: 0x00000100
MCH straps: 1, base: 0x00000b00
== Components ==
Components {
FLCOMP: FlashComponentConfig {
comp1_density: _Undefined,
comp2_density: _Undefined,
read_clock_frequency: M20,
fast_read_support: true,
fast_read_clock_frequency: M33,
write_erase_clock_frequency: M33,
read_id_status_clock_frequency: M33,
},
FLILL0: FlashInvalidInstructions {
inst1: 0x21,
inst2: 0x42,
inst3: 0x60,
inst4: 0xad,
},
FLILL1: FlashInvalidInstructions {
inst1: 0xb7,
inst2: 0xb9,
inst3: 0xc4,
inst4: 0xc7,
},
}
== Regions ==
Flash descriptor (IFD): 00000000 - 00000fff
BIOS (host) firmware: 01000000 - 01ffffff
(CS)ME firmware: 00003000 - 00ffffff
Gigabit ethernet data: 00001000 - 00002fff
Platform data: 01fff000 - 00000fff (unused)
Embedded controller (EC): 01fff000 - 00000fff (unused)
== Masters ==
0: 00a00f00
1: 00400d00
2: 00800900
3: 00000000
4: 10010100
5: 00000000
6: ffffffff
7: ffffffff
[2025-11-30T13:24:34Z ERROR intel_fw::show] No ME firmware found

FIT @ 01cc8600, 11 entries, version 0100, checksum: 00
Microcode Update 00000000 @ ffc20400 version 0100 no checksum
Microcode Update 00000000 @ ffc36800 version 0100 no checksum
Microcode Update 00000000 @ ffc4cc00 version 0100 no checksum
Microcode Update 00000000 @ ffc64c00 version 0100 no checksum
Microcode Update 00000000 @ ffc7b400 version 0100 no checksum
Microcode Update 00000000 @ ffc93000 version 0100 no checksum
Microcode Update 00000000 @ ffcaa000 version 0100 no checksum
Startup AC Module 00000000 @ fffa0000 version 0100 no checksum
TXT Policy Record 00000000 @ 7a040100710070 version 0000 no checksum
Key Manifest Record 00650300 @ fff6fb00 version 0100 no checksum
Boot Policy Manifest 00950400 @ fff6f600 version 0100 no checksum

Error: Custom { kind: NotFound, error: "no ME firmware recognized" }

E:>`

Where is the problem? In my dump?

[orangecms]

@orangecms
I have tried your tool to disable me on Z590. Run three times with different dumps - 1. stock bios from Gigabyte, 2. my normal dump via FPTW64 and finally 3. dump via FPTW64 with "FW mode operation: Unsecured mode by H/W jumper". I assume 3rd dump is full region dump - correct me if I am wrong. All three attempts result in error: "no ME firmware recognized". Please see code below:
`E:>intel_fw.exe me clean -S full.rom -O unme.rom
Intel Firmware Tool 🔧
[2025-11-30T13:24:33Z INFO intel_fw] Output will be written to: unme.rom
[2025-11-30T13:24:33Z INFO intel_fw] Reading full.rom...
[2025-11-30T13:24:34Z INFO intel_fw] ME region start @ 00003000

=== Flash descriptor ===
== Configuration ==
components: 1, base: 0x00000030
regions: 1, base: 0x00000040
masters: 3, base: 0x00000080
ICH8/PCH straps: 101, base: 0x00000100
MCH straps: 1, base: 0x00000b00
== Components ==
Components {
FLCOMP: FlashComponentConfig {
comp1_density: _Undefined,
comp2_density: _Undefined,
read_clock_frequency: M20,
fast_read_support: true,
fast_read_clock_frequency: M33,
write_erase_clock_frequency: M33,
read_id_status_clock_frequency: M33,
},
FLILL0: FlashInvalidInstructions {
inst1: 0x21,
inst2: 0x42,
inst3: 0x60,
inst4: 0xad,
},
FLILL1: FlashInvalidInstructions {
inst1: 0xb7,
inst2: 0xb9,
inst3: 0xc4,
inst4: 0xc7,
},
}
== Regions ==
Flash descriptor (IFD): 00000000 - 00000fff
BIOS (host) firmware: 01000000 - 01ffffff
(CS)ME firmware: 00003000 - 00ffffff
Gigabit ethernet data: 00001000 - 00002fff
Platform data: 01fff000 - 00000fff (unused)
Embedded controller (EC): 01fff000 - 00000fff (unused)
== Masters ==
0: 00a00f00
1: 00400d00
2: 00800900
3: 00000000
4: 10010100
5: 00000000
6: ffffffff
7: ffffffff
[2025-11-30T13:24:34Z ERROR intel_fw::show] No ME firmware found

FIT @ 01cc8600, 11 entries, version 0100, checksum: 00
Microcode Update 00000000 @ ffc20400 version 0100 no checksum
Microcode Update 00000000 @ ffc36800 version 0100 no checksum
Microcode Update 00000000 @ ffc4cc00 version 0100 no checksum
Microcode Update 00000000 @ ffc64c00 version 0100 no checksum
Microcode Update 00000000 @ ffc7b400 version 0100 no checksum
Microcode Update 00000000 @ ffc93000 version 0100 no checksum
Microcode Update 00000000 @ ffcaa000 version 0100 no checksum
Startup AC Module 00000000 @ fffa0000 version 0100 no checksum
TXT Policy Record 00000000 @ 7a040100710070 version 0000 no checksum
Key Manifest Record 00650300 @ fff6fb00 version 0100 no checksum
Boot Policy Manifest 00950400 @ fff6f600 version 0100 no checksum

Error: Custom { kind: NotFound, error: "no ME firmware recognized" }

E:>`

Where is the problem? In my dump?

All good! You have likely run into an IFWI - another way of partitioning that Intel added at some point. I have literally started to look into that just the other day myself, and I have some staging stuff, but it's unfortunately a bit tricky.

Or to cite ME Analyzer:
https://github.com/platomav/MEAnalyzer/blob/aa148556bbf09e418074c3cea18255a25432fb7c/MEA.py#L11490

Let's discuss that here please:
platform-system-interface/intel_fw#80

[orangecms]

@pacuro78 here is output from my work in progress; please comment on that issue if you are interested in furthering the development :)

platform-system-interface/intel_fw#80 (comment)

[minhkhoi89]

For my B560M and my Z590 chipsets (me v15), the HAP bit offset is at 196
ASRock B560M Steel Legend: 10 -> 11
Asus Tuf Z590 Gaming (including dual SPI version): 00 -> 01

This would change me_cleaner code f20532d to:
elif gen == 6:
# fdf.seek(fpsba + 0x7C)
fdf.seek(fpsba + 0x94)
pchstrp31 = unpack("<I", fdf.read(4))[0]
print("The HAP bit is " + ("SET" if pchstrp31 & 1 << 16 else "NOT SET"))

• intel me disabled is important, these TPM modules (Macronix/GigaDevice/etc.) are Chinese made. It's not the NSA but the Chinese human traffickers/drug dealers that are looking straight at your screens.
  Stay safe.

[skullface101]

For my B560M and my Z590 chipsets (me v15), the HAP bit offset is at 196 ASRock B560M Steel Legend: 10 -> 11 Asus Tuf Z590 Gaming (including dual SPI version): 00 -> 01

This would change me_cleaner code f20532d to: elif gen == 6: # fdf.seek(fpsba + 0x7C) fdf.seek(fpsba + 0x94) pchstrp31 = unpack("<I", fdf.read(4))[0] print("The HAP bit is " + ("SET" if pchstrp31 & 1 << 16 else "NOT SET"))

* intel me disabled is important, these TPM modules (Macronix/GigaDevice/etc.) are Chinese made. It's not the NSA but the Chinese human traffickers/drug dealers that are looking straight at your screens.
  Stay safe.

Just FYI
using Intel Flash Image Tool FIT, you can open flash dumps and use the reserved checkbox to disable intel ME.
you can also grab firmware update from vendor and clean ME partiton to uninitialized state.