Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug

TL;DR

— Photon-emission microscopy allowed us to find a register liable for the enabling of debug options on the Raspberry Pi microcontroller.

— Laser pulses at two close by positions then restored debugger entry to the chip’s Secure planet, though debug had been completely disabled.

— Using that entry after a rescue reset, we recovered a secret from one-time-programmable reminiscence. The reset halted the chip earlier than firmware may apply its runtime lock, so the web page stayed Secure-readable.

— The assault requires bodily entry, harmful preparation, and roughly $250,000 of laboratory gear.

The RP2350 safety mannequin

The RP2350 is Raspberry Pi’s dual-core microcontroller: every processor socket can choose both an Arm Cortex-M33 or a RISC-V Hazard3 core at boot. Its {hardware} safety features embody:

• Secure boot, which authenticates signed firmware towards public-key fingerprints provisioned in One-Time Programmable reminiscence (OTP)
• The Armv8-M TrustZone, which separates Secure and Non-secure execution states
• Permanent debug-disable settings
• Glitch detectors supposed to detect timing disturbances attributable to clock or provide manipulation

Raspberry Pi has actively invited researchers to judge these protections by way of its RP2350 Hacking Challenges. The first problem ran from August to December 2024 towards the unique chip. After a number of findings had been addressed, Raspberry Pi launched the A4 revision—the model we examined.

The everlasting safety configuration and boot public key fingerprints are saved in one-time-programmable (OTP) reminiscence: every bit may be flipped from 0 to 1 as soon as and by no means again, so no matter is written there lasts for the lifetime of the chip.

OTP is organised into 128-byte pages protected by two persistent, or laborious, lock rows: for web page n, PAGEn_LOCK0 configures elective learn and write keys and the behaviour when no secret’s entered, whereas PAGEn_LOCK1 accommodates the hardware-enforced LOCK_S and LOCK_NS permissions. Those states can advance from read-write to read-only or inaccessible however can not change into extra permissive.

The OTP subsystem makes use of redundant encodings for security-related fields: vital flags are “encoded with a three-of-eight vote throughout eight consecutive OTP rows”, and OTP lock bits are “triple-redundant with a majority vote”, in accordance with the RP2350 datasheet.

At an OTP reset, the persistent LOCK_S and LOCK_NS values initialise a per-page runtime lock, additionally referred to as a gentle lock. Firmware can tighten this lock till the subsequent OTP reset, however can not loosen it. The runtime change doesn’t survive that reset.

An exterior debugger communicates with the RP2350 by way of Arm’s Serial Wire Debug (SWD) interface. Requests first attain the Serial Wire Debug Port (SW-DP) and are then routed to entry ports. In the Cortex-M33 configuration used right here, every core has a reminiscence entry port (Mem-AP) related to its system bus; an enabled Mem-AP lets the debugger learn and write permitted reminiscence and peripherals. A separate always-on entry port, the RP-AP, exposes a small set of reset and restoration controls.

Secure debug refers to Mem-AP entry with Secure attribution. The debugger can then transact with Secure memory-mapped sources the access-control logic permits, and halt or examine a core working within the Secure state.

The everlasting CRIT1.DEBUG_DISABLE flag is meant to shut this path. When set, it drives the allow indicators for each cores’ Mem-APs to zero, which “prevents the APs from performing any bus accesses in any respect”, and disables the factory-test JTAG interface and the RISC-V debug module’s entry port. The SW-DP and RP-AP nonetheless reply, however neither core Mem-AP can entry the system bus.

There is, nonetheless, an override: the memory-mapped DEBUGEN register lets Secure software program re-enable every core’s Mem-AP and, individually, Secure accesses by way of it. The datasheet states that DEBUG_DISABLE “may be absolutely overridden by setting all bits of this register”.

This vital override within the enforcement chain is what made the debug interface our goal. Gaining entry to Secure debug on a Mem-AP is a general-purpose primitive to learn and write Secure reminiscence, halt and single-step a core, and examine its registers. Whether that register may very well be set by a fault is the query the remainder of this submit solutions.

Experimental setup

Target configuration

Raspberry Pi’s RP2350 Hacking Challenge requested members to extract a 128-bit secret saved in OTP¹. At startup, the signed problem firmware ensures that web page 48 has the anticipated persistent lock, then applies a runtime lock that denies each Secure and Non-secure entry to the key till the subsequent OTP reset.

We replicated this vendor-defined configuration on our personal revision A4 machine:

• Programmed the SHA-256 fingerprint of our public key into BOOTKEY0
• Set BOOT_FLAGS1.KEY_VALID to 0x1 and BOOT_FLAGS1.KEY_INVALID to 0xe
• Enabled safe boot (CRIT1.SECURE_BOOT_ENABLE = 1)
• Permanently disabled debug (CRIT1.DEBUG_DISABLE = 1)
• Enabled the glitch detectors at most sensitivity (CRIT1.GLITCH_DETECTOR_ENABLE = 1, CRIT1.GLITCH_DETECTOR_SENS = 3)
• Configured the persistent locks for pages 1 and a couple of in accordance with the problem configuration
• Set the web page 48 persistent lock to PAGE48_LOCK1 = 0x3c3c3c, which denied Non-secure entry (LOCK_NS = INACCESSIBLE) whereas retaining Secure read-write entry (LOCK_S = READ_WRITE)

Enabling safe boot permits solely the Cortex-M33 cores, so each processor sockets used Arm for these experiments.

Sample preparation and bench

The machine was bottom decapsulated, in order that infrared mild reaches the transistors by way of the silicon substrate relatively than being blocked by the metallic layers on the entrance. The chip was then soldered again onto a daughterboard related to Scaffold, Ledger Donjon’s open supply platform for driving and monitoring units underneath take a look at. Removing the lead body on the bottom of the chip breaks its GND connection, so a copper wire restores it².

DEBUGEN: overriding everlasting debug disable

DEBUGEN has 5 practical bits:

Bit	Name	Effect
0	PROC0	Enable core 0’s reminiscence entry port
1	PROC0_SECURE	Permit Secure accesses by way of core 0’s reminiscence entry port
2	PROC1	Enable core 1’s reminiscence entry port
3	PROC1_SECURE	Permit Secure accesses by way of core 1’s reminiscence entry port
8	MISC	Enable further debug elements, together with the cross-trigger interface and the RISC-V debug entry port

Secure debug on a core wants each of its bits: the one that allows the Mem-AP, and the one that allows Secure accesses by way of it.

In distinction to the redundant encoding used for OTP safety fields, the datasheet paperwork no bit redundancy, parity or majority vote for DEBUGEN.

We due to this fact examined whether or not laser pulses may set DEBUGEN bits on the secured machine described above.

Photon-emission-guided localization

That take a look at first requires figuring out the place to intention. Setting a person DEBUGEN bit means hitting the storage of a single register bit, a needle in a haystack. This is a tougher focusing on drawback than the instruction-skip faults widespread in laser fault injection, the place disturbing any of the various flip-flops in a core pipeline can produce the identical skip: that spreads the delicate space broadly sufficient for a random scan to search out it. A blind scan for one DEBUGEN bit is impractical.

Switching transistors emit faint near-infrared photons correlated with their exercise, so gathering that emission over repeated execution can reveal the place a particular management adjustments state. This made photon-emission microscopy (PEM) a very good match for DEBUGEN: as a memory-mapped register, Secure software program can toggle actual bits in a loop, driving the repeated state adjustments the measurement wants. We used it as the primary localization stage, and the ensuing map constrained the next laser scan to a area of some micrometres.

We in contrast loops that repeatedly toggled chosen DEBUGEN bits on and off, differing solely within the bits they focused. A register’s photon emission is faint subsequent to the digicam’s personal noise and delicate to slowly drifting ambient situations corresponding to temperature, so a single body reveals nothing. Averaging many frames of every loop suppressed random sensor noise, and subtracting the 2 imply stacks cancelled the whole lot the loops shared: static background, sensor offset, thermal emission, and switching unrelated to the chosen bits. Interleaving the 2 values throughout acquisition stored gradual drift from biasing that subtraction. What remained was the emission that tracked the chosen bits.

Repeated comparisons throughout completely different bit masks uncovered compact websites related to DEBUGEN bits 0–3 throughout three areas of the digicam discipline.

These zones present switching exercise related to every DEBUGEN bit; they don’t instantly determine storage cells. The a number of hotspots noticed for every bit might come up from the storage component or from associated logic. Without structure knowledge, we can not distinguish between the 2. However, these zones nonetheless considerably scale back the search area.

Finding 1 — faulting DEBUGEN provides Secure debug

For laser fault injection (LFI), we used a pulsed laser at 980 nm with 2.97 W most optical energy, operated at roughly 40% (about 1.2 W), with a 100 ns pulse width by way of a 50x goal. After every pulse, we probed the debug entry ports over SWD.

