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

XutaxKamay commented 2 years ago

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: https://github.com/corna/me_cleaner/pull/384#issuecomment-1220260578

mkopec commented 2 years ago

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 commented 2 years ago

That's good to know, thanks!

EmptyIsValue commented 2 years ago

Screenshot_20220803-053957_Termux

Z690 Screenshot_20220803-060357_Termux tried twice even more, just like this it said FTPR header not found

Z590 IMG_20220803_061212

XutaxKamay commented 2 years ago

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.

dt-zero commented 2 years ago

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 :disappointed:

XutaxKamay commented 2 years ago

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

dt-zero commented 2 years ago

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 commented 2 years ago

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

EmptyIsValue commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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. :)

dt-zero commented 2 years ago

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 :smiling_face_with_tear:

XutaxKamay commented 2 years ago

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 smiling_face_with_tear

Thank you! And yes I know that the same Intel ME version can have different offsets, hence why I'm not very sure.

And I'm not sure entirely either about the different SKU identifier (but I believe you because you probably worked on that much more than me, so I'll try look it up), how ever I can say that there's actually a lot of possibilities for the actual FPSBA HAP bit offset like you said, and not only for Intel ME 13. I certainly need to reverse engineer a bit more all of that but I don't know if I'll get enough time to do so. :/ The 16 bits shift to the left seems always to be present though.

