[Guide] Disable & Remove Intel Ibex Peak ME 6.0 Ignition firmware

After reading the research done by Trammell Hudson, Nicola Corna, Federico Amedeo Izzo and other members of the open source firmware initiatives, I decided to do some tests on an ASRock P55 Extreme system which comes with Intel ME 6.0 Ignition firmware.

Ibex Peak PCH came with four different Intel ME SKUs: Ignition (144KB - 148KB), Consumer 1.5MB, Corporate 5MB Desktop and Corporate 5MB Mobile. The Ignition SKU was the most cut down as far as functionality is concerned focusing mostly on clock control & power management. It is the only SKU that does not expose an OS communication device (MEI) no matter its state or health.

Testing the Ignition SKU is interesting because it’s the only one which is designed/allowed to work without any firmware. That is because, on such Ibex Peak PCH, the ME co-processor is only used to support Ignition firmware features and nothing else. These features are four: Platform Clock Configuration (PCC), Platform Feature Configuration (PFC), Silicon Workaround Capability (SWC), & Thermal Reporting (TR). Some are only relevant/useful to OEMs to reduce factory time and money spent on part acquisition/replacement (OEM) and don’t necessarily translate to actual consumer use/benefit (USER). PCC deals with EMI management/control, power management and allows using the same firmware across many boards (OEM). PFC enables automatic setting of platform specific values based on detected hardware such PCH support for ECC memory, CPU support of onboard iGPU, supported PCI Express Graphics lane width etc (OEM). SWC can resolve some specific types of post-Production silicon issues which would otherwise require a new PCH or CPU stepping (USER). TR makes thermal and power information from CPU, GPU, RAM & PCH available to the host or EC (OEM). From these four Ignition features, only SWC is irreplaceable from other open source or not firmware solutions. PCC seems purely an OEM assistance feature and PFC as well as TR can probably be implemented in BIOS.

The Ignition firmware does not run corrupted Code or Data. When the platform starts, the ME executes from the Internal PCH ROM and checks the integrity of the Ignition Runtime partition (IGRT). If IGRT checks out, the ME loads it and uses that instead of the internal ROM in order to verify the integrity of the IGRT Data partition (FAD0). If that checks out, the ME has found proper Code & Data partitions so it executes PCC, PFC, SWC & TR before giving control to the BIOS. If the IGRT integrity check fails, the Internal ROM checks the integrity of the Factory Recovery Partition (FTPR), uses it if proper, checks the integrity of FTPR Data partition (FAD1) and if they are both ok, it executes the four Ignition features and gives control to BIOS. If IGRT Code fails and then FTPR Code partition fails, the ME cannot find proper Code & Data partitions so the platform resets and starts again with ME disabled. The same happens if IGRT checks out but both IGRT and FTPR Data partitions do not at the next stage. With Ignition disabled, the system is supposed to boot properly but without PCC (stock hard-coded PCH clocks used, no power/EMI management, no board specific config), PFC (defaults used: iGPU on, ECC on, PCIE x16), SWC and TR.

So it seems that disabling & removing the ME 6.0 Ignition firmware from the SPI chip completely is very much possible. As a baseline, meaning when the Engine firmware is operating properly, we see the following status at Intel MEInfo tool:

Capture6.PNG



The ME has loaded Runtime Code (IGRT) and Runtime Data (FAD0) partitions. The ICC is configured, any PCH/CPU silicon issues are resolved (SWC) and no TR or similar events are reported.

First, I tried Corna’s me_cleaner (no LZMA modules at Ignition SKU, only Huffman) and it worked.

Capture2.PNG


Capture3.PNG



Then I nullified/padded (0xFF) the entire 128KB ME Ignition region. That basically removes the entire contents of the ME firmware from the SPI chip. Again, it worked.

Capture1.PNG



The next step would be to remove the ME Region from the SPI image entirely and also adjust the Flash Descriptor to have the ME disabled and thus gain some space at the BIOS. So, I removed the ME base and limit from the FD and adjusted the BIOS to fill the rest of the SPI chip. For my 2MB SPI chip, that meant 0x1000 for the FD and 0x1FF000 for the BIOS. It works.

Capture5.PNG



Now for some finishing touches, I removed the ME VSCC table entries from the FD (the ME should not be able to communicate properly with the SPI) & disabled the ME SMBus. Possibly more can be done at the FD (although there might be no point anymore) by reading what certain FITC values do at Intel’s BringUp Guide for ME6 if you can find such a document online. It works and after all these tests, the system stays operational even after the 30 minute obligatory shutdown (which is not used for the Ignition SKU firmware).

Capture4.PNG



So it indeed possible to completely disable & remove the ME 6.0 Ignition firmware without any major/apparent issues with the system except those that use the power management, thermal reporting and especially silicon workarounds.

  • Note though that these Ibex Peak findings are only relevant to the Ignition SKU and not 1.5MB, 5MB DT or 5MB MB. Such a modification will not work on these three SKUs.
  • There are two types of the Ignition SKU, 6.0.x for Ibex Peak (5/34xx-series) and 6.0.50 for Cave/Coleto Creek (89xx-series) PCH. The above have not been tested on the latter PCH, only Ibex Peak. It should allow the same degree of success but, without actual tests, we cannot be certain.

