This blog series was produced by Ibrahima Keita and covers his summer internship project at CC-SW. The project goals were to explore and reproduce the public work on glitching and fault injection attacks. We wanted to share the tools and processes and the results of his research. He has since graduated from UMass Amherst and joined Caesar Creek Software full time at the Woburn office where he continues his work on hardware and software security.

Introduction

Embedded systems have become very commonplace in our daily lives. From cell phones, to Internet-of-Things (IoT) devices in houses, to medical devices found in hospitals, they can pretty much be found anywhere. Because of how common they are, embedded systems have become a popular target for hackers.

As vulnerability researchers, our goal is to perform analysis on these devices in order to properly secure them. While black-boxing and penetration testing a device with known vulnerabilities is doable, the efficacy strongly depends on the firmware running on the device. Therefore, obtaining the firmware that runs on the device tends to be the first step in vulnerability analysis.

Historically, firmware extraction was fairly trivial. Oftentimes you could download the firmware from the manufacturer’s site. Whenever this was not possible, tearing down the device became important. Oftentimes the firmware is stored on an external memory chip, such as a Serial Peripheral Interface (SPI) flash, a NOR/NAND flash, or eMMC. Sometimes, depending on the device, it can be stored on a flash region in a Microcontroller Unit (MCU). Irrespective of where it is, as long as you could make a physical connection to the chip (either by removing the chip from the system and putting it in a reader, or wiring the reader to the chip in-circuit), and you know the commands that are needed to communicate with the chip (which tend to be specified in the datasheet for the chip), you could easily force the chip to spit out the data stored on it, provided there were no protections in place. As far as the chip is concerned, the main processor is the one asking for the data, so it has no problem spitting it out (as it needs to be spit out for it to run on the device).

Over time, however, hardware manufacturers have implemented security features to prevent unauthorized access to their devices. Some of these features include, but are not limited to, read protection, ID authentication, and lock protection. This means that security researchers now have a more difficult time getting access to the firmware. However, a lot of these protections are implemented at a software level on the hardware (i.e. within some bootloader). But, the execution of the software depends strongly on the hardware, and the hardware strictly follows the laws of physics. That being said, is it possible to utilize the laws of physics against these devices to change their behavior?

Throughout this series of blog posts, we will explore the weaponization of physics against an embedded processor (via fault injection and side-channel attacks) in order to defeat its security features.

On to Part 2, an introduction to the target.