We can see that actually by extracting the XML files in the FIT Tool that seems to be publicly available, which is either PCH_Strap_CSME_CSE_CSME_Reserved or actually sometimes PCH_Strap_CSME_CSE_HAP_Mode or PCH_Strap_CSME_CSE_Reserved_Softstrap_16 now, as you know already probably, I just saw it in your pull request now. (funny I didn't see that one before I tried to search for myself, but of course, this is purely theoretical)

We could simply force all the possible known bit offset to 1 and hope that one of them works and hopefully boots but this is not very elegant indeed.

Anyway, ideally this doesn't neutralize much Intel ME, however I found some interesting things related to the PMC which I need to figure out to be able to neutralize it which I can't talk about here sadly, but this thing looks promising. (again this is purely theoretical but it has probably something to do with Simi*s but I'm not promising anything!)

ghost commented 2 years ago

Hello @XutaxKamy, I have used your modified version of the me_cleaner on my system with an ASUS PRIME B660 PLUS D4 motherboard, and an i3-12100F Alder Lake CPU with Intel ME version 16.0.15.1735. The HAP bit was set successfully, and when running 'lspci -vvv' on GNU/Linux, the mei_me kernel module is not loaded at all, and the PCH interface for the ME appears to be gone too. Thank you all for your contributions.

lspci -vvv

00:00.0 Host bridge: Intel Corporation Device 4630 (rev 05)
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0

00:01.0 PCI bridge: Intel Corporation 12th Gen Core Processor PCI Express x16 Controller #1 (rev 05) (prog-if 00 [Normal decode])
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 121
        Bus: primary=00, secondary=01, subordinate=03, sec-latency=0
        I/O behind bridge: 6000-6fff [size=4K] [16-bit]
        Memory behind bridge: 83400000-836fffff [size=3M] [32-bit]
        Prefetchable memory behind bridge: 4100000000-43ffffffff [size=12G] [32-bit]
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: <access denied>
        Kernel driver in use: pcieport

00:06.0 PCI bridge: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 (rev 05) (prog-if 00 [Normal decode])
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin D routed to IRQ 122
        Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
        I/O behind bridge: f000-0fff [disabled] [16-bit]
        Memory behind bridge: 83800000-838fffff [size=1M] [32-bit]
        Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff [disabled] [64-bit]
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: <access denied>
        Kernel driver in use: pcieport

00:0a.0 Signal processing controller: Intel Corporation Platform Monitoring Technology (rev 01)
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Region 0: Memory at 4014210000 (64-bit, non-prefetchable) [size=32K]
        Capabilities: <access denied>
        Kernel driver in use: intel_vsec
        Kernel modules: intel_vsec

00:0e.0 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Region 0: Memory at 4012000000 (64-bit, non-prefetchable) [size=32M]
        Region 2: Memory at 80000000 (32-bit, non-prefetchable) [size=32M]
        Region 4: Memory at 4014100000 (64-bit, non-prefetchable) [size=1M]
        Capabilities: <access denied>
        Kernel driver in use: vmd
        Kernel modules: vmd

00:14.0 USB controller: Intel Corporation Alder Lake-S PCH USB 3.2 Gen 2x2 XHCI Controller (rev 11) (prog-if 30 [XHCI])
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 148
        Region 0: Memory at 4014200000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_pci

00:14.2 RAM memory: Intel Corporation Alder Lake-S PCH Shared SRAM (rev 11)
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Region 0: Memory at 401421c000 (64-bit, non-prefetchable) [disabled] [size=16K]
        Region 2: Memory at 4014224000 (64-bit, non-prefetchable) [disabled] [size=4K]
        Capabilities: <access denied>

00:15.0 Serial bus controller: Intel Corporation Alder Lake-S PCH Serial IO I2C Controller #0 (rev 11)
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 27
        Region 0: Memory at 4010600000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>
        Kernel driver in use: intel-lpss
        Kernel modules: intel_lpss_pci

00:15.1 Serial bus controller: Intel Corporation Alder Lake-S PCH Serial IO I2C Controller #1 (rev 11)
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 40
        Region 0: Memory at 4010601000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>
        Kernel driver in use: intel-lpss
        Kernel modules: intel_lpss_pci

00:15.2 Serial bus controller: Intel Corporation Alder Lake-S PCH Serial IO I2C Controller #2 (rev 11)
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin C routed to IRQ 29
        Region 0: Memory at 4010602000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>
        Kernel driver in use: intel-lpss
        Kernel modules: intel_lpss_pci

00:17.0 SATA controller: Intel Corporation Alder Lake-S PCH SATA Controller [AHCI Mode] (rev 11) (prog-if 01 [AHCI 1.0])
        DeviceName: Onboard - SATA
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 128
        Region 0: Memory at 83900000 (32-bit, non-prefetchable) [size=8K]
        Region 1: Memory at 83903000 (32-bit, non-prefetchable) [size=256]
        Region 2: I/O ports at 7050 [size=8]
        Region 3: I/O ports at 7040 [size=4]
        Region 4: I/O ports at 7020 [size=32]
        Region 5: Memory at 83902000 (32-bit, non-prefetchable) [size=2K]
        Capabilities: <access denied>
        Kernel driver in use: ahci

00:1a.0 PCI bridge: Intel Corporation Device 7ac8 (rev 11) (prog-if 00 [Normal decode])
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin ? routed to IRQ 123
        Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
        I/O behind bridge: 5000-5fff [size=4K] [16-bit]
        Memory behind bridge: 82a00000-833fffff [size=10M] [32-bit]
        Prefetchable memory behind bridge: 4010200000-40103fffff [size=2M] [32-bit]
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: <access denied>
        Kernel driver in use: pcieport

00:1c.0 PCI bridge: Intel Corporation Alder Lake-S PCH PCI Express Root Port #1 (rev 11) (prog-if 00 [Normal decode])
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin ? routed to IRQ 124
        Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
        I/O behind bridge: 4000-4fff [size=4K] [16-bit]
        Memory behind bridge: 82000000-829fffff [size=10M] [32-bit]
        Prefetchable memory behind bridge: 4010400000-40105fffff [size=2M] [32-bit]
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: <access denied>
        Kernel driver in use: pcieport

00:1c.2 PCI bridge: Intel Corporation Device 7aba (rev 11) (prog-if 00 [Normal decode])
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin C routed to IRQ 125
        Bus: primary=00, secondary=07, subordinate=07, sec-latency=0
        I/O behind bridge: 3000-3fff [size=4K] [16-bit]
        Memory behind bridge: 83700000-837fffff [size=1M] [32-bit]
        Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff [disabled] [64-bit]
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: <access denied>
        Kernel driver in use: pcieport

00:1f.0 ISA bridge: Intel Corporation Device 7a86 (rev 11)
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0

00:1f.3 Audio device: Intel Corporation Alder Lake-S HD Audio Controller (rev 11)
        DeviceName: Onboard - Sound
        Subsystem: ASUSTeK Computer Inc. Device 87fb
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32, Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 159
        Region 0: Memory at 4014218000 (64-bit, non-prefetchable) [size=16K]
        Region 4: Memory at 4014000000 (64-bit, non-prefetchable) [size=1M]
        Capabilities: <access denied>
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel, snd_sof_pci_intel_tgl

00:1f.4 SMBus: Intel Corporation Alder Lake-S PCH SMBus Controller (rev 11)
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin C routed to IRQ 18
        Region 0: Memory at 4014220000 (64-bit, non-prefetchable) [size=256]
        Region 4: I/O ports at efa0 [size=32]
        Kernel driver in use: i801_smbus
        Kernel modules: i2c_i801

00:1f.5 Serial bus controller: Intel Corporation Alder Lake-S PCH SPI Controller (rev 11)
        DeviceName: Onboard - Other
        Subsystem: ASUSTeK Computer Inc. Device 8694
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Region 0: Memory at 83904000 (32-bit, non-prefetchable) [size=4K]
        Kernel driver in use: intel-spi
        Kernel modules: spi_intel_pci

01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev c7) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 126
        Region 0: Memory at 83600000 (32-bit, non-prefetchable) [size=16K]
        Bus: primary=01, secondary=02, subordinate=03, sec-latency=0
        I/O behind bridge: 6000-6fff [size=4K] [16-bit]
        Memory behind bridge: 83400000-835fffff [size=2M] [32-bit]
        Prefetchable memory behind bridge: 4100000000-43ffffffff [size=12G] [32-bit]
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: <access denied>
        Kernel driver in use: pcieport

02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch (prog-if 00 [Normal decode])
        Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 127
        Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
        I/O behind bridge: 6000-6fff [size=4K] [16-bit]
        Memory behind bridge: 83400000-835fffff [size=2M] [32-bit]
        Prefetchable memory behind bridge: 4100000000-43ffffffff [size=12G] [32-bit]
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR+ <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: <access denied>
        Kernel driver in use: pcieport

03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6600/6600 XT/6600M] (rev c7) (prog-if 00 [VGA controller])
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5022
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 158
        Region 0: Memory at 4200000000 (64-bit, prefetchable) [size=8G]
        Region 2: Memory at 4100000000 (64-bit, prefetchable) [size=2M]
        Region 4: I/O ports at 6000 [size=256]
        Region 5: Memory at 83400000 (32-bit, non-prefetchable) [size=1M]
        Expansion ROM at 83500000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu

