How to Hack IoT Devices and Beyond!

Okay, so after conducting some extensive research, I’ve learnt that with the right tools, hacking into crypto wallets and IoT devices might not be as challenging as you'd think. I'm talking about some seriously potent physical attacks here, and let's focus on one in particular: Electromagnetic Fault Injection (EMFI). I'll explain how this technique is used to exploit the security of Microcontrollers (MCUs) and Systems on a Chip (SoCs).

The requirements

To successfully carry out EMFI attacks, two key factors come into play: precise timing and pinpointing the right location on the hardware, specifically the chip, where the fault needs to be introduced. Both of these parameters would depend on what you are trying to achieve. The fault needs to be injected at the exact spot where a targeted logic section is present or where the registers relevant to the operation are located, and the fault should be timed precisely when that instruction is executed.?The below images shows a close up look of ICs (STM32 MCU and DS28C36 SE), this kind of imagery is very important to identify the region where you would have to inject the fault.

STM32L4

Let's break this down further using a couple of examples. The following two graphs are the power traces and fault injection spots of the STM32L4 and they account for at what time and where the fault should be injected in order to downgrade the RDP (Read Out Protection) level from level 2 to level 1. The RDP level of the MCU depends on the option bytes value and each option byte is stored in the flash memory alongside their complements. These option byte values are 0xAA for RDP level 0, any value other than 0xAA and 0xCC for level 1, and 0xCC for level 2. By default, the in field product for users has its RDP level is set to the highest, which is level 2 and limits any access to the flash, SRAM and disables the debug interface.

Before the firmware is executed during the boot-up phase, five 64-bit wide option byte sections are loaded from flash memory into internal registers that users can't access. Subsequently, the option byte values are moved to the five 32-bit user-accessible option byte registers.

If there's a mismatch between option bytes and their complements, a default value of 0xFF is used. The problem here though is that the RDP level is getting downgraded to level 1 from level 2 with option byte value being set to anything other than 0xCC and 0xAA, here it is 0xFF.?

The interesting part is that downgrading the RDP level from 2 to 1 only requires a single bit flip in the option byte value. To achieve this, you need to glitch the transfer process of the option bytes from the flash memory to the internal registers. This downgrade would grant access to the SRAM and also reactivates the debug interface.?

Timing is everything in this process, and you must know when the particular instruction (the transfer of option bytes) is executed and where the option bytes register resides or where this instruction's code is located. According to the power trace and fault injection spot graphs, injecting a fault at around 5 microseconds from boot-up at the red spot would disrupt the memory transfer of FLASH_OPTR (the option bytes register), successfully downgrading the RDP level from 2 to 1 [1-2].

ESP32-V1

Now, in the case of ESP32 (V1). It has a 1024-bits eFuse memory divided into four equal blocks. Two of these blocks, BLK1 and BLK2, store flash encryption and secure boot keys, while the other two are reserved for system purposes and user applications. Once these keys are written to the memory, only the hardware can read and use them.

Fault injection attacks can be used to perform malicious data modifications by influencing the execution of the chip, in order to bypass sensitive operations such as memory protection and secure boot. In the ESP32-V1, EMFI can be employed to bypass the secure boot and flash encryption by targeting the chip's power up using a single EM pulse. That is, the chip is faulted during the power up, precisely when the eFuse protection bits (these protection bits once set, provides read and write access protection to eFuse) are manipulated. The specific injection position/point and time is shown in the following graphs below. Additionally, you can analyze the faulty responses during cryptographic operations using Differential Fault Analysis (DFA) attacks to extract secret keys [3].

nRF52

The nRF52840 (outlined in orange in the image below) IC used in IoT devices like the Apple AirTag, features a flash read-out protection that deactivates the debug interface to the core and all peripherals. By injecting a glitch during the boot phase of the microcontroller this read-out protection feature can be circumvented.

The coil (EM probe) position of the setup or the location on the chip where the fault is supposed to be injected is schematically outlined in the figure below and the probe to chip distance is about 330 micrometers. This attack allows you to extract all credentials and to manipulate the devices firmware without leaving any evidence [4].

STM32F2

