Lecture: Modchips of the State: Hardware implants in the supply-chain

Hardware implants and supply chain attacks have been in the news recently, but how feasible are they and what can we do about them? In this talk we’ll examine the design of a proof of concept SPI bus hardware implant that has similar capabilities to those described in the Bloomberg/Supermicro article as well as some countermeasures that we can use to try to detect these “modchips” and increase our trust in our systems.

We don’t know how much of the Bloomberg story about hardware implants installed in Supermicro servers shipped to Apple and Amazon is true, nor do we know the story behind the story and the reasons for the vehement denials by all the parties involved.

However, a technical assessment of details of the describe implants reveals that a supply chain attack on the hardware is definitely possible, that the capabilities of the BMC can be used to bypass OS protections, and that there are means to access the BMC that would not necessarily generate readily identified network traffic.

In this talk we’ll examine the design of a proof of concept SPI bus hardware implant that has similar capabilities to those described in the Bloomberg/Supermicro article as well as some countermeasures that we can use to try to detect these “modchips” and increase our trust in our systems.


CVE-2018-12169: Tianocore UEFI: Unauthenticated Firmware Chain-of-Trust Bypass

“The issue was reported by Trammell Hudson”





Trammell on LinuxBoot (NERF) and Heads

Note that NERF is also called LinuxBoot now.

The NERF project is a collaboration with Ron Minnich at Google (creator of LinuxBIOS and coreboot) that aims to build an open, customizable, and slightly more secure firmware for server machines based on using Linux and Heads in the ROM to replace UEFI as the bootloader. Unlike coreboot, NERF doesn’t attempt to replace the chipset initialization code with opensource. Instead it retains the vendor PEI (Pre-EFI environment) code as well as the signed ACM (authenticated code modules) that Intel provides for establishing the TXT (trusted execution environment). The NERF firmware replaces the DXE (Driver Execution Environment) portion of UEFI with a few open source wrappers, the Linux Kernel and the Heads measured runtime.





Trammell: eficheck finds Thunderstrike 2

Trammell Hudson tests Apple macOS’s eficheck against Thunderstrike2:


Thunderstrike 2

Purism and Trammell Hudson partnership

It looks like Purism is going to use Heads now! I hope other OEMs consider some of the features Heads offers.






I’ve made one brief post on Heads. Earlier I thought it was a new Linux distribution, which is not the case, it is more of a coreboot payload.

Heads looks great! I am currently looking for a used Thinkpad  to test one out. I hope others add support for other systems.

If you have not watched the CCC video, check it out, it is very informative.



33C3: If You Can’t Trust Your Computer, Who Can You Trust?

33rd CCC

The 33rd Chaos Communication Congress (CCC) takes place in December in Germany. There are MANY great presentations, and CCC is great at making video archives available. Here’s a sample of a few of the presentations, starting with Trammell’s lecture on Heads:

Bootstraping a slightly more secure laptop
Trammell Hudson

What could possibly go wrong with <insert x86 instruction here>?: Side effects include side-channel attacks and bypassing kernel ASLR
Clémentine Maurice and Moritz Lipp

Untrusting the CPU: A proposal for secure computing in an age where we cannot trust our CPUs anymore

Virtual Secure Boot: Secure Boot support in qemu, kvm and ovmf
Gerd Hoffmann

Full schedule:



Heads is a very interesting new distro by Trammel Hudson. If you like Qubes or Subgraph or Tails, read about this new distro.

The threat model that Heads proposes to address is very different from that of Tails. Tails’s goal is to allow users to to do computation on a machine in a way that doesn’t leave in trace on that system. This requires that the hardware in the system is trusted, which unfortunately is not the case for many users. Additionally many users need a way to keep state in a permanent way and don’t want to expose this state to random machines. Their machines might be subject to physical attacks that might install untrusted firmware or other devices into the system.[1][2] For these reasons, Tails is not sufficient for many users who want a laptop that they can travel with and want to have some assurances that most adversaries won’t be able to modify the hardware underneath them. Complicating this goal is that modern x86 hardware is full of modifiable state[3] and it is full of dusty corners that can hide malware or unauthorized code. Additionally there is unverifable code running in the Intel Management Engine, which has access to memory, to the network and various other peripherals. As a result we must trust certain entities more than others and this does affect our threat model. This document discusses some of the threats that make building slightly more secure mobile systems very difficult. There is a separate guide on installing Heads on the Thinkpad x230, which covers the practical issues of hardening a laptop against some of the threats described here.  […]”



tool: ReadPhysMem

Found on the Twitter feed of the The EFI Monster (@osxreverser):

ReadPhysMem is a small utility to read and write to Macs physical memory using default AppleHWAccess.kext. Quoting the readme:

(c) fG! – 2015 – reverser@put.ashttps://reverse.put.asA small utility to read and write to Macs physical memory using default AppleHWAccess.kext.

This kext is loaded by default on Mavericks and Yosemite. It has (finally) been disabled on El Capitan since beta 7 release, since it was a obvious way to bypass and disable the new rootless protection 😉

Trammell Hudson wrote a similar utility using DirectHW.kext (also blacklisted on El Capitan B7). Available at https://github.com/osresearch/rwmem.

The same warning as rwmem applies here. Use with caution, it can easily kernel panic your machine both on reads and writes (particularly on devices mapped areas, SMM ram, etc). If you already know PCI BAR addresses you need to use 4 bytes read size instead of default 8.

It works great to read kernel and other memory, and also BIOS (since it’s mapped/shadowed in physical memory). See also https://github.com/gdbinit/diagnostic_service2 for a real world rootkit application.

DirectHW.kext is a bit more powerful since it allows to read port info. AppleHWAccess.kext only implements memory reads and not ports. For example, it can’t be used to read PCI configuration.

Have fun,



quiz: define ‘firmworm’

The pre-conference preview videos are coming out… 🙂 One firmware one that caught my attention:

Thunderstrike 2 “firmworm” for MacBooks Preview Video

Apple EFI vulnerabilities: CVE-2015-3693 and CVE-2015-3692

From the security-announce@lists.apple.com announce list, Apple has an EFI update for multiple systems, available from the App Store. Two CVEs are listed:

APPLE-SA-2015-06-30-3 Mac EFI Security Update 2015-001

Mac EFI Security Update 2015-001 is now available and addresses the following:

Available for:  OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
Impact:  A malicious application with root privileges may be able to modify EFI flash memory
Description:  An insufficient locking issue existed with EFI flash when resuming from sleep states. This issue was addressed through improved locking.
CVE-2015-3692 : Trammell Hudson of Two Sigma Investments, Xeno Kovah and Corey Kallenberg of LegbaCore LLC, Pedro Vilaca

Available for:  OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
Impact:  A malicious application may induce memory corruption to escalate privileges
Description:  A disturbance error, also known as Rowhammer, exists with some DDR3 RAM that could have led to memory corruption. This issue was mitigated by increasing memory refresh rates.
CVE-2015-3693 : Mark Seaborn and Thomas Dullien of Google, working from original research by Yoongu Kim et al (2014)

More Information: