The RP2350 can permanently disable its debugger. Ledger Donjon turned it back on with two carefully placed laser faults.

That sentence sounds worse than the actual threat model and more magical than the actual work. This was not a remote exploit, a cheap bench trick, or a bypass that lets unsigned firmware boot. It required destructive access to the chip, backside decapsulation, specialized optical equipment worth about $250,000, and enough hardware-security experience to find register-sized targets on exposed silicon.

What makes the research useful is not that an expensive laboratory can hurt a microcontroller. It is how the team found the exact weak link in a long enforcement chain, then combined it with documented reset behavior to recover Raspberry Pi's 128-bit challenge secret.

The lock held. The override register did not.

A strong security model with one override

Raspberry Pi's RP2350 has a serious set of hardware protections for a low-cost microcontroller. It supports authenticated secure boot, Armv8-M TrustZone separation, permanent debug-disable settings, one-time-programmable memory, and glitch detectors intended to catch clock or power disturbances. Raspberry Pi has also invited public scrutiny through its RP2350 Hacking Challenges.

Ledger Donjon tested the A4 revision. Its target was configured with secure boot enabled, debug permanently disabled, glitch detection at maximum sensitivity, and the challenge secret stored in a protected OTP page. In that state, the normal memory access ports behind the Serial Wire Debug interface cannot reach the system bus.

The design still needs a legitimate way for Secure software to enable debugging. That path is a memory-mapped register named DEBUGEN. Its bits can enable each processor's memory access port and separately allow Secure-attributed transactions through it. Set the right pair for a core and the external debugger gains a route into the Secure world.

The permanent OTP settings use redundant encodings and majority voting for critical fields. Ledger found no equivalent protection documented for DEBUGEN. That made the override register a much smaller and more attractive physical target than the hardened configuration bits surrounding it.

First find the bit, then fault it

A laser fault is only useful if it lands on the right few micrometres of silicon at the right moment. Blindly scanning an entire die for one register bit would be painfully inefficient. The team used photon-emission microscopy to narrow the search.

Switching transistors emit extremely faint near-infrared photons. Ledger ran Secure code that repeatedly toggled selected DEBUGEN bits, captured many frames, and compared the averaged results. Subtracting one capture stack from another removed static background, sensor offset, thermal glow, and unrelated switching activity. The remaining differences pointed to compact regions associated with the target bits.

toggle known DEBUGEN bits
capture faint photon emission
average and subtract image stacks
locate activity within a few micrometres
scan only those regions with laser pulses
Photon emission turned an impractical whole-die search into a focused fault-injection experiment.

The chip had been decapsulated from the back so infrared light could pass through the silicon substrate without the front-side metal layers blocking it. Removing the package material also broke a ground connection, which the team restored with a thin copper wire before soldering the device onto an analysis board.

With the likely regions mapped, Ledger used 100-nanosecond pulses from a 980nm laser through a 50x objective. One location enabled core 1's memory access port. Another enabled Secure access through that port. The points were only a few micrometres apart, and a pulse that set one bit could clear the other, so the control script alternated between them until both states held.

Once calibrated, the sequence restored Secure debug within seconds. Reading the Secure-only register returned 0xc, the value produced by setting the core 1 enable and core 1 Secure-access bits.

Secure debug was only half the path

Reopening the debugger did not immediately reveal the challenge secret. The secret lived on OTP page 48 behind two layers of policy. A persistent lock allowed Secure reads, while challenge firmware applied a stricter runtime lock during boot that blocked both Secure and Non-secure access.

Runtime locks reset to their persistent values when the OTP block resets. Firmware normally tightens them again before an attacker can use the window. The RP2350, however, keeps a small recovery access port available even when external debug is disabled. Its rescue-restart control resets the system and tells the boot ROM to wait before user firmware runs.

That produced the second half of the attack:

  1. Rescue reset: return page 48's runtime lock to the persistent state while stopping before challenge firmware can tighten it.
  2. Fault DEBUGEN: set core 1's memory-access and Secure-attribution bits with the two calibrated laser positions.
  3. Halt the core: use the restored Secure debug path before normal firmware executes.
  4. Read the OTP rows: recover the complete 128-bit challenge secret through the now-permitted Secure path.

Every mechanism was doing what its documentation said. Secure boot still authenticated firmware. The permanent debug-disable flag still disabled the access ports. The runtime lock still blocked the secret after firmware applied it. The rescue path still halted before user code. The failure appeared in the composition: a mutable debug override could undo the permanent setting, while a rescue reset recreated a pre-firmware moment when the secret's page was Secure-readable.

The write lock was not a fault lock

The RP2350 also has DEBUGEN_LOCK, a write-once mechanism that prevents software from changing the corresponding debug-enable bits. Ledger tested that state too. Laser pulses could still set DEBUGEN while its lock bit remained set. Some pulses also set the lock bits themselves.

That distinction matters. A software write lock controls software writes; it is not automatically a physical-fault countermeasure. In a successful fault state, the lock could even prevent firmware from writing the debug bit back to zero.

Ledger discusses best-effort mitigations such as narrowing debugger permissions through access-control registers, locking those permissions, checking DEBUGEN at runtime, and failing closed on unexpected values. Those measures can reduce post-boot exposure. They cannot close the exact pre-firmware window demonstrated here, because rescue reset stops before the firmware gets a chance to establish them.

This is not a mass-market break

The practical limits are substantial:

  • Physical possession is mandatory. The attacker must remove package material and expose the die.
  • The preparation is destructive. This is not a covert cable or a reusable software implant.
  • The laboratory is specialized. Ledger estimates roughly $250,000 for the full setup.
  • The technique needs expertise. Sample preparation, optical localization, laser calibration, stage control, and SWD feedback all have to work together.

That makes the attack unlikely against ordinary hobby projects. It still matters for products that rely on inexpensive microcontrollers to protect valuable long-lived secrets from a capable owner, refurbisher, competitor, or forensic laboratory. Threat models change when the device can be bought, opened, and studied for months.

It also matters because localization is often the expensive part of physical research. Differential photon-emission microscopy did not merely produce a striking die photograph. It converted software-controlled bit activity into a map for the next instrument. Measurement guided fault injection.

The takeaway

Ledger disclosed the issue to Raspberry Pi on July 28 and published the research on September 18. The clearest lesson in its conclusion is broader than the RP2350: hardware security belongs to the full enforcement path.

Reviewing the permanent debug flag alone would miss the override. Reviewing the override alone would miss the reset window. Reviewing the runtime lock alone would miss the persistent state it reloads. Each component can be individually sensible while their composition leaves a path through the machine.

The RP2350 forced a sophisticated lab to work hard. That is meaningful security. The laser result does not erase those protections; it shows exactly where their guarantees end. For designers, that boundary is the useful part: protect the control that can override the lock, and reason about the state of every secret before firmware gets to speak.

Sources