Intel ME: The Way of Static Analysis

Image: Clive Darra, Flickr

Intel Management Engine (ME) has been known for over 10 years (since 2005), but official Internet sources about ME are few and far between. Fortunately, excellent works on the topic have been published in recent years. However, all of them deal with ME 10 and earlier, while modern computers implement ME 11, which was introduced in 2015 for the Skylake microarchitecture.

If you have never heard about ME, this is a good time to check out great slides from Igor Skochinsky about previous versions of ME.

In short, ME is a separate processor embedded in the chipset of any modern computer with an Intel CPU. ME runs even when the computer is sleeping or powered off (as long as it is plugged in to a power outlet). ME can access any part of RAM, but the RAM region used by ME is not accessible from the OS. What’s more, ME is capable of out-of-band access to the network adapter.

The most recent version of ME is 11. Older versions of ME were based on the ARCtangent/ARCompact/SPARC architecture, but version 11 is x86-based. This is helpful for us researchers since x86 is much more convenient (thanks to more available tools and past research to refer to).

However, ME v11 uses a different layout of data within the firmware image and old tools are unable to handle this layout properly. ME v11 also uses an unknown set of Huffman tables (which are required to decompress many modules embedded in firmware). This all makes it very difficult to start exploration of ME internals…

Playing with system tools

Intel is known to have at least two sets of tools for ME.

The first set, called “Intel ME System Tools,” is available to OEMs/vendors (think Acer, Gigabyte, Dell). This can be used to fine-tune ME firmware before delivering it to the end user. Fortunately for us, vendors often include these tools in the distribution package of BIOS updates, thus making them available to the general public.

The second set of tools is used internally within Intel and able to do almost anything with ME (including Huffman compression). We have never heard about any leaks of these tools, however.
We have collected many ME firmware images on the Internet and extracted some information about ME modules. Unfortunately, several modules with promising names are always Huffman-compressed and not amenable to analysis. These module names include kernel, syslib (System Library), bup (Bring-Up), and amt (Active Management Technology).

We started playing with Manifest Extension Utility (meu.exe) from ME System Tools and discovered that we could generate an XML file containing the text string “NOT_COMPRESSED”. We looked inside meu.exe and located an identical string. However, these strings are not referenced anywhere in code…

Explaining observations

After analysis, we found that the meu.exe binary contains an embedded file system that uses data compression and is accessible via the Qt Resource System interface. The same applies to Flash Image Tool (fit.exe). We extracted all embedded files and briefly analyzed them.

Some files appear to be XML (human-readable) and contain helpful information (meaningful names and comments) about the binary format of internal structures (extensions) used in Code Partition Manifest and Module Metadata. Therefore, after interpreting the XML data, we were able to understand almost every field in Manifest and Metadata.

Metadata analysis can suggest many interesting conclusions. For example, we were able to find a list of internal device names and check access permissions (which module is permitted to access which device).

ROM bypass

We were lucky to find several ME firmware images that contain a ROM bypass partition—code and data that could be used instead of the ROM in case of errors in non-updatable areas of ME.
The ROM bypass is not too big and can be analyzed in full. Some logic (related to memory-mapped devices and data obtained from them) can only be guessed at, but the process of loading and verifying the startup module (named rbe) seems straightforward.

Funny findings

We are still unable to build an overall picture of ME, due to Huffman compression of the kernel and syslib code. However, it is possible to analyze TXE (Trusted Execution Engine, the equivalent of ME for Intel Atom CPUs) thanks to the absence of Huffman compression.

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

Conclusion

Analyzing ME is a complicated task, and the work we have described here would be no more than 1% of the total. We hope that our findings will help other researchers so we can all learn more about Intel ME in the near future!

Author: Dmitry Sklyarov, Positive Technologies