From Ledger · · 4m
Laser attack breaks Raspberry Pi's secure debug lock
Researchers used photon microscopy and laser pulses to bypass permanent security features on the RP2350 microcontroller and extract secrets from protected memory.
In brief
Researchers used photon microscopy and laser pulses to bypass permanent security features on the RP2350 microcontroller and extract secrets from protected memory. Even redundantly-encoded security flags can be bypassed if override mechanisms lack equivalent protection, and system security depends on the complete…
Laser attack bypasses permanent debug lock

Researchers used photon-emission microscopy and laser pulses to enable debug access on a Raspberry Pi RP2350 microcontroller, even after its debug features were permanently disabled in one-time-programmable memory.
The RP2350 security model
The RP2350 dual-core microcontroller uses secure boot, TrustZone separation, permanent debug-disable settings, and glitch detectors to protect sensitive data and execution states.
One-time-programmable memory stores secrets
Critical security settings and boot keys are stored in OTP memory where each bit can flip from 0 to 1 once, permanently. Lock rows control read and write access to each 128-byte page.
Debug access through the serial interface

External debuggers communicate via the Serial Wire Debug interface to access memory and halt cores. The permanent DEBUG_DISABLE flag blocks this access by disabling the memory access ports.
DEBUGEN register overrides permanent disable
A memory-mapped DEBUGEN register can re-enable debug access even when DEBUG_DISABLE is set. This critical override has no redundant encoding like other security-critical fields.
“DEBUG_DISABLE can be fully overridden by setting all bits of this register”
Researchers replicated the hacking challenge
They configured an RP2350 with secure boot enabled, debug permanently disabled, glitch detectors at maximum sensitivity, and a 128-bit secret locked in OTP page 48.
Destructive sample preparation required

The chip was backside decapsulated to expose transistors to infrared light, then soldered onto a daughterboard connected to Ledger Donjon's Scaffold testing platform.
Photon emission reveals register locations

Switching transistors emit faint infrared photons correlated with activity. By toggling DEBUGEN bits in loops and averaging 200 frames, researchers identified which regions of the die controlled each bit.
Three hotspot regions located

Photon-emission microscopy found compact sites associated with DEBUGEN bits 0 through 3 across three regions of the chip, significantly reducing the search space for laser targeting.
Laser pulses set DEBUGEN bits

A 980-nanometer pulsed laser at 1.2 watts with 100-nanosecond pulses targeted two positions a few micrometers apart to set the PROC1 and PROC1_SECURE bits needed for secure debug.
Iterative sequence enables secure debug
Pulses at one position enabled bus access through core 1's memory access port. Pulses at the other set secure access permissions. An iterative script calibrated both positions within seconds.
Secure debug access confirmed
Once both bits were set, they remained set without further pulses. Reading the secure-only DEBUGEN register through the memory access port returned 0xc, confirming secure-attributed access was achieved.
Runtime lock prevents secret access
Even with secure debug enabled, the challenge firmware applies a runtime lock that makes page 48 inaccessible. This lock is reset to its persistent value only when the OTP block resets.
Rescue reset halts before firmware runs
The always-accessible RP-AP debug port can trigger a rescue reset that halts the boot ROM before user firmware executes, preventing the runtime lock from being tightened.
Complete attack sequence recovers secret
Researchers triggered a rescue reset, faulted DEBUGEN to 0xc, halted core 1, then read the secret from OTP rows through the guarded read interface. The complete challenge secret was recovered.
Lock bits cannot prevent laser faults
DEBUGEN_LOCK blocks software writes to DEBUGEN bits, but laser pulses could still set DEBUGEN while the lock remained active. Lock bits themselves could also be set by pulses.
Software mitigations have limits
Once secure debug is enabled, firmware-based protections like ACCESSCTRL cannot prevent a debugger from controlling the secure core or extracting values through registers.
Attack requires extreme resources
The attack demands destructive physical access, approximately 250,000 dollars of laboratory equipment, and specialized hardware-security expertise in sample preparation and laser targeting.
Security depends on complete enforcement chain
The RP2350 encodes critical flags with redundant voting, but DEBUGEN lacks equivalent protection. System security depends on the entire path from persistent OTP through mutable registers and reset behavior.
The essence
Even redundantly-encoded security flags can be bypassed if override mechanisms lack equivalent protection, and system security depends on the complete enforcement chain from boot through reset.




