The RP2350 A4 can keep signed boot intact and still expose a protected OTP secret to a lab attacker. Ledger Donjon used photon-emission microscopy and laser pulses at two spots a few micrometres apart to re-enable Secure debug on the microcontroller, then recovered a 128-bit secret from one-time-programmable memory. The part that matters is smaller than a boot-ROM bypass: two mutable register bits sat downstream from a setting described as permanently disabling debug.
This is a narrow physical attack. It requires destructive backside decapsulation, an exposed die, hardware-security expertise and a laboratory setup that Ledger estimates at about $250,000. Once the researchers had calibrated the equipment, though, the sequence reopened Secure debug within seconds. Their report says it worked on revision A4, the chip revision released after Raspberry Pi addressed several findings against the original silicon.
The override behind permanent debug disable
RP2350 has two processor sockets, each able to boot as an Arm Cortex-M33 or a Hazard3 RISC-V core. Its security controls include signed boot, Arm TrustZone, glitch detectors and permanent configuration in one-time-programmable memory, or OTP. Raspberry Pi's public hacking challenge configured those controls together: it enabled secure boot, disabled debugging and locked a 128-bit secret into OTP rows beginning at 0xc08.
The permanent CRIT1.DEBUG_DISABLE flag shuts down the core memory access ports, preventing a debugger from reaching the system bus. Yet the RP2350 datasheet documents a Secure-only DEBUGEN register that software can use to restore debug features. This is intentional. A device maker might want authenticated Secure firmware to open a debug session without weakening its default configuration.
For core 1, bit 2 of DEBUGEN enables its memory access port and bit 3 permits Secure transactions through that port. Set together, they produce the value 0xc. OTP security fields use redundant encodings and majority voting, while Ledger found no documented redundancy, parity or majority vote on these DEBUGEN bits in the register specification. That made the override register a more practical fault target than the permanent fuse itself.
A companion register, DEBUGEN_LOCK, can block later software writes. It did not block the physical fault. Ledger reports that a pulse could set a locked DEBUGEN bit while the lock bit remained set. In some successful runs, the pulse also set the lock, leaving software unable to write the debug-enable bit back to zero.
Finding two bits by watching the die glow
A blind laser scan would have been a poor search. The target was storage or nearby logic associated with individual register bits, rather than any one of the many processor elements that might cause an instruction skip. Ledger first removed the back of the chip package so infrared light could reach the silicon, then put the device back on a test board connected to its open Scaffold platform.
Switching transistors emit faint near-infrared photons. The team repeatedly toggled selected DEBUGEN bits from Secure software, captured the emissions and compared averaged images. The published experiment used mean stacks of 200 full-view captures. Subtracting one stack from another removed much of the shared background and left compact areas whose activity changed with bits 0 through 3. The images located activity associated with the bits. They did not prove which pixels were the storage cells.
That map reduced the laser search to a region measured in micrometres. The researchers used a 980 nm laser at roughly 1.2 watts, with 100 nanosecond pulses through a 50x objective. One responsive position enabled bus access through core 1's memory port. A second position made the port report that Secure transactions were enabled. Serial Wire Debug feedback after each pulse told the control script which bit had changed.
The physical behavior was awkward enough to reveal why precision mattered. A pulse that set one bit could clear the other, so the script moved between the two positions until both indicators were present. Ledger could not reproduce the sequence with a 20x objective. Its wider spot probably hit regions that set and clear the target state at the same time. With the 50x objective, the resulting DEBUGEN value read back as 0xc and remained set without further pulses.
Secure debug gave the probe access to memory-mapped resources that permit debugger transactions, plus the ability to halt or single-step the Secure core and inspect its registers. It did not make the boot ROM accept unsigned firmware. Ledger's account explicitly separates signed-boot enforcement from runtime debug access: authenticated code still boots, but sensitive state can become reachable after verification if the debugger regains control.
A rescue feature opens the second half of the path
Reopening debug was insufficient to read the challenge secret after normal startup. The OTP page's persistent lock denied Non-secure access but allowed Secure reads and writes. Challenge firmware tightened a runtime lock during boot, making the page inaccessible to both worlds until the next OTP reset. Those runtime locks can become stricter while the chip runs, but the datasheet says they are initialized again from persistent OTP locks at reset.
RP2350 also has an always-accessible debug component called the RP-AP. Its RESCUE_RESTART control exists so developers can recover a chip whose program has broken normal debug access. Setting and clearing that bit performs a reset and leaves the processors halted early in the boot path. Raspberry Pi's published boot-ROM source checks the rescue condition before ordinary flash or USB boot, then keeps core 0 in an interrupt-disabled wait while core 1 waits for a vector. User firmware never gets a chance to tighten page 48's runtime lock.
Ledger chained the two behaviors. The team issued a rescue reset, faulted core 1's two DEBUGEN bits to form 0xc, halted that core through the restored Secure memory port and read OTP rows 0xc08 through 0xc0f. The complete sequence recovered the challenge's 128-bit secret. Neither mechanism failed on its own terms: rescue mode stopped before user code, and the override register enabled debug as designed. Their composition broke the intended boundary.
What owners can defend today
The demonstrated read depended on page 48's persistent permissions still allowing Secure access after reset. Ledger says the fault does not override hard OTP locks or every target's own access controls. That distinction matters for deployment reviews. A secret protected only by a runtime lock can reappear during a reset window, while an OTP page whose persistent Secure permission is inaccessible does not offer the same direct read path described in this experiment.
Firmware can reduce exposure after an ordinary boot. Ledger suggests restricting debugger access to sensitive targets through ACCESSCTRL, locking that configuration and checking DEBUGEN for an unexpected value. Those measures have limits. An enabled debugger may halt the core before a periodic check, and rescue mode stops before firmware can install its access policy. The report treats them as best-effort controls, not a fix for the pre-firmware read.
The research also analyzes encrypted boot without claiming to have tested that path. After a rescue reset, encrypted payload code has not been decrypted, but an OTP-held decryption secret may still be exposed if its persistent permissions allow Secure reads. After a normal encrypted boot, plaintext in SRAM presents a different target. Ledger labels this portion as architectural analysis, so it should not be read as a second demonstrated extraction.
Ledger says it disclosed the fault to Raspberry Pi on July 28, 2026. The next useful evidence will be a public Raspberry Pi assessment, updated deployment guidance or a silicon revision that changes the DEBUGEN enforcement path. Until then, RP2350 threat models should treat permanent debug disable, mutable debug overrides and rescue-reset behavior as one system. The fuse alone did exactly what its documentation promised. The route around it remained on the die.