Voltage Glitching the STM32F1 Read-Out Protection: A Step-by-Step Crowbar Attack

Hook & Context

The STM32F1 is everywhere. It powers industrial controllers, automotive CAN nodes, medical devices, IoT edge modules, and consumer electronics. When engineers protect firmware intellectual property on these devices, they reach for the STM32's Read-Out Protection — a hardware-enforced mechanism that, in theory, prevents anyone from reading flash memory contents over the debug interface. The keyword is in theory.

The uncomfortable truth is that RDP Level 1 on the STM32F1 is not a cryptographic lock — it is a permission check executed by silicon logic that runs in the same physical environment you control. Voltage glitching attacks exploit the physics of that environment. By momentarily starving the processor's power supply at precisely the right moment, you can corrupt the internal decision that enforces the protection, making the chip behave as though the protection flag was never set. The firmware, unencrypted and intact in flash, becomes fully readable. This is not a theoretical vulnerability — it has been demonstrated repeatedly in academic research and security audits on real production hardware, and it is the reason modern STM32 families introduced RDP Level 2.

This piece tears apart the attack from first principles: why the voltage fault works at a hardware level, how the STM32F1's protection architecture creates the attack surface, and how to build and tune a minimal crowbar glitch harness to exploit it. If you are auditing embedded firmware security, evaluating product hardening posture, or building defenses — this is the mental model you need.

TL;DR

Target: STM32F1 RDP Level 1 (Option Byte protection flag) Attack class: Voltage fault injection (crowbar glitch on VDD) What breaks: The flash memory controller's permission check during the debug read path Tools: MOSFET crowbar circuit or ChipWhisperer, OpenOCD, oscilloscope Outcome: Full firmware dump via SWD after successful glitch Fix: Use RDP Level 2 (irreversible) + external flash encryption; Level 1 alone is insufficient for secrets

Foundations & Theory

Why Voltage Glitching Works at All

A modern microcontroller executes instructions by transitioning millions of transistors between logic states every clock cycle. Those transistors have voltage thresholds — below a certain VDD level, the gate does not switch reliably. Fault injection attacks exploit the gap between "just barely working" and "working correctly."

When you create a short, controlled voltage dip on VDD — a glitch lasting tens to hundreds of nanoseconds — you do not crash the CPU. Instead, you cause one or a few instructions to execute incorrectly: a branch may not be taken, a comparison may resolve to the wrong value, a register write may not commit. This is the foundation of all crowbar voltage glitching: induce a precisely timed hardware fault that corrupts exactly the logic path you want to subvert.

The attack is probabilistic and parameter-sensitive. Most glitch attempts either do nothing (pulse too short or too weak) or crash the device (pulse too long or too deep). The researcher's job is to find the narrow parameter window — glitch width and glitch offset relative to a trigger — where the fault corrupts the target instruction without crashing the system.

The STM32F1 RDP Architecture

The STM32F1 stores its protection configuration in a dedicated Option Byte region starting at address 0x1FFFF800. The RDP status is encoded in byte RDP at offset 0: a value of 0xA5 means no protection (Level 0); any other value activates Level 1. This byte is read by the flash memory controller at startup and cached in the FLASH_OBR register (bit 1: RDPRT).

The protection mechanism works as follows:

The critical insight: This check is not cryptographic verification — it is a conditional branch in silicon logic that evaluates a cached register value. The register lives in the same VDD domain you can manipulate. If you can corrupt the evaluation of RDPRT during the check, the flash controller may grant access it should deny.

The STM32F1 does not implement any glitch detection circuitry. It has no voltage monitor that locks down the device on VDD anomaly. This distinguishes it from later STM32 families where brown-out detection is tied to security state.

Where It Fits in the Workflow

In a hardware security assessment, voltage glitching sits in the exploitation phase after reconnaissance has confirmed the target, identified the protection level, and ruled out software-only extraction paths.

The workflow in context:

You typically attempt simpler extraction first — checking for UART bootloader exposure, JTAG/SWD with no RDP, or firmware update files in OTA packages — before investing in physical fault injection. Glitching is a precision tool for when the software surface is hardened.

Key Concepts in Depth

1. The Crowbar Circuit: How a MOSFET Becomes a Weapon

A crowbar glitch works by momentarily shorting VDD to ground through a low-resistance path, creating a controlled voltage dip. The simplest implementation uses an N-channel MOSFET:

VDD ──────────────────┬───── Target VDD pin
                      │
                   [Decoupling
                    capacitor]
                      │
                   Drain
                   [NFET]   ← Gate driven by glitch controller (FPGA/MCU/ChipWhisperer)
                   Source
                      │
                     GND

When the gate is driven high, the MOSFET pulls VDD toward ground. The key parameters are:

• MOSFET selection: You need a device with very low R_DS(on) (< 50 mΩ) and fast switching (< 5 ns gate transition). The BSS138 or Si2302 work for initial experiments; the DMN3404 is a common choice for sharper edges.
• Decoupling capacitor placement: This is counterintuitive — you want to remove decoupling capacitors near the target VDD pin. They act as energy reservoirs that fight your glitch, smoothing it out. For glitching, a bare VDD line responds faster.
• Series resistance: A small resistor (10–33 Ω) between the drain and VDD prevents catastrophic current surges while still allowing a sharp dip. Too large and the glitch is too soft; too small and you may damage the device.

The ChipWhisperer hardware implements this in a more sophisticated form with a dedicated glitch output driver designed for this application, but the underlying principle is identical.

2. Trigger Timing: NRST Release as the Anchor

Timing is everything. The glitch must arrive when the flash controller is evaluating the RDP permission check — not during unrelated initialization, not during user code execution. The question is: what event do you synchronize to?

On the STM32F1, the most reliable trigger is the NRST deassertion event — the moment the reset pin is released and the CPU begins executing from the reset vector. The boot sequence proceeds as:

1. NRST released → CPU fetches stack pointer and reset handler from address 0x00000000
2. System initialization (clock setup, flash wait states, option byte load)
3. Option bytes processed → FLASH_OBR register populated → RDP check point
4. If RDP set, SWD debug access is locked

The attack window is somewhere between steps 2 and 3. The offset, measured from NRST release, is typically in the range of 5–50 µs for the STM32F103 at 8 MHz internal oscillator, but this varies with clock configuration and silicon revision.

Your glitch controller watches NRST, detects the rising edge, waits offset microseconds, then fires a pulse of width nanoseconds. Both parameters must be swept systematically.

# Conceptual parameter sweep pseudocode (ChipWhisperer API style)
for offset_us in range(5, 50, step=0.1):
    for width_ns in range(20, 200, step=5):
        scope.glitch.ext_offset = offset_us
        scope.glitch.width = width_ns
        
        reset_target()         # Assert NRST
        time.sleep(0.001)
        release_reset()        # Deassertion triggers glitch sequence
        time.sleep(0.1)        # Wait for boot
        
        result = probe_swd_access()   # Attempt flash read via OpenOCD
        
        if result == SUCCESS:
            log_parameters(offset_us, width_ns)
            dump_firmware()
            break
        elif result == CRASH:
            log_crash(offset_us, width_ns)
        else:
            log_no_effect(offset_us, width_ns)

This sweep may require thousands of attempts. A hit rate of 1-in-500 to 1-in-5000 is realistic. Automation is not optional — it is the methodology.

3. Confirming Success: SWD Interrogation Post-Glitch

After each glitch attempt, you need to quickly determine whether the bypass occurred before the device re-locks or resets. The check sequence via OpenOCD is:

# Attempt connection and read FLASH_OBR register
openocd -f interface/cmsis-dap.cfg -f target/stm32f1x.cfg \
        -c "init; halt; mdw 0x4002201C; exit"

