A laser reopened a debug port Raspberry Pi closed permanently.
The chip did everything its documentation promised, and the secret came out anyway.
On 18 September, Ledger Donjon published a laser fault injection attack against the RP2350, Raspberry Pi's dual core microcontroller.
The team tested the A4 revision, the silicon Raspberry Pi shipped after the first round of findings from its RP2350 Hacking Challenge, which ran from August to December 2024, and disclosed the fault to Raspberry Pi on 28 July 2026.
The chip's security model is not thin. Secure boot authenticates signed firmware against public key fingerprints burned into one time programmable memory, an Armv8-M TrustZone split separates Secure execution from everything else, glitch detectors watch for clock and supply manipulation, and a documented flag disables debug for good.
The target was the 128 bit secret held in OTP page 48 of the challenge configuration, a page the signed firmware locks at each boot so that nothing can read it while that firmware runs.
Raspberry Pi invites this kind of scrutiny, and the challenge repository hands out the reference configuration to anyone who wants to try.
Ledger Donjon's answer was to attack the override its own datasheet admits to.
How the laser fault injection worked
The permanent flag is CRIT1.DEBUG_DISABLE. When it is set, both cores' memory access ports are driven to zero, which prevents the access ports from performing any bus accesses at all.
The RP2350 datasheet documents the escape hatch in the same section. The DEBUGEN register lets Secure software re-enable each core's port, and the disable flag can be fully overridden by setting all of its bits.
OTP security fields are encoded with redundant voting and OTP lock bits are triple redundant, yet the documentation lists no equivalent protection for DEBUGEN.
Setting two of its bits, PROC1 and PROC1_SECURE, would therefore give Secure debug on core 1. The entire problem was finding the storage of those two bits on a die.
Photon emission narrows the search
Switching transistors leak faint near infrared photons, so the team averaged 200 frames of a loop toggling selected DEBUGEN bits, then subtracted the average of a second loop, cancelling everything the two runs shared.
What remained marked candidate sites for each bit across three regions of the camera field, which cut a blind scan down to a few micrometres.
Pulses from a 980 nm laser then calibrated two responsive positions a few micrometres apart, one that set PROC1 and one that moved the port's Control/Status Word to SDeviceEn = 1.
Because a pulse that set one bit could clear the other, the script alternated between the two positions until DEBUGEN read back as 0xc, which is itself a Secure-only read and therefore proof that the transactions carried Secure attribution.
The same scan with a 20x objective failed, since the wider spot covered the region that clears each bit as well as the one that sets it.
The reset that undid the lock
Secure debug still did not reach the secret, because the firmware closes page 48 on every normal boot.
That runtime lock is a soft lock seeded from the page's persistent lock at each OTP reset, it can only be tightened rather than loosened, and a reset discards the tightened value.
The RP-AP access port, which stays reachable even when external debug is disabled, exposes CTRL.RESCUE_RESTART, a full reset that also tells the boot ROM to halt before any user firmware runs.
With both cores parked in boot ROM wait loops, nothing re-applied the runtime lock. Ledger Donjon halted core 1, read OTP rows 0xc08 to 0xc0f, and recovered the complete challenge secret.
A second result matters more for anyone shipping devices. DEBUGEN_LOCK blocks software writes to those bits, yet a pulse still set DEBUGEN while the lock bit stayed at 1, and no observed lock bit ever went back to 0, so firmware cannot restore the disabled state once a fault has set the lock.
The write up is careful about what this does not prove. Secure boot still refuses unsigned firmware, and encrypted boot still keeps external flash out of an offline reader's hands. What the attack reaches is runtime state, and the window before firmware runs where key material in OTP sits.
Three things to change
The full setup needs destructive physical access, hardware security expertise, and roughly $250,000 of laboratory equipment, which puts the attack outside most threat models. The price tag makes that easy to dismiss, and the way the chain broke is the part worth keeping.
- Decide whether a funded lab is in your threat model, and write the answer down. A device holding a key worth cloning, and a real answer about who owns the firmware and the keys inside it, is a different case from one holding a build date. If that case is out of scope, put it in writing rather than assuming it.
- Stop treating a permanent flag as a confidentiality boundary. Deny the debugger access to sensitive targets in
ACCESSCTRLand set the debugger bit in its lock so debugger transactions cannot reopen those permissions. Then have Secure firmware checkDEBUGENon a timer and reset on an unexpected value, while accepting that both measures are friction rather than a wall, because a rescue reset runs before firmware can configure anything. - Assume a secret that can be read at reset will eventually leave. Provision revocable per device keys, keep plaintext secrets out of the OTP pages that retain Secure read access, and rehearse the rotation before you need it. That is ordinary developer security practice applied to silicon.
The enforcement path is the system
The old assumption was that individually verified mechanisms add up to a verified device, so a debug port that was disabled permanently stays disabled.
The new reality is that the enforcement path is the boundary, and on the RP2350 it runs from persistent OTP configuration through a mutable control register to reset behaviour, with the mutable register carrying none of the redundancy the persistent one gets. Work that reaches this layer rewards Linux fundamentals more than another cloud certification.
Images: Ledger Donjon, from the research published on 18 September 2026.
If your product ships a per device secret in one time programmable memory, what does your plan say about the day one of them is read out on a bench?