Intel ME JTAG PoC for INTEL-SA-00086

Vulnerability INTEL-SA-00086 allows to activate JTAG for Intel Management Engine core. We developed our JTAG PoC for the Gigabyte Brix GP-BPCE-3350C platform. Although we recommend that would-be researchers use the same platform, other manufacturers’ platforms with the Intel Apollo Lake chipset should support the PoC as well (for TXE version[…]


Positive Technologies: JTAG in each house: full access via USB

It is amazing to see the Intel ME research coming out of Positive Technologies!

From Google Translate:

JTAG in each house: full access via USB

Researchers at Positive Technologies have activated hardware debugging (JTAG) for Intel Management Engine, which allows full access to all PCH devices (Platform Controller Hub) using Intel DCI technology (via USB interface). We plan to share the details at one of the nearest conferences. And how to activate this interface, but for the main processor, we will tell below.[…]

Intel ME is the new “Pandora’s Box”, defenders are going to need bigger (better) tools… 😦

Senrio: JTAG explained

Senrio has a nice blog post on JTAG usage on consumer IoT devices:

JTAG Explained (finally!): Why “IoT”, Software Security Engineers, and Manufacturers Should Care: Imagine you are handed this device and asked to get root on it as quickly as possible. No further information is given. Where would you begin?  (If you just want to see the router get rooted, jump down to “Mounting an Attack: Rooting a Home Router” 😉 Our target: A VERY common/popular consumer Access Point. Since you have the device in your hands, you might try directly attacking the hardware. However, if you’ve never done any kind of hardware hacking, getting started can be intimidating. In this post, we are going to talk about the fundamental information you need to know to use JTAG for hacking hardware. We’ll also go over a quick example to illustrate the power of direct hardware access. […]

Hardware security at Security B-Sides Seattle

This month is B-Sides Seattle, and there are 3 hardware workshops (Attacking USB, JTAG, and Arduino) one by Joe (SecurelyFitz) and two by Matt (CryptoMonkey):

I think I heard Matt say this was the last time he was offering this  Attacking USB training…

Note that Joe also has training at CanSecWest and Black Hat, in addition to B-Sides Seattle..

Intel’s Debug Extensions for WinDbg

Windbg is Microsoft’s Windows system debugger (both user-mode and kernel-mode), which has the ability to load third party extensions. I just noticed some Windbg extensions that Intel has created. One enables Windbg to work over JTAG, the other enables support for Intel PT:


The “Intel Debug Extensions for WinDbg” consists of two sets of debugger extensions:

1) Intel Debug Extensions for WinDbg for IA JTAG debugging (IA JTAG) enables the connection of WinDbg to a target over the JTAG. The server acts as a mediator and forwards the calls from WindDbg* to the IPC interface and back.

2) Intel Debug Extensions for WinDbg for Intel Processor Trace (Intel PT) is designed to help WinDbg users by extending their debugging tool set with execution tracing. The extension allows for easy setup of Intel PT by abstracting hardware configuration and then reconstructing and displaying execution flow from the collected trace data. It will integrate with other WinDbg* features like symbolization and high-level source display.  Intel PT is a new technology for low-overhead execution tracing. It facilitates debugging a program by exposing an accurate and detailed trace of the program’s activity, and its triggering and filtering capabilities help identifying and isolating the relevant program executions. Intel PT records information about software execution on each hardware thread using dedicated hardware facilities. After execution completes, a software can process the recorded trace data and reconstruct the exact program flow.
BIOS / UEFI firmware: With firmware that is Intel PT-aware, you can set up an Intel PT-specific memory allocation. In this case, the firmware allocates a dedicated memory area and reserves it in a memory map for further use. Operating systems will recognize this reserved memory range and will not use it. When firmware reserves a memory region for Intel PT, it also configures the Intel PT output MSRs accordingly and indicates that Intel PT output configuration is ready to be used. The extension will recognize this setup. No further configuration (from user’s side) is required.

I presume these extensions are only available as part of the commercial-only Intel System Studio product. If you use Windbg, you may want to try to get these extensions, they sound useful.

More information:


Joe Fitzpatrick (@securelyfitz) has released the slides and samples for the recent 44Con talk on “JTAGsploitation”.

Quoting the *entire* 1-line readme here:

jtagsploitation: scripts and examples for using JTAG debug tools to gain root access

More information:

44con presentations available

44con just finished. I didn’t mention this event earlier, but it included a few interesting presentations and workshops:

Is there an EFI monster inside your apple?
Pedro Vilaça

Hands-on JTAG for fun and root shells
Joe FitzPatrick

Pen Test Partners IoT Workshop
Dave Lodge


Parallax announces JTAGulator:

Designed by Grand Idea Studio, JTAGulator is an open source hardware tool that assists in identifying OCD connections from test points, vias, or component pads on a target device.

The product is currently on sale for the next few days, 15% off until 2015-08-31 (US$136 instead of US$160).

Low-cost UEFI debugging options for Intel

The other day I asked on the UEFI development list about hardware options for debugging UEFI, for security researchers (many UEFI debugging solutions only target OEMs/IBVs/IHVs). I was mainly thinking about Intel Tunnel Mountain, and related widgets like the Intel ITP-XDP, and other options in addition to AMI’s AMIdebug and Arium’s ITP products. It looks interesting; previously, all I knew of was Arium’s ITP and AMI’s AMIdebug products. Some of the commercial tools (eg, Arium) have new, expensive, closed-source debuggers, and don’t enable use of existing GDB/Windbg skills.