The register at 0x4002201C is FLASH_OBR. If bit 1 (RDPRT) reads as 0 post-glitch, the protection check was bypassed in the running instance. You then immediately dump flash before any reset occurs:

openocd -f interface/cmsis-dap.cfg -f target/stm32f1x.cfg \
        -c "init; halt; dump_image firmware.bin 0x08000000 0x20000; exit"

Critical nuance: A successful glitch does not permanently remove RDP. The Option Byte in flash still holds the protection value. What you achieved is a transient bypass — the running CPU's permission check was faulted, but a hardware reset will re-lock the device. You must dump the firmware in the same power cycle as the glitch.

4. Parameter Space Topology and Why It Matters

Understanding the shape of the success space makes sweeping more efficient. The glitch parameter space has a characteristic structure:

Axes: Glitch Width (vertical) vs Glitch Offset (horizontal). The success region is a narrow band between no-effect and crash.

The success region is not uniformly distributed — it tends to form narrow diagonal bands. This is because both dimensions interact: a slightly wider pulse at a later offset may behave the same as a narrower pulse at an earlier offset. Experienced researchers start with a coarse grid sweep to locate the approximate success region, then refine with a fine-grained sweep in that neighborhood.

Temperature significantly affects the parameter window. Colder silicon requires different glitch parameters than warm silicon. If you're struggling to reproduce a hit, temperature variation is often the culprit. Some researchers deliberately cool targets (though this introduces condensation risk) to widen the success window.

5. Oscilloscope Validation: Seeing What You're Doing

Running blind is how you waste days. Before starting parameter sweeps, validate your physical setup with an oscilloscope:

• Probe VDD directly at the target's VDD pin (not at the supply)
• Trigger on NRST rising edge
• Verify that your glitch circuit produces a clean, sharp dip of the expected depth and duration
• Check for ringing or secondary oscillations — these can cause unintended additional glitches

A well-shaped glitch looks like a sharp rectangular dip: fast falling edge (< 10 ns), flat bottom at the desired depth (typically 0.5–1.5 V below nominal 3.3 V), fast recovery. A poor glitch looks like a rounded dip with a long tail — still capable of crashing the device but unlikely to produce a precise fault.

The oscilloscope is not optional equipment. It is how you close the feedback loop between what your software thinks is happening and what silicon is actually experiencing.

Alternatives & Comparison

Clock glitching is a viable alternative — inserting a glitch cycle into the external clock to cause a similar single-instruction fault. It requires that the STM32F1 be running from an external clock source (HSE), which is not always the case. Voltage glitching works regardless of clock source.

EM fault injection uses a small coil driven by a high-current pulse to induce localized current changes on the die surface. It does not require physical VDD access but requires spatial precision (an XY stage) and more expensive equipment. It shines on devices with inaccessible VDD lines or active power monitoring.

Decapping and microprobing is the nuclear option — chemically or mechanically remove the package, expose the die, and probe internal nodes directly. It provides definitive results but destroys the sample and requires lab-grade equipment.

For the STM32F1, the crowbar voltage glitch hits the best intersection of low cost, moderate complexity, and high success rate, which is why it remains the canonical demonstration for this chip family.

Further Reading & References

• "Shaping the Glitch" — Miloš Žúbor, Jakub Breier et al. (TCHES 2019) — rigorous analysis of glitch parameter spaces
• Colin O'Flynn's ChipWhisperer documentation — chipwhisperer.readthedocs.io
• "Breaking Code Read Protection on the NXP LPC-family Microcontrollers" — Obermaier & Tatschner (WOOT 2017)
• AN4701 — ST Application Note on RDP — vendor documentation on protection levels and limitations
• "Fault Injection Attacks on Cryptographic Devices" — Verbauwhede et al.
• Wallet.fail (35C3) — Trezor hardware wallet glitch attack

Practice these techniques only on hardware you own or are explicitly authorized to test.