Lunar Labs Project

Misbehaving while awake: NRF52810 Runtime EM Fault Injection APPROTECT Bypass - (CVE-2025-9709)

Abstract

In this research a novel, runtime fault injection attack on Nordic Semi’s NRF52810 System-on-Chip (SoC) using electromagnetic (EM) fault injection is demonstrated. Achieving reliable and reproducible fault induction is incredibly simple as in this SoC the EM injection does not have to be neither precise nor accurately timed. The attack has success on the first pulse. These findings expand the threat model by showing that stealthy attacks can be performed in-field without necessarily altering the chip. This emphasizes the urgent need for advanced countermeasures, including EM shielding, fault detection circuitry, and software verification mechanisms, to defend against runtime EM-based fault injections. This work highlights a critical security gap in modern SoCs and stresses the importance of securing the entire execution environment, not just static chip properties. A practical, effective fault injection method is presented and the hardware hacking community is urged to focus on these runtime attack vectors.

Differences from the Limited Results work. The arguments against the novelty of the attacks can be several and all traced down to Limited Results (most respectable) 2020 work [1]. At first sight (fault injection on the same hardware already proven to be vulnerable to it by the vulnerability researcher Limited Results), it could look the same to untrained eyes, however these arguments can be easily dismissed by the following statement: the former attack had its novelty back then in being at boot time whilst the currently overviewed one is at runtime. Which has its implications both in the hypothetical hardware remediations and also in terms of impact.

The Target: nRF52810 inside ISP507-AL packaging. The nRF52810 is an 8 year old (2017) SoC belonging to the nRF52 SoC (system on chip) family. Nordic has implemented back then the so called APPROTECT protection for SWD (anti-)debugging purposes (to literally protect the access port). As dev boards of actual nRF52810 hardware (what Nordic sells you is a board with nRF52832 to emulate nRF52810 on - see [3] for more details) do not exist, this board has been used (or more precisely, several instances of it) [4] for the experiment. A RaspberryPi Pico to power on the device (pin 36 and pin 38 - VCC out and GND of the Pico) - see Figure 1.

Figure 1: Raspberry Pi Pico Pinout.; Figure 2: CCW (counter-clockwise) 4 mm antenna tip for ChipShouter in the successful attack position.

A ChipShouter [5] was used with a 4mm CCW probe tip (yet also other probes work, with just very subtle differences in outcome - position is immensely more important in this experiment).

More precisely the chip was loaded with the following code:

#include "nrf_gpio.h" // Nordic SDK header for GPIO manipulation
#include "nrf_delay.h"
// --- Configuration ---
// Choose a GPIO pin to turn on.
// P0.17 is listed as available on the ISP1507-AL in the provided documentation [2, 5].
// You can change NRF_GPIO_PIN_MAP(0, 17) to any other available GPIO pin.
// For example, NRF_GPIO_PIN_MAP(0, 13) for P0.13, etc. 2
// Please ensure the chosen pin is not used for other critical functions (like SWD, XTAL, etc.)
// and is accessible on your ISP1507-AL-TB.
#define RESET_INDICATOR_GPIO_PIN NRF_GPIO_PIN_MAP(0, 17) // Example: P0.17 - I used this one
/**
* @brief Function for application main entry.
*/
int main(void)
{
// --- Turn on GPIO pin on reset ---
// 1. Configure the chosen GPIO pin as a standard output.
nrf_gpio_cfg_output(RESET_INDICATOR_GPIO_PIN);
// 2. Set the GPIO pin high.
// If you want to turn it "off" (low), use nrf_gpio_pin_clear().
while (true){
nrf_gpio_pin_set(RESET_INDICATOR_GPIO_PIN);
nrf_delay_us(10000);
nrf_gpio_pin_clear(RESET_INDICATOR_GPIO_PIN);
nrf_delay_us(10000);
}

then the protection set up using nrfutil device protection set All using jlink mini edu attached to the target. Then PCBbites [6] were used to connect everything to the jlink mini edu [7] and the dev board, and the voltage on the P0.17 pin of the board was measured with the help of [8] and the use of a Rigol DHO4804. P0.17 acts like a canary: if it stops outputting 3.3V in a cyclical manner, for 1 ms circa it means the attack is similar in nature to [1], otherwise not. This is directly connected to the nature of the gpio pin: it behaves normally (or it resets for less than 1 ms, which is [1]’s attack timing) while being glitched successfully (the SWD is debuggable again), the glitch is at runtime.

Figure 3: The Rigol oscilloscope used in the experiment for the measurements.
Figure 4: PCBite used in the attack, less invasive, no soldering needed.

Why a clock and not a simple linear 3.3V on the GPIO? Because this way it is possible to distinguish full resets of the SoC from soft resets and so on. If a low (0) digital signal is perceived by the probe right before the glitch and it stays up right after the glitch for longer than a clock cycle this means the chip has be fully booted. This does not happen here, as it will be discussed below.

In the schematics attached hereby the P0.17 pin can be observed.

Figure 5: All property of Insight SiP

The Reset: ∼ 1µs. Using this setup has been confirmed the target did not undergo a full on poweron reset. As a matter of fact, in the image attached below the chip behaves as if a different kind of reset, shorter ∼ 1µs - as further proof of deviation from [1] - , less impactful, has happened. The pin keeps clocking as always, just with a slower frequency.

Figure 6: Clock slows down after successful glitch. - ROLL MODE
Figure 7: Clock slows down after successful glitch.- ZOOMED IN

The chip’s content is dumped (or memory tampered with - more interestingly) within the first pulse. It is immediate if you select the right area (which does not have to be super precise as it has been glitched by holding the chipshouter by hand several - around 20 - times; if you consider the probe tip is almost as 6big as the chip, you get the idea).

The type of reset is not a power-on reset which on [1] was on the order of magnitude of milliseconds. Here [2] on the ”Reset Behavior” paragraph there is a table encompassing all possible resets and the one involving the experiment has to be out of exclusion one of the following:

Figure 8: nRF52 family reset table.

DRAM as a (mechanical) protective factor. Other experiments on the other chips belonging to the nRF52 family have been conducted. Interestingly enough, the bigger the physical footprint of the RAM 7the less likely to be glitched successfully (or corrupted). As of today only the nrf52810 was glitched successfully at runtime, however it is worth noticing that the nrf52832, for instance, gets lots of ”Error reading AP” or other errors indicating some kind of corruption happening. And SoCs with bigger RAM in the same family have even less of these errors.

Figure 9: nRF52810 Successful glitch presenting ∼ 1µs reset range.

Misbehaving while awake: Tale of a Runtime Hack.

Figure 10: First setup reproduced at home and second setup reproduced at work.

References.