Breaking the Silence: Using Photon-Emission-Guided LFI to Unlock RP2350 Secure Debug

Source: Ledger Donjon | Date: September 18, 2026 Focus: Bypassing permanent debug disables on the Raspberry Pi RP2350 (A4 Revision).

---

⚡ Executive Summary (TL;DR)

The research team successfully bypassed the "permanent" security locks of the RP2350 microcontroller. Here is the breakdown of the operation:

• Localization: Used Photon-Emission Microscopy (PEM) to pinpoint the exact physical location of the debug-enable register.
• Injection: Applied precise laser pulses to two specific coordinates to flip the necessary bits.
• Extraction: Restored access to the "Secure world" via the debugger, allowing the recovery of a secret from the One-Time Programmable (OTP) memory.
• Timing: The attack utilized a "rescue reset" to halt the CPU before the firmware could apply runtime locks.

Warning: This is a high-barrier attack. It requires physical possession of the chip, destructive hardware modification, and a laboratory budget of approximately $250,000.

---

🛡️ The RP2350 Security Architecture

The RP2350 is a versatile dual-core MCU. At boot, each socket can be configured to run either a RISC-V Hazard3 or an Arm Cortex-M33 core.

Key Defensive Layers

1. Secure Boot: Validates signed firmware using public-key fingerprints stored in OTP.
2. Armv8-M TrustZone: Creates a hardware-level wall between Secure and Non-secure execution environments.
3. Debug Lockdown: Settings intended to permanently disable debug access.
4. Glitch Detectors: Hardware monitors designed to trigger if clock or voltage instabilities (common in fault injection) are detected.

The OTP Memory Model

The One-Time Programmable (OTP) memory is the root of trust. Bits can be transitioned from $0 \rightarrow 1$, but never $1 \rightarrow 0$.

Redundancy Logic: The hardware determines the state of a bit based on a majority vote: $\text{Final State} = \text{Majority}(bit_1, bit_2, bit_3)$

---

🔍 The Debug Interface & The Vulnerability

The RP2350 uses the Serial Wire Debug (SWD) protocol. The data flow is as follows:

The "Secure Debug" Problem: Normally, setting the CRIT1.DEBUG_DISABLE flag kills the enable signals for the Mem-APs, effectively blocking the debugger from the system bus. However, there is a critical architectural "backdoor":

The memory-mapped DEBUGEN register can fully override the DEBUG_DISABLE flag if all its bits are set.

By targeting this specific register with a fault, the researchers could re-enable the Mem-AP and gain full read/write access to Secure memory.

---

🧪 Experimental Setup

The team aimed to extract a 128-bit secret from OTP Page 48.

Target Configuration

The device was configured to mimic the Raspberry Pi Hacking Challenge:

• Secure Boot: Enabled (CRIT1.SECURE_BOOT_ENABLE = 1).
• Debug: Permanently disabled (CRIT1.DEBUG_DISABLE = 1).
• Glitch Detection: Max sensitivity (SENS = 3).
• OTP Page 48 Lock: PAGE48_LOCK1 = 0x3c3c3c (Secure: RW / Non-Secure: Inaccessible).

// Conceptual configuration of the target device
struct RP2350_Config {
    uint32_t boot_key_valid = 0x1;
    uint32_t boot_key_invalid = 0xe;
    bool secure_boot = true;
    bool debug_disabled = true;
    int glitch_sens = 3;
};

Hardware Preparation

To allow the laser to interact with the silicon, the chip underwent backside decapsulation. This process removes the bulk of the silicon substrate, allowing infrared light to reach the active transistor layers.

![Placeholder: Photon Emission Map showing register activity] Figure 1: Conceptual representation of PEM used to locate the DEBUGEN register.

The researchers used PEM to observe the chip's activity, narrowing the search area for the laser until they found the exact coordinates of the DEBUGEN register activity. Once located, they used LFI to flip the bits and restore the debugger's access to the Secure world.