coreboot and Intel ME

ME_Cleaner updated to set HAP bit

UNTESTED: Set the HAP bit:
Positive Technologies discovered the presence of an undocumented HAP bit in the PCHSTRP0 field of the descriptor which, when set to 1, disables completely Intel ME just after the initialization. This is confirmed both by an analysis of the status of Intel ME after the setting of the bit and by reverse engineering the BUP module.


PTSecurity on Intel ME

Our team of Positive Technologies researchers has delved deep into the internal architecture of Intel Management Engine (ME) 11, revealing a mechanism that can disable Intel ME after hardware is initialized and the main processor starts. In this article, we describe how we discovered this undocumented mode and how it is connected with the U.S. government’s High Assurance Platform (HAP) program.

Disclaimer: The methods described here are risky and may damage or destroy your computer. We take no responsibility for any attempts inspired by our work and do not guarantee the operability of anything. For those who are aware of the risks and decide to experiment anyway, we recommend using an SPI programmer.[…]

Finnbarr on state of Intel ME hacking tools

Finbarr has a new article on Intel ME, in which he’s wondering if current tools are acquiring bitrot:

[…]It seems to me there is little ongoing work to enhance existing ME analysis tools such as me_unpack or the meloader IDA plugin to support ME firmware versions 9.5.X.X or later. Possible reasons for this state of affairs include the lack of available documentation for ME versions above 9, no ROMB-enabled ME firmware later the version 9 in the wild, or simply that the ME tool developers have moved on to other projects.

Also, this post pointed out an Intel ME web site I had not seen before:

It has an invalid HTTPS cert, and appears to have been last updated a few years ago.

PS: Also, if you are using Finnbarr’s UEFI-Utilities, note that he’s recently started including ThinkPwn as one of the binaries, so be careful how you deploy it. CHIPSEC blacklists ThinkPwn as one of handful of known UEFI malware modules.

ME Analyzer 1.16.3 released

ME Analyzer Features:
Supports all Engine firmware generations (ME 1 – 11, TXE 1 – 3 & SPS 1 – 4)
Supports all types of file images (Engine Regions, SPI/BIOS images etc)
Detection of Family, Version, SKU, Date, Revision, Platform etc info
Detection of Production, Pre-Production, ROM-Bypass, MERecovery etc Releases
Detection of Region (Stock/clean or Extracted/dirty), Update etc Types
Detection of Security Version Number (SVN), Version Control Number (VCN) & PV
Detection of firmware’s Flash Image Tool platform configuration for ME 11 & up
Detection of Intel SPI Flash Descriptor region’s Access Permissions
Detection of whether the imported Engine firmware is updated
Detection of unusual Engine firmware (Corrupted, Compressed, OEM etc)
Detection of multiple Engine regions in input file, number only
Detection of special Engine firmware BIOS GUIDs via UEFIFind
Detection of unique mobile Apple Macintosh Engine firmware SKUs
Advanced detection & validation of Engine region’s firmware Size
Ability to analyze multiple files by drag & drop or by input path
Ability to unpack all Engine x86 firmware (ME >= 11, TXE >= 3, SPS >= 4)
Ability to detect & categorize firmware which require attention
Ability to validate Engine region’s $FPT checksums & entries counter
Ability to detect various important firmware problems and corruptions
Supports SoniX/LS_29’s UBU, Lordkag’s UEFIStrip & CodeRush’s UEFIFind
Reports all firmware which are not found at the Engine Repository Database
Reports any new, unknown, problematic, incomplete etc Engine firmware images
Features command line parameters to enhance functionality & assist research
Features user friendly messages & proper handling of unexpected code errors
Shows colored text to signify the importance of notes, warnings & errors
Open Source project licensed under GNU GPL v3, comment assisted code



Reversing Intel ME’s ROMP module

Reverse-engineering the Intel Management Engine’s ROMP module
Youness Alaoui, Hardware enablement developer

Last month, while I was waiting for hardware to arrive and undergo troubleshooting, I had some spare time to begin some Intel ME reverse engineering work. First, I need to give some shout out to Igor Skochinsky, a Hex-Rays developer, who had been working on reverse engineering the Intel ME for a while, and who has been very generous in sharing his notes and research on the ME with us, which is going to be a huge help and cut down months of reverse engineering and guesswork. Igor was very helpful in getting me to understand the bits that didn’t make sense to me. The first thing I wanted to try and reverse was the ROMP module. It is one of the two modules that me_cleaner doesn’t remove, and given how small it is (less than 1KB of code+data), I thought it would be a good starting point. Turns out my hunch was right, as I finished reverse engineering that module after only a couple of days.[…]