03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21/23 HDMI/DP Audio Controller
        Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21/23 HDMI/DP Audio Controller
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 160
        Region 0: Memory at 83520000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

04:00.0 Non-Volatile memory controller: Realtek Semiconductor Co., Ltd. Device 5765 (rev 01) (prog-if 02 [NVM Express])
        Subsystem: Realtek Semiconductor Co., Ltd. Device 5765
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        NUMA node: 0
        Region 0: Memory at 83800000 (64-bit, non-prefetchable) [size=16K]
        Region 5: Memory at 83804000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: <access denied>
        Kernel driver in use: nvme
        Kernel modules: nvme

07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
        Subsystem: ASUSTeK Computer Inc. Device 87d7
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at 3000 [size=256]
        Region 2: Memory at 83700000 (64-bit, non-prefetchable) [size=64K]
        Region 4: Memory at 83710000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: r8169
        Kernel modules: r8169

XutaxKamay commented 2 years ago

Nice, thanks for confirming!

By the way, this is just a guess but if you got the ME Coorp tools from a certain resource, there could be actually some hidden arguments inside the FPT including "MEALTDISABLE", of course also for newer versions of Intel ME. This option could have actually 3 arguments possible: 0, 1, 2. (0 seems to do nothing, 1 enable the HAP bit, and 2 enable the HAP bit and does more actually ...)

