ME Cleaner: A cleaner for Intel ME (Management Engine) images.
This tools removes any unnecessary partition from an Intel ME firmware, reducing its size and its ability to interact with the system. It should work both with Coreboot and with the factory BIOS. Currently this tool:
* Scans the FPT (partition table) and checks that everything is correct
* Removes any partition entry (except for FTPR) from FPT
* Removes any partition except for the fundamental one (FTPR)
Tag: Intel ME
coreboot adds Intel BootGuard support to Intel ME Tool
“util/intelmetool: Add bootguard information dump support:
With this implementation it’s possible to detect the state of bootguard in intel based systems.
Currently it’s WIP and in a testphase. Handle it with care!”
ME Analyzer switches from closed-source to open-source
Great news, the tool “ME Analyzer” — for analyzing the Intel Management Engine (ME) — has switched from closed-source freeware to open source!!
Intel on Intel ME backdoors
Steve Grobman of Intel has a new blob post which talks about — amongst other things — concerns of backdoors in the Intel Management Engine.
BoingBoing on Intel ME
Damien Zammit has a new post on BoingBoing:
Intel x86s hide another CPU that can take over your machine (you can’t audit it)
Recent Intel x86 processors implement a secret, powerful control mechanism that runs on a separate chip that no one is allowed to audit or examine. When these are eventually compromised, they’ll expose all affected systems to nearly unkillable, undetectable rootkit attacks. I’ve made it my mission to open up this system and make free, open replacements, before it’s too late. […]
Intel x86s hide another CPU that can take over your machine (you can’t audit it)
Petition for Intel to build a no-ME system
Here is where to sign:
https://puri.sm/posts/petition-for-intel-to-release-an-me-less-cpu-design/
I hope someone does a petition to get the Stateless Laptop built. If Intel builds a new ME-less system, it should also be building this Stateless system as part of it.
http://blog.invisiblethings.org/2015/12/23/state_harmful.html
AND… I don’t understand why OEMs are dancing around with tamper resistant screws. IMO, a system needs a lock, a good one, since lockpicking is a normal hacker sport, most locks are useless. A good laptop should have a lock to prevent casual evil maids. The Google Chromebox Pixel Developer Mode scew is nice, but an evil maid could also use that, no lock. Cars have locks. Houses have locks. Computer server rooms have locks. Data contained in laptops are often worth more than cars and houses. Why do modern expensive computers have no locks? Cost? Governments would not want them, harder to access boxes going through customs? I want a Stateless Laptop, with a secure metal enclosure and a good quality lock. Then I’ll keep the key and thumbdrives with me, and just deal with rubberhose attacks, not evil maid attacks.
PTSecurity on Disabling Intel Management Engine
N3mes1s points out an article from Maxim Goryachy and Mark Ermolov of PTSecurity, on disabling the Intel Management Engine (ME).
http://ptsecurity.com
https://github.com/ptresearch/
Click to access How%20to%20become%20the%20sole%20owner%20of%20your%20PC.pdf
Plutomaniac’s ME Analyzer
There are three tools from the win-raid.com firmware modding community that I’ve not used, but I’ve heard are quite awesome tools. The first is UBU[1], the second is GOPupd[2], and the third is ME Analyzer, the subject of this blog post. ME Analyzer is a tool by Plutomaniac, a member of the win-raid.com firmware modding community. The tool parses Intel BIOS images and provides various infos about Management Engine Firmware in them. It also has a related Firmware Database which contains a lot of interesting information.
ME Analyzer is an Intel Engine Firmware Analysis Tool, a tool that you can show various details about Intel Engine Firmware (Management Engine, Trusted Execution Engine, Service Platform Services) images. It can be used to identify whether the firmware is updated, what Release, Type, SKU it is etc. Features:
* Supports all current & legacy Engine firmware (ME 1.x – 11.x , TXE 1.x – 2.x & SPS 1 – 4)
* All types of firmware files are supported (ME/TXE/SPS Regions, BIOS images etc)
* Partial Firmware Update support for Corporate ME 8-11 enabled platforms
* UEFI Bios Updater (UBU) and Lordkag’s Extractor integration support
* Firmware Family (ME, TXE or SPS), Date & Version number detection
* Production, Pre-Production & ROM-Bypass firmware release detection
* Region (Stock or Extracted) & Update firmware type detection
* Identification of the platform that the firmware was configured for via FITC
* SKU & target platform detection for all supported firmware releases
* Security Version Number (SVN), Version Control Number (VCN) & PV-bit detection
* Intel SPI Flash Descriptor Access Region detection, Skylake compatible
* Identification of whether the imported Engine firmware is up-to-date
* Proper CPT/PBG SKU & BlackList Table detection for ME 7.x firmware
* Special Apple Macintosh ME 7.0 & 9.5 firmware SKU support
* FWUpdate OEMID detection at Region & SPI/BIOS images
* Multiple drag & drop & sorting of rare/problematic Engine Firmware
* Multiple Engine Firmware Region detection, number only
* Unidentifiable Engine Firmware Region (ex: Corrupted, Compressed) detection
* Reports unknown firmware not found at the Engine Repository Database
* Reports unknown firmware Major, Minor, SKU, Type etc releases
* Shows colored text to signify the importance of notes, warnings, errors etc
Engine Firmware Repository Database:
ME Analyzer’s main goal is to allow users to quickly determine & report new firmware versions without the use of special Intel tools (FIT/FITC, FWUpdate) or Hex Editors. To do that effectively, a database had to be built. The Intel Engine Firmware Repositories is a collection of every ME, TXE & SPS firmware I have found. It’s existence is very important for ME Analyzer as it allows me to find new types of firmware, compare same major version releases for similarities, check for updated firmware etc. Bundled with ME Analyzer there’s a file called MEA.dat which is required for the program to run. It includes all CSE firmware that are available at the Repository thread. This accommodates two actions: a) Check whether the imported firmware is up to date and b) Help find new CSE firmware releases sooner by reporting them at the Intel Management Engine: Drivers, Firmware & System Tools or Intel Trusted Execution Engine: Drivers, Firmware & System Tools threads respectively.
ME Analyzer is closed source freeware, targetting Microsoft Windows platform. As always, if you can’t review the code, be cautious where/how you use it, until you are ready to ‘trust’ the author.
ME Analyzer requires ME Util v0.1, and includes a modified version of it:
https://github.com/skochinsky/me-tools
More information:
http://www.win-raid.com/t840f39-ME-Analyzer-Intel-Engine-Firmware-Analysis-Tool.html
http://www.win-raid.com/t832f39-Intel-Management-amp-Trusted-Execution-Engine-Firmware-Repository.html
http://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html
http://www.win-raid.com/t624f39-Intel-Trusted-Execution-Engine-Drivers-Firmware-amp-System-Tools.html
[1]
[2]
Hackaday on Intel ME
Hackaday has a new blog on the Intel ME, covering recent news, as well as some background history I’d not seen.
[…] To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that’s used in the firmware remains an unsolved problem. But unsolved doesn’t mean that people aren’t working on it. There are efforts to break the ME’s Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now. […]
FYI: This blog was Hackaday’s first UEFI-tagged post. A few others had BIOS tags.
JEFF-Tools
Igor Skochinsky has created JEFF-Tools, tools for use Intel Management Engine. JEFF-Tools currently contains 2 tools:
dump_jeff.py
This script allows you to dump the JEFF files used by Intel ME’s DAL (Dynamic Application Loader). It supports the following input formats:
raw JEFF file (‘JEFF signature’)
JEFF packaged as an ME applet with signed manifest header ($MN2 magic) (currently ME 8-9.5 only)
any binary containing an uncompressed JEFF file inside (e.g. JOM_mod.bin produced by unpacking an ME firmware)
unp_dalp.py
This script unpacks DAL applets from a .dalp file (such files are used by Intel to package several ME applets into one XML).
https://github.com/skochinsky/jeff-tools
See-Also some Intel ME tools and presentations here:
Tweaktown on Intel ME
The modding site Tweaktown.com has a forum on the Intel ME, which has a LOT of interesting links:
http://forums.tweaktown.com/gigabyte/54860-about-intel-management-engine-firmware.html#post469078
New ITL research on x86 security!!
Joanna of Invisible Things Lab has a new blog post on Intel x86 security!!
http://blog.invisiblethings.org/2015/10/27/x86_harmful.html
Click to access x86_harmful.pdf
http://blog.invisiblethings.org/papers/2015/x86_harmful.epub
https://github.com/rootkovska/x86_harmful
And there’s a second paper in the works, as well!
Purism BIOS efforts
Purism mentioned in a Tweet that they have 3 developers working on Intel Management Engine:
They have one document, from the summer, talking about how they’re trying to free the BIOS:
https://puri.sm/posts/freeing-the-bios-the-memory-init-stage/
And another more recently-updated status page:
https://puri.sm/road-to-fsf-ryf-endorsement-and-beyond/
Purism offers the first high-end privacy and freedom-respecting laptops by manufacturing the motherboard and sourcing daughter cards, where all chips are designed to run free software. Purism laptops are completely free from the bootloader through the kernel (with no mystery code, binary blobs, or firmware blobs), including the operating system and all software. We have yet to free the Intel FSP binary and ME binary from within the coreboot BIOS to move us toward FSF RYF endorsement. We are working diligently to free the BIOS, but our goal is to go further than that: Purism also intends to free the firmware within HDDs and SSDs.
I’m still unclear how this will result. I’m of two minds on this: I love the idea of having a system I can trust, so am happy to see projects like Novena and Purism. On the other hand, Purism is fighting Intel’s security mechanisms, and I’m a little concerned the result will remove some Intel defensive technology that makes the system more easily attackable.
Their current model has a kill switch, which is a nice feature. [I’d also like a case that closes access to the ports when closed, and has a LOCK, with a good quality lock, that can’t be easily picked. That’d be an issue for TSA checkpoints, though.] I might also consider getting ride of Suspend/Resume, a lot of attacks happen there, and systems are fast enough these days to live without this feature.
I wish other OEMs would compete with Purism, it would be nice to have more options than a handful of ancient refurbished Thinkpads and a handful of remaining Novenas. The current Purism model is nearly done with funding, only a few days left:
Interview with LegbaCore (and: their OpROM checker ships!)
A while ago, I emailed Corey and Xeno of LegbaCore, and sent them a few questions for an ‘interview’ for this blog. Well, here’s the results (also see EOM for URLs):
Q: This October in Singapore you’re giving 3-days of training at HITB. Besides new Apple EFI skills, can you give us some other new things that’ll be in this training?
A: The course introduces the basics of evaluating firmware and SMM on modern platforms for security vulnerabilities, as well as for potential compromises. Specifically we work through methodologies for identifying whether or not your system contains publically known vulnerabilities (which a great majority of them do). We also introduce a firmware forensic and reverse engineering methodology for identifying potential firmware compromises… so say if you got comprised by something like the hacking team UEFI rootkit, we’d talk about the tools and procedures that would be useful for identifying and analyzing this threat both on one particular system and at scale across your enterprise.
The most important point of the training is it will be focused on real hardware that is deployed in real environments. A large portion of the course will involve evaluating the hardware that students bring with them. This way if you’re in charge of malware detection/response in an enterprise, you’ll walk away with actionable information related to the hardware you are deploying on your network.
Q: You had a Twitter post a few weeks (months?) back, saying that you were going to start releasing information about OEM systems’s vulnerabilities. What’s up with that project, I’m eager to see this data, as Consumer Reports and other computer review sources are useless for this most crucial pre-sales information. Any chance you could give FirmwareSecurity.com a teaser of this information, perhaps one new OEM model released in the last 6 months that’s insecure? 🙂
A: We anticipate that the project to start making some vendors’ firmware security failings more apparent (via a public website) will probably kick off in early 2016. We want to give all vendors that we think may have an interest in improving their security a chance to either talk with us about working with them, or show that they can make measurable security improvements on their own within this timeframe.
Q: You had a Twitter post a few days ago, pointing to a new LegbaCore Github repository for a new Option ROM checking tool. This sounds very interesting! What kinds of Option ROM(s) will it support? What platform(s) will it run on? When can we expect initial release?
A: It will only integrity check the Apple Thunderbolt to Ethernet adapter’s option ROM. It will work in conjunction with a port of the linux tg3 kernel driver to run on Macs to dump the OROM. The “ethtool” command can also be run to dump the OROM on linux systems that have a thunderbolt port and the tg3 driver available. The tool will be released to coincide with the talk at BlackHat, August 6th.
Q: Beyond this new Option ROM checker, does LegbaCore have any additional tool plans in the works? If so, any details to reveal?
A: Our current thinking on tools is that we expect that we will make clean-slate “best effort” tools freely available at some point in the future. These tools would be like all typical security tools, being not particularly trustworthy, and thus vulnerable to attacker subversion. They would mostly be useful for catching attackers as they first enter into the domain, and are not particularly sophisticated. However we will only make those tools available once we have commercial-grade tools available, that have a trust argument for why these paid tools have the ability to stand up to sophisticated and well-resourced adversaries. And in the background we will work with vendors to add capabilities such as SMM Dual Monitor mode, which significantly strengthen the trust arguments
Q: The Copernicus release is mostly Windows-centric, but also includes a cross-platform, bios_diff.py tool in the release. Will the new LegbaCore github tree include a open source bios_diff project, perhaps to get open source patches for improved BIOS parsing beyond EFIPWN, perhaps like that in UEFITool?
A: While bios_diff.py continues to provide the only simple, semantically aware integrity checking capability for BIOS, it has a number of issues. E.g. in the context of our latest work, it simply doesn’t work to integrity check Apple firmware, because Apple firmware update structure does not look the same as the structure on-disk.
Q: Post-October/HITB, what’s the next LegbaCore BIOS/UEFI security training event you’ll be giving?
A: Later in October I’ll be offering a similar training at Ruxcon breakpoint. Beyond that we are fairly busy with private training engagements.
Q: Any hints what kind of new firmware vulnerability research you’re working on, and when we might see some of the results?
A: We are branching out to the security of peripheral devices such as network cards, HDs/SSDs, embedded controllers, GPUs, the Intel Management Engine, etc. We are shooting to have our first talk on one of these topics around December.
Q: Recently Stephan of coreboot mentioned that in the past MITRE said that Chrome OS firmware was more secure than UEFI. Both coreboot+depthcharge’s Verified Boot and UEFI’s Secure Boot both seem pretty similar, in terms of PKI usage. Have you an opinion on the security strength of either of these firmware solutions?
A: We have never evaluated CoreBoot to any level of depth. Hardware-wise, we like the Chromebook requirement to provide physical write protection for the flash chip via a screw. The way that Chromebooks supposedly root their boot trust in the embedded controller hardware, as described to us, sounded like a good idea. But without having actually spent time looking at the platforms, we cannot say much in terms of the security (or lack thereof) relative to UEFI-based systems.
—-[End of interview.]
Thanks Corey and Xeno!
Links:
<blink>THEIR OPROM CHECKER IS RELEASED!</blink>
The code was added 5 days ago, and I missed it!
https://github.com/legbacore/t2e_integrity_check
Upcoming training:
http://gsec.hitb.org/sg2015/sessions/tech-training-6-introductory-bios-smm-attack-defense/
https://ruxconbreakpoint.com/training/bios/
http://www.legbacore.com/Training.html
Stephan’s comment on coreboot security:
