RP2350-A4 debug lock falls to a $250,000 laser lab, and Raspberry Pi won't respin the chip

Ledger Donjon, Ledger's security research team, has restored Secure debug access on an RP2350-A4 that had debug permanently disabled, and used it to read the 128-bit secret from Raspberry Pi's own Hacking Challenge configuration. It published the method on September 18. The same day, Raspberry Pi answered that "these findings don't warrant a respin of the chip." Donjon says it disclosed the fault on July 28.

The weak link was a register, not the fuses

The RP2350 keeps its permanent security settings in one-time-programmable memory, with redundancy. Donjon quotes the datasheet: critical flags are "encoded with a three-of-eight vote across eight consecutive OTP rows." Setting CRIT1.DEBUG_DISABLE cuts both cores' memory access ports off the bus.

The override is where the attack went. The memory-mapped DEBUGEN register lets Secure software re-enable those ports, and the datasheet says DEBUG_DISABLE "can be fully overridden by setting all bits of this register." Donjon's point: "In contrast to the redundant encoding used for OTP security fields, the datasheet documents no bit redundancy, parity or majority vote for DEBUGEN."

Finding one bit with a camera, then a laser

Setting one register bit is, in Donjon's words, "a needle in a haystack." Donjon backside-decapsulated the chip, then used differential photon-emission microscopy: loop firmware that toggles chosen DEBUGEN bits, average many frames, and subtract to see which transistors switch with which bit. That narrowed the laser scan to "a region of a few micrometres."

The fault itself: "a pulsed laser at 980 nm with 2.97 W maximum optical power, operated at roughly 40% (about 1.2 W), with a 100 ns pulse width through a 50x objective." Two positions a few micrometers apart set PROC1 and PROC1_SECURE. Once calibrated, "the sequence enabled Secure debug within seconds." A 20x objective did not work, likely because the wider spot hit both the set and clear regions.

The software lock did not help. DEBUGEN_LOCK blocks software writes, but "a pulse could still set DEBUGEN while the lock remained 1," and pulses also set lock bits. Donjon writes that "a later write of DEBUGEN = 0 cannot restore the disabled state once the fault has set the corresponding lock."

Getting past the runtime lock

The challenge firmware locks the secret's OTP page at every boot. The persistent lock underneath still allowed Secure reads. Donjon used the always-on RP-AP port to trigger a rescue reset: a full system reset that flags the boot ROM to halt "before any user software runs." The firmware never ran, so the page stayed readable. They then faulted DEBUGEN to 0xc, halted core 1, and read OTP rows 0xc08 to 0xc0f. "We ran this sequence on the tested device and recovered the complete challenge secret."

The same logic reaches encrypted boot. Donjon flags this as "architectural analysis, not a tested encrypted-boot result": after a rescue reset, the decryption key may be readable if its OTP page's persistent permissions allow Secure access.

Raspberry Pi's position, and what designers can do

Raspberry Pi gives three reasons for not changing the silicon:

This is a destructive attack that requires the chip to be removed and de-encapsulated

Raspberry Pi, "Everything is better with lasers"

The other two: "Assuming that per-device keys are used, it should have only a single-device scope," and the attack "requires a very particular set of skills, together with a lab full of bougie equipment and/or a spare $250K." Donjon's own estimate for the setup is "approximately $250,000."

That reasoning gives product designers their checklist:

• Per-device keys. Raspberry Pi's scope argument depends on them. A fleet-wide secret in OTP turns one decapsulated chip into every device.
• Persistent OTP locks, not just runtime ones. The secret was readable because its page's persistent lock left LOCK_S at read-write. A runtime lock applied by firmware does not survive a rescue reset.
• ACCESSCTRL and a DEBUGEN watchdog reduce exposure after boot. Donjon calls them "best-effort runtime mitigations" that "do not prevent the pre-firmware secret read demonstrated here."

Raspberry Pi says its second Hacking Challenge, on side-channel analysis, "remains unbeaten" after two deadline extensions and "runs until the end of next month."

Primary sources: Ledger Donjon, "Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug", Raspberry Pi, "Everything is better with lasers", read 2026-09-25.