Zachary Gray of of the Intel System Studio debugger team replied with some answers:

Tunnel Mountain is OK but it is a bit old (by Intel standards) If you are looking for a small target for UEFI research purposes I *strongly* recommend the MinnowBoard Max.  This target has a freely available firmware that is mostly public, you can compile the firmware with GCC or MSVC, it is debuggable using JTAG (Arium,  or our Intel System Studio debugger with the ITP-XDP3 probe) and it is also debuggable using the Agent-based solution that is built into the image (cheap and easy!).

With regards to Intel System Studio vs Arium, I would say that the Arium JTAG debugger has a broader feature set that is proportional to their price, but the System Studio JTAG debugger also provides a useful feature set at a lower cost.  We can debug all the UEFI code from reset to boot loader, and also into the OS if you have an interest there as well.  With any of these debug tools you do not need a special compiler, you just use a standard debuggable build of the firmware.

Another even cheaper alternative would be to debug an Intel Galileo board using a low-cost FTDI probe such as an Olimex with the OpenOCD open-source JTAG debug server.  The board + probe would be <$200 and the firmware is publicly available.  For a front-end to the OpenOCD debug server you can use either the Intel System Studio debugger, or simply use GDB.  Some google searches will lead you to some documentation on all this.  The catch is that Galileo is not a “normal” Intel CPU so depending on your research interest the firmware may not present the concepts you are interested in.

Bruce Cran also replied with a lower-cost options:

Another even cheaper alternative, if you don’t need real hardware, is qemu+OVMF. It’s what I use to debug UEFI problems with the PCI driver I  work on (using gdb).

Alternatively, if you don’t need an x86-based system, I believe the BeagleBone/BeagleBoard (with ARM CPU) can be reflashed to edk2 firmware and debugged with a Flyswatter2 – with the main problem likely being being surface-mounting the JTAG header!

I also received some more advice via private email, from a firmware security researcher. Paraphrasing, they felt that the MinnowboardMAX is not much better than the Galileo for UEFI debugging, because it has many more blobs in it’s “open source” BIOS, and the Minnow is harder to debug than Galileo, since modern Atom CPUs are complex. Their advice was low-cost debugging was Galileo over Minnow, $20 for JTAG probe, and free GDB.

Thanks for all the advice!!

Obviously, this post doesn’t cover ARM [much], just Intel and virtual solutions. I’m still learning the best options for ARM-based hardware and UEFI, and will post another article on ARM in the future.

More Information:


[UDPATE: comment from a smart reader:
AMIDebug technology is not useful for end users and researchers because it’s support should be specifically compiled in in a special DEBUG build. The AMI DebugRX hardware part is OK to get port 80h codes via USB, mediocre source-level debugging. Intel XDP or Arium-ITP are similar to AMIDebug, both nice products, and don’t require any firmware changes or special build modes.
BTW, I don’t know why Comments don’t show up on blog web site, working on trying to fix that… ]

Earlier this week AMI announced USB3 support for their AMIDebug for UEFI product.

Apparently AMI has 3 versions of this: 1) AMIDebug for UEFI software for Aptio V, 2) the AMIDebug Rx handheld USB debug device, and 3) Aptio V UEFI Firmware from AMI.

Press release excerpts:

American Megatrends, Inc. (AMI), a global leader in BIOS, remote management, network data storage products and solutions for the Android(TM) operating system, is pleased to announce support for USB 3.0 controllers in the latest release of its AMIDebug(TM) for UEFI debugging solution for Aptio(R) V UEFI Firmware.

AMIDebug for UEFI from American Megatrends is a powerful software-based solution for debugging UEFI projects based on Aptio or the UEFI Shell, offering source-level symbolic (C and Assembler) debugging without the need for expensive JTAG hardware debug tools.

The latest AMIDebug for UEFI release, developed specifically for the company’s flagship Aptio V UEFI Firmware, adds support for USB 3.0 debug among other important features. These newly-added features signify a key development in the evolution of this debug software, since many chipsets now only support USB 3.0 (XHCI) and in many cases no longer incorporate older USB standards (EHCI) in their hardware designs, such as the Intel(R) Atom(TM) x5-Z8300 series processors.

What remains unchanged in AMIDebug for UEFI is its ability to facilitate firmware development for AMI OEM and ODM customers in unprecedented ways thanks to its deep integration into the entire UEFI development ecosystem. AMIDebug for UEFI continues to offer standard debugging features like Break, Step, Step Over, Step Into, Step, run to cursor and set next statement, in addition to UEFI-specific debugging features like Stop at Driver Name Entry, Stop at PEIM Name Entry, Stop at CheckPoint, Stop at beginning of PEI/DXE, SMM Debugging and disassembly view. Moreover, many different firmware development viewers are supported including memory, CPU registers, PCI Bus, call stack, I/O and Indirect I/O.

Sigh, I wish these were available for UEFI ISVs and UEFI Security Researchers, not just restricted to AMI’s UEFI OEM/ODMs! I want one. 😦

More Information: