Photon-Emission-Guided Laser Fault Injection Breaks RP2350 Secure Debug

TL;DR

  • Photon‑emission microscopy pinpointed the DEBUGEN register that controls debug access on the RP2350.
  • Focused 980 nm laser pulses set the PROC1 and PROC1_SECURE bits, re‑enabling Secure‑world debugging even though permanent debug‑disable was programmed.
  • After a rescue reset, the attacker read a 128‑bit secret from OTP memory that the firmware had locked at runtime.
  • The attack needs destructive chip preparation, precise laser equipment, and roughly $250 k of laboratory gear.

RP2350 security architecture and the debug‑disable chain

The RP2350 microcontroller implements:

  • Secure boot with public‑key verification stored in One‑Time‑Programmable (OTP) memory.
  • Armv8‑M TrustZone separating Secure and Non‑Secure states.
  • A permanent CRIT1.DEBUG_DISABLE flag that disables the Mem‑APs of both cores, cutting off all SW‑DP and debug‑AP bus accesses.
  • A DEBUGEN register that can override DEBUG_DISABLE when all its bits are set, as documented in the datasheet.
  • DEBUGEN_LOCK bits that lock software writes to DEBUGEN but have no hardware redundancy.

The OTP subsystem stores persistent lock rows (PAGEn_LOCK0/1) and uses three‑of‑eight voting for critical flags, making the permanent debug‑disable flag robust against single‑bit faults. However, the DEBUGEN register itself lacks redundancy, parity, or majority voting, making it a potential weak link.

Experimental configuration for the hacking challenge

The authors reproduced the Raspberry Pi RP2350 Hacking Challenge on a revision A4 device:

  • Programmed a SHA‑256 public‑key fingerprint into BOOTKEY0 and enabled Secure boot.
  • Set CRIT1.DEBUG_DISABLE = 1 and maximized glitch‑detector sensitivity.
  • Configured OTP page 48 with PAGE48_LOCK1 = 0x3c3c3c, granting Secure read‑write but denying Non‑Secure access.
  • The challenge firmware locks page 48 at runtime (sw_lock[48] = 0b1111) after boot, preventing any further reads.

Photon‑emission microscopy (PEM) isolates DEBUGEN bit activity

To locate the tiny storage cells for individual DEBUGEN bits, the team used PEM:

  1. Secure software toggled specific DEBUGEN bits in tight loops.
  2. Thousands of infrared frames were captured for two complementary bit‑masks.
  3. Averaging and subtracting the stacks cancelled static background and revealed localized photon emission correlated with the toggled bits.
  4. The resulting maps highlighted three micrometer‑scale regions containing activity for bits 0‑3.

"Repeated comparisons across different bit masks exposed compact sites associated with DEBUGEN bits 0–3 across three regions of the camera field." – Ledger Donjon blog

These hotspots narrowed the laser scan area from the entire die to a few‑micron window.

Laser fault injection (LFI) flips DEBUGEN bits

Using a 980 nm pulsed laser (≈1.2 W, 100 ns pulses, 50× objective), the researchers scanned the PEM‑identified region while monitoring SW‑DP responses:

  • One position consistently set PROC1 (enabling core 1’s Mem‑AP).
  • A second position set PROC1_SECURE (allowing Secure accesses through that Mem‑AP).
  • The two positions were only a few micrometers apart; a 20× objective could not isolate them because the larger spot hit both a set and a clear region.
  • An iterative script pulsed each spot until both bits stayed set, achieving a persistent DEBUGEN = 0xc value.

Crucially, the laser also flipped the corresponding DEBUGEN_LOCK bits to 1, preventing any later software write from clearing the debug enable.

Exploiting the rescued reset to read OTP secret

With Secure debug restored, the attacker performed a rescue reset via the always‑on RP‑AP (CTRL.RESCUE_RESTART). This reset:

  • Halts the boot ROM before user firmware runs, so the runtime lock on page 48 is never applied.
  • Leaves the persistent OTP lock (LOCK_S = READ_WRITE) intact, permitting Secure reads.

The attack sequence was:

  1. Trigger rescue reset.
  2. Fault DEBUGEN to 0xc while the cores are in the boot‑ROM wait loops.
  3. Halt core 1 via its Secure DHCSR.
  4. Read OTP rows 0xc08–0xc0f through the guarded read interface, extracting the 128‑bit secret.

The secret was recovered in a single run, demonstrating that Secure debug can bypass runtime OTP locks when combined with a rescue reset.

Why DEBUGEN_LOCK does not stop the attack

DEBUGEN_LOCK is intended to block software writes, but the laser fault could set both the DEBUGEN bit and its lock bit simultaneously. Once the lock is 1, software cannot clear the corresponding DEBUGEN bit, making the fault permanent until another physical fault occurs.

Assessment of mitigations and broader impact

  • Hardware‑level: OTP redundancy protects the permanent debug‑disable flag, but the unchecked DEBUGEN register creates a bypass.
  • Software‑level: Runtime ACCESSCTRL restrictions can limit direct Mem‑AP accesses, yet a debugger with Secure attribution can still control the core and read registers, undermining confidentiality.
  • Reset‑level: The RP‑AP rescue reset restores OTP runtime locks to their persistent state before firmware can re‑lock them, exposing any OTP pages that permit Secure read‑write.
  • Practicality: The attack requires destructive decapsulation, a high‑precision laser system, and expert hardware‑security knowledge, costing about $250 k. Commenters note that a functional replica could be built for under $25 k, but the barrier remains high for casual attackers.

"The attack requires physical access, destructive preparation, and approximately $250,000 of laboratory equipment." – Ledger Donjon blog

Community reactions

  • Cost perspective: BitBangingBytes argues the setup can be assembled for under $10 k using cheaper components like a ChipShouter.
  • Broader relevance: byb notes the findings are important for any secure‑enclave device, such as Yubikey‑style products.
  • Technical curiosity: akoboldfrying asks how the challenge secret is initially programmed, highlighting that the public repository only writes placeholder values and the real secret must be provisioned by the contest organizers.
  • Methodology critique: nullc suggests alternative fault stimuli (e.g., X‑rays) could avoid decapsulation, though no evidence is provided.

Conclusions

  • The RP2350’s security chain is only as strong as its weakest enforcement point; DEBUGEN provides an unprotected override that laser fault injection can exploit.
  • Photon‑emission microscopy is an effective pre‑targeting step, turning a needle‑in‑a‑haystack problem into a tractable micrometer‑scale search.
  • Rescue‑reset behavior, combined with a faulted DEBUGEN, enables reading OTP secrets that firmware intentionally hides at runtime.
  • Mitigations must consider the full enforcement path—from immutable OTP bits through mutable control registers and reset logic—rather than treating each mechanism in isolation.

Disclosure: The vulnerability was reported to Raspberry Pi on 28 July 2026. The authors thank the Raspberry Pi team for their constructive response.

Sources

Related