Intel AMT story, continued

A little bit more (warning: a few of these are related to Intel ME hardware, not Intel AMT firmware):

Rumor has it that OpenAMT can also be used for AMT detection:

AMT advisory from ASUS:

Is Intel’s Management Engine Broken?


Intel AMT story, continued

Intel AMT chip bug suspected backdoor, but likely coding error
[…]Some researchers accused the vulnerability of being a backdoor. Tatu Ylonen, the inventor of the Secure Shell protocol told SC Media Charlie Demerjan, the researcher who spotted the flaw, claims to have been in discussions over bug with Intel for years urging them t to fix it. “If his claim is true (I have no reason to doubt it but have no independent evidence), then it begins to sound very much like a backdoor,” Demerjan said. “I mean, if someone knows their product has a vulnerability that undermines the security of pretty much every enterprise server in the world and most security tools, wouldn’t they want to disclose it to the government, one of their biggest customers?”[…]

[…]What is clear, however, is that this flaw (which has existed for more than 9 years) truly is somewhere between nightmarish and apocalyptic. Taking no action is not an option.

Intel ME: based on Minix?

“[…]In addition, when we looked inside the decompressed vfs module, we encountered the strings “FS: bogus child for forking” and “FS: forking on top of in-use child,” which clearly originate from Minix3 code. It would seem that ME 11 is based on the MINIX 3 OS developed by Andrew Tanenbaum :)[…]”


Intel AMT story, continued

Click to access Silent-Bob-is-Silent.pdf

more on Intel AMT news

Intel AMT remotely exploitable since 2008?

Remote security exploit in all 2008+ Intel platforms
Nehalem through Kaby all remotely and locally hackable
May 1, 2017 by Charlie Demerjian
Every Intel platform from Nehalem to Kaby Lake has a remotely exploitable security hole. SemiAccurate has been begging Intel to fix this issue for literally years and it looks like they finally listened. The short version is that every Intel platform with AMT, ISM, and SBT from Nehalem in 2008 to Kaby Lake in 2017 has a remotely exploitable security hole in the ME (Management Engine) not CPU firmware. If this isn’t scary enough news, even if your machine doesn’t have SMT, ISM, or SBT provisioned, it is still vulnerable, just not over the network. For the moment. From what SemiAccurate gathers, there is literally no Intel box made in the last 9+ years that isn’t at risk. This is somewhere between nightmarish and apocalyptic.[…]


Schneier: avoid Intel/AMD hardware, Intel ME, and UEFI

[[UPDATE: See comment from one reader, I mistakingly took below quote to be from Bruce, where it is apparently from someone else. Oops.]]

Bruce Schneier has a new blog post on citizen cybersecurity, including advice for non-US citizens to avoid blobs in firmware.

I hope Intel and AMD are reading this. Are the patents in the IP you’re protecting in your FSP and AGESA binaries really worth the security risks you’re enabling for attackers to all of your systems? Open-sourcing your blobs will reduce this attack vector and make your products more trustworthy, and reduce the potential market loss to RISC-V and OpenPOWER, which by contrast to Intel/AMD have blob-free firmware potential.  In addition to criminal use by cybercriminals, backdoors can be “legally” misused by tyrants, bigly. Hidden backdoor management processes like Intel ME should be owner-controllable, including the ability to remove/disable it. How can I use NIST 147 guidance to check the hashes of the hundreds of blobs within the FSP/AGESA packages? The are numerous supply-chain opportunities for firmware attackers to subvert these blobs, at the IHV, OEM, ODM, IBV, some of which also have source access to these packages and modify them (for example Purism modifies FSP for their laptops, but they can’t publish their code, due to Intel NDA).

New Rules on Data Privacy for Non-US Citizens”
“- build firewalls everywhere, if possible based on non-Intel, non-AMD too, hardware platforms or at least supporting old, non-Intel ME and non-UEFI, firmware;”




more on ME Cleaner

I did a brief post on ME Cleaner, found on an article pointed out to me by a reader (i.e., I missed it). Phoronix has a story on ME Cleaner, including a pointer to it’s hardware/firmware-compatibility page, which I also missed: