"Laser fault injection on the RP2350: what a $250k bench taught us about secure boot and physical access"

Laser fault injection on the RP2350: what a $250k bench taught us about secure boot and physical access

If you write firmware for a microcontroller, "the attacker has the device" is the threat model you quietly hope stays theoretical. A recent Ledger Donjon research post makes the boundary of that hope very concrete. Raspberry Pi's RP2350 has a serious security architecture: secure boot with public-key fingerprints burned into one-time-programmable (OTP) memory, Arm TrustZone splitting Secure and Non-secure execution, permanently disable-able debug, and glitch detectors that defeat the classic voltage-glitching techniques. Donjon broke it anyway, with a laser, and read out a 128-bit secret that the chip's own challenge was designed to protect.

The target and its defences

The RP2350 is Raspberry Pi's dual-core microcontroller, which can boot either Arm Cortex-M33 or RISC-V cores. The vendor ran a public RP2350 Hacking Challenge asking researchers to extract a secret held in OTP memory while a signed challenge firmware locked the page away. The device under test, revision A4, was configured exactly as a security-conscious product designer would:

• Secure boot enabled, with the SHA-256 fingerprint of the legitimate public key in OTP.
• Debug permanently disabled via the CRIT1.DEBUG_DISABLE flag. This drives the per-core debug access ports (Mem-APs) to zero bus access, so an SWD probe physically cannot reach the system bus.
• Glitch detectors at maximum sensitivity, blocking the voltage/clock manipulation class of attacks.
• The challenge's OTP page locked so the secret is unreadable from both Secure and Non-secure state.

The weakness Donjon found is architectural, and it is the same shape as the Citrix log-poisoning bug this month: a redundant, hard-to-change setting whose effect can be overridden by something softer downstream. The OTP flags that disable debug are written with heavy redundancy: critical fields use an eight-row three-of-eight vote, and lock bits are triple-redundant with majority vote, per the RP2350 datasheet. But a memory-mapped register called DEBUGEN exists specifically so that Secure software can re-enable debug at runtime, and it has no documented redundancy, parity or vote at all. Five bits in a register decide whether the debugger reaches the Secure world, and a laser can flip bits.

How the attack worked

The attack needed two expensive ingredients: knowing where to aim, and a tool that can flip a chosen transistor. Donjon's process:

1. Find the register on the die. The chip was decapsulated from the back, so infrared light passes through the silicon substrate instead of bouncing off the metal layers on top. Using photon-emission microscopy, the team recorded the faint near-infrared light that switching transistors emit, running two firmware loops that toggled different DEBUGEN bits, averaging hundreds of frames, and subtracting one from the other. What survived the subtraction was the emission tied to exactly those bits, localising them to zones a few micrometres wide.
2. Flip the bits with a laser. Within those zones, a pulsed 980 nm laser at about 1.2 W injected photo-carriers into the die. At two positions a few micrometres apart, pulses set PROC1 (the debug-port enable) and PROC1_SECURE (the Secure-attribution allow) for core 1. Each pulse was verified by probing over SWD and checking the access port's status word, a nice example of measurement-guided fault injection.
3. Reset into the window. With Secure debug restored, the team used the RP-AP's rescue reset to bounce the chip before firmware could re-apply the runtime lock on the secret's OTP page. The runtime lock is strictly a boot-time artefact: it cannot loosen, but it also does not survive the reset. The halted chip, with DEBUGEN still set, exposed the page. The 128-bit challenge secret fell out.

Total equipment: roughly US$250,000 of laser, microscope, positioning and measurement hardware, plus destructive sample preparation and serious expertise. Hackaday's coverage puts the result in context: this is not a wallet-friendly attack, but it also is not exotic-military-only territory anymore. Photonic-emission guided fault injection is a documented, reproducible laboratory technique.

The defensive lessons

Three lessons generalise beyond Raspberry Pi's silicon:

• Redundancy must cover the whole enforcement path. The OTP flags were defended like a vault door, but the runtime override register that gates their effect was defended like a light switch. Design review needs to follow a security property from its storage, through its runtime enforcement, to its reset behaviour, and require the same tamper resistance at each hop.
• Boot-time locks need boot-time thinking. The runtime lock failed not because it was weak but because its lifetime (until next OTP reset) was longer than the firmware's ability to reassert it in some boot modes (halted before the lock re-applies). If a lock's purpose is "nothing can read this page", the design must ask what a debugger sees in every boot state, including rescue paths.
• Cheap devices deserve honest threat models. None of this means RP2350-based hobby gear is suddenly insecure: an attacker who spends a quarter of a million dollars defeating your dev board's debug lock is after something much more valuable than your device. It matters for commercial products that embed secrets (media-player keys, payment tokens, firmware IP) where one lab extraction scales to every shipped unit.

Raspberry Pi disclosed the finding to the vendor on 28 July 2026, and the company's engagement was noted positively by the researchers. Expect the next silicon revision to answer the comment-thread suggestions, such as redundant encoding of the debug-enable state.

What this means for your own hardware

It is also a reminder that the firmware-verification habit matters: knowing what code should be on a device, and checking signatures from upstream, is the cheap defence that survives even the fancy attacks. Our firmware verification page explains how we handle that for the hardware we ship.

Two more practical notes worth carrying into product design conversations, if you ship embedded hardware yourself. First, fault injection resistance is partly a coding discipline: computing a security-critical decision twice, in different ways, and comparing the results before acting on them (a redundant-computation check) raises the number of precise laser hits an attacker needs from a couple to many, which is often enough. Second, keep secrets out of mutable runtime registers where you can. The difference between "the OTP flag is triple-redundant" and "the override register has no parity" in this research is the difference between an unbroken design and a broken one, and that level of detail is a genuine code-review question, not just a datasheet footnote. Neither measure is free, but for any product whose whole value rests on one secret, they are the conversation to have before the product ships, not after Donjon or its equivalents publish.

For Australian buyers of hobby and prosumer security hardware, the practical takeaways are modest but real. Physical access remains king: a Faraday pouch or a lockbox stops casual tampering, but no consumer device should be trusted to hold your most critical secrets if its silicon was never designed for a lab-grade adversary. Our faraday shielding guide covers what shielding does and does not stop, and our ESP32 Bruce firmware guide covers the research tooling ecosystem on comparable chips. If you want a board to study the same concepts hands-on, the Marauder WiFi devboard and a general ESP32 dev starter kit are honest starting points, with the standing caveat that security research belongs on devices you own or are authorised to test.

This post is general security information, not legal advice.

Sources: Ledger Donjon: photon-emission-guided laser fault injection on RP2350 · Raspberry Pi RP2350 Hacking Challenge · RP2350 datasheet (RP-008373) · Hackaday: Laser your way into debug mode on the RP2350

← All posts