AI-assisted hardware hacking just collapsed a six-week brute-force glitch campaign into seven minutes. When security researcher Adam Laurie asked an LLM where to position an EM probe, when to fire the pulse, and at what voltage — instead of getting a refusal or vague guidance, he got a precise, bootloader-derived answer that cracked a locked chip on the first calibrated attempt. This is what AI-assisted hardware hacking looks like in practice.
For security engineers and hardware researchers, this shift matters enormously. The techniques that once required nation-state lab budgets and months of expertise are being compressed into $7 microcontrollers and an afternoon of AI-guided iteration. This post breaks down exactly how Laurie used LLMs to guide EM fault injection, how Claude autonomously designed a full hardware hacking toolkit on a Raspberry Pi Pico, and what the democratization of hardware exploitation means for the security community.
Key Takeaways
- You'll learn how to use LLMs like ChatGPT and Claude to determine optimal EM fault injection parameters — probe position, pulse timing, and voltage — in minutes instead of weeks of brute-force trial and error.
- You'll be able to build a sub-$10 disposable hardware hacking platform using a Raspberry Pi Pico that replaces over $1,000 of lab equipment, with AI generating all the embedded firmware for you.
- Apply AI-driven closed-loop control (ADC voltage feedback) to transform non-deterministic glitch attacks into reproducible, deterministic exploits — a technique Claude conceived autonomously mid-conversation.
Why Hardware Hacking Resisted AI — Until Now
AI-assisted hardware hacking seemed like a contradiction in terms — at least to Adam Laurie, a veteran hardware hacker with decades of experience. His initial skepticism was grounded in something concrete: hardware hacking is physical work. It requires a lab. Oscilloscopes, FPGAs, EM pulse generators, debuggers, power supplies, and a tangle of cables connecting them all. When AI emerged as a force in the security industry, Laurie’s instinct was straightforward — until a robot arm could walk into a lab and start plugging things in, AI had nothing to offer him.
The Physical Problem with AI in Hardware Security
The objection wasn’t philosophical — it was practical. Hardware hacking requires physical interaction with silicon. To perform electromagnetic fault injection, you need:
- A probe positioned over a specific point on a chip die
- Precisely timed voltage pulses measured in nanoseconds or microseconds
- A power supply tuned to specific voltages
- Oscilloscopes and logic analyzers monitoring the target in real time
None of that is addressable by a language model. Laurie’s view was that AI was useful for lookup tasks — identifying an unknown component from a photograph, pulling a datasheet — but not for the core work of hardware exploitation. He summed it up bluntly: “How the hell can AI help me with that?”
What Changed: The Six-Week Failure That Forced the Question
The turning point wasn’t a philosophical shift — it was a failed glitch campaign. Laurie had been attempting to dump firmware from a locked chip using EM fault injection. The process is non-deterministic: there’s no guarantee any single glitch attempt will succeed, so scripts run continuously, varying probe position, timing, and pulse voltage across thousands or millions of iterations. He left his scripts running for six weeks straight, 24/7, while traveling on a business trip. He returned to find the scripts still running and zero successful dumps.
Around the same time, an organizer of an online AI event pressed Laurie to give a talk about AI in his work. Laurie’s response was that he had nothing to say — he wasn’t using AI in any meaningful way. The organizer offered a reframe: “You’re asking the wrong questions. Think of three questions that are really relevant to what you’re trying to do and ask AI.”
For chip glitching, those three questions are universal:
- Where to glitch — which physical location on the chip die to target with the probe
- When to glitch — how many nanoseconds or microseconds after a specific trigger event to fire the pulse
- How much to glitch — what voltage level to apply with the EM pulse
These are exactly the parameters that six weeks of brute-force scripting had failed to optimize. Asking an LLM those three specific questions — rather than asking AI to “help with hardware hacking” in the abstract — is what broke the logjam.
Actionable Takeaways
- Reframe AI queries from broad capability questions ("can AI help with hardware hacking?") to specific parameter questions ("where, when, and how hard should I glitch this chip?"). Specificity is what unlocks useful responses.
- When a brute-force approach is failing after extended iteration, treat it as a signal to look for better priors — AI can synthesize datasheet knowledge and bootloader analysis into targeted starting parameters, replacing days of blind search.
Common Pitfalls
- Dismissing AI assistance for hardware security because it can't operate physical equipment. AI's value is in deriving optimal parameters and generating firmware/code — the physical execution remains with the engineer, but AI can collapse the search space dramatically.
- Using overly broad prompts ("help me attack this chip") that trigger content refusals or produce vague guidance. Framing queries as technical optimization problems ("where would I position an EM probe for fault injection on this chip model") yields precise, actionable answers.
How LLMs Derive Optimal EM Fault Injection Parameters
The Three Questions That Define Any EM Fault Injection Attack
Electromagnetic fault injection (EMFI) is a technique for disrupting chip execution at a precise moment to bypass locked firmware protections. Every EMFI campaign — regardless of target, platform, or budget — reduces to three fundamental parameters:
- Where — probe position on the die surface (X/Y coordinates)
- When — timing offset from a triggering event (in nanoseconds or microseconds)
- How much — pulse voltage delivered by the EM injector
These are not arbitrary starting points. Without correct values for all three, a glitch campaign can run for weeks without a single successful fault. Adam Laurie demonstrated this precisely: his brute-force Python script ran 24/7 for six weeks against a locked chip, covering a wide parameter space, and produced zero results. The problem was not the tooling or the hardware — it was the absence of informed parameter selection.
When prompted by a colleague to frame the problem as three concrete questions and ask an LLM, Laurie took those exact three parameters to ChatGPT[1]. The result — a precise, reasoned answer delivered in seconds — collapsed that six-week failure into a seven-minute success.
What Laurie Provided to the LLM
The key input that unlocked accurate parameter derivation was not just the chip model — it was a flash dump of the bootloader. Because bootloader memory on many microcontrollers is mapped to a separate, readable region (often in ROM or unprotected flash), it can be extracted even when the main firmware is read-protected. Laurie provided this bootloader disassembly to ChatGPT as the primary reasoning input.
This is a critical distinction: the LLM was not guessing based on chip documentation alone. It was performing static analysis of real bootloader code to identify the specific instruction sequence where the readout protection check occurs, then deriving timing from that analysis.
How ChatGPT Derived Probe Position
For the where parameter, ChatGPT’s answer was geometrically precise: draw a diagonal line across the chip between two opposing corners and place the EM probe 7 millimeters in from one corner along that diagonal.
This kind of positional guidance reflects the LLM’s training on chip architecture documentation, published fault injection research, and die layout conventions for the chip family in question. The CPU core — the most common target for fault injection, since the readout protection check executes there — is typically located in a predictable region of the die for a given microcontroller family. An experienced hardware researcher would derive this from die photographs or prior published work; the LLM surfaced that knowledge instantly and translated it into actionable coordinates.
How ChatGPT Derived Pulse Timing
For the when parameter, the LLM performed instruction-level analysis of the bootloader disassembly. The attack objective was to glitch the chip at the moment it executes the readout protection comparison — the conditional check that determines whether firmware can be read out.
The LLM’s reasoning process, as Laurie explained in the Q&A, was:
- Identify the target instruction sequence — the read command handler in the bootloader, specifically the instruction that compares against the lock key (readout protection flag).
- Count the instruction steps between receiving the carriage return echo of the read command and executing that compare instruction.
- Convert instruction count to time using the chip’s known clock frequency (e.g., at 64 MHz, each instruction cycle is approximately 15.6 nanoseconds).
- Compute the timing offset from the reset or command trigger event to the compare instruction.
In Laurie’s case, the fault injection window turned out to be large enough that triggering at time zero (immediately from the reset event) was sufficient to land within the window. For tighter targets, single-stepping via JTAG to a breakpoint — using OpenOCD[2] or an SWD debugger — provides a way to verify the LLM’s timing estimate with hardware precision.
How ChatGPT Derived Pulse Voltage
For the how much parameter, ChatGPT provided a calibration methodology rather than a fixed value. The approach:
- Start at the maximum rated voltage of the EM pulse generator (500 V for the ChipShouter[3] used in this campaign).
- Run the glitch at that voltage and monitor the chip’s response.
- Reduce voltage progressively until the chip is crashing approximately 50% of the time.
- That 50% crash rate is the sweet spot — it indicates the glitch is disrupting normal execution but not reliably destroying state. At that voltage, useful faults (skipped instructions, wrong branch decisions) become likely.
- Lock in that voltage and begin the real campaign.
This calibration heuristic is well-established in the fault injection research community. Laurie applied the calibration, found his voltage threshold, started the run, made coffee, and returned to a complete firmware dump in seven minutes.
Why Bootloader Disassembly Is the Key Reasoning Input
The prompt phrasing Laurie used is worth noting. He did not say “attack this chip” — which triggers content refusals — but instead framed it as: “If I wanted to perform an EM pulse fault injection on this chip model, where would I put the probe, when would I send the pulse, and how hard should I hit it?” He also provided the bootloader dump as supporting context.
The bootloader disassembly enables the LLM to reason concretely rather than generically:
- Generic answer (chip model only): “Place the probe near the CPU core region, time the glitch to the readout protection check, use a moderate voltage.” — Usable in principle, imprecise in practice.
- Disassembly-informed answer (with bootloader): “Draw a diagonal, 7 mm from the corner, trigger at zero offset from reset, calibrate from 500 V down to 50% crash rate.” — Actionable immediately.
For engineers replicating this approach on other targets, the workflow is:
- Extract any readable memory region (ROM bootloader, public firmware, vendor-published binary)
- Disassemble it to identify the security check you want to fault
- Provide the disassembly to the LLM with the three questions
- Use the LLM’s output as a starting parameter set, not a guaranteed solution — it dramatically narrows the search space
The Non-Deterministic Nature of Fault Injection — and How Parameters Tame It
EMFI is inherently probabilistic. Even with correct parameters, the glitch may not land in the right clock cycle every attempt. Physical variation in the EM coupling, chip temperature, power supply noise, and exact probe position all affect outcomes. This is why Laurie’s original six-week campaign was not wrong in principle — it was wrong in parameter space. With LLM-derived parameters, the search space collapses from a multi-dimensional brute force across thousands of positions, timings, and voltages to a narrow, informed region where success probability per attempt is high enough to achieve results in minutes.
The seven-minute result was not luck. It was the consequence of starting in the right place.
Six Weeks to Seven Minutes: AI-Guided EM Fault Injection on a Locked Chip
Proof of Concept
-
Initial brute-force campaign (baseline): A Python glitch script was run continuously for six weeks, 24/7, against a locked chip mounted on an XY positioning platform using an EM pulse generator (ChipShouter). The target chip had read-out protection enabled, blocking direct firmware extraction. The script varied probe position, pulse timing, and voltage in an unguided sweep. After six weeks of non-deterministic hammering: zero successful glitches, zero firmware dumps.
-
Identifying the three key parameters: Recognizing that effective EM fault injection requires answers to three questions — (a) where to place the probe, (b) when to fire the pulse, and (c) how much voltage to apply — Laurie reformulated his approach as an AI query rather than a brute-force sweep.
-
Querying ChatGPT with deliberate phrasing: Laurie intentionally avoided the word “attacking” to prevent the LLM from refusing the query. He asked: “If I wanted to perform an EM pulse fault injection on [chip model], where would I put the probe, when would I send the pulse, and how hard should I hit it?” — providing the chip model as the primary context.
-
Probe placement via diagonal geometry: ChatGPT responded with a specific spatial instruction: draw a diagonal line between two corners of the chip die and position the probe 7 mm in from the corner along that diagonal. This targets the region of the die most likely to contain the memory read/lock comparison logic.
-
Timing derivation from bootloader disassembly: Laurie supplied ChatGPT with a flash dump of the bootloader. The LLM reverse-engineered the bootloader, identified the specific instruction sequence handling the memory read command — the point where the chip checks whether readout protection is set — and counted the clock cycles between the carriage-return echo of the read command and the lock-key comparison instruction. It then converted that cycle count to microseconds using the chip’s known operating frequency, producing a precise pulse timing target.
-
Voltage calibration procedure: For pulse strength, ChatGPT provided a methodical calibration process: (a) start at 500 V, the maximum rated output of the ChipShouter EM pulse generator; (b) fire pulses and monitor chip response; (c) reduce voltage incrementally until the chip crashes on approximately 50% of pulses — this “50% crash rate” threshold identifies the sweet spot where the pulse is strong enough to cause a fault but not so strong as to reliably hard-reset the chip every time.
-
Executing the calibrated attack: With probe position set to the AI-specified coordinate, pulse timing set to the LLM-derived microsecond offset, and voltage dialed to the calibrated 50%-crash level, Laurie launched the glitch script. He went downstairs, made a cup of coffee, came back — seven minutes later the firmware was dumped. The chip had yielded its protected contents on the first calibrated run, compared to six weeks of zero results from unguided brute-force sweeping.
-
Why it worked: The LLM’s ability to reason over the bootloader disassembly and map instruction sequences to clock-cycle timing windows transformed a probabilistic, exhaustive search problem into a targeted, near-deterministic strike. AI-assisted firmware extraction succeeded where weeks of scripted enumeration had failed because it applied semantic understanding of the code — identifying the exact compare instruction — rather than treating timing as an unknown variable to be swept.
Actionable Takeaways
- Before starting any EMFI campaign, extract any readable memory region from the target (bootloader ROM, vendor firmware, public binary) and disassemble it to locate the security check instruction. Provide this disassembly to an LLM with the three-question framework (where/when/how much) to get an informed starting parameter set — this transforms a weeks-long brute-force search into a targeted, high-probability campaign.
- Use the 50% crash rate calibration method to find optimal voltage for your EM pulse generator: start at maximum rated voltage and step down until approximately half of glitch attempts produce a crash. That threshold voltage maximizes useful fault probability without reliably destroying chip state — apply it as the fixed voltage for your main campaign.
- When the LLM's timing estimate needs verification, use JTAG single-stepping to walk to a breakpoint at the target instruction. This converts the LLM's cycle-count derivation into a hardware-confirmed timing offset and is especially important on targets with tighter fault injection windows where "trigger at zero" is not sufficient.
Common Pitfalls
- Asking the LLM for glitch parameters without providing a bootloader disassembly or firmware binary produces generic guidance that is too imprecise to be actionable. The LLM's instruction-counting and timing derivation depend on real code — without it, probe position and timing offset will be approximations that still require large-scale parameter sweeps to resolve.
- Using adversarial framing ("attack this chip", "bypass security") in LLM prompts triggers content refusals before the LLM can reason about the parameters. Frame queries as fault injection research questions (e.g., "if I wanted to perform EM fault injection on this chip for security research, where would I position the probe") to get substantive technical responses.
Building an AI-Designed Hardware Hacking Platform on Raspberry Pi Pico
From Advisor to Architect: Handing Claude the Lab
After the ChatGPT-assisted glitch success, Adam Laurie shifted the relationship with AI from “give me instructions I’ll follow” to “here is my lab — design the system yourself.” This is a fundamentally different mode of AI-assisted hardware hacking: instead of soliciting parameter recommendations and translating them into scripts manually, Laurie gave Claude[4] a complete inventory of available hardware and asked it to produce a unified, multi-function firmware.
The lab inventory passed to Claude included:
- A debugger with SWD and JTAG support
- A logic analyzer capable of sniffing UART, SPI, and I2C
- An FPGA-based glitch trigger (the EM pulse generator)
- Voltmeters, oscilloscopes, and a power supply
Each of these is a separate, expensive piece of equipment that normally must be individually procured, configured, and wired into a test circuit. Collectively, this stack represents well over $1,000 of hardware — and the physical complexity of the wiring (“spaghetti is your enemy in glitching,” Laurie notes) introduces timing uncertainty and reliability problems of its own.
What Claude Produced: A Unified Pico Firmware
Claude’s response was a complete Raspberry Pi Pico[5] firmware that consolidated every function of that lab stack into a single $7 microcontroller. The capabilities Claude implemented include:
- SWD/JTAG direct interface — communicates directly with target chips for debugging and firmware interaction
- UART/SPI/I2C sniffing — passively monitors protocol traffic from the target
- 5-nanosecond resolution glitch timing — precise enough for the sub-microsecond windows required by fault injection attacks
- Peripheral control — managing eight hardware UARTs from a board that nominally supports only two
That last point deserves particular attention, because it illustrates how AI-assisted design can surface non-obvious solutions.
The UART Multiplexing Solution
The Raspberry Pi Pico has two hardware UART peripherals. Laurie needed to communicate with up to eight devices. The obvious workaround — bit-banging software UARTs — sacrifices the timing precision that makes the Pico valuable for glitching. Asking Claude how to solve this produced a solution Laurie describes as “genius”:
Each hardware UART on the Pico supports four alternate pin configurations (pin muxing). Rather than running all UARTs simultaneously, Claude designed the firmware to dynamically flip pin configurations on demand — switching the active UART mapping to whichever device needs to communicate at that moment. Eight physical devices are wired in, and the firmware manages the multiplexing transparently.
The result: eight functional hardware UARTs from a two-UART microcontroller, with full hardware timing fidelity preserved throughout.
This kind of insight is exactly what makes AI code generation valuable for embedded systems work. The constraint is known (two UARTs), the solution exists in the datasheet (alternate pin mappings), but translating that constraint into a workable multiplexing architecture — and implementing it correctly in firmware — is the sort of problem that previously required either deep microcontroller expertise or significant time spent reading peripheral documentation.
Why the Pico and Why Disposable
Laurie’s rationale for choosing the Raspberry Pi Pico as the target platform is practical and replicable:
- Cost: At approximately $7, a Pico is roughly 1/150th the cost of the equipment it replaces.
- Disposability: In hardware hacking, physical integration with a target circuit often means soldering directly onto a test board. With expensive lab equipment, this is a commitment. With a $7 Pico, it is acceptable to solder the controller directly into the circuit and discard it afterward. “You can actually solder the Pico directly into a test circuit and it’s disposable. You don’t care if you burned a Pico.”
- Consolidation: Replacing five or six separate components with one board eliminates the wiring complexity that degrades glitch timing precision.
For engineers working on embedded system security or hardware security AI tools integration, this architecture means a self-contained attack platform that can be built, deployed, and discarded on a per-engagement basis — a significant shift from traditional lab configurations.
Raiden Pico: A Year of Work Rebuilt in Three Days
To illustrate the code generation speed advantage, Laurie offered a direct comparison. Raiden Pico is a hardware hacking framework he and a colleague wrote at IBM X-Force. The original implementation took two engineers working full-time for over a year to complete. Claude rewrote it in three days.
This is not simply a productivity anecdote. It suggests that the iteration cycle for embedded firmware — historically slow due to the expertise required, the tight hardware-software coupling, and the difficulty of testing — can be compressed dramatically when AI handles the implementation layer. The engineer’s role shifts from writing firmware to specifying requirements, validating outputs, and composing capabilities.
Portability and Extensibility
The Pico-based platform is not the ceiling. Laurie explicitly addressed its upper bounds: for targets running at gigahertz speeds where the Pico’s clock rate becomes a limiting factor, the same Claude-generated firmware can be ported to faster hardware — a Raspberry Pi 5, for instance. The prompt to Claude would be “port this code to [target platform],” and Laurie estimates the porting time at roughly an hour.
This establishes a general pattern for AI firmware extraction tooling: develop against an inexpensive, well-supported baseline (the Pico), validate the architecture, then use AI to port to higher-performance hardware when the target demands it — without rewriting the logic from scratch.
Claude Designs a Multi-Function Hardware Hacking Firmware for Raspberry Pi Pico
Proof of Concept
-
Define the lab inventory as a capability list: Laurie enumerated the discrete equipment in his home lab to Claude: an SWD/JTAG debugger, a logic analyzer (UART/SPI/I2C sniffing), an FPGA-based glitch trigger, a voltmeter, an oscilloscope, multiple UARTs, and a power supply. Rather than asking for advice, he framed the prompt as a delegation: “Here’s my lab — it’s yours now. Do your thing.”
- Claude produces a unified Raspberry Pi Pico firmware design: Claude responded with a complete firmware specification targeting the Raspberry Pi Pico microcontroller. The design mapped every discrete lab function onto the Pico’s hardware peripherals and programmable I/O (PIO) state machines:
- SWD/JTAG interface: Bit-banged via GPIO pins, enabling direct debug attach and single-step execution on target devices.
- Protocol sniffing: UART, SPI, and I2C capture using PIO state machines for non-blocking real-time capture.
- Glitch timing engine: 5-nanosecond resolution pulse timing, implemented via PIO to sidestep CPU interrupt latency.
- Peripheral control: Power supply switching and voltage monitoring integrated directly into the platform.
-
Claude invents an 8-UART multiplexing scheme to exceed hardware limits: Laurie needed to communicate with up to eight UART devices simultaneously, but the Raspberry Pi Pico has only two hardware UART peripherals. Claude identified that each of those two UARTs supports four alternate GPIO pin configurations (remappable via pad control registers). Claude’s solution: wire up to eight physical devices to the appropriate GPIO pins, then dynamically reconfigure the UART peripheral’s pin mapping at runtime when switching between devices. This gives the Pico the effective throughput of eight independent hardware UARTs while using only two hardware blocks.
-
AI code generation replaces year-long manual development: Laurie noted that the Raiden Pico — a prior hardware hacking framework he and a colleague wrote at IBM X-Force — took two engineers over a year to build. Claude rewrote it in three days. The AI-designed firmware for this Pico platform represents the same class of capability consolidation, with Claude handling the entire embedded systems architecture from GPIO assignment to protocol state machines.
- Result — a sub-$10 disposable hardware hacking platform: The final Raspberry Pi Pico firmware replaced all of the following discrete lab instruments:
- SWD/JTAG debugger
- Logic analyzer (multi-protocol)
- FPGA glitch trigger
- ChipShouter pulse controller interface
- Multi-UART interface hub
The Pico costs approximately $7. The equipment it replaces costs over $1,000. Because the Pico is so cheap, it can be soldered directly into a target’s test circuit and treated as disposable — eliminating the “spaghetti” wiring complexity that Laurie identifies as a major failure point in traditional glitching setups.
Actionable Takeaways
- Describe your full hardware lab inventory to Claude and request a consolidated firmware design for the Raspberry Pi Pico before purchasing additional equipment. List each function you need (SWD/JTAG, UART sniffing, glitch trigger, ADC) and ask for a single firmware that handles all of them — the cost-to-capability ratio is difficult to match with any other approach.
- When you hit microcontroller peripheral limits (e.g., only two hardware UARTs available), explicitly surface the constraint to Claude and ask for a solution that preserves hardware timing fidelity. Peripheral multiplexing via alternate pin configurations is one class of solution; Claude can identify and implement others that a datasheet search might not surface quickly.
- For fault injection engagements, consider designing for disposability from the start. Solder a Pico directly into the test circuit rather than wiring through expensive lab equipment. Physical integration removes cable-induced timing jitter and reduces the spaghetti wiring that degrades glitch precision — and at $7 per unit, the board is expendable.
Common Pitfalls
- Treating the Pico as a drop-in replacement for all lab equipment without validating timing fidelity for your specific target. The Pico's 5-nanosecond resolution glitch timing is sufficient for many embedded targets, but chips running at gigahertz clock speeds may require porting to faster hardware. Confirm the target's timing window before assuming the Pico's resolution is adequate.
- Failing to account for the spaghetti wiring problem when replicating this setup. A consolidated Pico firmware eliminates inter-component cabling, but if the Pico itself is wired to the target through a breadboard nest of jumpers, timing uncertainty returns. Soldering the Pico directly into the test circuit is the intended deployment model for precision-sensitive attacks.
Closed-Loop Voltage Control: AI-Invented Deterministic Glitching
The most technically significant breakthrough in Laurie’s talk wasn’t the initial seven-minute chip crack — it was what came next. Mid-conversation with a colleague while explaining a voltage-drop glitch technique, Laurie had an insight: instead of manually tuning timing parameters to hit a specific voltage threshold, why not use the Raspberry Pi Pico’s onboard ADC to measure the voltage directly and trigger the glitch when the right level was reached?
That observation alone was a useful improvement. But Claude went further — autonomously.
From Measurement to Active Closed-Loop Control
Laurie described the moment in the transcript: “Claude took it one step further… Claude said, well, an alternative approach would be instead of just measuring, we could use the ADC to actively control the timing. So we’re going to do the glitch. I’m not going to give it any parameters. It’s going to measure the voltage on the target and when we hit the right point, then bam, it’s going to do the glitch.”
This is the architectural distinction that matters to fault injection researchers:
- Open-loop glitching (traditional): You supply fixed timing parameters — nanoseconds from a trigger event, voltage level, pulse duration. The attack fires at the pre-set offset regardless of actual chip state. Because silicon behavior varies with temperature, supply voltage, and manufacturing variation, this is inherently probabilistic. You run it thousands or millions of times hoping to land in the right window.
- Closed-loop glitching (AI-invented): The Pico’s ADC continuously samples the target’s supply voltage in real time. No timing offset is pre-specified. The firmware waits for the voltage to reach the exact threshold where the glitch condition is met, then fires. The feedback loop replaces human-tuned parameters with measured physical reality.
The practical consequence was immediate and dramatic: “I connected up the ADC. It wrote the code. It ran it. I didn’t even run it. I just came back and I saw this string… it dumped it unlocked and dumped the data on the first try.”
One wire. First try. No timing parameters.
Why This Transforms Fault Injection Research
Traditional voltage glitching requires extensive calibration. Engineers spend hours — or weeks — sweeping timing offsets and power levels, often building custom tooling to automate the sweep. The problem is that every new target chip introduces a new parameter space to explore.
The closed-loop ADC approach collapses this problem in a fundamental way:
- Target-adaptive: The feedback loop adjusts to whatever voltage behavior the specific chip exhibits. Manufacturing variation, temperature drift, and board parasitics are accounted for automatically because the loop reacts to measured reality, not assumed timing.
- Parameter-free triggering: Engineers no longer need to characterize the exact offset from reset to the vulnerable instruction window — the Pico watches the voltage rail and fires when the condition is met.
- Reproducible across runs: Because the trigger is tied to a physical threshold rather than a fixed time offset, the glitch fires at the same point in the chip’s execution across repeated attempts. Non-deterministic becomes deterministic.
Laurie framed the goal explicitly: “I’m doing the opposite of what [the organizer] said we should all be aiming for. I’m trying to turn a nondeterministic process into a deterministic one.”
The Live Demo: What the Voltage Sweep Reveals
Laurie demonstrated this on stage with an STM32-class target (white board) and the Pico platform (green board). Using the R command in the Pico’s menu interface, the platform performed an automated voltage sweep to characterize the brownout window:
- The Pico progressively lowered the target’s supply voltage, recording at each level whether SRAM survived and whether the NRST reset pin triggered.
- The sweep produced a table showing a voltage window between 1.61V and 0.89V where a reset was triggered but flash contents were preserved.
- This window is where the glitch must land: low enough to cause a brownout reset, high enough that the payload code loaded into flash survives.
The ADC-based closed-loop controller targets this exact window — not by guessing, but by watching. When the measured voltage enters the window, the glitch fires.
The Two-Stage Attack Chain
The full exploit sequence the Pico executes autonomously illustrates how the closed-loop control integrates into a multi-step attack:
- Connect via SWD and load a payload into flash on the locked target.
- Trigger a brownout — drop voltage low enough to cause a reset, but not low enough to corrupt flash. The closed-loop ADC ensures the brownout stays in the safe voltage window.
- Payload survives the glitch. On reboot, the injected code is present.
- Stage two glitch: Reconfigure the memory mapper so the chip treats flash as SRAM.
- Boot off “SRAM” — which the chip now believes is flash — granting read access to the formerly locked flash contents.
- Dump memory.
The ADC feedback loop is what makes step 2 reliable. Without it, step 2 is a probabilistic shot in the dark. With it, the reset lands in the window on command.
What Claude Actually Did
It’s worth being precise about Claude’s role here. Laurie didn’t ask for closed-loop control. He had the measurement idea himself. Claude’s contribution was the autonomous extension from passive measurement to active feedback-driven triggering — proposed unprompted, mid-conversation, as a superior architectural alternative.
Claude then wrote the firmware implementing the closed-loop ADC control, integrated it with the existing Pico platform, and the system worked on the first attempt without Laurie executing a single command himself.
This is the pattern that makes AI-assisted exploitation useful in hardware research beyond just answering questions: identifying the better engineering approach when the human has articulated the problem, then executing the implementation without further hand-holding.
ADC Closed-Loop Glitch Control: Claude’s Autonomous Firmware Improvement
Proof of Concept
-
Context — the timing problem being solved: Laurie and a colleague were discussing the challenge of creating a precise voltage drop on a target chip at the right moment for fault injection. The conventional approach requires manually calibrating delay parameters (in nanoseconds or microseconds from a trigger event) to hit the brief window when the chip’s supply voltage is at the vulnerable level — an inherently trial-and-error, non-deterministic process.
-
Laurie’s mid-conversation insight: While chatting with his colleague, Laurie realized that the Raspberry Pi Pico platform already had an onboard ADC (analog-to-digital converter) — meaning instead of inferring voltage state from fixed delay timers, the firmware could directly measure the actual supply voltage on the target in real time. He posed this idea: use the ADC to measure when the voltage reaches the critical threshold, rather than approximating it with a timing offset.
- Claude’s autonomous extension — closed-loop active control: When Laurie brought this ADC idea into the conversation with Claude, Claude did not simply confirm the measurement approach. It went a step further and proposed an alternative architecture: use the ADC not just to observe the voltage, but to actively control the glitch trigger in a closed loop. In Claude’s proposed design, the Pico firmware would:
- Drive the target chip’s supply voltage downward (initiating the brownout/glitch sequence).
- Continuously sample the ADC to monitor the actual supply voltage in real time.
- Trigger the glitch pulse autonomously at the exact moment the measured voltage hits the predetermined vulnerable threshold — with no hardcoded timing parameters required from the operator.
- Stop the glitch and restore the supply voltage immediately after triggering.
-
Implementation — single wire, full autonomy: Claude instructed Laurie to connect one additional wire: the ADC input pin on the Pico to the target chip’s supply voltage rail. With that single hardware change, Claude wrote the updated embedded firmware incorporating the closed-loop control logic.
-
Outcome — firmware dumped on first attempt: On the very first run of the ADC-controlled glitch firmware against the locked test chip (a blank chip filled with the value
0xB00B1E5for demonstration purposes), the attack succeeded completely. The chip’s read-out protection was bypassed, and the full flash contents were dumped to the terminal. This result, achieved without any manual timing calibration or parameter tuning, validated Claude’s closed-loop design. -
Why this matters technically — non-deterministic to deterministic: Traditional electromagnetic fault injection and voltage glitching are inherently non-deterministic: the attacker picks timing parameters based on estimates, runs the attack thousands or millions of times, and hopes statistical variance eventually lands a glitch in the right window. By closing the loop with real-time ADC feedback, the Pico firmware eliminates the timing estimation problem entirely — it triggers when the condition is actually met, not when a timer estimates it might be.
-
Live demo validation at [un]prompted 2026: Laurie demonstrated the full attack live on stage. He used the official STM32 configuration tool to write
0xB00B1E5into flash memory on a target chip, then enabled read-out protection to lock it. With the official tool confirming the chip was locked and returning no data on a read attempt, he switched to the Pico-based hacking platform running the ADC closed-loop firmware (built on the stm-pico/picoprobe[6] framework). The Pico executed the two-stage glitch sequence: first a brownout to load a payload into flash without wiping SRAM, then a second glitch to reconfigure the memory mapper so the chip booted from flash (treated as SRAM), granting read access. The firmware dump completed successfully on stage. - Broader significance: Claude’s autonomous proposal — not prompted by Laurie, but generated by Claude mid-conversation as a superior architectural alternative — illustrates a qualitative shift in AI-assisted hardware hacking. The LLM did not just answer a direct question; it identified a suboptimal approach, proposed an improvement, designed the firmware to implement it, and produced a working exploit.
Actionable Takeaways
- Replace fixed-timing glitch parameters with ADC-based closed-loop voltage control on any microcontroller platform that exposes ADC pins. Measure the target's supply rail continuously and trigger the fault pulse when the measured voltage enters your target window — this eliminates the parameter sweep entirely and makes attacks reproducible across temperature and manufacturing variation.
- Before beginning a new fault injection engagement, perform an automated voltage sweep (as Laurie's Pico `R` command demonstrates) to characterize the exact voltage window where brownout resets occur without corrupting retained memory. This window is your glitch target, and knowing it precisely is prerequisite to closed-loop control.
- When using an LLM to improve an attack tool or technique, describe the physical constraint you're trying to solve (e.g., "I need to hit a specific voltage point but can't predict the exact timing offset") rather than asking for a solution. Models like Claude will often propose architecturally superior approaches — like feedback loops — that you wouldn't reach by asking for incremental fixes.
Common Pitfalls
- Treating fault injection as purely a timing problem leads engineers to spend weeks sweeping nanosecond offsets when the real variable is voltage state. If your target architecture performs a security check conditional on a voltage-sensitive register or memory read, the timing window correlates with a voltage condition — measure the voltage, don't guess the time.
- Running the closed-loop ADC at too low a sampling rate can cause the controller to miss the target voltage window, especially on targets with fast brownout transitions. Ensure the ADC polling loop runs fast enough to catch transients in the relevant voltage range — Laurie's Pico implementation operates at five-nanosecond resolution for glitch timing, which must be matched by sufficiently fast ADC reads to avoid triggering too late.
The Democratization of Hardware Security: Impact and Implications
From Nation-State to $7: How AI Rewrote the Hardware Hacking Access Equation
The most consequential moment in Adam Laurie’s talk at [un]prompted 2026 wasn’t the seven-minute chip crack. It was the moderator’s framing of what that crack actually means. Hardware security — specifically voltage glitching and electromagnetic fault injection — has historically occupied two narrow bands of the capability spectrum: expensive hobbyist pursuit and nation-state operation. What Laurie demonstrated is that both of those lanes have been permanently disrupted.
The moderator put it plainly: glitching has been a nation-state capability, or an expensive hobbyist’s role. SIM cards, credit cards, and hardened secure elements have been hardened over decades precisely because exploitation required resources that only well-funded labs could assemble. That calculus has now changed.
Three Layers of Disruption
The moderator identified three distinct ways this shift has altered the threat landscape:
Layer 1 — Access: The first disruption is purely economic. The equipment in Laurie’s original setup — debugger, logic analyzer, EM pulse generator, FPGA glitch trigger, power supply, scopes — represents over $1,000 of hardware. The Raspberry Pi Pico that Claude configured to replace all of it costs $7. More importantly, it is disposable — operators can solder a Pico directly into a target circuit without worrying about burning equipment worth hundreds of dollars. This changes who can participate in hardware exploitation research entirely.
Layer 2 — Iteration speed: The second disruption is the elimination of the expertise gradient. Laurie spent six weeks failing before a single LLM conversation redirected him to success. Claude rewrote Raiden Pico — a tool that took two experienced IBM X-Force engineers over a year to build — in three days. The time-cost of hardware hacking expertise has collapsed. The moderator’s framing here is instructive: this isn’t about frontier foundation model labs or PhD researchers. It is about power users who keep iterating, who say they don’t know something and then go find out, who move from one layer to the next. AI amplifies the people who already have curiosity and persistence; it removes the requirement for expensive apprenticeship.
Layer 3 — Depth: The third disruption is capability ceiling. AI-assisted hardware hacking doesn’t just replicate what skilled engineers could already do — it opens the next layer. Laurie himself noted that once glitching works, the question immediately becomes: can I do two glitches in a row? Can I manipulate the timing dynamically rather than setting it statically? Claude’s autonomous ADC closed-loop proposal is exactly this pattern: a capability improvement the human operator hadn’t thought to ask for. The moderator observed that Laurie kept “programming the next layer” — and that AI is the engine enabling that acceleration.
What This Means for Defenders and Policymakers
The moderator drew an explicit parallel to other AI-amplified attack surfaces: social engineering becoming psychological profiling, AI-assisted code exploitation, and now hardware exploitation. The common thread is that AI-assisted exploitation is removing the expertise prerequisite across every attack domain simultaneously.
For defenders and practitioners, the practical implications are concrete:
- Threat models for embedded hardware must be updated. Devices designed under the assumption that fault injection requires nation-state resources are now exposed to a much wider population of operators. Secure boot implementations, readout protection schemes, and firmware encryption strategies need to be evaluated against a lower-cost, AI-guided adversary model.
- Defensive tooling can use the same AI leverage. The same LLM-guided iteration that Laurie used to crack chips can be applied to building countermeasures — automated glitch detection firmware, ADC-based tamper monitoring, and rapid porting of defensive frameworks across microcontroller families.
- The community norm around hardware hacking training is shifting. The moderator specifically credited Laurie with making hardware hacking accessible and noted his groups and mentorship efforts. The combination of low-cost hardware platforms and AI-guided learning means the barrier to entry for legitimate hardware security research is also lower — not just for attackers.
The Broader Pattern
What Laurie’s work illustrates is a pattern that will repeat across every domain where expertise has historically been the limiting factor. The moderator’s closing point was not hyperbole: a $7 microcontroller, a free LLM session, and a few hours of iteration can now produce results that previously required a fully equipped lab and months of specialist work. This is not a future development. It is the current state of AI-assisted hardware hacking, and the security community’s threat models, training pipelines, and defensive investments need to catch up to it.
Actionable Takeaways
- Update embedded hardware threat models to account for AI-assisted fault injection: assume adversaries can derive probe placement, timing windows, and voltage parameters from publicly available datasheets and bootloader dumps using commercial LLMs, without specialist lab equipment beyond a $7 Pico.
- Evaluate all existing readout protection and secure boot implementations against a low-cost, AI-guided adversary scenario — specifically voltage brownout glitching and EM fault injection — rather than only against nation-state or well-resourced lab actors.
- Apply the same AI-iteration leverage defensively: use LLMs to rapidly port glitch detection and tamper-response firmware across microcontroller families, just as Laurie used Claude to port offensive tooling in hours rather than weeks.
Common Pitfalls
- Assuming hardware security threat models based on expensive lab equipment requirements remain valid: the $1,000+ toolchain barrier has been replaced by a $7 Pico and an LLM conversation, so any defensive design that relies on attacker resource constraints needs reassessment.
- Treating AI-assisted hardware exploitation as a future concern rather than a present capability: Laurie's live demo at the conference — locking a chip and then unlocking it with the Pico-based stm-pico attack in under two minutes — demonstrated that this is not theoretical. The framework is published and operational.
Conclusion
Adam Laurie’s talk at [un]prompted 2026 documents a genuine inflection point in hardware security. Three developments converge here, each significant on its own, but decisive together: LLMs can derive precise EMFI parameters from bootloader disassembly in seconds; AI can design complete, production-grade embedded firmware from a lab inventory description; and AI can autonomously propose and implement architectural improvements — like closed-loop ADC glitch control — that turn probabilistic attacks into deterministic ones.
The thread connecting all three is that AI removes the requirement for expensive, time-consuming expertise at exactly the stages where that expertise has historically been the bottleneck. Six weeks of failed brute-force became seven minutes. A year of two-engineer development became three days. An inherently non-deterministic attack technique became reproducible on first attempt.
For defenders, the practical mandate is clear: threat models that assume nation-state-level resources as a prerequisite for fault injection are outdated. The attack surface now includes anyone with $7, a free LLM session, and a bootloader dump. Security designs that depend on attacker resource constraints — rather than genuine cryptographic or architectural protections — need to be revisited now.
For hardware security researchers and practitioners, the tools are all available: the stm-pico/picoprobe framework is published, the Pico is $7, and the AI-assisted parameter derivation workflow described in this post is reproducible on your next target.
Explore related topics on The Cyber Archive: hardware security research, embedded system security techniques, and reverse engineering for security professionals.
References & Tools
- ChatGPT — Used to derive all three EM fault injection parameters (probe position, pulse timing, voltage calibration) from chip model and bootloader disassembly analysis. ↩
- OpenOCD — Open on-chip debugger supporting SWD/JTAG single-stepping for hardware-confirmed timing verification of LLM-derived instruction offsets. ↩
- ChipShouter — Voltage-controlled EM pulse generator (500 V max) used in Laurie's original six-week brute-force glitch campaign; replaced by Pico-based implementation. ↩
- Claude (Anthropic) — Used to design complete hardware hacking firmware for Raspberry Pi Pico, invent the UART-multiplexing workaround, and autonomously propose ADC-based closed-loop voltage control for deterministic glitching. ↩
- Raspberry Pi Pico — $7 microcontroller configured by Claude as a full hardware hacking platform with SWD/JTAG, UART sniffing, and 5-nanosecond glitch timing; replaces over $1,000 of lab equipment. ↩
- stm-pico / picoprobe — Open-source STM32 glitching framework for Raspberry Pi Pico that Laurie extended with non-deterministic-to-deterministic closed-loop control. Framework is published and available for community use. ↩
Questions from the audience
Related deep dives
Kinetic Risk: Securing and Governing Physical AI in the Wild | [un]prompted 2026
Shared-GPU Security Learnings from Fly.io
This Wasnt in the Job Description- Building a production-ready AWS environment from scratch