Within the world discovered from PEM, we ran an LFI scan and used that SWD suggestions to calibrate two responsive positions a number of micrometres aside. At one place, pulses enabled bus entry by way of core 1’s Mem-AP, indicating that PROC1 was set. At the opposite, the Mem-AP’s Control/Status Word reported SDeviceEn = 1, a state-guided sign that PROC1_SECURE was probably set. We checked each indicators after each pulse.

A pulse that set one bit may clear the opposite, so setting each required an iterative sequence. Our script pulsed the PROC1 place till bus entry was accessible, then pulsed the PROC1_SECURE place till SDeviceEn = 1, returning to the primary place at any time when bus entry was misplaced. Once the positions and pulse parameters had been calibrated, the sequence enabled Secure debug inside seconds. Interestingly, we couldn’t reproduce this sequence utilizing a 20x goal. Because the 2 positions are just a few micrometres aside, that wider spot probably hit each the area that units a bit and the one which clears it, so it was not potential to acquire the proper worth.

Once each bits had been set, they remained set with out additional pulses or software program writes. Reading the Secure-only DEBUGEN register by way of core 1’s Mem-AP then returned 0xc; as a result of DEBUGEN is Secure-only, that profitable learn confirms the transaction was Secure-attributed.

Enabling Secure accesses by way of core 1’s Mem-AP permits the debugger to learn and write memory-mapped sources whose ACCESSCTRL permissions admit the debugger as a bus supervisor and whose target-specific controls admit Secure AHB transactions. Independently of these direct reads, the debugger can halt and single-step the core and examine or modify its registers, compromising TrustZone runtime isolation by way of Secure-core-mediated extraction. This doesn’t make the boot ROM settle for unauthenticated firmware: when firmware boots usually, safe boot nonetheless authenticates it, however can not defend runtime state that is still accessible to the debugger after verification.

Application to the Hacking Challenge configuration

The Secure-attributed Mem-AP entry described above exposes Secure runtime state, however the problem’s web page 48 runtime lock nonetheless prevents entry to the key after firmware has run. The web page’s persistent lock, PAGE48_LOCK1 = 0x3c3c3c, denies Non-secure reads however leaves LOCK_S at READ_WRITE, so it stays readable by way of Secure-attributed accesses earlier than the runtime lock is tightened.

During every boot, the firmware writes essentially the most restrictive binary worth, 0b1111, to the runtime lock otp_hw->sw_lock[48]. That register then makes the web page inaccessible to each Secure and Non-secure accesses, together with Secure debug, and due to this fact prevents Secure transactions from the Mem-AP from studying the key.

As documented, software program locks “are initialised from the OTP lock pages at reset”, and a write solely advances the state “till subsequent reset”. Resetting the OTP block discards 0b1111 and restores the worth derived from PAGE48_LOCK1, for which LOCK_S = READ_WRITE.

The remaining query is learn how to reset a locked chip with out permitting firmware to re-apply the runtime lock. The RP-AP stays “at all times accessible, even when exterior debug is disabled”. Setting CTRL.RESCUE_RESTART triggers a rescue reset: a full system reset that additionally flags the boot ROM to halt earlier than any person software program runs.

The boot ROM checks POWMAN_CHIP_RESET.RESCUE_FLAG earlier than watchdog, flash or USB boot, clears it, then holds core 0 in an interrupt-disabled wait loop and core 1 in its wait-for-vector path.³ The datasheet paperwork no restriction on CTRL.RESCUE_RESTART.

We proceeded within the following sequence:

1. Rescue reset. Set CTRL.RESCUE_RESTART to 1, then clear it to 0 by way of the RP-AP. The chip resets and stays in boot-ROM wait paths. The signed firmware by no means runs, so sw_lock[48] isn’t tightened and stays on the permissive worth derived from PAGE48_LOCK1 — LOCK_S = READ_WRITE.
2. Fault DEBUGEN to 0xc. With each cores in boot-ROM wait paths, set PROC1 and PROC1_SECURE as described above; these two set bits produce the worth 0xc.
3. Halt core 1 by way of its Debug Halting Control and Status Register (DHCSR) over the now-Secure Mem-AP.
4. Read the key from OTP rows 0xc08–0xc0f by way of the guarded learn interface.

We ran this sequence on the examined machine and recovered the entire problem secret.

DEBUGEN_LOCK doesn’t forestall laser-induced adjustments

