little foxes at the keyboards little foxes making clicky-clacky little foxes on the servers little foxes all untame there's a black hat and a white hat and a grey one and fun for everyone! and they're all making clicky-clacky and they're all in your mainframe
Mounting a LUKS encrypted physical medium is a straightforward enough process, per the man page for cryptsetup: cryptsetup open --type luks /dev/loop0 mapped-name
mount /dev/mapper/mapped-name /mnt/location Note while the man page encourages using the --type luks flag the format will typically be autodetected when omitted.
The same syntax may be used to mount a straight partition image. Things become a little more complicated however when dealing with a full disk image containing multiple partitions, as we are not able to specify partitions with the same ease that a /dev block device avails.
Those familiar with administrating Xen virtualized environs will no doubt be accustomed to using the lomount binary that comes with the distribution for gaining easy access to partitions contained in full-disk images, yet one may find one's self in a position where default repositories don't provide a simple means of installing this tool, or it might necessitate installing a full Xen implementation that may be intrusive and certainly top-heavy in storage-constrained circumstances. I encountered such a situation using a fresh installation of Kali Linux.
One may take one's chances clunkily setting up loop devices with losetup and its -o|--offset flag, but fortunately a shell-scripted drop-in has been published by Pádraig Brady at http://www.pixelbeat.org/scripts/lomount.sh: #!/bin/sh
# Mount partitions within a disk image file
# License: LGPLv2
# Author: [email protected]
# V1.0 29 Jun 2005 Initial release
# V1.1 01 Dec 2005 Handle bootable (DOS) parititons
# v1.2 25 Jan 2013 Glen Gray: Handle GPT partitions
if [ "$#" -ne "3" ]; then
echo "Usage: `basename $0` <image_filename> <partition # (1,2,...)> <mount point>" >&2
exit 1
fi
FILE=$1
PART=$2
DEST=$3
if parted --version >/dev/null 2>&1; then # Prefer as supports GPT partitions
UNITS=$(parted -s $FILE unit s print 2>/dev/null | grep " $PART " |
tr -d 's' | awk '{print $2}')
elif fdisk -v >/dev/null 2>&1; then
UNITS=$(fdisk -lu $FILE 2>/dev/null | grep "$FILE$PART " |
tr -d '*' | awk '{print $2}')
else
echo "Can't find the fdisk or parted utils. Are you root?" >&2
exit 1
fi
OFFSET=`expr 512 '*' $UNITS`
mount -o loop,offset=$OFFSET $FILE $DEST
This is an excellent, almost drop-in solution for mounting standard-issue partitions residing in disk image files, however it is not intended for dealing with encrypted volumes. As such, using it as a starting point I have made some modifications:
#!/bin/sh
# Mount encrypted partitions within a disk image file
# License: LGPLv2
# Original Author: [email protected]
# Encryption added by: karma @ https://foxpa.ws/mounting-luks-encrypted-volumes
# V1.0 29 Jun 2005 Initial release
# V1.1 01 Dec 2005 Handle bootable (DOS) parititons
# v1.2 25 Jan 2013 Glen Gray: Handle GPT partitions
# v2.0 07 Jun 2023 karma @ foxpa.ws: Modified for LUKS encrypted volumes
if [ "$#" -ne "5" ]; then
echo "Usage: `basename $0` <image_filename> <partition # (1,2,...)> </dev/loopX> <dm-name> <mount point>" >&2
echo "\n [*] Run losetup -a first to determine free loop devices (i.e. compare assigned loops to available nodes at /dev/loop[0,1,...])" >&2
echo "\t [*] Provide a user-friendly label for dm-name where the volume will be mapped to under /dev/mapper/label" >&2
echo "\n You will be interactively prompted to provide a passphrase; often this is a string of random data that has itself been gpg-encrypted with a passphrase to allow for altering the password used to authenticate without changing the so-called master passphrase which would necessitate re-encrypting the entire volume. Use gpg -d keyfile if this applies to you." >&2
echo "\n To tear down and free the loop device after umounting your volume, run: cryptsetup close dm-name before disconnecting/ejecting or otherwise removing access to the image." >&2
exit 1
fi
FILE=$1
PART=$2
LOOP=$3
NAME=$4
DEST=$5
if parted --version >/dev/null 2>&1; then # Prefer as supports GPT partitions
UNITS=$(parted -s $FILE unit s print 2>/dev/null | grep " $PART " |
tr -d 's' | awk '{print $2}')
elif fdisk -v >/dev/null 2>&1; then
UNITS=$(fdisk -lu $FILE 2>/dev/null | grep "$FILE$PART " |
tr -d '*' | awk '{print $2}')
else
echo "Can't find the fdisk or parted utils. Are you root?" >&2
exit 1
fi
OFFSET=`expr 512 '*' $UNITS`
losetup -o $OFFSET $LOOP $FILE
cryptsetup open --type luks $LOOP $NAME
mount /dev/mapper/$NAME $DEST
The most fascinating Shenzen Special I have ever held b'twixt me paws: a Samsung Galaxy S21+ Ultra - but isnt'! It's minty fresh and hot off Hung Lo Charlie's own drafting table. It's ... not so much clone... but is it anything approaching a knockoff? Time will tell, and with research aided by these preliminary photos, snippets and whatever else I post to this page in pursuit of truth, justice and the Canadian-American way!
Subdomain Takeover (SDTO) attacks are popular for their ease of exploitation and inherent severity. Essentially they take advantage of forgotten, uncommitted or mismanaged CNAME records that point from a victim domain or subdomain to another domain or subdomain which has expired and become available, or the service once located there has lapsed and been deactivated by a service provider that is still operating, who then makes the target address available for re-use, including by malicious actors. Controlling a subdomain on a target domain provides access and capabilities too numerous to list here, but they start at session hijacking (cookie stealing) and run the gamut from there.
Ideal, lapsed endpoints belonging to still-running service providers take the form of things like web hosts, cloud service providers, content delivery networks, reverse proxy services and DoS protectors, countless SaaS and free webapps that are individualized by company or organization and served up or validated at registration, periodically authenticated etc. at an address under the victim's own subdomain. This includes applications like mass mailing services, analytics platforms, ad managers, blog services, online stores and virtually anything else you can think of.
Additional details and demonstrations that I have found particularly useful and have something unique to teach you about the topic can be found at pages contained in the following curated list:
At present writing the previous list only contains links to articles with general information, be sure to check back as I begin to implement automated scanning, exploitation and begin uncovering undiscovered instances of this vulnerability all my own.
Bug bounty hunters and malicious actors alike are automatically scanning the web to uncover easy targets. The biggest part of doing this successfully is maintaining a list of popular products and service endpoints to scan for (or leverage legitimately for the benefit of your own entrepreneurial endeavors... just... don't leave the keys in the ignition when you're done with them...). In particular we want to focus on providers that are squatting or parking a domain but will allow us to purchase the whole domain outright OR SaaS/web applications and hosting providers that: 1) are still operational 2) will allow previously registered URLs to be registered again in the same location 3) provide an easy way for us to upload or manipulate content at that location. As usual, this is a living list I am maintaining for personal use and sharing with you; you can expect to see continuous updates into the future so check back now and then and be sure to update your copy if you end up using it for anything. It would also be great to hear from you in the Telegram group.
This post serves as a living list of free, online banking service options that are available to Canadians (lacking permanent residency, a green card or mailbox, permanent or forwarding address in the United States). This includes banks that provide chequing/savings accounts, prepaid credit cards, taxable and non-taxable investment products and so on. As offerings are constantly changing and the so-called "FinTech" (Financial Technology, mainly referring to the recent spate of emerging online-only self-serve banks) industry is evolving rapidly it is entirely likely that you will find some entries no longer offer what they were originally listed for, some no longer exist at all (or have been acquired by/merged with another organization). Please drop by the Telegram group to let me know if this is the case for you or to suggest an option not shown.
Full Service Banks
These banks provide at least a chequing account, often a savings account and a handful of other meat-and-potatoes products like credit cards, mortgages and TFSAs (Tax Free Savings Account, more flexible than an RRSP which is similar in purpose to a 401k).
Reloadable Credit Cards
Reloadable credit card accounts provide access to credit card payment methods with most merchants that accept credit cards - however their nature as a "reloadable" or cash-secured card (where money is provided to an account that maintains a north-of-zero balance) is detected by and not suitable for reserving vehicle rentals etc. This can sometimes be finessed by providing a large cash deposit, depending on the vendor. Generally speaking these cards do not offer the same level of anonymity as traditional prepaid credit cards but have convenient features like the ability to accept deposits by Interac e-transfer and may include perks like discounts at certain restaurants, rewards or reward points and even cashback.
KohoReferral bonus! We both get $20 after you activate your card, e-transfer any amount to load your balance then make a purchase of $5 or more
American Banks
Some American banks will open accounts or sell certain products directly to Canadian citizens lacking a US permanent address within the United States.
...or to be hysterical: Brainstorming Methods to Defeat the Spying Rootkit Backdoor Intel Hid in Your Chipset.
Then again, is that hysterical or is it accurate? Maybe if it hadn't been locally exploited... then remote exploited... again and again... even on machines that Intel doesn't commercially support remote management functionality on... and if we can break into it, what of those invested in it? Literally invested: state actors, the moneyed folk... And then why do even some technically gifted users, in the year 2022 - a decade after it was introduced - flip out when they find out about the little computer inside their computer that has full control and never turns off? One might think with a feature that is so powerful, has so much potential, that clearly cost a fortune to develop and has downright creepy ubiquity - if not enforced implementation - that Intel would do more than very vaguely, extremely quietly market it to anyone but the highest volume IT department executives.
This functionality, "Out of Band Management" - and especially ipKVM (the ability to remotely intercept and take over a system's keyboard, video and mouse) is typically one of the prime selling points on a server. All the remote provisioning and remote wiping features and batch management et cetera make all the sense in the world for business-owned devices that are managed by the thousands in a corporate context. When I'm shopping for a datacentre or a business I don't just want those features, I want the good stuff. I do not want it in my personal, home-use desktops and laptops!. Not even a trace of it - I invoke the time weathered maxim: one vendor's trace is an adversary's vector. So why does it need to be so tightly integrated - even on platforms its full functionality is not sold on? It strikes one as something akin to furnishing a shotgun to protect the cabin from black bears: logical and useful - were we not situated instead in a Floridian condo - and then keeping it loaded and by the door so any intruder that fancies their way in might find themselves graciously equipped, much to one's disadvantage.
Call me crazy, but I don't trust it. I don't trust it when it tells me it's off - nevermind that: I know it's not off! And I sure as hell don't trust that the attack surface would be nullified even if it was! Can't just take it out - Intel's made damn sure that its tentacles are wrapped around the system's spinal cord and if you have the audacity to try to assert ownership over your own hardware you better believe it will brick. But not all is lost. As long as there are hackers there is a way. Bless the eternal arms race, that gilded cat-and mouse game of ages: all well and good, the only problem is that getting rid of ME is not a dance for the feint of heart. Indeed, the reprehensible nature of the ordeal is brought into focus in that turning the tables is, at least at present, not something grandma can deftly achieve. Unless grannie got some rather spry game. In which case, props grannie. Big ph33r.
I have been planning a video to kick off a new endeavour for over two years now regarding hardware-based procedures for modifying various BIOS ROMs, in particular with the aim of disabling Intel's Management Engine if not entirely replacing the stock, proprietary BIOS code with open source alternatives like coreboot. Obviously this is a very hardware-specific kind of operation further complicated by the now very advanced age and breadth of the whole integrated Intel OOB management platform.
Consequentially there are a lot of relevant and plain interesting things to say on the topic, every time I come up against modifying the BIOS of a new machine I end up learning something worth remembering. Therein lays the problem: there are dozens of articles, videos - even my own hand-written notes - that I have to rediscover every time and if I am to make a comprehensive video (or video series as seems the more likely route at this point) along with complimentary articles on this site then I need to start collecting this information in a centralized, memorable and easy to update place. Which is exactly what I have recently started doing here, on this site foxpa.ws: my personal administrative blog and note compendium, in pages like Windows Software and various other articles I have taken to calling "living lists". I figure it makes sense to start centralizing my notes on ME here since it's turned into such a big part of my personal research and this is where my more refined articles are going to go anyway - if readers of those want to chew on some "bonus content" then the utility of publishing all this raw, rough-draft info is merited.
Being a living list, if this topic interests you please check back from time to time as I add new clippings; I will also be sure to link to the articles and, hopefully, videos I have planned as I produce them as well.
In addition to links, scrap and original notes I've included some blog and forum posts where the content is so dense and important to the topic that to include only the pertinet parts would essentially be the same as including the entire thing. Blog and forum posts in particular have a way of moving at best and disappearing at worst over time and those things that I've chosen to include are too important to me to risk their being lost over the ages. Case in point, much of this content comes in the form of posts to the win-raid forum which very nearly closed at the end of 2021, fortunately it was saved by a migration to and sponsorship by level1techs.com. That being said, any content that has been copied from another source has - as always on this site - been approptiately credited and linked to the original. In fact I urge you to go to the original source instead of reading the content on this site, wherever that remains possible, not least becasue the forum posts I've inlcuded in particular are frequently updated by their authors and I do not intent to keep the data at this location updated in step. It also makes sense to go there so you have an opportunity to see the following comments/posts including questions you might ask - assuming you don't take advantage of the opportunity to interact with the original authors yourself. I also include the date of the content as it was frozen here, where that is relevant, so you are better able to determine if the version archived here has become too outdated for your purposes.
You are welcome to join us in the foxpa.ws discussion Telegram Group if you would like to talk about or ask questions regarding vPro, AMT, ME its implications and removal/disabling - even possibly get help neutering it on your own system.
Background I uploaded a bunch of the conventional/oem tools to the foxpa.ws downloads telegram channel. This list links to those downloads and other OEM resources.
foxpa.ws downloads (link to official download (usually) contained in post, be sure to check that for latest version - these uploads have been 'stuck in time' like flies in amber...):
This looks like a good resource I look forward to putting some time into snooping around later: https://www.basicinputoutput.com.
Since you're forced to have all the guts for AMT/vPro maybe you want to take this the opposite direction and enable vPro for, say, ipKVM functionality? This boffin details how they manually update Optiplex BIOSes with fresh video ROMs, microcodes (especially important given all the vendors leaving early model systems unpatched for SPECTRE and MELTDOWN) and the missing vPro libraries at https://github.com/zearp/OptiHack/blob/master/text/BIOS_STUFF.md. Jolly good.
Interacting with the SPI flash chip though software requires a compatible flashing tool; where possible this is preferred over using a hardware flasher (buspirate etc) because it's more reliable, you don't need an ISP clip for each package type and often the chips are hard to reach/there are things blocking getting a solid connection. Most people recommend using the Intel Flash Programming Tool (fpt.exe, fptw64.exe) on Windows which is shipped as part of the Intel Converged Security Management Engine System Tools package. Unfortunately this isn't made available from the source to the public. You have a few options, one of them is:
Another option is to use the AMI AFU which is provided by AMI free of charge (along with some other neat tools) at: https://www.ami.com/bios-uefi-utilities/
I have used the Flash Descriptor Override jumper to disable ME on a few machines, and seen it on many more.
Oi! There's one right now!
Most of these have been Lenovo Thinkstations and HP business class workstations but it also pops up almost randomly, as on this server motherboard where it is even covered in the official user manual (though short on details) alongside a much more rare jumper that, using obvious deduction, clears the ME.AMT configuration:
The reason I stopped using this as a method to disable ME - though it certainly seems reliable (so long as it is left shorted permanently...) - is that, as you would imagine with a name like Flash Descriptor Override, it is often said to make that section (sometimes more) of your NVRAM (the BIOS' SPI flash where the firmware is stored) writeable.
It buggered ME up good enough that my Bitlocker is right pissed, mate.
While we intend use that power for good, i.e. (under idyllic circumstances) with flashrom to reprogram our BIOS after having me_cleaned it without having to go through all the ballache of setting up an SPI flasher and connect directly to the SPI chip(s, sometimes!) perhaps we don't want to leave god-knows-what open to any potential malicious actors or software.
Not a lot of room for an SPI clip... if I even have one for 16 pin chips....
That being said, usually when people do this and then go to try flashing their new ROM they find they're obstructed from writing anyway - which leads me to belive it's still necessary to update the permissions in the UEFI partition meta section (forgive me, the correct title escapes me at the moment :s), at the very least.
It is recommended that the Intel® ME be disabled when you are programming the
Intel® ME region. Non Intel® Management Engine Ignition firmware performs regular
writes/erases to the Intel® ME region. Therefore some bits may be changed after
programming. Please note that not all of these options will be optimal for your
manufacturing process.
Any method of programming SPI flash where the system is not powered will
not result in any interference from Intel® Management Engine FW. The
following methods are for non - Intel® ME Ignition FW.
Program via In Circuit Test – System is not fully powered here.
Program via external flash buring solution.
Disable the Intel® ME through the BIOS/MEBX before programming fixed offset
variables (FOV) into the non-volatile memory area, or before any operation that
depends on the base address for fixed variable offsets remaining constant.
Assert HDA_SDO low (Flash Descriptor Override Jumper) on the rising edge of PWROK.
Note: this is only valid as long as you do not specifically disable this functionality in
fixed offset variable.
With Intel® ME Ignition FW, there is no need to disable Intel® ME, as Intel® ME does not
perform writes or erases.
The ATX specification defines the Power-Good signal as a +5-volt (V) signal generated in the power supply when it has passed its internal self-tests and the outputs have stabilized. This normally takes between 0.1 and 0.5 seconds after the power supply is switched on. The signal is then sent to the motherboard, where it is received by the processor timer chip that controls the reset line to the processor.
The ATX specification requires that the power-good signal ("PWR_OK") go high no sooner than 100 ms after the power rails have stabilized, and remain high for 16 ms after loss of AC power, and fall (to less than 0.4 V) at least 1 ms before the power rails fall out of specification (to 95% of their nominal value).
Cheaper and/or lower quality power supplies do not follow the ATX specification of a separate monitoring circuit; they instead wire the power good output to one of the 5 V lines. This means the processor will never reset given bad power unless the 5 V line drops low enough to turn off the trigger, which could be too low for proper operation.
From this I draw the following conclusions:
Power should be disconnected from the system completely before shorting the jumper; if the system was only powered down be sure to physically disconnect the mains for a reasonable interval so the ME goes down. Being an OOB management embedded parallel system is powered on as long as there is power supplied regardless of the primary system's status.
It should be OK to leave the jumper connected after the PWR_OK signal has been transmitted i.e. while the system is running but it might be interesting to see if anything changes if it is removed before manipulating the SPI flash through software based methods.
Background: Setting up an HP Compaq 8300 Elite SFF (Small Form Factor) to be my new "Media PC" as I have been using a core2duo, haltingly, as my main workstation while I am mired in bullshit before working on the hot new i7 I bought myself for christmas... 7 months ago... which is supposed to be the subject of my first video on me_cleaning...
Check out the gorgeous photos Paul Murana took for that article (sorry for re-hosting them here Paul but I can't let anything happen to them until I've taken my own (UPDATE: OK you showed me yours. Fair is fair, I showed you mine... in the section immediately above! ^)):
...The HP 8300 motherboard has a similar function called FDO (Flash Descriptor Override) ... Putting a jumper on to these pins allows the Intel Management Tools to fully read the BIOS, but the Intel Flash Programming Tool (fpt.exe) is not able to write back to it...
...a top down view of the HP 8300 Elite Motherboard, with an arrow pointing at the BIOS Chip
...a close-up of the BIOS chip, which is a 16Mb Winbond W25Q128BVFG ... Note: PIN 1 on the BIOS chip is identified by a small circle above the PIN
I attached the 16-Pin chip quite easily once the RAM clip was snapped off
This guide is relevant to those who need to understand what the Intel Flash Descriptor is, how its SPI Region Read/Write Access Permissions work, how to check its Locked/Unlocked status and what methods are available to unlock it for system firmware repair and/or updating. In this guide, the term "system" means an individual user machine whereas "model" refers to all those "systems" released by the OEM/ODM.
A. About Intel Flash Descriptor
Every system stores its firmware at one or more SPI chips. The SPI firmware image of Intel based systems consists of various regions such as Flash Descriptor, (Management/Trusted Execution) Engine, Gigabit Ethernet, BIOS/UEFI and so on. Although the SPI image can be commonly referred to as "BIOS" or "UEFI", it is very important to note that it is not technically the same, as the BIOS/UEFI is only one of its regions. This guide will focus on its first region, the Flash Descriptor.
The Intel Flash Descriptor (FD) is a data structure that is programmed on the SPI flash chip on all Intel based platforms. It contains information such as space allocated for each region of the flash image, read-write permissions for each region, reserved space for vendor-specific data, chipset configuration parameters and more. The fixed size of the Flash Descriptor is 4 KB (0x1000) and, depending on platform generation, roughly consists of these sections:
Header: Consists of a 0x16 sized Reset Vector and a 0x4 sized Signature tag 0x5AA5F00F.
Map: Pointers to all the descriptor sections as well as the size of each.
Component: Information about the number & density of all components, read, write and erase frequencies as well as invalid instructions.
Region: Defines the offsets & sizes of all available regions which are Flash Descriptor (FD), BIOS, Management Engine (Engine), Gigabit Ethernet (GbE), Platform Data (PDR), Device Expansion 1, Secondary BIOS, CPU Microcode, Embedded Controller (EC), Device Expansion 2, Innovation Engine, 10 Gigabit Ethernet 1, 10 Gigabit Ethernet 2, Reserved 1, Reserved 2 and Platform Trust Technology (PTT).
Master: Contains the hardware security settings for the flash, granting read/write permissions for each region and identifying each master.
CPU Complex Soft Strap: Contains Processor configurable parameters.
ROM-Bypass Size: Stores the Engine firmware regions’ debug partition size.
Reserved: For future use or FD revisions.
VSCC Table: Holds the JEDEC ID and the Engine VSCC information for all the SPI Flash chip(s) supported by the SPI image.
Upper Map: Determines the length and base address of the Engine VSCC Table.
OEM Section: Reserved for use by the OEM/ODM and 0x100 in size.
Older platforms used the (community-named) Flash Descriptor v1 which, among others differences, could support up to 8 SPI regions. More modern platforms (>= 100-series or APL) utilize Flash Descriptor v2-3 which can support up to 16 SPI regions.
B. Read/Write Access Permissions
The Flash Descriptor Region Read & Write Access Permissions are found at its Master section. Each FD Permission Access Entry is 0x4 sized and in Little Endian order (each byte read from right to left). At FD v1/v2 Entries, only the first two/three bytes are used respectively, with the rest remaining unused. The first value is the Write access and the second is the Read access. Each Read and/or Write bit signifies that particular partitions’ access to the other ones. Take for example a hypothetical FD v1 region "E" which has these Read/Write permissions to the other 7 regions:
In bits, "Yes" is signified by 1 and "No" as 0. So, region Es’ Write equals to 10101100 = 0xAC whereas Es’ Read equals to 10111111 = 0xBF. Since Write proceeds Read value and only the first two bytes are used at FD v1, the final Access Permissions Entry for the hypothetical Region E is 0xACBF0000.
Thus, if you want to enable full & unsecured read/write access at the Flash Descriptor for all important regions (CPU/BIOS, Engine, GbE, EC), you must set them to 0xFF for FD v1 or 0xFFF for FD v2-3 as follows:
C. Security vs Serviceability
The information stored in the Flash Descriptor can normally only be written during the manufacturing process as its read/write permissions should be set to Read only when the system leaves the factory. That is the Intel recommended practice to improve the platforms’ security by not allowing remote or OS-based attacks to the systems’ SPI firmware. However, that does not allow to repair the SPI firmware via software solutions in case something is wrong. This guide will focus on how to unlock the Flash Descriptor in order to temporarily allow read/write access to its regions.
When it comes to the most important SPI image regions (FD, GbE, Engine & BIOS/UEFI), the Flash Descriptor read/write access permissions recommendation by Intel is to always keep the Flash Descriptor itself, the Gigabit Ethernet as well as Engine CS(ME)/CS(TXE)/CS(SPS) firmware locked, for security purposes. Notice that BIOS/UEFI is not locked by the Flash Descriptor and thus OEMs are responsible for implementing BIOS-specific read/write restrictions such as Protected Range Registers and so on. That means that the Flash Descriptor is not responsible for any read/write restrictions set at the BIOS/UEFI region of the SPI chip, so the FD-related methods below will not be of any assistance in such cases.
It is worth noting that users who want to service or manually update their system firmware, must pay attention to not accidentally lock an already unlocked Flash Descriptor when updating or re-flashing the SPI/BIOS image either manually or from the official OEM/ODM package. If your FD is unlocked and you flash a SPI/BIOS update with its FD Region set to locked, the old FD locks will be replaced by the new and result in an updated system but with now locked FD read/write access configuration. However, the opposite does not apply for obvious security reasons. Meaning, if your FD is currently locked, you cannot re-flash it with one which is unlocked in order to unlock read/write access to the SPI chip regions.
D. Check Locked/Unlocked Status
To check if your SPI chips’ Flash Descriptor is locked or unlocked, you can simply try to dump its contents via software-based general purpose SPI flashers such as AMI AFU, Intel Flash Programming Tool, Flashrom etc. For Intel systems, it is recommended to use Intel’s Flash Programming Tool from the Engine CS(ME)/CS(TXE) System Tool packages by running the command "fpt -d spi.bin". If it completes successfully, by dumping the entire contents of the SPI chip, your FD is unlocked. However, if you encounter any CPU/BIOS Access or similar errors, your FD is locked for system security purposes, as per Intel recommendations.
Note: If you encounter any BIOS related errors while trying to dump the system’s SPI chip, relating to Protected Range Registers or similar, then your FD might still be unlocked but certain OEM/ODM BIOS protections do not allow you to dump that specific region, which is protected on its own and not FD-related. In such cases, try to dump the individual SPI regions that you want to update/service/re-flash only and look for any access errors there. For example "fpt -me -d me.bin" for Engine region, "fpt -desc -d desc.bin" for FD etc.
E. Unlock Methods for SPI Servicing
E1. HDA_SDO/GPIO33 (a.k.a. "Pinmod")
The official Intel method to unlock the Flash Descriptor on the field is commonly called "pinmod" and requires asserting HDA_SDO HIGH (Voltage/3.3V) during the rising edge of PWROK. To do that, you need to find your audio chip (HDA) at the motherboard and short two pins while the system starts.
To short the two pins, you need to use a small electrical conductor such as jumper, wire, paperclip, tweezers or similar. The pins are SDATA_OUT (or SDO) and DVDD (3.3V). For Realtek audio chips, which are the most common, these two pins are usually 1 & 5, starting from the dot/mark and moving counter clock-wise.
To perform the HDA_SDO/"pinmod" method, you need to follow these steps:
Shutdown the system completely (S5 power state)
Locate the two HDA pins and start shorting them
Keep shorting the pins and power on the system
Once the BIOS/OS starts to load, stop shorting
The Flash Descriptor should now be unlocked
Note 1: The HDA_SDO/"pinmod" method is temporary and valid only until the next system reboot. You will otherwise need to perform it again.
Note 2: You should always verify the location of the SDATA_OUT and DVDD pins on your own audio chip, especially if it is not from Realtek, by finding the manufacturers’ datasheet and searching for the chips’ pinout diagram. Since finding Realtek datasheets is not always easy/possible, you can try the HDA_SDO/"pinmod" using the 1 & 5 rule of thumb. For other manufacturers (VIA, IDT etc), it is highly unlikely that pins 1 & 5 will work so try to find a datasheet. Usually, even datasheets from similar audio chip models will do just fine.
Note 3: During the HDA_SDO/"pinmod" state, depending on OEM/ODM configuration, some side-effects may be seen such as fan speed at 100%, no audio output, no Intel(R) Management Engine or Intel(R) Trusted Execution Engine driver at Device Manager and so on. These are all normal and will be restored to default after the HDA_SDO/"pinmod" state is over.
Note 4: Older platforms before 2011 (<= 5-series), did not use the HDA_SDO pin but required instead to assert GPIO33 LOW (Ground/GND) during the rising edge of PWROK. To do that, you need to find your motherboards’ GPIO33 pin location by looking at its OEM/ODM manual or service schematics and short two pins while the system starts, GPIO33 & GND.
Note 5: All modern audio chip/general purpose IO pins are usually very small so shorting two of them requires precision, steadiness and thus the use of thin/small electrical conductors. You may not succeed right away so keep trying. Always be extremely careful when shorting the pins because you may end up "frying" the audio chip of your motherboard otherwise.
E2. Motherboard Jumper/Switch
Some motherboard vendors implement certain jumpers or switches which unlock the Flash Descriptor for system maintenance/servicing purposes. Depending on the OEMs’/ODMs’ implementation, these may unlock the entire SPI chip (FD + Engine + BIOS) or just the BIOS region for read/write access. You need to consult your motherboards’ manual or, in absence of that, the motherboard itself and find anything related to "Service Mode", "ME/TXE/SPS Unlock", "FD Unlock", "FD Override", "ME/TXE/SPS Service", "Manufacturing Mode" or similar. You need to set the jumper/switch while the system is shut down and at the next power on, the FD and/or BIOS regions should be unlocked.
Note 1: Unlike HDA_SDO/"pinmod", this method will work as long as the jumper/switch is set to enable read/write access to the FD. Remember to set it back once the system is repaired.
Note 2: During the enabled jumper/switch state, depending on OEM/ODM configuration, some side-effects may be seen such as fan speed at 100%, no audio output, no Intel(R) Management Engine or Intel(R) Trusted Execution Engine driver at Device Manager and so on. These are all normal and will be restored to default after the jumper/switch is set back to its default setting.
E3. OEM/ODM Servicing Features
Most system and/or motherboard vendors implement certain technologies which are meant to update or re-flash the systems’ firmware, either to improve or service it. Depending on the OEMs’/ODMs’ implementation, these may be able to automatically unlock the FD temporarily in order to initiate an update before locking it back again when they’re done (MSI M-Flash). They may be able to use a secondary/failsafe SPI chip which copies its contents to the primary/main one in case corruption is discovered on the latter (Gigabyte Dual BIOS). Other implementations however may only deal with specific regions of the SPI chip, mainly the BIOS, so they don’t unlock and are thus unable to repair the FD and/or Engine regions (ASUS BIOS Flashback, Samsung). Since there are many OEMs/ODMs and each one has their own system firmware recovery methods and requirements, depending on platform generation as well, you need to consult your systems’ or motherboards’ manual.
Note: A lot of "weak" OEM/ODM implementations are forced to respect the Flash Descriptor locks so they may not actually re-flash the usually locked FD or Engine regions despite appearances. Other "stronger" OEM/ODM implementations tend to use hidden BIOS options or Embedded Controller (EC) commands to temporarily unlock the FD for one boot, update/re-flash the firmware and then boot back up to a secure state in which SPI read/write access is blocked.
E4. OEM/ODM Servicing Utilities
Some system and/or motherboard vendors use certain factory floor servicing tools which are capable of unlocking or altering various aspects of a system. These are commonly used both during initial manufacturing and customer-requested repairing. In some cases, either by accident or intentionally (required for the provided update), these OEMs/ODMs leave those tools within their official end-user SPI/BIOS updates. You can thus use them to potentially unlock the Flash Descriptor locks and repair/update your Engine firmware or any other FD locked regions which might require servicing, such as the FD itself or GbE. So pay attention to the included files in your OEMs’/ODMs’ SPI/BIOS official update package for anything that might be capable of unlocking restricted access to the FD, Engine (ME/TXE/SPS), BIOS or similar. Some assumed logical tool names to look for are "ME/TXE/SPS Disable", "ME/TXE/SPS Unlock", "ME Set", "ME ON OFF", "DIS ME/TXE/SPS", "Boot Mode", "BIOS Unlock", "ME/TXE/SPS Jumper", "ME/TXE/SPS Override" and so on.
Note: Be careful when using such OEM/ODM servicing tools because they might not work with all models of a certain manufacturer’s product line/generation, even if the models are similar. This is especially important when said tools modify certain values at the EC firmware in order to unlock the FD. It is always recommended to use the tools provided with your own system’s SPI/BIOS update, if they are available of course.
E5. OEM/ODM BIOS-UEFI Options
Some motherboard vendors allow certain BIOS options to be changed which unlock the Flash Descriptor for system maintenance/servicing purposes. Depending on the OEMs’/ODMs’ implementation, these may unlock, for read/write access, the Engine region of the SPI chip only or all regions (FD + Engine + BIOS). Generally, the former is much more common that the latter. You need to consult your motherboards’ manual or, in absence of that, the BIOS itself and find anything related to "Me FW Image Re-Flash", "ME/TXE Disable", "HMRFPO", "Disable SPI/BIOS Protection" or similar. You need to set the option and after a restart to apply settings, the FD and/or Engine regions should be unlocked.
Note 1: Most manufacturers hide these options for security purposes but they can sometimes be shown either by hitting a special hotkey within the BIOS to enable a secret servicing menu (Acer), by powering on the system with certain keys/buttons pressed (HP) etc. Since this is highly OEM/ODM dependent, manual research on your manufacturer and/or model is required. So look around the web to find clues or try other methods.
Note 2: If a BIOS option enables read/write access to the Engine region of the SPI chip only, then you can repair its firmware but you cannot re-flash the FD or anything else that is not covered by the settings’ effect.
Note 3: Unlike HDA_SDO/"pinmod", this method will work as long as the BIOS option is set to enable read/write access to the FD and/or Engine region. Remember to set it back once the system is repaired.
Note 4: While the BIOS option is set, depending on OEM/ODM configuration, some side-effects may be seen such as fan speed at 100%, no audio output, no Intel(R) Management Engine or Intel(R) Trusted Execution Engine driver at Device Manager and so on. These are all normal and will be restored to default after the BIOS option is set back to its default value.
E6. OEM/ODM Hidden BIOS-UEFI Options
As mentioned above, various OEMs/ODMs allow certain BIOS options to be changed in order to unlock the SPI chip or at least the Engine region. However, for security purposes, most of them prefer to hide these options instead. On some cases, it may be possible to trigger these options by manually modifying the NVRAM/settings of the BIOS. The most basic requirement to try this method is for your BIOS/UEFI to support booting into an EFI environment to use its shell (command prompt). Usually, systems from 2012+ should be capable of booting into an EFI shell. Then, you need to download the latest UEFITool, IFR Extractor LS and attached "Setup EFI Shell". The goal is to find where a desired hidden BIOS option is located at the NVRAM/settings area of the BIOS and manually trigger it. To do that, you need to follow these steps:
Download the same version SPI/BIOS image from your manufacturer or dump your own.
Open the downloaded/dumped SPI/BIOS image in UEFITool and search for "Setup" string with Unicode option selected.
At the results window, select one-by-one only those that are located in "UI" (User Interface) sections until you find the DXE driver named "Setup".
Now you need to right click and "Extract [the] body" of the Setup DXE driver. Usually you need to extract the body of the "PE32 image section" but sometimes you may need the body of the entire "Setup" DXE driver or some sort of "Freeform subtype GUID" instead. Every BIOS can be different so you may need to experiment on your own.
Open the extracted file in IFR Extractor LS and you should see the Protocol change to "UEFI" in green letters. If it remains at "Unknown" in red letters, you may need to extract a different body or you may have found a wrong "Setup" DXE driver. Then Extract the IFR and save it as a text file.
Open the text file and look for any BIOS option which might be interesting such as "Me FW Image Re-Flash", "ME Disable", "HMRFPO", "Lock" etc.
Once you locate it, note down its "VarOffset" next to "VarStoreInfo" field which should be a hexadecimal number such as 0x3E, 0x6A7 and so on. You’ll also probably be able to see that the option is set by "default" to a non-desirable state. In this case, "Me FW Image Re-Flash" is set to "Disabled" by default but we want to "Enable" it temporarily. Note down the Enabled/Disabled "Value" of that BIOS option as well, usually 0x1 and 0x0 respectively.
Copy the content of the EFI Shell archive, a single "efi" folder, to the root of a USB drive and boot from it when the system starts. You should reach an EFI Shell prompt.
At the EFI Shell, run "setup_var 0x*** 0x^^" command, where *** = BIOS option "VarOffset" and ^^ = desired Enabled/Disabled "Value". In this example, we run "setup_var 0x3E 0x01". It should compete successfully.
You now need to manually/forcefully reboot (Ctrl+Alt+Del) or reset the system and depending on the BIOS options’ effect, you should now have FD and/or Engine region read/write access.
Note 1: This method is highly dependent on a lot of factors and is thus not recommended unless you can recover from NVRAM corruption via a programmer or OEM/ODM emergency BIOS recovery implementations. Some of those factors are listed below, in no particular order. The hidden BIOS option may not actually work because the OEM/ODM never intended it to do so or never tested it. The OEM/ODM may have locked the NVRAM/settings so that they cannot be modified manually, for security purposes. After manually/forcefully restarting/resetting the system, it is possible for the BIOS to be set in such a way as to automatically re-assign any hidden (none user accessible) options to default, thus restoring the value you just tried to change. The altered setup variable may not necessarily correspond to what you saw at the IFR text file which may cause unexpected behavior in case something else ends up being modified by accident. The BIOS may refuse to boot if an unsanctioned NVRAM modification is detected, thus leaving the user with a soft-brick.
Note 2: The same method can be followed in order to disable some OEM/ODM BIOS Locks or Protected Range Registers by looking for "BIOS Lock" or similar hidden BIOS options at the extracted IFR text file from the "Setup" DXE driver. Since the BIOS region is not locked by the Flash Descriptor and thus not relevant to it, any BIOS lock related questions are out of scope for this thread. Instead, you can ask for help at BIOS related sub-forums or threads.
E7. Hardware SPI Programmer
The easiest, fastest and safest (when something goes wrong) method to bypass the Flash Descriptor read/write access locks is to use a hardware programmer to reprogram the entire SPI chip. This method requires more advanced users who own and know how to use a programmer. This can be done either by removing a socketed/removable SPI chip (not common) or directly on the motherboard (may not always work) or by de-soldering, programming and then re-soldering the chip back. If you want to buy a hardware programmer, you can get the job done even with ones which cost around 5$ (CH341A, Raspberry Pi etc).
Note 1: Since the FD locks are implemented in software, they cannot block hardware programmer re-flashing but only software-based general purpose SPI flashers such as AMI AFU, Intel Flash Programming Tool, Flashrom etc.
Note 2: If the SPI chip is socketed or you have re-soldering tools & knowledge, the programmer by itself is enough. If you plan to try SPI chip re-flashing while it is still soldered to the motherboard, you’ll also need a clip and maybe a more expensive programmer with enough output current to power the entire motherboard and thus read/write the contents of the chip.
Note 3: Programmer, soldering or wiring related questions are out of scope for this thread. Instead, you can ask for help at programmer related threads such as this or this. Setup_EFI_Shell.rar (651 KB)
Legitimate reasons to be cheerful why would you want to remove Intel Management Engine (I’m sorry I don’t have guides in respect of AMD firmware but there is a hint or rumour that AMD may go open-source possibly?) I have written a companion basic Rtf Readme file to help in the removal of IME for those who want to print off instructions. Naturally if there are any errors let me know please? This file is attributed to the link below in Bold DIY: Disabling Intel ME ‘Backdoor’ on your Computer attachment.
Why would you want to remove IME?
1) Its an unnecessary vulnerability (From many sources or agent provocateurs)
2) Intel don’t tell you its there
3) Intel don’t fully explain what it does
4) They don’t give you an official way to shut it off (unless you are the NSA)
5) And probably the biggest reason is to make your PC as secure as you can from exploits running below or behind your OS.
WARNING - Please be advised that undertaking any of these procedures “Could” result in damage to your PC. “If” you are an ineXperienced PC user, you do NOT understand are “Confused” in any way about any aspect of the information below, or you are the kind of person that takes short cuts & refuses to read manuals DO NOT ATTEMPT THIS Instead find either a suitably competent person, pay a competent third party or if you have the right financial resources Purchase a new PC from a PC Vendor. You will need to decide the best/least path of resistance to undertake these procedures to achieve the best results for yourself. The worst that could happen is that you could render your PC unusable but IF you strictly follow the guidelines and make a suitable backup of your UEFI/Bios you will be in a favourable position to make an appropriate recovery should the effluent hit the fan. It’s a good idea to also visit your PC manufacturers Website before undertaking these procedures and obtain the current and/or updated firmware flash for extra belt & braces backup reassurance. You are of course going to need to establish what UEFI/Bios make and model version you have & make sure the relevant build number and whether your firmware is consumer or corporate related in nature. I’m only stating this because you may have acquired a second hand PC that may have been supplied from a corporate source rather than a consumer PC. Trust me there is a difference & it will become relevant to you, if this is the case.
There are essentially two (2No) ways of disabling IME to date, one is to use the NSA Kill Switch which is undertaken in two ways dependent on your firmware build . Whether or not you believe this switch could be over-ridden or re-activated is for you to decide? I think also the NSA would have procedures that would allow them to re-activate IME easily. I think also “If” I worked for the NSA I wouldn’t rely only on a kill switch without knowing the complete Architecture of the Intel AMD CPU/Southbrige but that is just me speculating. I think also the NSA would have their own procedures that would allow them to re-activate IME after-all a light switch can be either On or Off dependent on the person in the driver seat, the infra-structure behind the switch will remain in the same state, again second guessing.
1. Watch these videos first to gain an appreciation of the potential threat level of IME It’s quite good in explanation but the presentation is by a senior Google
employee so make of it what you will. I liked it for its content & understandable explanations
Okay heres the U-tube help-me on how to undertake the removal/neutering of Intel Management Agent if you are concerned about it’s Potential backdoor capabilities:
Here are some useful utils that you can you to diagnose whether your IME is at risk, what your IME version is etc
a) This site has useful utils to diagnose which version of IME you have like Plutomaniac’s ME-analyzer couldn’t get it to work with my XP OS (Kernel32.dll error) but no doubt useful for those with Vista & above.
b) For XP users HWinfo (I use the portable version no interlacing with the registry) here’s how install progey where-ever. Dbl click on HWINFOPortable.exe, leave sensors-only summary-only un-ticked depress <RUN> button let it do its thing examining then close System summary which will close both windows open System summary and Active clock. Then within the remaining window HWiNFO whatever build window click on LH window plus sign Expand “+” aligned to “Motherboard” which will open 3 things, select Intel ME (Dbl click it which will open the right hand pane window with “viola” "Intel Manageability Engine Features, build etc then scroll down to "ME Firmware platform type & make a note of:
Platform Target Market Type: Corporate or what ever
Host ME Region Flash Protection Override (HMRFPO) Status: Locked
c) Another useful tool is CrystalDMI.zip google it you will find it give a print out of a lot of useful info for flashing bios etc
d) Another useful tool is Universal BIOS Backup ToolKit 2.0.zip to make a backup of your BIOS etc however a word of caution here how do you know that this tool has made a successful backup until you actually test it. It has been reported that it is not 100% reliable and when you think about it is perfectly understandable.
e) Also Intel themselves furnish quite a lot of utils (Linux & Windows) which you can find & if you can’t always use Way-Back-Machine to obtain older stuff for older systems etc. CSME detection tool command-line & gui front end etc
f) Inspectre2 GRC’s old but gold for older PC systems to check for vulnerability of your PC works on XP.
g) Intel ME 9.1 Firmware Repository r21.rar will need WinRar to unpack 7Zip won’t cut it when trying to unpack it. For older systems with Bin files contained therein.
h) UEFITool_0.28.0_win32.zip again google it you will find it NOT4XP
i) Putty putty-0.74-installer.msi needed to connect R-pi to ME_Cleaner website when flashing
Hardware - That will be needed, a spare Bios chip for your make & model of your PC (always a good Idea) , if the Mboard does not have a removable bios chip then you can get an adapter from ebay etc that will clip onto your Bios Chip. A Raspberry Pi with case with GPIO header, long or short wires depending on your choice, a breadboard, a jumper. Tweezers long nose pliers a PLCC chip extractor, Circuit board diagram of both your chip-set & your raspberry Pi you can get these on-line.
Some twisted light humour, tongue in cheek humour Re IME from the perspective of adolf hitler’s last days in his underground bunker subtitled. If you are the type of person that does not like inuendoed profanity do NOT watch this video.
I cannot vouch for the material contained within these videos especially the humourous utube link & I would encourage everyone to do their own additional research as this is a rolling road what is current soon evolves into new information tomorrow. Satisfy your own minds in terms of the authenticity of the links provided?
Built into many Intel-based platforms is a small, low power computer subsystem called the Intel Management Engine (Intel ME). This can perform various tasks while the system is booting, running or sleeping. It operates independently from the main CPU, BIOS and OS but can interact with them if needed. The ME is responsible for many parts of an Intel-based system. Such functionality extends, but it's not limited, to Platform Clocks Control (ICC), Thermal Monitoring, Fan Control, Power Management, Overclocking, Silicon Workaround (resolves silicon bugs which would have otherwise required a new cpu stepping), Identity Protection Technology, Boot Guard, Rapid Start Technology, Smart Connect Technology, Sensor Hub Controller (ISHC), Active Management Technology (AMT), Small Business Advantage (SBA), Wireless Display, PlayReady, Protected Video/Audio Path etc. For certain advanced/corporate features (i.e. AMT, SBA) the ME uses an out-of-band (OOB) network interface to perform functions even when the system is powered down, the OS and/or hard drivers are non-functional etc. Thus it is essential for it to be operational in order for the platform to be working properly, no matter if the advanced/corporate features are available or not.
Intel Converged Security Engine Introduction:
The evolution of Intel Management Engine into a unified security co-processor, running x86 code under a Minix-based Operating System. It was first introduced in 2015 with the release of Skylake CPUs working alongside 100-series Sunrise Point Platform Controller Hub (PCH). The CSE hardware can run Management Engine (ME) 11+, Trusted Execution Engine (TXE) 3+ or Server Platform Services (SPS) 4+ firmware. So there are a total of three families of CSE-based firmware: CSME (CSE ME), CSTXE (CSE TXE) and CSSPS (CSE SPS). The CSE hardware is also capable of running other types of firmware such as Power Management Controller (PMC), Integrated Sensor Hub (ISH), Imaging Unit (iUnit), Clear Audio Voice Speech (cAVS), Wireless Microcode (WCOD) etc.
Intel Power Management Controller Introduction:
Handles all Platform Controller Hub (PCH) power management related activities, running ARC code on top of the CSE hardware. PMC administers power management functions of the PCH including interfacing with other logic and controllers on the platform to perform power state transitions, configure, manage and respond to wake events, aggregate and report latency tolerance information for devices and peripherals connected to and integrated into the PCH etc. It was first introduced in 2018 with the release of Coffee/Cannon Lake CPUs working alongside 300-series Cannon Point PCH.
Disclaimer:
All the software and firmware below comes only from official updates which were provided and made public by various manufacturers! The System Tools are gathered and provided with the sole purpose of helping people who are out of other viable solutions. Thus, they can be extremely helpful to those who have major problems with their systems for which their manufacturer refuses to assist due to indifference and/or system age.
Getting Started:
Intel (CS)ME is a Hardware platform which runs Firmware, is monitored/configured by Tools and interfaces with the user via Drivers. To get started, you need at the very least to know what (CS)ME firmware major and minor version your system is running. Such info can be retrieved in various ways but you can use the free system information and diagnostics tool HWiNFO > Motherboard > Intel ME > Intel ME Version. The format is Major.Minor, Build, Hotfix. Once you determine the system's (CS)ME firmware major and minor version, you can install the latest Drivers from section A and update the (CS)ME Firmware by following sequentially the relevant steps at Section B using the required Tools from Section C.
A. Intel MEI Drivers
The latest v16.0 drivers are usable with (CS)ME 10, 11, 12, 13, 14, 15 and 16 systems running under Windows 10 >= 1709. The latest v15.0 drivers are usable with (CS)ME 10, 11 and 12 systems running under Windows 8, 10 <= 1703 or (CS)ME 10 and 11 systems running under Windows 7. Users of systems with ME <= 9, must check Section D to find the driver they need. In order to check your current installed version, use Intel MEInfo tool as instructed below.
Note: To extract the files below you need to use programs which support RAR5 compression!
A1. Intel MEI Drivers and Software
These packages contain the Intel MEI drivers with their respective software and system services. It is advised to install these to enable all the Engine-related functionality. Since the Intel MEI Drivers and Software are OS version dependent, search and run "winver.exe" to determine your own.
Note: MEI Drivers and Software v2216.16.0.2805 includes MEI v2210.2.80.0. MEI Drivers and Software v2112.15.0.2221 includes MEI v2108.100.0.1053.
A2. Intel MEI Driver Only
These packages contain only the Intel MEI Drivers without any additional software or system services. Installing these allow only very basic Engine-related functionality. Since the Intel MEI Driver is OS version dependent, search and run "winver.exe" to determine your own.
MEI Driver v2214.0.85.0 (Windows 10 >= 1709)
MEI Driver v2108.100.0.1053 (Windows 8, 10 <= 1703)
MEI Driver v2108.100.0.1053 (Windows 7)
Note: The MEI Drivers listed above are part of the complete Drivers and Software packages found at section A1. A newer Drivers and Software package has newer Software but the actual MEI Driver may still be an older version.
B. Intel (CS)ME, PMC, PCHC and PHY Firmware
SPI/BIOS Regions (FD/Engine/BIOS):
The SPI/BIOS chip firmware is divided into regions which control different aspects of an Intel-based system. The mandatory regions are the Flash Descriptor 166 (FD), the (Converged Security) Management Engine (CSME/ME or Engine) and the BIOS. The FD controls read/write access between the SPI/BIOS chip regions and holds certain system hardware settings. The (CS)ME holds the system's Engine firmware. For security reasons, the FD and Engine regions of the SPI/BIOS chip are usually locked so that no read/write access is allowed via software means. Since the FD controls that read/write access, it must be locked/protected so that it is not manually overwritten to allow unauthorized access to the firmware regions of the system's SPI/BIOS chip. The Engine region at the system's SPI/BIOS chip is also locked/protected due to the nature of the CSE/ME co-processor, as explained at the Introductions above.
Intel (CS)ME or Engine firmware is mainly categorized based on its target Chipset Family (i.e. Cougar Point, Cannon Point, Lake Field, Tiger Point), Chipset Platform (H = Halo, LP = Low Power, N = Nano, V = Value), Type/SKU (i.e. Consumer, Corporate, Slim, Lite, 1.5MB, 5MB) and Version (i.e. 12.0.6.1120 = Major.Minor.Hotfix.Build). Be careful of what firmware your download relevant to your system. To understand your exact Chipset Family, Chipset Platform, (CS)ME Type/SKU and (CS)ME Version, you can usually run MEInfo or MEManuf tools with "-verbose" parameter. Otherwise, ME Analyzer 466 can show you all the relevant information, after loading your SPI/BIOS image (Flash Descriptor + Engine + BIOS), when the latter is available. If a SPI/BIOS image is not available, run FWUpdate tool with parameter "-save fw.bin" and load the resulting "fw.bin" image into ME Analyzer 465 instead. All the firmware below correspond to a specific Platform which runs a specific (CS)ME firmware version (example: For systems running CSME Corporate H v11.0 - v11.8).
Engine Firmware Regions (RGN/EXTR):
The Type of each Engine/(CS)ME firmware Region can be either Stock (RGN) or Extracted (EXTR). Stock are clean/stock/unconfigured images provided by Intel to OEMs. Extracted are dirty/extracted/configured images from various SPI/BIOS. The Engine firmware at the system's SPI/BIOS chip is always EXTR, generated by the OEM after configuring the equivalent RGN with the appropriate system settings.
Engine Firmware Configuration (CODE/DATA):
The Engine Firmware Regions (RGN/EXTR) consist of two sections: CODE and DATA. CODE is the actual Engine firmware whereas DATA is where all the system-specific settings are stored, as configured by the OEM at the factory via Intel Flash Image Tool. The Engine firmware is not static as it holds system-specific configuration and can additionally be configured by the Engine co-processor itself while the system is running in order to provide the proper support and functionality. Any such changes are written into the DATA section of the Engine Region and the firmware is considered Initialized. That means that the DATA section can be in one of three states: Unconfigured, Configured or Initialized. Unconfigured means that the Engine firmware image is the stock one Intel provides and not configured by the OEM at all (RGN). Configured means that the OEM has applied model specific settings and the Engine region is ready for deployment (EXTR). Initialized means that the Engine region comes from a system which was already running and thus the Engine co-processor has further configured the DATA section to suit that particular system better (system specific or dirty EXTR).
FWUpdate Update Images (UPD):
FWUpdate images (UPD) are partial RGN/EXTR firmware regions which contain only ME CODE without any DATA. They are created and used only by Intel's FWUpdate tool. Thus, they can neither be opened nor configured by Intel Flash Image Tool (FIT). Never flash UPD images via anything other than Intel FWUpdate tool. UPD images are not needed for 7-series (ME 8) or newer systems. However, all 6-series (ME 7) or older systems must use UPD images in order to initiate a ME firmware update. Thus, at section B1 below, only RGN/EXTR images are provided for 7-series (ME 8) or newer systems and only UPD images are provided for 6-series (ME 7) or older systems.
Independent Update Partitions (IUP):
The Engine firmware consists of multiple Partitions (sections) and each one is responsible for different features/capabilities. For example, the Fault Tolerant Partition (FTPR) contains CODE which is essential for the (CS)ME operation whereas the File System Partition (MFS, EFFS) contains the Configured and/or Initialized DATA. Some (CS)ME firmware Partitions target auxiliary CSE/ME co-processor devices or capabilities and can also be updated independently of the main (CS)ME firmware. These are called Independent Update Partitions (IUP) with the most notable/important ones being Power Management Controller (PMC), Platform Controller Hub Configuration (PCHC) and USB Type C Physical (PHY).
Starting from CSME 12+, the main CSME firmware must first be combined/stitched with one or more obligatory IUPs, before initiating an update procedure via FWUpdate tool. Whenever CSME + IUP merging is required, equivalent instructions and firmware are provided below. The following CSME/IUP Table lists the CSME 12+ firmware Major.Minor versions which require the presence of IUP(s) and their respective versions or SKUs. You'll need to consult this table while following the update instructions below to choose the correct CSME + IUP combination for your system.
CSME/IUP Table
Engine Security Version Number (SVN):
All (CS)ME >= 8 and all IUP firmware are defined by a Security Version Number (SVN) like 1,2,3 etc which is used to control the possible upgrade/downgrade paths provided by Intel’s FWUpdate tool. The SVN gets incremented if there is a high or critical security fix that requires a Trusted Computing Base (TCB) 10 recovery operation, a significant event in the life cycle of the firmware which requires renewal of the security signing keys in use. A downgrade to a lower SVN value via FWUpdate tool is prohibited whereas an upgrade to the same or higher SVN is allowed. For example if your current firmware has a SVN of 2, you can update to another firmware with SVN >= 2 (for example 3) but you cannot downgrade to another firmware with SVN < 2 (for example 1). Trying to flash a firmware with lower SVN will result in the error "The image provided is not supported by the platform" or similar. To view the SVN value of any (CS)ME or PMC firmware, you can use ME Analyzer 465 tool.
Engine Version Control Number (VCN):
All (CS)ME >= 8 and all IUP firmware are defined by a Version Control Number (VCN) like 1,2,45,193 etc which is used to control the possible upgrade/downgrade paths provided by Intel’s FWUpdate tool. The VCN gets incremented if there is a security fix, a significant firmware change or a new feature addition. A downgrade to a lower VCN value via FWUpdate tool is prohibited whereas an upgrade to the same or higher VCN is allowed. For example if your current firmware has a VCN of 176, you can update to another firmware with VCN >= 176 (for example 193) but you cannot downgrade to another firmware with VCN < 176 (for example 174). Trying to flash a firmware with lower VCN will result in the error "The image provided is not supported by the platform" or similar. To view the VCN value of any (CS)ME firmware, you can use ME Analyzer 465 tool.
Engine Production Ready Status (PV):
All (CS)ME >= 8 and all IUP firmware are defined by a Production Version/Ready Status (PV) which can be either Yes or No and is used to control the possible upgrade/downgrade paths provided by Intel’s FWUpdate tool. The PV status is set to Yes when a firmware is validated/ready for use at Production platforms, thus when its status is Stable and not Beta, Alpha etc. An upgrade/downgrade from PV to non-PV firmware via FWUpdate tool is prohibited whereas upgrades/downgrades to the same PV or from non-PV to PV are allowed. For example if your current firmware has PV set to Yes, you can upgrade/downgrade to another firmware with PV set to Yes but you cannot upgrade/downgrade to another firmware with PV set to No. Trying to flash a firmware with incompatible PV will result in the error "The image provided is not supported by the platform" or similar. To view the PV status of any (CS)ME firmware, you can use ME Analyzer 465 tool.
Power Down Mitigation (PDM):
At CSME v11 LP firmware, make sure to mind the PDM status which is distinguished between YPDM (Yes) and NPDM (No). PDM is some sort of erratum 3, which is only relevant to 100-series PCH-LP systems. Thus, it is an attribute of every CSME v11.0 - v11.8 firmware which supports 100-series PCH-LP systems. The PDM status of a firmware can be detected by ME Analyzer 465 by loading either your SPI/BIOS image (Flash Descriptor + Engine + BIOS) or an Engine Firmware Recovery image which can be generated via FWUpdate tool parameter "-save recovery.bin".
Power Management Controller (PMC) IUP:
PMC firmware always targets a specific Chipset Family/Codename (i.e. CNP, ICP, LKF, CMP), Chipset Platform (i.e. H, LP, N, V) and Chipset Stepping/Revision (i.e. A, B, C, D). For example, a CSME 12.0 Corporate H B system must use PMC CNP H B 300.2 firmware, a CSME 15.0 Consumer LP B system must use PMC TGP LP B 150.1 firmware etc. The PMC firmware can only be updated after being merged with a compatible CSME firmware via Flash Image Tool.
Platform Controller Hub Configuration (PCHC) IUP:
PCHC firmware always targets a specific Chipset Family/Codename (i.e. ICP, CMP, TGP). For example, a CSME 13.0 Consumer LP D system must use PCHC ICP 13.0 firmware, a CSME 15.40 Server LP B system must use PCHC EHL 15.0 firmware etc. The PCHC firmware can only be updated after being merged with a compatible CSME firmware via Flash Image Tool.
USB Type C Physical (PHY) IUP:
PHY firmware always targets a specific Chipset Family/Codename (i.e. LKF, CMP, TGP) and PHY Type/SKU (i.e. S, N, P). For example, a CSME 14.1 Consumer H A system must use PHY P CMP firmware, a CSME 13.30 Lite LP B SPI system must use PHY S LKF firmware etc. The PHY firmware can only be updated after being merged with a compatible CSME firmware via Flash Image Tool.
How to update Engine firmware:
There are two ways to upgrade or downgrade the Engine firmware: either via Intel FWUpdate tool or manually.
The Intel FWUpdate tool is an official command line utility provided by Intel which uses the Engine co-processor itself to upgrade/downgrade the (CS)ME firmware quickly and easily. FWUpdate tool requires that the Engine co-processor is operational and that its current Engine firmware region is healthy at the system's SPI/BIOS chip. To check if the Engine itself as well as its current firmware are healthy, you can use Intel MEInfo and MEManuf tools, as instructed below. FWUpdate tool also requires that the SVN, VCN and PV are not violated. FWUpdate tool does not require the user to have read/write access to the Engine firmware region of the system's SPI/BIOS chip, as dictated by the Flash Descriptor region permissions. Moreover, FWUpdate tool deals only with Engine CODE and does not require any prior Configuration (DATA). It can thus work with either RGN or EXTR Engine Regions. The basic usage is FWUpdLcl -allowsv -f update_file_name.bin for (CS)ME >= 7 or FWUpdLcl update_file_name.bin -generic for ME <= 6. Starting from CSME 12+, the main CSME firmware needs to be combined/stitched together with one or more IUPs first before initiating an update/downgrade procedure, as described below. You can see the entire supported parameters by displaying the utility's help screen via FWUpdLcl -?. You can also see a few basic usage examples via FWUpdLcl -exp. Note that the name of the file to be flashed via FWUpdate does not matter.
In the event in which the usage of Intel FWUpdate tool is not possible, you can try to upgrade/downgrade the (CS)ME firmware manually. Such cases include downgrading to Engine firmware which violate SVN, VCN or PV, repairing a corruption/problem etc. To upgrade/downgrade/repair manually, you need first and foremost to have read/write access to the Engine firmware region of the system's SPI/BIOS chip. To check if your FD is locked or to attempt to unlock it, follow the [Guide] Unlock Intel Flash Descriptor Read/Write Access Permissions for SPI Servicing 167. Once you have read/write access to the Engine firmware region of your system's SPI/BIOS chip, you can use any general purpose firmware flasher software such as Intel Flash Programming Tool, AMI AFU, Flashrom etc, which directly reads/writes the system's SPI/BIOS chip firmware. Before flashing, you must make sure that the Engine firmware region to be flashed back is Configured (EXTR) for your specific system via Intel Flash Image Tool (FIT). In order to do that, follow the [Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization 50. Never flash RGN or 3rd-party EXTR firmware to the Engine firmware region of the system's SPI/BIOS chip without first configuring them for your specific system (EXTR) via FIT. Since general purpose firmware software do not upgrade/downgrade/repair the Engine firmware region of the system's SPI/BIOS chip via the Engine co-processor itself, they are usually not restricted by the SVN, VCN and PV security measures. As long as you have read/write access to the Engine firmware region of the system's SPI/BIOS chip and a DATA Configured (EXTR) Engine firmware image, they should accomplish the desired action. Note however that some platforms have the current TCB SVN and/or ARB SVN value permanently set/fused/burned in the Chipset so you cannot downgrade their firmware with another which has lower TCB SVN and/or ARB SVN.
How to use FWUpdate Tool at CSME v16+:
At CSME 16 or newer, FWUpdate tool requires CSME firmware which has been combined/stitched with its equivalent IUP firmware (i.e. PMC, PCHC, PHY) via Modular Flash Image Tool (FIT). To proceed, you must first learn your system's Chipset Family/Codename (i.e. ADP), Chipset Platform (i.e. H, LP, N), Chipset Type (i.e. Consumer, Corporate, Slim, Lite, Server) and Chipset Stepping/Revision (i.e. A, B, C, D).
Download the latest Intel CSME System Tools from Section C2 as well as ME Analyzer 253 tool.
From Intel CSME System Tools, run MEInfo command line tool and under "Intel(R) ME Code Versions" > "FW Version" you will find your system's Chipset Platform as well as Chipset Type (e.g. H Consumer). Under "PCH Information" > "PCH Revision ID" you will find your system's Chipset Stepping/Revision which starts with a letter (i.e. Ax, Bx, Cx). Alternatively, drag and drop your system's SPI/BIOS image (Flash Descriptor + Engine + BIOS) at ME Analyzer 252 tool and find "SKU" field which shows your system's Chipset Type and Chipset Platform (e.g. Consumer LP). Next, find "Chipset Stepping" field which lists one or more supported Chipset Steppings in the form of letters (i.e. A, B, C).
Based on your system's Chipset Family/Codename, Chipset Platform, Chipset Type and Chipset Stepping/Revision, consult the CSME/IUP Table above and choose the correct CSME, PMC, PCHC and/or PHY firmware from Sections B1-B4.
Input the chosen CSME firmware into ME Analyzer 465 tool and make sure that "FWUpdate Support" is not reported as "Impossible".
From Intel CSME System Tools, go to Modular Flash Image Tool folder and make sure that only one (1) file exists: mfit.exe. Otherwise, delete the rest.
Run Modular Flash Image Tool (FIT) and click "Create and build a new image". Select the "FWUpdate" layout that matches your system's equivalent CPU specifications. Each Chipset works with certain CPUs. Usually the Chipset codenames end in "Point" whereas CPU codenames end in "Lake". Also, the Chipset Types (i.e. H, LP, N) match to equivalent CPU Families (i.e. S, P, N). For example, "Alder Point (ADP)" Chipset Platform works with "Alder Lake (ADL)" CPU Family and "ADP-H" Chipset Type works with "ADL-S" CPU Family.
Go to "Flash Layout > Ifwi: Intel(R) Me and Pmc Region" and load the chosen CSME firmware at "Intel(R) ME Binary File". The CSME firmware version should be shown below.
If your chosen CSME firmware requires PMC IUP, input its firmware at "Flash Layout > Ifwi: Intel(R) Me and Pmc Region > PMC Binary File". The PMC firmware version should be shown below.
If your chosen CSME firmware requires PCHC IUP, input its firmware at "Flash Layout > Sub Partitions > PCH Configuration Sub-Partition > PCH Configuration File". The PCHC firmware version should be shown below.
If your chosen CSME firmware requires PHY IUP, input its firmware at "Flex IO > *PHY Configuration > *PHY Binary File". The PHY firmware version should be shown below.
Click the green "Build" button at the left and a "FWUpdate.bin" file will be generated.
Input "FWUpdate.bin" file into ME Analyzer 465 tool and make sure that "FWUpdate Support" is reported as "Yes".
Use FWUpdate tool to flash the "FWUpdate.bin" image.
How to use FWUpdate Tool at CSME v13+:
At CSME 13 or newer, FWUpdate tool requires CSME firmware which has been combined/stitched with its equivalent IUP firmware (i.e. PMC, PCHC, PHY) via Flash Image Tool (FIT). To proceed, you must first learn your system's Chipset Family/Codename (i.e. ICP, LKF, JSP, CMP, TGP, EHL), Chipset Platform (i.e. H, LP, N, V), Chipset Type (i.e. Consumer, Corporate, Slim, Value, Atom, Server) and Chipset Stepping/Revision (i.e. A, B, C, D).
Download the latest Intel CSME System Tools from Section C2 as well as ME Analyzer 252 tool.
From Intel CSME System Tools, run MEInfo command line tool and under "Intel(R) ME code versions" > "FW Version" you will find your system's Chipset Platform as well as Chipset Type (e.g. LP Consumer). Under "PCH Information" > "PCH Step Data" you will find your system's Chipset Stepping/Revision which starts with a letter (i.e. Ax, Bx, Cx). Alternatively, drag and drop your system's SPI/BIOS image (Flash Descriptor + Engine + BIOS) at ME Analyzer 252 tool and find "SKU" field which shows your system's Chipset Type and Chipset Platform (i.e. Consumer LP). Next, find "Chipset Stepping" field which lists one or more supported Chipset Steppings in the form of letters (i.e. A, B, C).
Based on your system's Chipset Family/Codename, Chipset Platform, Chipset Type and Chipset Stepping/Revision, consult the CSME/IUP Table above and choose the correct CSME, PMC, PCHC and/or PHY firmware from Sections B1-B4.
Input the chosen CSME firmware into ME Analyzer 465 tool and make sure that "FWUpdate Support" is not reported as "Impossible".
From Intel CSME System Tools, go to Flash Image Tool folder and make sure that only two (2) files exist: fit.exe and vsccommn.bin. Otherwise, delete the rest.
Run Flash Image Tool (FIT) and adjust the Chipset Platform drop-down menu at the top based on your system's Chipset Platform (i.e. H series, LP series, N series, V series, Lakefield, Jasper Lake, Elkhart Lake). At CSME 14.1, adjust to "H series (With RocketLake)". For the purposes of FWUpdate, there is no need to further adjust the actual Chipset SKU on the right.
Load or drag and drop the chosen CSME firmware image anywhere at FIT and go to "FW Update Image Build" tab on the left.
If your chosen CSME firmware requires PMC IUP, input its firmware at "PMC Image" > "PMC Binary File" field.
If your chosen CSME firmware requires PCHC IUP, input its firmware at "PCHC Image" > "PCH Configuration File" field.
If your chosen CSME firmware requires PHY IUP, input its firmware at "PHY Image" > "PHY Binary File" field.
Click the green "Build Image For FWUpdate" button at the top right and a "FWUpdate.bin" file will be generated.
Input "FWUpdate.bin" file into ME Analyzer 465 tool and make sure that "FWUpdate Support" is reported as "Yes".
Use FWUpdate tool to flash the "FWUpdate.bin" image.
How to use FWUpdate Tool at CSME v12:
At CSME v12, FWUpdate tool requires CSME firmware which has been combined/stitched with its equivalent IUP firmware (PMC) via Flash Image Tool (FIT). To proceed, you must first learn your system's Chipset Platform (H, LP), Chipset Type (Consumer, Corporate, Slim) and Chipset Stepping/Revision (i.e. A, B, C).
Download the latest Intel CSME System Tools from Section C2 as well as ME Analyzer 252 tool.
From Intel CSME System Tools, run MEInfo command line tool and under "Intel(R) ME code versions" > "FW Version" you will find your system's Chipset Platform as well as Chipset Type (e.g. H Consumer). Under "PCH Information" > "PCH Step Data" you will find your system's Chipset Stepping/Revision which starts with a letter (i.e. Ax, Bx, Cx). Alternatively, drag and drop your system's SPI/BIOS image (Flash Descriptor + Engine + BIOS) at ME Analyzer 252 tool and find "SKU" field which shows your system's Chipset Type and Chipset Platform (i.e. Consumer H). Next, find "Chipset Stepping" field which lists one or more supported Chipset Steppings/Revisions in the form of letters (i.e. A, B, C).
Based on your system's Chipset Platform, Chipset Type and Chipset Stepping/Revision, consult the CSME/IUP Table above and choose the correct CSME and PMC firmware from Sections B1-B2.
Input the chosen CSME firmware into ME Analyzer 465 tool and make sure that "FWUpdate Support" is not reported as "Impossible".
From Intel CSME System Tools, go to Flash Image Tool folder and make sure that only two (2) files exist: fit.exe and vsccommn.bin. Otherwise, delete the rest.
Run Flash Image Tool (FIT) and adjust the Chipset Platform drop-down menu at the top to either "H Series Chipset" or "LP Series Chipset" based on your system's Chipset Platform. For the purposes of FWUpdate, there is no need to further adjust the Chipset SKU on the right.
Load/drop the chosen CSME firmware image and then input the chosen PMC IUP firmware at "Flash Layout" > "Ifwi: Intel(R) Me and Pmc Region" > "PMC Binary File".
Adjust "Flash Settings" > "Flash Components" > "Number of Flash Components" to "0".
CSME 14.1 Slim H A
For CSME Slim H A v14.0 - v14.1
CSME 13.50 Atom N A
For CSME Atom N A v13.50
CSME 13.30 Lite LP B SPI
For CSME Lite LP B SPI v13.30
CSME 13.0 Consumer LP D
For CSME Consumer LP D v13.0
CSME 13.0 Slim N A
For CSME Slim N A,B v13.0
CSME 12.0 Consumer H B,A
For CSME Consumer H B,A v12.0
CSME 12.0 Corporate H B,A
For CSME Corporate H B,A v12.0
CSME 12.0 Consumer LP C
For CSME Consumer LP C v12.0
CSME 12.0 Consumer LP B
For CSME Consumer LP B v12.0
CSME 12.0 Corporate LP C
For CSME Corporate LP C v12.0
CSME 12.0 Slim H B,A
For CSME Slim H B,A v12.0
CSME 12.0 Slim LP C
For CSME Slim LP C v12.0
CSME 11.22 Corporate H B,A
For CSME Corporate H B,A v11.20 - v11.22
CSME 11.22 Slim H B,A
For CSME Slim H B,A v11.20 - v11.22
CSME 11.12 Consumer H A
For CSME Consumer H A v11.10 - v11.12
CSME 11.12 Corporate H A
For CSME Corporate H A v11.10 - v11.12
CSME 11.12 Slim H A
For CSME Slim H A v11.10 - v11.12
CSME 11.8 Consumer H D,A
For CSME Consumer H D,A v11.0 - v11.8
CSME 11.8 Corporate H D,A
For CSME Corporate H D,A v11.0 - v11.8
CSME 11.8 Consumer LP C NPDM
For CSME Consumer LP C NPDM v11.0 - v11.8
CSME 11.8 Consumer LP C YPDM
For CSME Consumer LP C YPDM v11.0 - v11.8
CSME 11.8 Corporate LP C NPDM
For CSME Corporate LP C NPDM v11.0 - v11.8
CSME 11.8 Corporate LP C YPDM
For CSME Corporate LP C YPDM v11.0 - v11.8
CSME 11.8 Slim H D,A
For CSME Slim H D,A v11.0 - v11.8
CSME 11.8 Slim LP C NPDM
For CSME Slim LP C NPDM v11.0 - v11.8
ME 10.0 1.5MB
For ME 1.5MB v10.0
ME 10.0 5MB
For ME 5MB v10.0
ME 10.0 Slim
For ME Slim v10.0
ME 9.5 1.5MB
For ME 1.5MB v9.5
ME 9.5 5MB
For ME 5MB v9.5
ME 9.5 Slim
For ME Slim v9.5
ME 9.1 1.5MB
For ME 1.5MB v9.1
ME 9.1 5MB
For ME 5MB v9.1
ME 9.0 1.5MB
For ME 1.5MB v9.0
ME 9.0 5MB
For ME 5MB v9.0
ME 8 1.5MB
For ME 1.5MB v8
ME 8 5MB
For ME 5MB v8
ME 7 1.5MB
For ME 1.5MB v7
ME 7 5MB
For ME 5MB v7
ME 7 Slim
For ME Slim v7
ME 6 1.5MB
For ME 1.5MB v6
ME 6 5MB Desktop
For ME 5MB DT v6
ME 6 5MB Mobile
For ME 5MB MB v6
ME 6 Ignition IBX
For ME Ignition IBX v6
ME 6 Ignition CCK
For ME Ignition CCK v6.0.50
ME 5 Base Consumer
For ME Base Consumer v5
ME 5 Digital Office
For ME Digital Office v5
ME 4 TPM
For ME TPM v4
ME 4 AMT
For ME AMT v4
ME 4 AMT + TPM
For ME AMT + TPM v4
ME 3 QST
For ME QST v3
ME 3 ASF
For ME ASF v3
ME 3 AMT
For ME AMT v3
ME 2 QST
For ME QST v2
ME 2 AMT Mobile
For ME AMT MB v2.5 - v2.6
ME 2 AMT Desktop
For ME AMT DT v2.0 - v2.2
B2. Power Management Controller - PMC
PMC ADP H A 160.2
For PMC ADP H A v160.2.0x
PMC ADP LP A 160.1
For PMC ADP LP A v160.1.0x
PMC ADP SoC A 160.0
For PMC ADP SoC A v160.0.0x
PMC MCC LP B 154.1
For PMC MCC LP B v154.1.1x
PMC TGP H B 150.2
For PMC TGP H B v150.2.1x
PMC TGP LP C 150.1
For PMC TGP LP C v150.1.2x
PMC CMP V A 140.1
For PMC CMP V A v140.1.0x
PMC CMP H A 140.2
For PMC CMP H A v140.2.0x
PMC CMP LP A 140.1
For PMC CMP LP A v140.1.0x
PMC JSP N A 135.3
For PMC JSP N A v135.3.0x
PMC LKF SoC B 133.0
For PMC LKF SoC B v133.0.1x
PMC ICP LP D 130.1
For PMC ICP LP D v130.1.3x
PMC ICP N B 130.3
For PMC ICP N B v130.3.1x
PMC CNP H B 300.2
For PMC CNP H B v300.2.1x
PMC CNP LP C 300.1
For PMC CNP LP C v300.1.2x
PMC CNP LP B 300.1
For PMC CNP LP B v300.1.1x
B3. Platform Controller Hub Configuration - PCHC
PCHC ADP 16.0
For PCHC ADP v16.0
PCHC MCC 15.40
For PCHC MCC v15.40
PCHC TGP 15.0
For PCHC TGP v15.0
PCHC CMP 14.5
For PCHC CMP v14.5
PCHC CMP 14.0
For PCHC CMP v14.0
PCHC JSP 13.5
For PCHC JSP v13.5
PCHC LKF 13.30
For PCHC LKF v13.30
PCHC ICP 13.0
For PCHC ICP v13.0
B4. USB Type C Physical - PHY
PHY N ADP 14
For PHY N ADP v14
PHY N ADP 13
For PHY N ADP v13
PHY S ADP 13
For PHY S ADP v13
PHY P TGP 12
For PHY P TGP v12
PHY P CMP 12
For PHY P CMP v12
PHY S LKF 10
For PHY S LKF v10
C. Intel (CS)ME System Tools
The Intel (CS)ME System Tools are used for creating, modifying, and writing binary image files, manufacturing testing, Intel (CS)ME setting information gathering and Intel (CS)ME firmware configuration and updating. These tools are not released to end-users but only to OEMs. The software below comes only from official updates which were provided and made public by various OEMs.
Flash Image Tool: Creates and configures a complete SPI image file which includes regions such as Flash Descriptor (FD), BIOS/UEFI, Intel Integrated LAN (GbE), Intel (CS)ME etc. The user can manipulate the completed SPI image via a GUI and change the various chipset parameters to match the target hardware.
Flash Programming Tool: Used to program a complete SPI image into the SPI flash device(s). FPT can program each region individually or it can program all of the regions with a single command. The user can also use FPT to perform various functions such as view the contents of the flash on the screen, write the contents of the flash to a log file, perform a binary file to flash comparison, write to a specific address block, program fixed offset variables etc.
Manifest Extension Utility: Used to generate a 3rd party Independent Update Partitions (IUP) which are compressed and signed by an external signing tool, such as OpenSSL. The signed contents may then be stitched into a SPI/BIOS image using the Intel Flash Image Tool (FIT).
Notice: Avoid using the Windows builds of very old (CS)ME System Tools which either retrieve info (MEInfo, MEManuf, Flash Programming Tool) or modify the platform (FWUpdate, Flash Programming Tool, Integrated Clock Controller) as they may not work properly on newer operating system versions. When available, it is advised to use either the DOS or EFI builds of said very old tools.
Notice: Avoid running the System Tools from paths which include non-English characters (i.e. Cyrillic, Chinese, Arabic, Greek) as it may cause them to crash or behave unpredictably.
C1. Identifying, Updating and Diagnosing Intel (CS)ME Firmware
Those who are looking to update/downgrade their firmware should use MEInfo, FWUpdate and MEManuf tools for status information, updating and functionality checking accordingly. The information and instructions below apply to these three tools only and can be found inside the full Intel ME System Tools Packages.
MEInfo: Shows (CS)ME and IUP info and checks that the Engine co-processor is operating properly on the software/firmware level. Make sure it doesn't report any errors. You can use "-verbose" parameter to get status info in more detail. The "GBE Region does not exist" warning is normal for systems that don't have an Intel GbE Controller, you can safely ignore it.
MEManuf: Diagnostic tool which runs various manufacturing-line tests to ensure that the Engine co-processor is operating properly on the hardware level. It should report a "MEManuf Operation Passed" or similar success message. You can use "-verbose" parameter to get diagnostic info in more detail.
FWUpdate: Used to effortlessly upgrade or downgrade the (CS)ME and IUP (i.e PMC, PCHC, PHY) Engine firmware. Read more about FWUpdate tool at Section B.
C2. (CS)ME System Tools
Note: To extract the files below you need to use programs which support RAR5 compression!
CSME System Tools v16.0
For CSME v16.0
CSME System Tools v15.40
For CSME v15.40
CSME System Tools v15.0
For CSME v15.0
CSME System Tools v14.5
For CSME v14.5
CSME System Tools v14.0.20+
For CSME v14.0.20 or newer
CSME System Tools v14.0.11-
For CSME v14.0.11 or older
CSME System Tools v13.50
For CSME v13.50
CSME System Tools v13.30
For CSME v13.30
CSME System Tools v13.0
For CSME v13.0
CSME System Tools v12
For CSME v12
CSME System Tools v11
For CSME v11
ME System Tools v10.0
For ME v10.0
ME System Tools v9.5
For ME v9.5
ME System Tools v9.1
For ME v9.0 - v9.1
ME System Tools v8
For ME v8
ME System Tools v7
For ME v7
ME System Tools v6 IBX
For ME v6 1.5MB, 5MB DT, 5MB MB or Ignition IBX
ME System Tools v6 CCK
For ME v6.0.50 Ignition CCK
ME System Tools v5
For ME v5
ME System Tools v4
For ME v4
ME System Tools v3
For ME v3
ME System Tools v2
For ME v2
Second, supplemental post by user Fernando initially posted October 11, 2013 - updated since then:
D. Old Intel MEI Drivers
You should always install the latest drivers for all 8-series Broadwell mobile and up systems, which can be found at section A. The driver versions linked below are the latest of each older Engine major branch.
Note: To extract the files below you need to use programs which support RAR5 compression!
D1. Old Intel MEI Drivers and Software
These packages contain the Intel MEI/SOL drivers with their respective software and system services. It is advised to install these to enable all the Engine-related functionality. It is important to install the correct package depending on your Consumer/1.5MB or Corporate/5MB system.
Note: MEI Drivers and Software v11.7.0.1069 includes MEI v11.7.0.1057. MEI Drivers and Software v11.0.6.1194 includes MEI v11.0.5.1189. MEI Drivers and Software v6.2.50.1062 includes MEI Driver v6.2.50.1050. MEI Drivers and Software v3.2.50.1059 includes MEI Driver v3.2.20.1046. MEI Drivers and Software v2.6.30.1051 includes MEI Driver v2.6.30.1046.
These packages contain only the Intel MEI Driver without any additional software or system services. Installing these allow only very basic Engine-related functionality. They are compatible with both Consumer/1.5MB and Corporate/5MB systems. The MEI Installer is the setup file from Intel which includes the MEI Driver but also allows easy installation and adds a Control Panel entry for quick driver removal.
MEI Installer v11.7.0.1069 (ME 9)
MEI Driver v11.7.0.1057 (ME 9, Windows 8 and Windows 10)
MEI Driver v11.7.0.1057 (ME 9, Windows XP and Windows 7)
MEI Installer v11.0.6.1194 (ME 7-8)
MEI Driver v11.0.5.1189 (ME 7-8)
MEI Driver v6.2.50.1050 (ME 6)
MEI Driver v5.2.0.1008 (ME 5)
MEI Driver v4.2.0.1008 (ME 4)
MEI Driver v3.2.20.1046 (ME 3)
MEI Driver v2.6.30.1046 (ME 2 MB)
MEI Driver v2.1.22.1033 (ME 2 DT)
AMT Driver v1.1.30.2 (AMT 1 GbE)
Note: The MEI Drivers listed above are part of the complete Drivers and Software packages found at section D1. A newer Drivers and Software package has newer Software but the actual MEI Driver may still be an older version.
Note: The MEI Installer includes the MEI Driver but allows easy installation of it. However, since we cannot always find the latest MEI Installer, it is advised to manually install the MEI Driver in case its version is newer. MEI Installer v11.7.0.1069 includes MEI Driver v11.7.0.1057. MEI Installer v11.0.6.1194 includes MEI Driver v11.0.5.1189.
D5. Old Intel SOL “Driver” Only
These packages contain only the Intel SOL “Driver” without any additional software or system services. It is compatible only with Corporate/5MB systems. If the software and system services are required in case of remote management etc, users of such systems should install the equivalent complete Drivers and Software package (section D1).
SOL “Driver” v11.6.0.1009 (ME 9)
SOL “Driver” v11.0.0.1136 (ME 7-8)
SOL “Driver” v6.2.50.1060 (ME 6)
SOL “Driver” v5.5.1.1012 (ME 5)
SOL “Driver” v5.4.1.1016 (ME 4)
SOL “Driver” v5.4.1.1051 (ME 3)
SOL “Driver” v5.3.1.1046 (ME 2 MB)
SOL “Driver” v5.2.0.1019 (ME 2 DT)
Note: The SOL “Drivers” for ME 2-5 listed above are part of the complete Drivers and Software packages found at section D2. A newer Drivers and Software package has newer Software but the actual SOL “Driver” may still be an older version.
Note: The SOL “Driver” is not really a driver but rather a placeholder INF file which assigns a correct device name at Device Manager and prevents the latter from showing the yellow exclamation mark of “No driver was found for this device”.
This guide is relevant to those who need to clean the DATA section of an Engine (CSME, ME, CSTXE, TXE) Region, which is part of a dumped SPI/BIOS image, in order to flash the latter on a different machine of the same OEM model. It is not meant as a guide on how to completely transform a dumped Engine region into a stock Intel-provided one. Although the guide can be used for that sometimes, the goal is not to update the firmware but to clean the already existing one inside the dumped SPI/BIOS image from any system-specific data while maintaining any configuration settings applied by the OEM of the given model. In this guide, the term "system" means an individual user machine whereas "model" refers to all those "systems" released by the OEM.
A. About Engine Regions & Configuration
The SPI/BIOS chip firmware is divided into regions which control different aspects of an Intel-based system. The mandatory regions are the Flash Descriptor64 (FD, controls read/write access between the regions among other things), the (Converged Security) Management or Trusted Execution Engine (CSME/CSTXE/ME/TXE, holds the Engine firmware which has been configured for a specific system) and the BIOS. The Type of each (CS)ME/(CS)TXE firmware Region can be either Stock (RGN, clean/stock/unconfigured images provided by Intel to OEMs) or Extracted (EXTR, dirty/extracted/configured images from various SPI/BIOS). The (CS)ME or (CS)TXE firmware at the system's SPI/BIOS chip is always EXTR, generated by the OEM after configuring the equivalent RGN at the factory via Intel Flash Image Tool (FIT).
The Engine firmware Regions (RGN/EXTR) consist of two sections: CODE and DATA. CODE is the actual Engine firmware whereas DATA is where all the system-specific settings are stored, as configured by the OEM at the factory via Intel Flash Image Tool. The Engine firmware is not static as it holds system-specific configuration and can additionally be slightly configured by the Engine co-processor while the system is running in order to provide the proper support and functionality. Any such changes are written into the DATA section of the Engine Region and the firmware is considered initialized. That means that the DATA section can be in one of three states: Unconfigured, Configured or Initialized. Unconfigured means that the Engine firmware image is the stock one Intel provides and not configured at all (RGN). Configured means that the OEM has applied model specific settings and the Engine region is ready for deployment (EXTR). Initialized means that the Engine region comes from a system which was already running and thus the Engine co-processor has further configured the DATA section to suit that particular system better (system specific or dirty EXTR).
A dumped SPI/BIOS image comes from a system which was already operating so the contained Engine Region should have a Initialized DATA section. In order for that dump to be usable on another system of the same OEM model we need to clean the "Initialization" extra data and thus end up with an Engine Region which has a Configured-only DATA section. This is important because on some cases these small dumped "initialization" changes made by the Engine co-processor of a system can lead to a malfunctioning or a corrupted Engine Region when transferred to another system even one of the same OEM model.
B. Helpful Resources
First you need to identify what Engine firmware the dumped SPI/BIOS image has inside. For that you can use ME Analyzer 88 tool which is capable of telling you the version, sku, release, type etc of any inputted Engine firmware. You can use it to analyze both the dumped SPI/BIOS image you plan to clean and the firmware with which you plan to achieve that. The latter can be retrieved from Intel (CS)ME, CS(TXE), CS(SPS), PMC, PHY & PCHC Firmware Repositories 202 thread which includes all Engine (CSME, ME, CSTXE, TXE) firmware that we have gathered for such cases.
Before proceeding, make sure to also check the dedicated Intel Management Engine: Drivers, Firmware & System Tools 258 and Intel Trusted Execution Engine: Drivers, Firmware & System Tools 30 threads first. There you can find some more information about each firmware's chipset compatibility as well as the Engine System Tools packages which include the Flash Image Tool (FIT/FITC/FTOOLC) which we will be using for the cleanup process. You will also understand various terms which are used throughout the guide such as FIT, FITC, FTOOLC, CSE, CSME, CSTXE, RGN, EXTR, UPD, FD and so on.
C. Method Compatibility
This method has been tested to work on (CS)ME 2 - 15 and (CS)TXE 1 - 4. The process depending on the generation, so the guide differs. It has not been tested on any (CS)SPS firmware.
Since the purpose of the guide is to clean the DATA section, it is important to choose a clean RGN Engine firmware from the Intel Engine Firmware Repositories thread and not EXTR which is extracted from various SPI/BIOS images/dumps and considered dirty as far as the DATA section is concerned. Moreover, a full RGN Engine Region is required and not an Update (UPD) image. That means that you should look only for Engine firmware of this structure at the Repositories:
Major.Minor.Hotfix.Build_SKU_PRD_RGN
As previously mentioned, the goal is not necessarily to update the Engine firmware so you can choose any RGN firmware of the same SKU as long as the major and minor versions are the same. It is usually recommended to take the exact same RGN firmware from the repositories, otherwise the closest you can find in case that one doesn't exist or it's not RGN, same SKU etc.
In this section we have taken as an example a SPI/BIOS image dump of a model which comes with ME firmware version 9.1.x.xxxx and SKU 1.5MB. However, the same applies to ME 2 - 3 firmware.
3. Open the dumped SPI/BIOS image with ME Analyzer to see what major/minor version we need as well as SKU. In this case we have:
So our SPI/BIOS image dump has a ME 9.1 firmware with 1.5MB SKU.
4. Browse the Repository pack, copy the same (or as similar as possible) ME RGN firmware of the same SKU and major/minor version (as instructed above) somewhere and then rename it to "ME Region.bin". In this case:
So we pick the firmware file 9.1.25.1005_1.5MB_PRD_RGN which matches perfectly what we saw at ME Analyzer. If for example the dumped SPI/BIOS image had ME 9.1.37.1002, we would have picked ME 9.1.32.1002 instead because the one we wanted is EXTR and not RGN. Thus, we rename the "9.1.25.1005_1.5MB_PRD_RGN.bin" copy to "ME Region.bin".
5. From the System Tools folder, go to Flash Image Tool subfolder and run ftoolc.exe. Drag & drop the dumped SPI/BIOS image you want to clean. After it is done loading:
Go to Build > Build Settings... , untick the option to "Generate intermediate build files", leave all other settings intact and click OK.
6. Keep the FTOOLC window open. At the FITC folder there should now be a folder named after the inputted file, in this case it's named "Z97OCF1.80". Enter "Decomp" subfolder. There should be a number of files there (BIOS Region, Flash Descriptor, OEM Region etc) including a "ME Region.bin" file. Take the previous "ME Region.bin" file you saved at step 4 and copy it where the current "ME Region.bin" file is, effectively replacing it.
7. Go to the already open FTOOLC window, click the "Build Image" icon (or "Build > Build Image"), save as "intermediate.bin" and it should complete successfully.
8. At the FTOOLC folder you should now see a file named "intermediate.bin" which is the dumped SPI/BIOS image with an Engine region which has an "Unconfigured" DATA section without any needed "Configuration" or unneeded "Initialization" information stored. Thus, it now needs to be "Configured".
9. From the System Tools folder, go to iAMTNVM subfolder and open a command prompt there. Copy the original input image (for example: "input.bin") as well as the Unconfigured one ("intermediate.bin") at the iAMTNVM subfolder. At the command prompt, enter "AMTNVM.exe -parse input.bin -out config.txt". A "config.txt" file should be created which holds the input firmware configuration. To transfer it into the Unconfigured image, enter "AMTNVM.exe -edit intermediate.bin config.txt -out outimage.bin" which should build the final "Configured" output SPI/BIOS image.
10. Now, you need to verify that the resulting image has the same configured DATA settings as the imported one.
Remove any leftover temporary files from FTOOLC's directory (folders, ftool.ini, ftool.log). Run FTOOLC and drag & drop the output file. Go to "File > Save As" and save the configuration xml file with a descriptive name such as "after.xml". Afterwards, close the FTOOLC window. Repeat this step for the original image and you should end up with two configuration xml files, in this case they are named "before.xml" and "after.xml". Open these two files in any comparison tool that supports XML and check for any differences. All settings should be identical apart from "InputFile" fields.
Go to iAMTNVM subfolder and open a command prompt there. At the command prompt, enter "AMTNVM.exe -parse input.bin -out before.txt" followed by "AMTNVM.exe -parse outimage.bin -out after.txt". You should end up with two configuration txt files, in this case they are named "before.txt" and "after.txt". Open these two files in any comparison tool and check for any differences. All settings should be identical.
Import the output file to ME Analyzer and check if the Major/Minor versions & SKU are the same as before. Also, make sure the Type is reported as "Extracted" which means that the inputted image is OEM/FTOOLC configured. Whether the DATA section is now Configured and not Initialized cannot be checked/verified by ME Analyzer but if you followed the above steps properly you should not be having any issues.
D2. ME 4 - 6
In this section we have taken as an example a SPI/BIOS image dump of a model which comes with ME firmware version 9.1.x.xxxx and SKU 1.5MB. However, the same applies to ME 4 - 6 firmware.
3. Open the dumped SPI/BIOS image with ME Analyzer to see what major/minor version we need as well as SKU. In this case we have:
So our SPI/BIOS image dump has a ME 9.1 firmware with 1.5MB SKU.
4. Browse the Repository pack, copy the same (or as similar as possible) ME RGN firmware of the same SKU and major/minor version (as instructed above) somewhere and then rename it to "ME Region.bin". In this case:
So we pick the firmware file 9.1.25.1005_1.5MB_PRD_RGN which matches perfectly what we saw at ME Analyzer. If for example the dumped SPI/BIOS image had ME 9.1.37.1002, we would have picked ME 9.1.32.1002 instead because the one we wanted is EXTR and not RGN. Thus, we rename the "9.1.25.1005_1.5MB_PRD_RGN.bin" copy to "ME Region.bin".
5. From the System Tools folder, go to Flash Image Tool subfolder and run fitc.exe. Drag & drop the dumped SPI/BIOS image you want to clean. After it is done loading:
Go to Build > Build Settings... , untick the option to "Generate intermediate build files", leave all other settings intact and click OK.
If you are working on an Engine region only (extracted via Flash Programming Tool with "-me" parameter or via UEFITool > ME region > Extract as is...) and not a full SPI/BIOS image (Flash Descriptor + Engine + BIOS), go to "Flash Image > Descriptor Region > Descriptor Map" and set "Number of Flash Components" to "0".
If you are working on ME 5 - 6, go to Flash Image > Configuration > "Features Supported" or "Intel Anti-Theft Technology" and set "Intel (R) Anti-Theft Technology Permanently Disabled?" to "Yes" or "Enable Intel Anti-Theft Technology" to "false". Intel Anti-Theft Technology has been EOL since January 2015 and can cause issues if left activated nowadays.
6. Keep the FITC window open. At the FITC folder there should now be a folder named after the inputted file, in this case it's named "Z97OCF1.80". Enter "Decomp" subfolder. There should be a number of files there (BIOS Region, Flash Descriptor, OEM Region etc) including a "ME Region.bin" file. Take the previous "ME Region.bin" file you saved at step 4 and copy it where the current "ME Region.bin" file is, effectively replacing it.
7. Go to the already open FITC window, click the "Build Image" icon (or "Build > Build Image") and it should complete successfully.
8. At the FITC folder you should now see a file named "outimage.bin" which is the dumped full SPI/BIOS (or ME) image with an Engine region which has a Configured DATA section without any unneeded "Initialization" information stored.
9. Now, you need to verify that the resulting image has the same configured DATA settings as the imported one.
Remove any leftover temporary files from FITC's directory (folders, fitc.ini, fitc.log). Run FITC and drag & drop the output file. Go to "File > Save As" and save the configuration xml file with a descriptive name such as "after.xml". Afterwards, close the FITC window. Repeat this step for the original image and you should end up with two configuration xml files, in this case they are named "before.xml" and "after.xml". Open these two files in any comparison tool that supports XML and check for any differences. All settings should be identical apart from "InputFile" fields and possibly Intel Anti-Theft related ones such as "SmBusMctpAddrEn", "SmBusMctpAddr" & "ATPerm", if those required changes at step 5.
If you are working on ME 6, remove any leftover temporary files from FITC's directory (folders, fitc.ini, fitc.log, before.xml, after.xml etc). Run FITC and drag & drop the output file. Rename the file "ConfigParams.txt" to "before.txt" and close FITC. Run FITC and drag & drop the original file. Rename the file "ConfigParams.txt" to "after.txt" and close FITC. You should end up with two configuration txt files, in this case they are named "before.txt" and "after.txt". Open these two files in any comparison tool and check for any differences. All settings should be identical apart from any Intel Anti-Theft related ones, if those required changes at step 5.
If you are working on ME 4 - 5, remove any leftover temporary files from FITC's directory (folders, fitc.ini, fitc.log, before.xml, after.xml etc). Run FITC, drag & drop the output file and close it. Run FITC, drag & drop the original file and close it. At the FITC folder there should now be two folders named after the inputted files. At each input file folder, enter "Decomp" subfolder, copy "Configuration.txt" (ME 5) or "NVARs.txt" (ME 4) file and rename them to "before.txt" and "after.txt" respectively. You should end up with two configuration txt files, in this case they are named "before.txt" and "after.txt". Open these two files in any comparison tool and check for any differences. All settings should be identical apart from any Intel Anti-Theft related ones, if those required changes at step 5.
Import the output file to ME Analyzer and check if the Major/Minor versions & SKU are the same as before. Also, make sure the Type is reported as "Extracted" which means that the inputted image is OEM/FITC configured. Whether the DATA section is now Configured and not Initialized cannot be checked/verified by ME Analyzer but if you followed the above steps properly you should not be having any issues.
As an extra verification step, you can open your original SPI/BIOS image dump in one FITC window and the output image in another and manually check quickly if the Engine Region settings are identical at both. This method is not needed if you have already checked via the configuration xml & txt files, it is not recommended because some settings are not visible at the FITC window but only at the configuration files and it requires a lot of time for manual comparisons.
10. Last but not least, if you are working on ME 5 - 6, once your new cleaned+configured full SPI/BIOS dump or Engine region is flashed on the target system, run Flash Programming Tool with command fpt -greset and wait for the system to reset (no settings are lost). This step is very important because it forces the Engine co-processor to re-initialize and properly accept any changes to its SPI/BIOS image region counterpart.
If you are working on an Engine region only (extracted via Flash Programming Tool with "-me" parameter or via UEFITool > ME region > Extract as is...) and not a full SPI/BIOS image (Flash Descriptor + Engine + BIOS), make sure that the output region has the same size at the input/dumped one. To do that, subtract the output region size from the input/dumped one to get the difference, which is the amount of 0xFF padding that needs to be appended at the end of the output region using a hex editor. For example, in a hypothetical case in which the size difference is 0xA000, the output region would need to be adjusted in HxD Hex Editor 2 like so:
D3. ME 7 - 10 & TXE 1 - 2
In this section we have taken as an example a SPI/BIOS image dump of a model which comes with ME firmware version 9.1.x.xxxx and SKU 1.5MB. However, the same applies to all ME 7 - 10 and TXE 1 - 2 firmware.
3. Open the dumped SPI/BIOS image with ME Analyzer to see what major/minor version we need as well as SKU. In this case we have:
So our SPI/BIOS image dump has a ME 9.1 firmware with 1.5MB SKU.
4. Browse the Repository pack, copy the same (or as similar as possible) ME/TXE RGN firmware of the same SKU and major/minor version (as instructed above) somewhere and then rename it to "ME Region.bin" or "TXE Region.bin" depending on what you're working with. In this case:
So we pick the firmware file 9.1.25.1005_1.5MB_PRD_RGN which matches perfectly what we saw at ME Analyzer. If for example the dumped SPI/BIOS image had ME 9.1.37.1002, we would have picked ME 9.1.32.1002 instead because the one we wanted is EXTR and not RGN. Thus, we rename the "9.1.25.1005_1.5MB_PRD_RGN.bin" copy to "ME Region.bin".
5. From the System Tools folder, go to Flash Image Tool subfolder and run fitc.exe. Drag & drop the dumped SPI/BIOS image you want to clean. After it is done loading:
Go to Build > Build Settings... , untick the option to "Generate intermediate build files", leave all other settings intact and click OK.
If you are working on FITC v8.1.40.1456 with ME 8 firmware which is configured as any "Intel (R) C600 Series Chipset" (Patsburg SKU), then you must use a ME region only for the cleanup process and not a SPI/BIOS image. So if you have a SPI/BIOS image, first extract the ME region and then load it to FITC. That is due to a FITC bug in which Patsburg settings are not properly shown/transferred when using anything but a bare Engine region image (extracted via Flash Programming Tool with "-me" parameter or via UEFITool > ME region > Extract as is...). More info can be found here 2. When you load the bare ME region at FITC, if the SKU at the top bars does not match what you see when loading the full SPI/BIOS image, make sure to first adjust that accordingly and don't leave it empty or different.
If you are working on ME 9, go to "Flash Image > ME Region > Configuration > Boot Guard" and make sure that "Boot Guard Profile Configuration" is not set to "Unknown". If it is set to "Unknown", change it to the default value of "Boot Guard Profile 0 - No_FVME". Also, go to "Flash Image > ME Region > Configuration > Integrated Clock Controller" and make sure that "Default Lock Enables Mask" is not set to "Unknown". If it is set to "Unknown", change it to the default value of "0:Default".
If you are working on an Engine region only (extracted via Flash Programming Tool with "-me" parameter or via UEFITool > ME region > Extract as is...) and not a full SPI/BIOS image (Flash Descriptor + Engine + BIOS), go to "Flash Image > Descriptor Region > Descriptor Map" and set "Number of Flash Components" to "0".
If you are working on ME 7 - 9 or TXE 1, go to Flash Image > ME/TXE Region > Configuration > Features Supported and set "Intel (R) Anti-Theft Technology Permanently Disabled? " to "Yes". Intel Anti-Theft Technology has been EOL since January 2015 and can cause issues if left activated nowadays.
If you are working on a SPI/BIOS image with ME 7 - 9, go to Flash Image > Descriptor Region > PCH Straps > PCH Strap 2 and set "Intel (R) ME SMBus MCTP Address Enable" to "false". Also, set "Intel (R) ME SMBus MCTP Address" to "0x00". These are Intel Anti-Theft Technology settings and these changes will stop the "MCTP 3G" error seen at Intel MEManuf tool when the former is disabled.
Note: These two settings are set at the Flash Descriptor (first 4KB of a full SPI/BIOS image) and not at the Engine Region (extracted via Flash Programming Tool with "-me" parameter or via UEFITool > ME region > Extract as is...). So for these to apply, you need to reflash the FD as well either by preparing a full SPI/BIOS image (Flash Descriptor + Engine + BIOS) or by flashing it manually via a tool such as Flash Programming Tool with -desc command.
6. Go to "File > Save As" and save the configuration xml file, in this case it's named "config.xml". Afterwards, close the FITC window. 7. At the FITC folder there should now be a folder named after the inputted file, in this case it's named "Z97OCF1.80". Enter "Decomp" subfolder. There should be a number of files there (BIOS Region, Flash Descriptor, OEM Region etc) including a "ME Region.bin" or "TXE Region.bin" file. Take the previous "ME Region.bin" or "TXE Region.bin" file you saved at step 4 and copy it where the current "ME Region.bin" or "TXE Region.bin" file is, effectively replacing it.
8. Run FITC again. From "File > Open" select the saved configuration xml file from step 6 and open it.
9. Click the "Build Image" icon (or "Build > Build Image") and it should complete successfully.
10. At the FITC folder you should now see a file named "outimage.bin" which is the dumped SPI/BIOS (or ME/TXE) image with an Engine region which has a Configured DATA section without any unneeded "Initialization" information stored.
11. Now, you need to verify that the resulting image has the same configured DATA settings as the imported one.
Remove any leftover temporary files from FITC's directory (folders, fitc.ini, fitc.log). Run FITC and drag & drop the output file. Go to "File > Save As" and save the configuration xml file with a descriptive name such as "after.xml". Afterwards, close the FITC window. Repeat this step for the original image and you should end up with two configuration xml files, in this case they are named "before.xml" and "after.xml". Open these two files in any comparison tool that supports XML and check for any differences. All settings should be identical apart from "InputFile" fields and possibly Intel Anti-Theft related ones such as "SmBusMctpAddrEn", "SmBusMctpAddr" & "ATPerm", if those required changes at step 5.
Import the output file to ME Analyzer and check if the Major/Minor versions & SKU are the same as before. Also, make sure the Type is reported as "Extracted" which means that the inputted image is OEM/FITC configured. Whether the DATA section is now Configured and not Initialized cannot be checked/verified by ME Analyzer but if you followed the above steps properly you should not be having any issues.
As an extra verification step, you can open your original SPI/BIOS image dump in one FITC window and the output image in another and manually check quickly if the Engine Region settings are identical at both. This method is not needed if you have already checked via the configuration xml files, it is not recommended because some settings are not visible at the FITC window but only at the configuration file and it requires a lot of time for manual comparisons.
12. Last but not least, once your new cleaned+configured full SPI/BIOS dump or Engine region is flashed on the target system, run Flash Programming Tool with command fpt -greset and wait for the system to reset (no settings are lost). This step is very important because it forces the Engine co-processor to re-initialize and properly accept any changes to its SPI/BIOS image region counterpart.
If you are working on an Engine region only (extracted via Flash Programming Tool with "-me" parameter or via UEFITool > ME region > Extract as is...) and not a full SPI/BIOS image (Flash Descriptor + Engine + BIOS), make sure that the output region has the same size at the input/dumped one. To do that, subtract the output region size from the input/dumped one to get the difference, which is the amount of 0xFF padding that needs to be appended at the end of the output region using a hex editor. For example, in a hypothetical case in which the size difference is 0xA000, the output region would need to be adjusted in HxD Hex Editor 2 like so:
= BBAR on ICH8 =
There is no sign of BBAR (BIOS Base Address Configuration Register) in the
public datasheet (or specification update) of the ICH8. Also, the offset of
that register has changed between ICH7 (SPIBAR + 50h) and ICH9 (SPIBAR +
A0h), so we have no clue if or where it is on ICH8. Out current policy is to
not touch it at all and assume/hope it is 0.
= Accesses beyond region bounds in descriptor mode =
Intel's flash image tool will always expand the last region so that it covers
the whole flash chip, but some boards ship with a different configuration.
It seems that in descriptor mode all addresses outside the used regions can not
be accessed whatsoever. This is not specified anywhere publicly as far as we
could tell. flashrom does not handle this explicitly yet. It will just fail
when trying to touch an address outside of any region.
See also http://www.flashrom.org/pipermail/flashrom/2011-August/007606.html
= (Un)locking the ME region =
If the ME region is locked by the FRAP register in descriptor mode, the host
software is not allowed to read or write any address inside that region.
Although the chipset datasheets specify that "[t]he contents of this register
are that of the Flash Descriptor" [PANTHER], this is not entirely true.
The firmware has to fill at least some of the registers involved. It is not
known when they become read-only or any other details, but there is at least
one HM67-based board, that provides an user-changeable setting in the firmware
user interface to enable ME region updates that lead to a FRAP content that is
not equal to the descriptor region bits [NC9B].
There are different ways to unlock access:
- A pin strap: Flash Descriptor Security Override Strap (as indicated by the
Flash Descriptor Override Pin Strap Status (FDOPSS) in HSFS. That pin is
probably not accessible to end users on consumer boards (every Intel doc i
have seen stresses that this is for debugging in manufacturing only and
should not be available for end users).
The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of
the HECI/MEI PCI device by setting them to 4 (SECOVR_JMPR) [MODE_CTRL].
- Intel Management Engine BIOS Extension (MEBx) Disable
This option may be available to end users on some boards usually accessible
by hitting ctrl+p after BIOS POST. Quote: "'Disabling' the Intel ME does not
really disable it: it causes the Intel ME code to be halted at an early stage
of the Intel ME's booting so that the system has no traffic originating from
the Intel ME on any of the buses." [MEBX] The ME indicates this in
bits [19:16] (Operation Mode) in the HFS register of the HECI/MEI PCI device
by setting them to 3 (Soft Temporary Disable) [MODE_CTRL].
- Previous to Ibex Peak/5 Series chipsets removing the DIMM from slot (or
channel?) #0 disables the ME completely, which may give the host access to
the ME region.
- HMRFPO (Host ME Region Flash Protection Override) Enable MEI command
This is the most interesting one because it allows to temporarily disable
the ME region protection by software. The ME indicates this in bits [19:16]
(Operation Mode) in the HFS register of the HECI/MEI PCI device by setting
them to 5 (SECOVER_MEI_MSG) [MODE_CTRL].
== MEI/HECI ==
Communication between the host software and the different services provided by
the ME is done via a packet-based protocol that uses MMIO transfers to one or
more virtual PCI devices. Upon this layer there exist various services that can
be used to read out hardware management values (e.g. temperatures, fan speeds
etc.). The lower levels of that protocol are well documented:
The locations/offsets of the PCI MMIO registers are noted in the chipset
datasheets. The actually communication is documented in a whitepaper [DCMI] and
an outdated as well as a current Linux kernel implementation (currently in
staging/ exist [KERNEL]. There exists a patch that re-implements this in user
space (as part of flashrom).
== Problems ==
The problem is that only very few higher level protocols are documented publicly,
especially the bunch of messages that contain the HMRFPO commands is probably
well protected and only documented in ME-specific docs and the BIOS writer's
guides. We are aware of a few leaked documents though that give us a few hints
about it, but nothing substantial regarding its implementation.
The documents are somewhat contradicting each other in various points which
might be due to factual changes in process of time or due to the different
capabilities of the ME firmwares, example:
Intel's Flash Programming Tool (FPT) "automatically stops ME writing to SPI
ME Region, to prevent both writing at the same time, causing data corruption." [ME8]
"FPT is not HMRFPO-capable, so needs [the help of the FDOPS pin] HDA_SDO if
used to update the ME Region." [SPS]
When looking at the various ME firmware editions (and different chipsets), things
get very unclear. Some docs say that HMRFPO needs to be sent before End-of-POST
(EOP), others say that the ME region can be updated in the field or that some
vendor tools use it for updates. This needs to be investigated further before
drawing any conclusion.
[PANTHER] Intel 7 Series Chipset Family Platform Controller Hub (PCH) Datasheet
Document Number: 326776, April 2012, page 857
[NC9B] Jetway NC9B flashrom v0.9.5.2-r1517 log with ME region unlocked.
NB: "FRAP 0e0f" vs. "FLMSTR1 0a0b".
http://paste.flashrom.org/view.php?id=1215
[MODE_CTRL] Client Platform Enabling Tour: Platform Software
Document Number: 439167, Revision 1.2, page 52
[MEBX] Intel Management Engine BIOS Extension (MEBX) User's Guide
Revision 1.2, Section 3.1 and 3.5
[DCMI] DCMI Host Interface Specification
Revision 1.0
[KERNEL] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/staging/mei;hb=HEAD
[SPI_PROG] Ibex Peak SPI Programming Guide
Document Number: 403598, Revision 1.3, page 79
[ME8] Manufacturing with Intel Management Engine (ME) Firmware 8.X on Intel 7 Series
Revision 2.0, page 59
[SPS] Manufacturing with Intel Management Engine (ME) on Intel C600 Series Chipset 1
for Romley Server 2 Platforms using Server Platform Services (SPS) Firmware
Revision 2.2, page 51
![[attachment-YnUUll]](/files/2022/11/14/bodysnatcher1.jpg)
![[attachment-1ZBLVv]](/files/2022/11/14/bodysnatcher2.jpg)
![[attachment-sjvoz8]](/files/2022/11/14/bodysnatcher3.jpg)
![[attachment-zLHpFZ]](/files/2022/11/03/checkmate.jpg)
![[attachment-KxD2E1]](/files/2022/07/19/me_fdojumper.jpg)
![[attachment-i5Y3gW]](/files/2022/07/19/fdo_manual.png)
![[attachment-OWzn7G]](/files/2022/07/19/me_bitlockerreset.png)
![[attachment-t1Iz6A]](/files/2022/07/19/me_spiflash16sop.jpg)
![[attachment-pNkXly]](/files/2022/07/17/hp-8300-fdo-flash-descriptor-override.jpg)
![[attachment-HcvssP]](/files/2022/07/17/hp-elite-8300-motherboard-top-view-900.jpg)
![[attachment-Dyps9m]](/files/2022/07/17/hp-elite-8300-bios-chip.jpg)
![[attachment-cHh6ON]](/files/2022/07/17/hp-8300-spi-programmer-bios-chip.jpg)
![[attachment-p1MWyC]](/files/2022/07/18/chipset.png)
