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.

Sep 18, 2026

19 cards · 4m · tap to begin

From · · 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

Experimental bench used for the attack

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

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

Backside-decapsulated RP2350 mounted on the analysis daughterboard

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

Mean stacks of 200 full-view photon-emission captures for DEBUGEN masks 0x3 and 0xc followed by their signed difference.

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

Infrared overview of the die with three marked regions, plus zooms of those regions overlaid with coloured DEBUGEN bit sites.

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

Side-by-side infrared views with PEM bit sites on the left and LFI fault points on the right.

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.

Read the original on Ledger

React

Sign in to react and comment.

Comments (0)

Life is short. Keep it sweet. Respect others' opinions and be kind!

    Recommended next

    More decks on raspberry pi and related topics.