Donjon's writeup emphasizes that laser fault injection has existed for two decades, but using the chip's own infrared photon emissions as a spatial and temporal map for aiming turns a needle-in-a-haystack search into a reproducible procedure. This methodological innovation — mapping transistor activity live during secure-boot verification — is what made a deterministic bypass possible against a modern MCU.
The editorial frames the attack as the intended outcome of Raspberry Pi's public hacking challenge, which explicitly invited this level of scrutiny by offering a bounty for extracting secrets from a locked chip. A $1 general-purpose MCU falling to a decap-plus-laser-lab attack is not evidence of a design flaw — it's evidence the threat model never included nation-state-grade physical attacks.
By submitting the Donjon writeup to Hacker News where it reached 167 points and 61 comments, synack signaled that this hardware security research is significant enough for a general developer audience — not just the embedded security niche. The high engagement suggests the community sees photon-guided fault injection as a meaningful advance in the practical capabilities of well-equipped attackers.
Ledger's Donjon security lab published a full walkthrough of how they bypassed the RP2350's secure debug lock using photon-emission-guided laser fault injection — a mouthful that describes a surprisingly elegant physical attack. The RP2350 is Raspberry Pi's second-generation microcontroller, launched in August 2024 with dual Cortex-M33 cores, optional Hazard3 RISC-V cores, and a new emphasis on security features: signed boot, OTP fuses, glitch detectors, and a locked-down debug interface. Raspberry Pi paired the launch with a public hacking challenge — extract a secret from a locked chip, collect a bounty. Donjon collected.
The technique works in two phases. First, the team decapped the die and used a photon emission microscope to observe faint infrared light emitted by transistors as they switch. That emission map, captured while the chip runs the secure-boot verification routine, tells them exactly where and when the relevant compare-and-branch is executing on silicon. Second, they aim a near-infrared laser at that specific transistor cluster and pulse it at the specific microsecond the branch resolves. The laser injects enough charge to flip the branch decision. Signed-boot check passes. Debug unlocks. Secret extracted.
The novel piece is not the laser — labs have been shooting lasers at chips for two decades — it's using the chip's own light emissions as a live guide for where to aim and when to fire. Without that map, laser fault injection against a modern MCU is a needle-in-a-haystack search across millions of transistors and nanosecond timing windows. With it, the attack becomes deterministic enough to write up as a reproducible procedure.
The first thing to say clearly: this is not a break of the RP2350 in any panic-worthy sense. Raspberry Pi shipped the chip with a hacking challenge specifically to attract this kind of scrutiny, and Donjon's report is the answer to that invitation. The RP2350 is a $1 general-purpose microcontroller, not a secure element. Nobody serious was going to store their private keys on one and ship it into the field expecting it to resist a nation-state lab. The interesting question is what "secure debug" on a commodity MCU is actually worth, and to whom.
The answer, roughly: it stops software attackers and casual hardware attackers cold, and it does essentially nothing against an adversary with a decapsulation rig, a photon-emission microscope, and a femtosecond laser. The equipment stack for this attack runs into six figures and requires operators who know what they're doing. That is not a garage-hacker threat model. It is, however, well within reach for competitor reverse-engineering, forensic labs, and the kind of state actors who care about extracting firmware from confiscated hardware.
Compare this to what actual secure elements do. A modern EAL5+ smartcard or the Secure Enclave on Apple silicon uses active shielding — a mesh of live wires over the sensitive logic that trips a self-destruct if cut or probed — plus light sensors, glitch detectors on multiple power and clock domains, and randomized instruction timing so an attacker can't predict when the compare-and-branch will happen. The RP2350 has some of these (glitch detectors, brownout resets), but it doesn't have the physical countermeasures, and it wasn't designed to. Donjon's writeup essentially confirms what the datasheet already told you: read the spec sheet's threat model, believe it, don't extend it.
The community reaction on Hacker News (167 points at time of writing) split predictably into two camps. One camp reads this as a failure of the RP2350's security story — Raspberry Pi marketed the security features hard, and here they are being bypassed. The stronger reading is the other one: this is exactly how the process is supposed to work. Vendor ships chip, offers bounty, world-class lab publishes reproducible attack, everyone updates their mental model. The alternative — vendors quietly overpromising and no one testing — is much worse. Donjon has done the same to STM32, NXP, and others; the RP2350 write-up is unusual only in how cleanly the photon-emission guidance ties the whole method together.
If you're building anything that sits inside a physically accessible enclosure — smart locks, medical devices, POS terminals, industrial sensors, anything a competitor might buy off the shelf and reverse — the practical rules haven't changed, but this attack sharpens them:
Do not store long-lived secrets on general-purpose MCUs. The RP2350's OTP fuses are fine for device identity that only needs to survive casual attackers. They are not fine for a signing key that unlocks a fleet, a customer database decryption key, or DRM roots. If you need any of those to survive a physically motivated attacker, put them in an actual secure element (ATECC608, SE050, OPTIGA Trust M) and speak to it over I2C. The secure element is $1–3 in bulk and does the one job the MCU cannot.
Design so extracting one device's secrets doesn't compromise the fleet. Per-device keys, provisioned at manufacture and never reused, mean the six-figure attack yields one unit's worth of access. If your device auth is a shared symmetric key baked into firmware, one Donjon-style attack ends your product line.
Treat physical security as a probabilistic delay, not a binary boundary. The right question is never "is this chip secure?" It's "how many hours and dollars does this add to an attacker's cost, and does that exceed the value they'd extract?" For a lot of products the honest answer is that a $5 MCU with signed boot is already overkill, because nobody is decapping your smart bulb. For a few products — anything with a payment secret, a fleet key, or a regulatory attestation — nothing short of a certified secure element is defensible.
The interesting frontier isn't more countermeasures on cheaper chips — the economics don't work — it's making the guidance step harder. Photon emission microscopy relies on the fact that CMOS transistors leak light in predictable patterns. Chip vendors have started experimenting with backside metal fills, dummy logic that emits similar patterns, and timing randomization that makes the emission map less predictive of the sensitive instant. Expect the next round of MCU security marketing to quietly mention these. In the meantime, the mental model to carry away is the older one, freshly re-illustrated: on a commodity part, secure boot means "secure against people who don't own a laser." That is a useful boundary. It is not the only boundary you need.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.