Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug | Ledger Donjon
Pangram verdict · v3.3
We believe that this text is a mix of AI, AI-assisted, and human-written content.
AI likelihood · overall
MixedArticle text · 1,412 words · 11 segments analyzed
TL;DR — Photon-emission microscopy allowed us to locate a register responsible for the enabling of debug features on the Raspberry Pi microcontroller. — Laser pulses at two nearby positions then restored debugger access to the chip’s Secure world, even though debug had been permanently disabled. — Using that access after a rescue reset, we recovered a secret from one-time-programmable memory.
The reset halted the chip before firmware could apply its runtime lock, so the page stayed Secure-readable. — The attack requires physical access, destructive preparation, and approximately $250,000 of laboratory equipment.
The RP2350 security model The RP2350 is Raspberry Pi’s dual-core microcontroller: each processor socket can select either an Arm Cortex-M33 or a RISC-V Hazard3 core at boot. Its hardware security features include: Secure boot, which authenticates signed firmware against public-key fingerprints provisioned in One-Time Programmable memory (OTP) The Armv8-M TrustZone, which separates Secure and Non-secure execution states Permanent debug-disable settings Glitch detectors intended to detect timing disturbances caused by clock or supply manipulation Raspberry Pi has actively invited researchers to evaluate these protections through its RP2350 Hacking Challenges.
The first challenge ran from August to December 2024 against the original chip. After several findings were addressed, Raspberry Pi released the A4 revision—the version we tested. The permanent security configuration and boot public key fingerprints are stored in one-time-programmable (OTP) memory: each bit can be flipped from 0 to 1 once and never back, so whatever is written there lasts for the lifetime of the chip. OTP is organised into 128-byte pages protected by two persistent, or hard, lock rows: for page n, PAGEn_LOCK0 configures optional read and write keys and the behaviour when no key is entered, while PAGEn_LOCK1 contains the hardware-enforced LOCK_S and LOCK_NS permissions. Those states can advance from read-write to read-only or inaccessible but cannot become more permissive.
The OTP subsystem uses redundant encodings for security-related fields: critical flags are “encoded with a three-of-eight vote across eight consecutive OTP rows”, and OTP lock bits are “triple-redundant with a majority vote”, according to the RP2350 datasheet.
At an OTP reset, the persistent LOCK_S and LOCK_NS values initialise a per-page runtime lock, also called a soft lock. Firmware can tighten this lock until the next OTP reset, but cannot loosen it. The runtime change does not survive that reset. An external debugger communicates with the RP2350 through Arm’s Serial Wire Debug (SWD) interface. Requests first reach the Serial Wire Debug Port (SW-DP) and are then routed to access ports. In the Cortex-M33 configuration used here, each core has a memory access port (Mem-AP) connected to its system bus; an enabled Mem-AP lets the debugger read and write permitted memory and peripherals. A separate always-on access port, the RP-AP, exposes a small set of reset and recovery controls. Secure debug refers to Mem-AP access with Secure attribution. The debugger can then transact with Secure memory-mapped resources the access-control logic permits, and halt or inspect a core running in the Secure state. The permanent CRIT1.DEBUG_DISABLE flag is intended to close this path. When set, it drives the enable signals for both cores’ Mem-APs to zero, which “prevents the APs from performing any bus accesses at all”, and disables the factory-test JTAG interface and the RISC-V debug module’s access port. The SW-DP and RP-AP still respond, but neither core Mem-AP can access the system bus. There is, however, an override: the memory-mapped DEBUGEN register lets Secure software re-enable each core’s Mem-AP and, separately, Secure accesses through it. The datasheet states that DEBUG_DISABLE “can be fully overridden by setting all bits of this register”. This critical override in the enforcement chain is what made the debug interface our target. Gaining access to Secure debug on a Mem-AP is a general-purpose primitive to read and write Secure memory, halt and single-step a core, and inspect its registers. Whether that register could be set by a fault is the question the rest of this post answers.
Experimental setup Target configuration Raspberry Pi’s RP2350 Hacking Challenge asked participants to extract a 128-bit secret stored in OTP1. At startup, the signed challenge firmware ensures that page 48 has the expected persistent lock, then applies a runtime lock that denies both Secure and Non-secure access to the secret until the next OTP reset. We replicated this vendor-defined configuration on our own revision A4 device: Programmed the SHA-256 fingerprint of our public key into BOOTKEY0 Set BOOT_FLAGS1.KEY_VALID to 0x1 and BOOT_FLAGS1.KEY_INVALID to 0xe Enabled secure boot (CRIT1.SECURE_BOOT_ENABLE = 1) Permanently disabled debug (CRIT1.DEBUG_DISABLE = 1) Enabled the glitch detectors at maximum sensitivity (CRIT1.GLITCH_DETECTOR_ENABLE = 1, CRIT1.GLITCH_DETECTOR_SENS = 3) Configured the persistent locks for pages 1 and 2 according to the challenge configuration Set the page 48 persistent lock to PAGE48_LOCK1 = 0x3c3c3c, which denied Non-secure access (LOCK_NS = INACCESSIBLE) while retaining Secure read-write access (LOCK_S = READ_WRITE) Enabling secure boot permits only the Cortex-M33 cores, so both processor sockets used Arm for these experiments. Sample preparation and bench The device was backside decapsulated, so that infrared light reaches the transistors through the silicon substrate rather than being blocked by the metal layers on the front. The chip was then soldered back onto a daughterboard connected to Scaffold, Ledger Donjon’s open source platform for driving and monitoring devices under test. Removing the lead frame on the backside of the chip breaks its GND connection, so a copper wire restores it2. Backside-decapsulated RP2350 mounted on the analysis daughterboard Experimental bench used for the attack DEBUGEN: overriding permanent debug disable DEBUGEN has five functional bits: BitNameEffect0PROC0Enable core 0’s memory access port1PROC0_SECUREPermit Secure accesses through core 0’s memory access port2PROC1Enable core 1’s memory access port3PROC1_SECUREPermit Secure accesses through core 1’s memory access port8MISCEnable additional debug components, including the cross-trigger interface and the RISC-V debug access port Secure debug on a core needs both of its bits: the one that enables the Mem-AP, and the one that permits Secure accesses through it. In contrast to the redundant encoding used for OTP security fields, the datasheet documents no bit redundancy, parity or majority vote for DEBUGEN. We therefore tested whether laser pulses could set DEBUGEN bits on the secured device described above. Photon-emission-guided localization That test first requires knowing where to aim. Setting an individual DEBUGEN bit means hitting the storage of a single register bit, a needle in a haystack.
This is a harder targeting problem than the instruction-skip faults common in laser fault injection, where disturbing any of the many flip-flops in a core pipeline can produce the same skip: that spreads the sensitive area widely enough for a random scan to find it. A blind scan for one DEBUGEN bit is impractical. Switching transistors emit faint near-infrared photons correlated with their activity, so collecting that emission over repeated execution can reveal where a selected control changes state. This made photon-emission microscopy (PEM) a good fit for DEBUGEN: as a memory-mapped register, Secure software can toggle exact bits in a loop, driving the repeated state changes the measurement needs. We used it as the first localization stage, and the resulting map constrained the subsequent laser scan to a region of a few micrometres. We compared loops that repeatedly toggled selected DEBUGEN bits on and off, differing only in the bits they targeted. A register’s photon emission is faint next to the camera’s own noise and sensitive to slowly drifting ambient conditions such as temperature, so a single frame reveals nothing. Averaging many frames of each loop suppressed random sensor noise, and subtracting the two mean stacks cancelled everything the loops shared: static background, sensor offset, thermal emission, and switching unrelated to the selected bits. Interleaving the two values during acquisition kept slow drift from biasing that subtraction. What remained was the emission that tracked the selected bits.
Mean stacks of all 200 mask 0x3 and mask 0xc acquisitions, followed by their signed difference. Red is positive, indicating greater emission for 0x3; blue is negative, indicating greater emission for 0xc.
The localization maps below additionally balance acquisition order before combining matched differences. Repeated comparisons across different bit masks exposed compact sites associated with DEBUGEN bits 0–3 across three regions of the camera field.
Infrared overview of the camera field, with three marked regions. Coloured pixels mark sites associated with `DEBUGEN` bits 0-3. These zones show switching activity associated with each DEBUGEN bit; they do not directly identify storage cells. The multiple hotspots observed for each bit may arise from the storage element or from related logic. Without layout data, we cannot distinguish between the two.