Add soft-disable support for Intel ME 12, 14, 15 and 16 #384
Conversation
XutaxKamay
changed the title
|
Seems to work on NovaCustom NV4x laptop (TGL-U "Premium" chipset, ME version |
|
That's good to know, thanks! |
|
Z690 Z590 |
|
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. |
|
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 😞 |
|
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: |
|
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 BDR layout: 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. Some of the relevant modules could be |
Needs testing
XutaxKamay
changed the title
|
Let me know if Intel ME 16 HAP bit offset works please, I'm not really sure about this one either. :) |
|
If you can give me your ROM, it might be something else. |
|
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
force-pushed
the
master
branch
8 times, most recently
from
a354a0d
to
835056b
Compare
|
Intel ME 13 will be also possible but I really need people that could test for me. 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. 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 🥲 |
|
So with my current build of the System76 firmware, I didn't turn off the HECI command, so I see no visible difference. Do I need to do a build with ME "enabled" and do a before/after? Assuming the HAP bit works that's a big step forward; additionally, are we setting it to 1 or 2? I think that some if not all of the newer chips support an "enhanced" disable with value 2 but I'm not sure what the difference is. Additionally, with System76 it may be possible to strip a whole lot more out of the ME than even you suggest if the EC is truly controlling the fans, and it does seem to since I have custom curves built into my EC now... |
The HECI command have high chance to be sent by coreboot. Perhaps check your configuration. It does work. And sorry, but what the fuck? Setting a bit to 2? A bit can be set only to 0 or 1 ... If you talk about DbC_Strap_CSME_eHAP_EN which I've discovered one year ago, this is a different bit which is an hidden configuration by FIT, which could mean either enhanced or emergency HAP. Yes the EC controls the fans? Not sure what you mean here, but you won't be able to remove rbe, kernel, bup and syslib, with HAP only. |
|
Well, not setting the bit to 2, but a previous comment by someone in this thread suggested something about hap/altmedisable or whatever. The one you mention discovering is probably what he (or you, wall of text, tl;dr) meant - DbC_Strap_CSME_eHAP_EN I'm also operating on about 3 hours sleep so if I'm in coherent this is why. I'll try a build with the HECI command config flag unset when I can, and if that shows the ME pci device, I'll test your modification here again. If that works I may go to a certain forum, if that is what you mean for locating the FPT tool, and try the full disable there... Ultimately if it all works the HECI being sent or not will be irrelevant. |
Get some sleep, my brother. :) |
|
The flash image for my laptop is interesting digging with those tools...other areas of interest include camera config. I assume "reserved" is the bit in the ME config to look at in my case. |
|
Yes - so I doubt I need to bother with disabling the HECI stuff if the reserved bit is also set to yes using this PR to set it... |
|
I can't get the EFI vesrion of FPT working, and don't want to install Windows on this machine really, and with ME disabled already there's no PCI device to talk to - so is the ehap stuff even worth looking into or should I wait until more research has been done? Could it have anything to do with this?
Likewise tracehub is still scary enough...the debugging is off here but messages enabled... |
|
I realize that is under debugging but if you set it to just halt ME on reset, I wonder if it would allow removing more modules? |
|
And for what it's worth, my HAP bit was at 0x1DE:
|
|
Hello, I'm a bit bugged. What do you mean exactly about the PCI devices. You don't get any detected on your computer ? Plus some sentences are not making any sense. Could you explain it a bit please ? Yours, -- |
|
*FPT, my bad, have seen too much infra today. -- |
I used vbindiff on the before/after of my firmware, this was the only part of the image that changed. Hex notation. Here's the IFD before/after: |
|
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 |
|
Get yourself a ch341a programmer and either a chip clip or pogoplug - then you can flash it on board. |
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.
And modify here the offset: https://github.com/XutaxKamay/me_cleaner/blob/master/me_cleaner.py#L771 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. 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 |
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: |
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? 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. |
yes, I know. but HAP did not work so I have no other option
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.
there were vulnerabilities reported, even used
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.
this is called scientific approach. operating with facts and hard evidence, if none exists - checking yourself. Somebody said something is not a prove
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. |
|
When I used me_cleaner to modify my externally flashed image, it says |
|
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 |
|
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... |
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)