I think it could be called like so ./FPT -MEALTDISABLE 2 which could enable the HAP bit for your Intel ME firmware, but also two bits getting enabled inside the MipTable/MipDescriptor. My guess is that it could be related for the "enhanced" HAP version. (eHAP in DbcConfiguration, but maybe I'm wrong, I'll need to guess better)

It could also give hints about the different HAP bit offsets and how the FPT handles it aswell.

XutaxKamay commented 2 years ago

there isn't only the "HAP bit" it seems, there is also the Alt Disable Mode which is still present, I'll give soon some details

GoldenDawn commented 2 years ago

Hi, I am using this on a MSI z690 carbon ME version 16.1.25.1917 and am encountering an identical issue to @EmptyIsValue except the byte is 0xa2.

I've tried it on both a full dump and a ROM from msi's website, the results are the same.

GoldenDawn commented 2 years ago

Quick update, I was able to successfully disable ME on a msi z690 carbon running stock bios v191 and ME 16.1.25.1917. I previously encountered a lot of issues attempting it while running on v18. Not sure if bios version was the issue or it could have been me swapping cpus.

Had some initial side effects of very noticeable desktop flickering, but has since been resolved after running DDU for igp.

Edit: I would not attempt this unless you have a relatively good board that supports onboard flashing.

parker-stephens commented 1 year ago

Tried soft-disabling (-s) on my MSI Z790-P WIFI on both BIOS versions 7E06vA3 and 7E06vA4, and it technically flashes fine with the onboard-flashing (M-Flash), but it will never POST after flashing and is stuck in a continuous boot loop.

End up having to use the flashback feature to get it back to a working state.

Wojtaz0w commented 1 year ago

Hi. I have a ASRock B560M Pro4 with 2.20 BIOS. I applied your me_cleaner (soft disable only) to 2.30 update file but it complains about signatures. Log:

C:\Users\*****\Desktop>me_cleaner.py -c B56MP4_2.30
Full image detected
Found FPT header at 0x19e000
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.22.1680 (generation 6)
Public key match: Intel ME, firmware versions 15.x.x.x
The HAP bit is NOT SET
Checking the FTPR RSA signature... INVALID!!
The FTPR partition signature is not valid. Is the input ME/TXE image valid?

It sets the bit:

