Skip to content
HN On Hacker News ↗

Laser Fault Injection on a Budget: RP2350 Edition

▲ 66 points • 18 comments • by gregsadetsky • 3w ago • HN discussion ↗

Pangram verdict · v3.3

We believe that this entire text is human-written.

0 %

AI likelihood · overall

Human
100% human-written 0% AI-generated
SEGMENTS · HUMAN 1 of 1
SEGMENTS · AI 0 of 1
WORD COUNT 1,514
PEAK AI % 0% · §1
Analyzed
Oct 17
backend: pangram/v3.3
Segments scanned
1 windows
avg 1514 words each
Distribution
100 / 0%
human / AI fraction
Verdict
Human
Pangram v3.3

Article text · 1,514 words · 1 segments analyzed

Human AI-generated
§1 Human · 0%

IntroductionIn August 2024, Raspberry Pi introduced the RP2350 microcontroller. This part iterates over the RP2040 and comes with numerous new features. These include security-related capabilities, such as a Secure Boot implementation.A couple of days after this announcement, during DEFCON 2024, an interesting challenge targeted at these new features was launched: the RP2350 Hacking Challenge.After some work and the development of a fully custom “Laser Fault Injection Platform”, I managed to beat this challenge and submitted my findings to Raspberry Pi.This article will provide technical details about this custom platform, including manufacturing files for those interested in building their own. Additionally, I will explain how injecting a single laser-induced fault can bypass the Secure Boot feature of the RP2350.WarningThe “Laser Fault Injection Platform” introduced in this article makes use of an infrared high-power laser source. Such a component can be hazardous; be careful if you attempt to reproduce this work.Hacking Challenge & RP2350 Security FeaturesObjectives of the ChallengeThe target of this challenge is a Pico 2 board, which hosts a RP2350 microcontroller. It must be configured according to the instructions provided in the challenge’s GitHub repository.Following the instructions from the repository will:Write “secret” data into one of the OTP areas of the RP2350.Configure and enable the Secure Boot feature, locking the chip as much as possible. This includes disabling debug interfaces (SWD) and enabling various security features, such as glitch detectors.Flash a signed firmware that primarily restricts even more access to the OTP area where the secret is stored.The goal of the challenge is to find a way to recover the secret data, potentially bypassing the Secure Boot feature in the process.Security FeaturesThe Secure Boot feature is enforced by code contained in the Boot ROM of the RP2350. This code is hardened in several ways, going beyond software methods; the Boot ROM leverages hardware-specific features.These features are primarily related to an innovative component called the “Redundancy Co-Processor.” Quoting the RP2350 Datasheet:The redundancy coprocessor (RCP) is used in the RP2350 bootrom to provide hardware-assisted mitigation against fault injection and return-oriented programming attacks. This includes the following instructions:generate and validate stack canary values based on a per-boot random seedassert that certain points in the program are executed in the correct order without missing stepsvalidate booleans stored as one of two valid bit patterns in a 32-bit wordvalidate 32-bit integers stored redundantly in two words with an XOR parity maskhalt the processor upon reaching a software-detected panic condition[…]Each core’s RCP has a 64-bit seed value (Section 3.6.3.1). The RCP uses this value to generate stack canary values and to add short pseudorandom delays to RCP instructions.Additionally, the RP2350 is capable of detecting fault injection attempts using glitch detectors. These configurable circuits respond to voltage or electromagnetic fault-injection attempts and reset the system. For this challenge, these detectors are set to their maximum sensitivity level.Article OverviewBelow is a brief, high-level summary of the article’s content.Why choosing Laser Fault InjectionConsidering that the Boot ROM of the RP2350 has been audited before the opening of the challenge, I did not attempt to find logic bugs in it and quickly considered a hardware attack, such as a fault injection attack.However, online comments tend to show that the glitch detector system implemented in the RP2350 was rather efficient in mitigating simple voltage fault injection attacks.Hence, I quickly decided to tackle the challenge with laser fault injection, assuming that focusing a laser beam away from the glitch detector circuits could allow for injecting faults without triggering them.Now, the thing is, while I did have some experience with “classic” voltage fault injection attacks, I knew nothing about laser fault injections.This challenge was then used as an opportunity to build a fully custom, cheap laser fault injection platform.Note that while traditionally known to be expensive to implement, several “cheap” platforms aimed at injecting faults with a laser have emerged over the past few months:Laser Fault Injection for The Masses is repurposing laser engraving hardware.The “RayV-Lite” from NetSPI. However, at the time of writing, very few publicly available technical details are available regarding this project.NoteMy mistake, after some research, I actually managed to find this presentation of the “RayV-Lite” introduced at Blackhat 2024. Their project presents various similarities with my “Laser Fault Injection Platform”, but also interesting differences. I’ll highlight some of these differences in this article and encourage you to check out their work.August 2025 update: Even more material is now publicly available! This includes an article on NetSPI’s website.Sample PreparationThe idea being LFI is reasonably simple. A focused laser beam is directed at the silicon die of the target component. Transistors are sensitive to photoelectric effects, meaning the emitted light can be enough to induce temporary faults or malfunctions. When precisely timed, these faults could be leveraged to bypass security features.A major downside of such an attack compared to voltage or clock glitching is that the silicon die of the target has to be exposed. Of course, the circuit must still be able to operate normally after the die has been exposed.Accessing the silicon can either be attempted from the top, or the bottom side of the packaged chip.Simplified Top and Bottom Sides Render of a Packaged Integrated CircuitI chose to expose performed from the backside of the die. This choice has been made for two reasons:Accessing the backside can be achieved with cheap mechanical tools. However, exposing the top of the die would have required chemicals I would rather not deal with, such as concentrated nitric acid.Based on images available online, it seems the top of the die is fully covered by a metal layer, likely complicating fault injection.The process I developed to expose the backside of the silicon die is detailed in the relevant sections of this article.Die Imaging & Laser FocusingLFI requires targeting with a focused laser beam relatively precise areas of the die. A custom, cheap Laser Fault Injection platform has been designed for this purpose.The Laser Fault Injection PlatformBecause the design of this platform is very budget oriented, corners had to be cut in multiple paces, resulting in various limitations. These limitations, alongside various technical details and working principles, are detailed in the corresponding sections of this article.To enable others to reproduce my results, I will also be sharing the relevant manufacturing files and source code.Fault Injection & Secure Boot BypassBeing able to inject faults is just the first step in attacking the RP2350. As previously mentioned, the glitch detectors are not the only security feature that Raspberry Pi developed to protect the system.It is also necessary to identify a weakness in the Boot ROM of the component, where the Secure Boot feature is implemented. The specific sequence of instructions I targeted will be discussed in the relevant sections of this article.Sample PreparationThis section describes the initial steps required to execute the attack. The backside of the die of the target RP2350 must be carefully exposed, ensuring that the chip’s functionality remains intact.Die ExposureThe target RP2350 first has to be desoldered from the Pico 2 board. This can be achieved with a simple hot air reflow station.Next, a cheap (€30) dremel-like tool, advertised as an “Engraving Tool” (Amazon Part Number: UKH062_FR), has been used to carefully remove material around the ground pad.The tool used to expose the dieAfter enough material has been removed, the metallic ground pad can be taken off, exposing a layer of what looks like silver (heat-conductive?) paste. This paste can easily be scratched out, revealing the backside of the die.Exposed Backside after Mechanical GrindingMain Carrier BoardThe prepared sample can then be soldered on a custom PCB, designed to integrate with the Laser Fault Injection Platform.RP2350 Backside Carrier BoardA hole in the middle exposes the backside of the RP2350 die.Backside view of the board, the die is visibleThe board doesn’t include anything more, apart from a small LDO used to power the core. Power and control signals are routed away to an FFC connector. flowchart LR B{{FFC Connector}} <-->|UART| A(RP2350) A <-->|SWD| B A <-->|USB| B A <-->|QSPI| B A <-->|Control Signals| B B .->|3V3| A B .->|3V3| C((LDO)) C .->|1V1|A Main Carrier Board Architecture DiagramThis PCB can be hand-assembled, and the total unit BOM cost for small quantities is estimated at less than €10. Interactive 3D Render & Design Files I/O BoardThe Main Carrier Board detailed above connects to the I/O Board through a FFC cable.I/O Board and Main Carrier Board, placed in a 3D-printed holderThe assembly of these two boards is designed to integrate with the Laser Fault Injection Platform.I/O Board and Main Carrier Board, placed in the Laser Fault Injection PlatformThe I/O Board breaks out the various control signals over:A USB connectorPin headers that are connected to a FPGA board, later used to implement the attack’s logicA few test points used for SWD debugging (seldom used, especially considering SWD needs to be disabled for this challenge) flowchart TB A((LDO)) .->|3V3| B((Power Switch)) C{{USB Connector}} .->|5V| A C <-->|USB| D{{FFC Connector}} B .->|3V3| D E{{Pin Headers}} -->|Enable| B D <-->|Control Signals| E D <-->|QSPI| E D <-->|UART| E D <-->|SWD| F(Test Points) D <-->|QSPI| G(QSPI Flash #0) D <-->|QSPI| H(QSPI Flash #1) I/O Board Architecture