Hello plutomaniac,i want to remove ME completely from my system
my computer is asus x552cl notebook
its ivy bridge based and the me firmware i use is the latest 8.1.65.1586,how can i remove it

i could not understand steps

There are no steps, this is not a guide. It’s a small observation post, like a “paper” so to speak.

You cannot completely remove ME8, the closest you can get is achieved by me_cleaner.

Read the introduction by corna and if you give it a try, post your result in the status report github issue.

I’ve added an explanation as to why Ignition was interesting for me to test when it comes to completely removing its firmware. Includes initial Ignition boot flow and usefulness, according to Intel.

Capture.PNG

Hi, thanks for info about ME removal. I read a lot about it, also on me_cleaner github discussion. It seems that removing ME on newer platform is futile and can have several impact on the system. Even after they remove most of ME partitions and keep it from 30min shutdown it cannot be 100% trusted because it still starts a code from ROM and nobody can see what ROM code do neither cannot disable it. It may be possible there’s a backdoor in ROM code to load some specific rootkit, who knows…

BTW one specific question that came in my mind - can a modern BIOS that includes ME work or even boot with HW-protected flahsrom? I mean WP# pin on the SPI flash tied to GND. I read that ME use some flash area to store some data structures so this is why dumps of ME regions with the same ME version and configuration can differ. But I don’t know when and how often. Also I know that BIOS stores some PnP/ESCD config data and user profiles to flash but it should happen only on some system change. In ancient ages there was WP jumper on some MBs would it work now? For somebody it may be important to be sure that some mallware cannot silently instal a persistent code into flash…

I don’t know the answer to your question. ME dumps are different because of the DATA (MFS/EFFS) section it has. That section is pre-configured by the OEM but is also adjusted by the ME during normal operation. It gets removed by me_cleaner and thus stock clocks and configuration are used until the ME is repaired.

I just tried to make 2 full SPI flash dumps with a power cycle between and found there are differences in ME region and BIOS region too. I have 4MB flash and ME starts at 0x1000.
ME diff ranges:
000047AD - 000047E3
00010086 - 000100A3
00013DC0 - 00013E16
BIOS ranges:
003ECD90 - 003ECE9F
003ED2C5 - 003EDCC2
It seems to me like ME is logging something. Most of the changes are from 0xFF (empty regions) to something. BTW if it would write to flash very often it may damage some sectors after a longer period as SPI flash has no any wear leveling like a SSD. Would be interesting to try what happens on write protected system.

Hi pluto… sorry to disturb u… im trying to disable intel ignition fw but i get error 26 saying no access to read fw.
And also… failed memanuf test
I can post ss here tomorrow… if u can help… tks

That is not related to the guide. You need to have read/write access to the Engine region of the SPI in order to reflash the ME firmware. I’ve explained the various (difficult) ways of during that at other threads. If you have a programmer, use that instead.

ah i see… understood… ok ok…

Hello this topic of the Ibex Peak ignition firmware is really interesting to me. I actually have a PM55 system where the ignition firmware is not launching. It says "error loading ME firmware" at BIOS boot and that message has annoyed me for a very long time. Updating the BIOS does not properly repair the ME launch and thinking the VSCC of the later BIOS does not match up with the HW of this board.

Can you detail how to dump/repair the VSCC table entries? I have access to the ME region. I have successfully extracted and reconfigured later and earlier 6 ignition firmware packages using FITC (from reading your guides). However all seem to have the same result. The MEInfoWin shows similar output to your entry and MEManufWin complains about VSCC entries.

This is not really related to this guide. Anyway, what system are we talking about? When it comes to VSCC, they are stored in the Flash Descriptor and you can see such errors only if you replaced the SPI chip with a different one. So did you do that? If you haven’t done that, I suggest you follow the [Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization on your full SPI dump or the latest full SPI/BIOS from the OEM, if provided. You need to have read/write access to the SPI/BIOS chip or use a hardware programmer.

I guess I am trying to work backwards from a disabled ignition firmware, so somewhat related =)
Yes, I believe that this has a different SPI than what the BIOS is expects. Thanks for the tips. Following your direction I checked the copies of the binaries in the update package. The 2MB Phoenix bios file does have accurate VSCC descriptors visible from FITC for four different SPI, including the one on the motherboard. But opening up the 2.3MB file (has same name with one added character) that Phlash16.exe is targeting in f.bat update, the FITC has an error processing the file (and cannot build a BIOS using that XML), but viewing the VSCC from that it is targeting a different SPI. Thus guessing the incorrect VSCC values are being passed to the SPI that is on the board and the ME stops the ignition launch shows the error and continues boot with default values.