C:\Users\*****\Desktop>me_cleaner.py -s B56MP4_2.30
Full image detected
Found FPT header at 0x19e000
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.22.1680 (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?

But I'm afraid if flashing (internal) won't brick my board. Could someone help please? Also what options do I have if brick occurs?

GoldenDawn commented 1 year ago

@Wojtaz0w did you set an output file when you ran that command? Since it doesn't look like your board have a built in flash function, you're going to need an external programmer to rescue the board if it gets bricked.

Wojtaz0w commented 1 year ago

Hi!! I internally flashed ASRock's B560M Pro4 2.30 update with -s HAP bit set and it works! PC doesn't shutdown, boot time is normal, etc. However, I can't confirm if ME indeed is disabled. ME version shown in UEFI hasn't changed. I'd really appreciate if someone could help me. Here is screenshot: metool

XutaxKamay commented 1 year ago

Hi!! I internally flashed ASRock's B560M Pro4 2.30 update with -s HAP bit set and it works! PC doesn't shutdown, boot time is normal, etc. However, I can't confirm if ME indeed is disabled. ME version shown in UEFI hasn't changed. I'd really appreciate if someone could help me. Here is screenshot:

If the PCI device is gone, then it should be disabled. Congratz.

To be sure though you could use Intel's System Tools

ilikenwf commented 1 year ago

@XutaxKamay I'm also running into what @luke-jr is here:

https://github.com/corna/me_cleaner/issues/396

The bare ME image for my machine is just part of system76's firmware repo, though:

https://github.com/system76/firmware-open/blob/master/models/serw13/me.rom

Otherwise I can provide a full image if needed if required. me_cleaner doesn't like the above rom, but it does at least try to process my firmware image with the same result as the above issue - this is on a 13th gen raptor lake cpu.

XutaxKamay commented 1 year ago

@XutaxKamay I'm also running into what @luke-jr is here:

396

The bare ME image for my machine is just part of system76's firmware repo, though:

https://github.com/system76/firmware-open/blob/master/models/serw13/me.rom

Otherwise I can provide a full image if needed if required. me_cleaner doesn't like the above rom, but it does at least try to process my firmware image with the same result as the above issue - this is on a 13th gen raptor lake cpu.

Full image would help indeed. Though, if you are ready to make this manually, try manually setting the HAP bit at 0xDC or 0xD0 (16th bit) and check if it works.

About the RSA Signature mismatch, ignore it for now, it's not important, it might be just something wrong with where the offset starts/ends in order to calculate the hash with.

Looks like something like this

auto Stripper::CalcExtCPDManifestHash(
  const BPDTInfo& bpdtInfo,
  const UModelIndex& partitionManifestModelIndex)
{
    auto partitionManifest = reinterpret_cast<
      CPD_EXT_IFWI_PARTITION_MANIFEST* const>(
      GetNewImageDataAt(_model.base(partitionManifestModelIndex)).base());

    const auto cpdPartitionImageOffset = _model.base(
      partitionManifestModelIndex.parent());

    const auto partitionName = std::string(
      reinterpret_cast<const char* const>(
        partitionManifest->PartitionName),
      sizeof(partitionManifest->PartitionName));

    const auto module = std::ranges::find_if(
      bpdtInfo.modules,
      [&](const BPDTInfo::Module& module)
      {
          return module.name == (partitionName + ".man");
      });

    assert(module != bpdtInfo.modules.end());

    const auto cpdEntry = reinterpret_cast<const CPD_ENTRY* const>(
      GetNewImageDataAt(_model.base(module->entryModelIndex)).base());

    const auto bpdtPartitionImageOffset = _model.base(
      bpdtInfo.partitionsModelIndex);
    const auto bpdtPartitionBegin = GetNewImageDataAt(
      bpdtPartitionImageOffset);

    const auto bpdtPartitionSize = partitionManifest
                                     ->CompletePartitionLength;
    const auto cpdPartitionImageOffsetEnd = cpdPartitionImageOffset
                                            + cpdEntry->Length;

    std::vector<UINT8> data;
    data.reserve(bpdtPartitionSize);

    for (std::size_t i = 0; i < bpdtPartitionSize; i++)
    {
        const auto calcOffset = i + bpdtPartitionImageOffset;

        if (calcOffset >= cpdPartitionImageOffset
            and calcOffset < cpdPartitionImageOffsetEnd)
        {
            continue;
        }

        data.push_back(*(bpdtPartitionBegin + i));
    }

    std::vector<UINT8> hash(partitionManifest->HashSize, 0);

    if (partitionManifest->HashSize == 0x10)
    {
        sha1(data.data(), data.size(), hash.data());
    }
    else if (partitionManifest->HashSize == 0x20)
    {
        sha256(data.data(), data.size(), hash.data());
    }
    else if (partitionManifest->HashSize == 0x30)
    {
        sha384(data.data(), data.size(), hash.data());
    }
    else
    {
        sha384(data.data(), data.size(), hash.data());
    }

    return hash;
}

In case you're wondering, I discussed it a bit with Dasharo community but I'm working a new ME tool to remove modules for modern boards, but this will probably take some time, especially cause I need to work on some of tools first to make extensive tests, like flashing with network with a second board remotely and powering up my board to test multiple versions against with, so I don't need to move my ass everytime I want to make a new test.

The sauce will be released once I feel confident enough about it. It might end up aswell maybe being a completely waste of time, so don't get hopes too much high.

ilikenwf commented 1 year ago

@XutaxKamay I'm also running into what @luke-jr is here:

396

The bare ME image for my machine is just part of system76's firmware repo, though: https://github.com/system76/firmware-open/blob/master/models/serw13/me.rom Otherwise I can provide a full image if needed if required. me_cleaner doesn't like the above rom, but it does at least try to process my firmware image with the same result as the above issue - this is on a 13th gen raptor lake cpu.

Full image would help indeed. Though, if you are ready to make this manually, try manually setting the HAP bit at 0xDC or 0xD0 (16th bit) and check if it works.

About the RSA Signature mismatch, ignore it for now, it's not important, it might be just something wrong with where the offset starts/ends in order to calculate the hash with.

Looks like something like this
auto Stripper::CalcExtCPDManifestHash(
  const BPDTInfo& bpdtInfo,
  const UModelIndex& partitionManifestModelIndex)
{
    auto partitionManifest = reinterpret_cast<
      CPD_EXT_IFWI_PARTITION_MANIFEST* const>(
      GetNewImageDataAt(_model.base(partitionManifestModelIndex)).base());

    const auto cpdPartitionImageOffset = _model.base(
      partitionManifestModelIndex.parent());

    const auto partitionName = std::string(
      reinterpret_cast<const char* const>(
        partitionManifest->PartitionName),
      sizeof(partitionManifest->PartitionName));

    const auto module = std::ranges::find_if(
      bpdtInfo.modules,
      [&](const BPDTInfo::Module& module)
      {
          return module.name == (partitionName + ".man");
      });

    assert(module != bpdtInfo.modules.end());

    const auto cpdEntry = reinterpret_cast<const CPD_ENTRY* const>(
      GetNewImageDataAt(_model.base(module->entryModelIndex)).base());

    const auto bpdtPartitionImageOffset = _model.base(
      bpdtInfo.partitionsModelIndex);
    const auto bpdtPartitionBegin = GetNewImageDataAt(
      bpdtPartitionImageOffset);

    const auto bpdtPartitionSize = partitionManifest
                                     ->CompletePartitionLength;
    const auto cpdPartitionImageOffsetEnd = cpdPartitionImageOffset
                                            + cpdEntry->Length;

    std::vector<UINT8> data;
    data.reserve(bpdtPartitionSize);

    for (std::size_t i = 0; i < bpdtPartitionSize; i++)
    {
        const auto calcOffset = i + bpdtPartitionImageOffset;

        if (calcOffset >= cpdPartitionImageOffset
            and calcOffset < cpdPartitionImageOffsetEnd)
        {
            continue;
        }

        data.push_back(*(bpdtPartitionBegin + i));
    }

    std::vector<UINT8> hash(partitionManifest->HashSize, 0);

    if (partitionManifest->HashSize == 0x10)
    {
        sha1(data.data(), data.size(), hash.data());
    }
    else if (partitionManifest->HashSize == 0x20)
    {
        sha256(data.data(), data.size(), hash.data());
    }
    else if (partitionManifest->HashSize == 0x30)
    {
        sha384(data.data(), data.size(), hash.data());
    }
    else
    {
        sha384(data.data(), data.size(), hash.data());
    }

    return hash;
}
In case you're wondering, I discussed it a bit with Dasharo community but I'm working a new ME tool to remove modules for modern boards, but this will probably take some time, especially cause I need to work on some of tools first to make extensive tests, like flashing with network with a second board remotely and powering up my board to test multiple versions against with, so I don't need to move my ass everytime I want to make a new test.

The sauce will be released once I feel confident enough about it. It might end up aswell maybe being a completely waste of time, so don't get hopes too much high.

I was under the impression, at least with the Clevo boards, that the ME image is required to bring up the CPU - if this is only the case because nobody's built a tool to remove modules yet, that's pretty cool!

I'm going to assume that the "trust me bro" ME disable is indeed working if the PCI device isn't there, but the mei_me module still loads...but then again, I suspect that with my CPU and machine, where AMT isn't an option, probably has an ME image that at worst only does hardware init...and sits there as a backdoor for the authorities, maybe, idk.

So does me_cleaner still set the HAP bit even if it fails the signature check? If so I suppose I can test flashing this rom if I don't mind recovering after the fact with my pogo plug adapter...

ilikenwf commented 1 year ago

...that said, the PCI device doesn't exist on my machine. I wonder if the HAP vs whatever is used for the "softer" disable option that Sys76 uses.

ilikenwf commented 1 year ago

YOLO, so I flashed... so far so good.

XutaxKamay commented 1 year ago

@XutaxKamay I'm also running into what @luke-jr is here:

396

The bare ME image for my machine is just part of system76's firmware repo, though: https://github.com/system76/firmware-open/blob/master/models/serw13/me.rom Otherwise I can provide a full image if needed if required. me_cleaner doesn't like the above rom, but it does at least try to process my firmware image with the same result as the above issue - this is on a 13th gen raptor lake cpu.

Full image would help indeed. Though, if you are ready to make this manually, try manually setting the HAP bit at 0xDC or 0xD0 (16th bit) and check if it works. About the RSA Signature mismatch, ignore it for now, it's not important, it might be just something wrong with where the offset starts/ends in order to calculate the hash with. Looks like something like this
auto Stripper::CalcExtCPDManifestHash(
  const BPDTInfo& bpdtInfo,
  const UModelIndex& partitionManifestModelIndex)
{
    auto partitionManifest = reinterpret_cast<
      CPD_EXT_IFWI_PARTITION_MANIFEST* const>(
      GetNewImageDataAt(_model.base(partitionManifestModelIndex)).base());

    const auto cpdPartitionImageOffset = _model.base(
      partitionManifestModelIndex.parent());

    const auto partitionName = std::string(
      reinterpret_cast<const char* const>(
        partitionManifest->PartitionName),
      sizeof(partitionManifest->PartitionName));

    const auto module = std::ranges::find_if(
      bpdtInfo.modules,
      [&](const BPDTInfo::Module& module)
      {
          return module.name == (partitionName + ".man");
      });

    assert(module != bpdtInfo.modules.end());

    const auto cpdEntry = reinterpret_cast<const CPD_ENTRY* const>(
      GetNewImageDataAt(_model.base(module->entryModelIndex)).base());

    const auto bpdtPartitionImageOffset = _model.base(
      bpdtInfo.partitionsModelIndex);
    const auto bpdtPartitionBegin = GetNewImageDataAt(
      bpdtPartitionImageOffset);

    const auto bpdtPartitionSize = partitionManifest
                                     ->CompletePartitionLength;
    const auto cpdPartitionImageOffsetEnd = cpdPartitionImageOffset
                                            + cpdEntry->Length;

    std::vector<UINT8> data;
    data.reserve(bpdtPartitionSize);

    for (std::size_t i = 0; i < bpdtPartitionSize; i++)
    {
        const auto calcOffset = i + bpdtPartitionImageOffset;

        if (calcOffset >= cpdPartitionImageOffset
            and calcOffset < cpdPartitionImageOffsetEnd)
        {
            continue;
        }

        data.push_back(*(bpdtPartitionBegin + i));
    }

    std::vector<UINT8> hash(partitionManifest->HashSize, 0);

    if (partitionManifest->HashSize == 0x10)
    {
        sha1(data.data(), data.size(), hash.data());
    }
    else if (partitionManifest->HashSize == 0x20)
    {
        sha256(data.data(), data.size(), hash.data());
    }
    else if (partitionManifest->HashSize == 0x30)
    {
        sha384(data.data(), data.size(), hash.data());
    }
    else
    {
        sha384(data.data(), data.size(), hash.data());
    }

    return hash;
}
In case you're wondering, I discussed it a bit with Dasharo community but I'm working a new ME tool to remove modules for modern boards, but this will probably take some time, especially cause I need to work on some of tools first to make extensive tests, like flashing with network with a second board remotely and powering up my board to test multiple versions against with, so I don't need to move my ass everytime I want to make a new test. The sauce will be released once I feel confident enough about it. It might end up aswell maybe being a completely waste of time, so don't get hopes too much high.
I was under the impression, at least with the Clevo boards, that the ME image is required to bring up the CPU - if this is only the case because nobody's built a tool to remove modules yet, that's pretty cool!

I'm going to assume that the "trust me bro" ME disable is indeed working if the PCI device isn't there, but the mei_me module still loads...but then again, I suspect that with my CPU and machine, where AMT isn't an option, probably has an ME image that at worst only does hardware init...and sits there as a backdoor for the authorities, maybe, idk.

So does me_cleaner still set the HAP bit even if it fails the signature check? If so I suppose I can test flashing this rom if I don't mind recovering after the fact with my pogo plug adapter...

There isn't only one ME module. For consumer boards, there's like 50ish modules, including for CSE Main and CSE Bring Up. ME is required to bring up the CPU but not all modules are necessary to bring up the CPU. In fact according to what ptsecurity researched with HAP enabled, only rbe (ROM Boot Extension), kernel, bup (Bring Up), syslib (System Library) should be kept, with not forgetting fixing aswell the CPD entries checksum. And this is what I'm trying to confirm by this. I wasn't yet able to remove all the modules, only some but it's been a bit unstable for now.

About the backdoors, well I'm not sure myself but if you look on the leaks inside the Intel ME ROMs, there is interesting features like DnX through USB (maybe JTAG) and a lot of interesting https links, even though it has probably "legitimate" purposes behind it like for AMT, PAVP. Static analysis is a bit harder on ME, ROM especially because I miss a lot of MMIOs devices addresses which I don't know about.

Yes it does, signature is related to only one partition in the ME firmware (FTPR, Fault Tolerant Partition), it's not related to the IFD where the HAP bit is set (the fist 0x1000 bytes inside the image), so you can totally ignore that message.

I'm thinking one day to take some vulnerable boards to have JTAG and try dynamic analysis on them.

By the way, having the HECI disabled doesn't necessary ensure that ME is doing nothing, it's just an interface inside Gasket as it is said on its own name.

What System76 does is just sending a command to the HECI and hoping for the best that it is "disabled".

ilikenwf commented 1 year ago

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...

XutaxKamay commented 1 year ago

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. It can be activated with through FPT tools that have the option to set both HAP and eHAP, which is up to you to find.

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.

ilikenwf commented 1 year ago

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.

XutaxKamay commented 1 year ago

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. :)