Similar to STM32L4, you can just inject an EM fault to perform an RDP downgrade attack on the STM32F2 MCU. The only difference here is the timing and location on the chip where the fault is to be injected as these are two different families of MCUs.?

According to the detailed graph below, if we look at the trace at roughly 170 microseconds, we can see the flash activity before the main application begins execution. And If you can inject a fault roughly around 170 microseconds after the processor began executing its bootrom, an RDP check could be bypassed. This would allow you to drop the RDP level of the microcontroller from RDP2 to RDP1, allowing SRAM access via SWD (debug interface). The content in the SRAM can then be dumped and all of the stored data and information could be extracted [5].

MediaTek MT8163V

Voltage glitching is a type of a fault injection attack where the supply voltage of a target device is modified to induce unanticipated behavior. The trick is to briefly disrupt the core power to the processor, which messes up what it's doing inside. By carefully tweaking the glitch, you can make the device skip critical security checks.

In the case of the MediaTek MT8153V SoC, its BootROM is susceptible to glitching, allowing an adversary to bypass signature verification of the preloader.?

During startup, the BootROM will read the eFuses to determine the configured secure boot policy. Next, the BootROM will load the preloader from the eMMC into RAM and will verify its signature before executing it. The preloader is stored on the BOOT0 eMMC partition.

The MediaTek SoC stores two copies of the preloader in BOOT0. If the first image is corrupt (i.e. doesn’t pass the signature verification check), then the BootROM will load the second image. If both copies are corrupt, then the BootROM will enter Download Mode.?

On bootup, it takes about 2 seconds between the events of completely loading the preloader from eMMC and the first eMMC command being issued by the preloader. That is, If the first preloader image is valid. On the other hand, if the first preloader image is invalid (that is, it fails signature verification), then it takes only about 700ms between the BootROM attempting to load the first and the second preloader images.

We assume that during the first ~700ms is when the BootROM is busy parsing the preloader image structure and performing signature validation.

In order to inject a voltage glitch with precise timing, a custom trigger is implemented using a FPGA. The FPGA is used to generate a trigger output once the preloader has been completely loaded from the eMMC for signature verification (FPGA is clocked by the eMMC clock signal and the code implements a shift register using DAT0 to keep track of the last 4 bytes transferred over the line). The trigger output signal is then fed to the ChipWhisperer where a delay is inserted and a glitch of a specific width is generated.

Along with the FPGA and ChipWhisperer, a 1.8v UART adapter is used to monitor the target's output and see if the glitch attempt worked. And a Raspberry Pi is used to reset the target device by turning off and on its USB power.

The glitch shorts VCCK_PMU (the voltage supply to the core) to ground through ChipWhisperer’s low-power MOSFET. This disruption messes with the processor's internal state, like register values, without crashing the whole system.

Different glitches of varying widths were tested while the device was running the BootROM and preloader. The critical signature check happens within the 700ms window after the preloader is fetched. If a tampered preloader is stored in the eMMC, ideally the BootROM should reject it due to a failed signature check. But if the glitch works, the tampered preloader will load and run.

Experimentally, the successful glitches were found to be clustered around a narrow range of widths (93-130) and offsets (41428-41438). This was enough to successfully bypass the signature validation check and load the tampered image.?

Now to read out and extract the data and information on the eFuse and BootROM memory, a payload can be injected into the preloader binary, replacing a portion of the string section. The injected payload will be able to execute arbitrary code.

This circumvents all secure boot functionality and enables the execution of unsigned preloader images, completely undermining the hardware root of trust. Because this vulnerability affects the BootROM, it cannot be patched in the field, and as-such all in-field products will remain vulnerable indefinitely [6].

Further Analysis

Physical attacks like EMFI pose genuine threats to hardware security, and they're becoming more affordable and accessible day by day. Therefore, it's important to be vigilant and aware of such attacks and their potential implications for device security.

At Cypherock , we are fully focused on improving hardware security. Our dedication to hardware security research is a vital step in achieving this goal, and we are continually engaged in studying the current vulnerabilities and threats associated with hardware wallets.

Through our research efforts, we aim to share the essential knowledge required by the community to effectively safeguard their cryptocurrency assets.

We will be sharing more analysis on ICs like the Raspberry Pi Broadcom chip (BCM2835), STM32H7 and more soon.