I do not understand what process is needed to take the 2MB file (which works in FITC) to generate the 2.3MB version that Phlash16 can use. Guessing it adds some parameters for the update process to allows the sw tool phlash to unlock the SPI? I combed through the 2.3MB ver of the BIOS file with hex editor and couldn’t figure out how to “inject” the FITC built 2MB.

I think the problem would be solved if I could flash the 2MB file onto the SPI since I see accurate VSCC or somehow edit the 2.3MB file’s descriptor region and change the VSCC.

What is the model of the system that we are talking about so that I can check the OEM provided SPI/BIOS?

Second .exe link will create a folder with these two. W6702MB can be opened via FITC while W6702M is the file used by phlash, it will not accept W6702MB. Can re-create the error with WinPhlash
https://www.dell.com/support/home/us/en/…?driverid=h9dy5

Edit: Ah now I see your post about the Flash Descriptor Region. I think I’ve also located the VSCC portion of the W6702M file and will try and hex edit it.

The proper SPI image is “W6702MB.A09”. The SPI image included within the larger phlash file (“W6702M.A09”) has an older GbE firmware and various debug settings enabled in the Flash Descriptor. The VSCC tables are the same at both. However, some of those debug options could easily be the cause of you issue. So re-flash the entire SPI chip manually using “W6702MB.A09” file.

First off, thank you for your time! W6702M.A09 is the production BIOS file but it’s screwy.

I cannot flash W6702MB.A09 as Phlash.exe (Link below for WinPhlash to reproduce the error that I get in DOS) will not accept it. Says missing descriptors and errors out. W6702M.A09 is the production file that the Dell (phlash) tool puts onto the system. Command from f.bat is "phlash16 W6702M.A09 /mode=3 /bbl /c /s /exit"

It is quite strange that the production BIOS has the Read/Write settings different than the “source” W6702MB.A09 file (i.e. offset 40062h 40063h set as FF FF vs. offset 62h 63h as 0B 0A) But that explains why I had read/write access to the ME region when I tried to swap in older or newer ME ignition firmware.

What is puzzling to me is that looking at W6702M.A09 VSCC table (offset 40EF0h) it does have the proper 2009 VSCC setting for the SPI hardware on the board ( BF254A ) but the board itself reports 2019 after flash, that 2019 output is reported by MEManuf.


Side note: If I open W6702M.09 in FITC tool and check the VSCC table it lists AT26DF321 (1F4600 and settings 2015, perhaps an artifact?) I am shocked too that the source W6702MB has different Gbe firmware from what the stock dell tool places on the system.

Next Steps: I am now editing the W6702M.A09 to see if I can “force” the VSCC to be the 2009 by removing other SPI entries. I do notice that W6702M or W6702MB differ on PCH2 strappings. (W6702MB actually seems to have debug settings enabled)

WinPlash x64 link: https://www.wimsbios.com/files/flashers/…sh64-1.0.76.zip

I order to do any useful comparisons between the two SPI images you need to first manually extract the debug SPI image from W6702M.A09 by finding the Flash Descriptor offset and copying the next 0x200000 (2MB) of data. Once you do that you can load each in FITC, save the configuration xml, format it properly and comparing the results. You will then clearly see that W6702M.A09 has the FD unlocked and some ME debug settings enabled as well as an older GbE firmware.

You cannot use phlash to flash W6702MB.A09 back because that utility expects its own structure like we see at W6702M.A09. So that’s why I said that you need to manually re-flash the SPI image via Flash Programming Tool (if your FD is unlocked) or via a hardware programmer. As long as we have the proper/stock SPI image, which is W6702MB.A09, it doesn’t matter what is currently flashed, why it differs, why the phlash image includes a debug image (probably a mistake by Dell or maybe the phlash command flashes the BIOS region only which is the same) etc.

Since you say that your FD is unlocked we can fix everything manually by re-flashing the FD and ME regions via FPT. I took W6702MB.A09 and followed [Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization to clean & update the ME firmware. I also set the FD to be unlocked so that you can re-flash if required. The end result is W6702MB.A09_New SPI image. From that I extracted the FD and ME regions which can be re-flashed via FPT as follows:

fptw -desc -f fd.bin
fptw -me -f me.bin
fptw -greset

After the reboot, the ME should be operational and updated.

M15R1A09_New.rar (1.03 MB)

You rock. Yes, I found that phlash was only doing the BIOS region per decoding flags so old Gbe did not matter.

I will disassemble the system to get to the SPI and externally flash. I was dorking around with the settings using fptw and thought locking the SPI might help. Nope.

Prior to that I did fptw -DESC -D desc.bin and checked the VSCC it was set to 2009 but MeManuf still claims 2019. I tried to adjust the issue with fptw -DES -F desc_edit.bin. On reboot the ME fw complained as usual and the 2019 was reported by MeManuf. Very odd!

Alright, flashing externally is much better. Keep a backup to be sure and then flash the _New image to see if that works at least.