DEBUGEN_LOCK blocks software program writes to the corresponding DEBUGEN bits: every lock bit is “Write 1 to lock the […] little bit of DEBUGEN. Can’t be cleared as soon as set”. The datasheet presents this as a method “to keep away from unintended writes”.

In trials with the goal DEBUGEN bit at 0 and its lock bit at 1, a pulse may nonetheless set DEBUGEN whereas the lock remained 1. Pulses additionally set lock bits, with or with no corresponding DEBUGEN change. In profitable sequences, all 5 practical lock bits had been 1 by the point PROC1 and PROC1_SECURE had been each set. We by no means noticed a lock bit return from 1 to 0, so a later write of DEBUGEN = 0 can not restore the disabled state as soon as the fault has set the corresponding lock.

Limits of software-based mitigations

Once Secure accesses by way of the Mem-AP are enabled, Secure attribution alone now not separates the debugger from Secure firmware. This entry doesn’t override laborious OTP locks or peripheral-specific controls. ACCESSCTRL can block direct debugger-manager transactions to explicit targets, nevertheless it doesn’t by itself forestall a debugger controlling the Secure core from inflicting core-originated accesses or extracting loaded values by way of core registers. After a rescue reset, ACCESSCTRL returns to its all-open reset-time defaults earlier than firmware can reconfigure it. ACCESSCTRL due to this fact reduces direct Mem-AP publicity relatively than forming a standalone confidentiality boundary.

Firmware can nonetheless scale back post-boot publicity by denying the debugger entry to delicate targets in ACCESSCTRL, then setting the debugger bit in ACCESSCTRL.LOCK in order that debugger transactions can not reopen these permissions. Secure firmware also can verify DEBUGEN periodically and, on an sudden worth, set off a fail-safe reset that clears the processor-cold reset area. These measures are best-effort runtime mitigations: an enabled debugger might halt the core earlier than the subsequent verify, and rescue reset stops earlier than firmware can configure ACCESSCTRL or run the monitor. They due to this fact don’t forestall the pre-firmware secret learn demonstrated right here.

RP2350’s documented encrypted-boot circulation illustrates the pre-firmware limitation of runtime locks and the post-boot limitation of debugger-manager filtering in two distinct machine states. After rescue reset, the boot ROM halts earlier than decryption: no plaintext payload exists but, however the decryption key could also be instantly readable if the OTP web page’s persistent permissions permit Secure entry and no different goal management blocks the transaction. After regular encrypted boot, plaintext exists in SRAM: direct Mem-AP reads depend upon debugger-manager permissions in ACCESSCTRL, whereas Secure-core management might allow core-mediated extraction even when direct reads are denied. This is architectural evaluation, not a examined encrypted-boot outcome; encrypted boot nonetheless protects exterior flash from offline inspection.

Impact and assault necessities

The demonstrated sequence gives Secure-attributed reminiscence entry, management over Secure-world execution, and entry to the problem secret after resetting its runtime web page lock. It requires the next sources:

• Destructive bodily entry. Backside decapsulation completely modifies the package deal and leaves the die uncovered.
• Specialised laboratory gear. The full setup described above prices roughly $250,000.
• Hardware-security experience. The process requires pattern preparation, die navigation, laser parameter choice, and coordinated laser management, stage positioning, and SWD measurement.

Conclusion

The RP2350 encodes vital debug-disable flags in OTP with redundant voting, however DEBUGEN can override their impact and has no equal safety documented within the datasheet. In our experiments, laser pulses modified DEBUGEN regardless of DEBUGEN_LOCK and will set a lock bit that prevented firmware from restoring the disabled worth. Separately, the RP-AP rescue reset restored the problem’s runtime web page lock to its persistent worth whereas stopping person firmware from executing. The software-visible mechanisms every carried out their documented perform, however their interplay with the laser fault enabled Secure debug and restoration of the problem secret. Differential PEM first remoted bit-dependent DEBUGEN exercise, and guided LFI transformed that spatial lead into persistent Secure debug. The system-level lesson is that safety evaluation should cowl the entire enforcement path, from persistent OTP configuration by way of mutable management registers and reset behaviour, as a result of system safety relies on that path relatively than on particular person mechanisms in isolation.

Disclosure and acknowledgements

We disclosed this fault to Raspberry Pi on 28 July 2026. We thank the Raspberry Pi group for his or her engagement within the disclosure discussions and for his or her clear method to safety analysis.

---

Antoine Plin, Hardware Security Intern at Ledger Donjon