ilikenwf commented 1 year ago

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.

ilikenwf commented 1 year ago

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...

ilikenwf commented 1 year ago

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...

ilikenwf commented 1 year ago

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?

ilikenwf commented 1 year ago

And for what it's worth, my HAP bit was at 0x1DE:

DaemonOnUnix commented 1 year ago

Hello,

I'm a bit bugged. I know that you don't have a lot of sleep, and understand that. But a bit can't be equal to a value greater than 1. Where does this hexdump come from ?

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. What are you saying about an EFI version of FTP ? And can't see what you mean about the Mei_me module.

Could you explain it a bit please ?

Yours,

-- DaemonOnUnix

DaemonOnUnix commented 1 year ago

*FPT, my bad, have seen too much infra today.

-- DaemonOnUnix

XutaxKamay commented 1 year ago

https://www.youtube.com/watch?v=h_D3VFfhvs4

ilikenwf commented 1 year ago

Hello,

I'm a bit bugged. I know that you don't have a lot of sleep, and understand that. But a bit can't be equal to a value greater than 1. Where does this hexdump come from ?

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. What are you saying about an EFI version of FTP ? And can't see what you mean about the Mei_me module.

Could you explain it a bit please ?

Yours,

-- DaemonOnUnix

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: ifd.zip

mlario commented 1 year ago

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

ilikenwf commented 1 year ago

Get yourself a ch341a programmer and either a chip clip or pogoplug - then you can flash it on board.

XutaxKamay commented 1 year ago

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:
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..

mlario commented 1 year ago

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

XutaxKamay commented 1 year ago

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)

mlario commented 1 year ago

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

mlario commented 1 year ago

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:

https://github.com/MrChromebox/firmware/issues/139

corna / me_cleaner

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

396

396

396