RP2350 Secure Debug Access via Photon-Emission-Guided Laser Fault Injection

Researchers from Ledger Donjon have demonstrated a successful attack on the Raspberry Pi RP2350 microcontroller (A4 revision), bypassing permanent debug-disable settings to recover secrets from One-Time Programmable (OTP) memory. The attack leverages a combination of photon-emission microscopy (PEM) and laser fault injection (LFI) to override the chip's security enforcement chain, granting the attacker Secure-attributed debug access.

The Vulnerability: The DEBUGEN Override

The RP2350's security model relies on a permanent CRIT1.DEBUG_DISABLE flag stored in OTP memory. When this flag is set, it is intended to permanently disable the Memory Access Ports (Mem-APs) of the cores, preventing external debuggers from accessing the system bus.

However, the hardware includes a memory-mapped register called DEBUGEN that can override this permanent disable. If the DEBUGEN register is set, Secure software can re-enable the Mem-APs. The researchers found that while the OTP security fields use redundant encoding and majority voting to prevent accidental or malicious flips, the DEBUGEN register lacks such protections. This lack of redundancy makes the register a high-value target for fault injection.

Attack Methodology: PEM and LFI

Locating a single register bit on a silicon die is a "needle in a haystack" problem. To solve this, the researchers used a two-stage localization and injection process:

1. Photon-Emission Microscopy (PEM)

Transistors emit faint near-infrared photons when they switch states. By having Secure software toggle specific bits of the DEBUGEN register in a loop and capturing the resulting emissions using a high-sensitivity camera, the researchers could isolate the physical location of the bits. By subtracting the mean stacks of different bit-mask loops, they cancelled out background noise and isolated the specific sites associated with DEBUGEN bits 0–3.

2. Laser Fault Injection (LFI)

Once the spatial coordinates were identified, the researchers used a pulsed laser (980 nm) to inject faults. Because setting one bit might accidentally clear another, they used an iterative sequence: pulsing the position for PROC1 (enabling the Mem-AP) and then pulsing the position for PROC1_SECURE (permitting Secure accesses) until both were set.

This process enabled Secure debug access within seconds. The researchers noted that a 50x objective lens was required for the precision needed; a 20x objective was too wide, often hitting both a "set" and "clear" region simultaneously.

Recovering the Secret from OTP

Even with Secure debug access, the researchers faced a runtime lock on the OTP page containing the secret. In the challenge configuration, the firmware applies a runtime lock (sw_lock[48]) that makes the page inaccessible to all, including Secure debug, immediately after boot.

To bypass this, the researchers utilized the RP-AP rescue reset. The CTRL.RESCUE_RESTART command triggers a full system reset that flags the boot ROM to halt the processor before any user firmware runs. Because the runtime lock is only applied by the firmware, a rescue reset restores the OTP page to its persistent lock state (LOCK_S = READ_WRITE), leaving the secret readable via the now-enabled Secure Mem-AP before the firmware can tighten the lock.

Analysis of Mitigations and Limitations

Software-Based Mitigations

The researchers concluded that software-based mitigations are only "best-effort" runtime protections. While firmware can use ACCESSCTRL to block debugger transactions or periodically check the DEBUGEN register to trigger a fail-safe reset, these cannot prevent the attack because the rescue reset halts the chip before the firmware ever executes.

DEBUGEN_LOCK Effectiveness

The DEBUGEN_LOCK register, designed to prevent accidental software writes to DEBUGEN, did not stop the laser-induced changes. Laser pulses were able to set DEBUGEN bits even when the corresponding lock bits were set to 1, and in some cases, the pulses actually set the lock bits themselves, preventing the firmware from later restoring the disabled state.

Attack Requirements and Impact

The attack is highly targeted and requires significant resources:

• Physical Access: The device must be backside decapsulated (the package is removed to expose the silicon substrate).
• Equipment: The setup described by Ledger Donjon costs approximately $250,000.
• Expertise: Requires advanced knowledge of sample preparation, die navigation, and laser fault injection.

Despite the high cost, community discussion suggests that similar attacks could potentially be replicated with lower-cost, home-lab equipment (e.g., using tools like PicoEMP for different types of faults) or by using a scattershot approach once the coordinates are known.

Conclusion

The RP2350 attack highlights a critical system-level lesson: security depends on the entire enforcement path. While the Raspberry Pi team implemented robust redundant voting for OTP flags, the mutable DEBUGEN register and the rescue reset behavior created a vulnerability that allowed the researchers to recover the challenge secret. The system's security was compromised not by a failure of a single mechanism, but by the interaction of multiple documented hardware features.