## Summary Raelize reproduced their earlier electromagnetic (EM) fault-injection attack on Espressif's ESP32 - which bypasses Secure Boot and Flash Encryption - using a cheaper, more accessible **crowbar voltage glitch** delivered by a NewAE ChipWhisperer-Husky, as taught in their "Art of Fault Injection" (TAoFI) training. The attack does **not** break any cryptography: the signature check and flash encryption remain correct. Instead it abuses the implementation around them - the un-disable-able UART ROM bootloader, SRAM data retention across a warm watchdog reset, and precise glitch timing during boot - to hijack the CPU Program Counter and redirect execution to attacker code staged in SRAM, which then reads out unencrypted flash in Normal Mode. They first proved PC control by loading the marker value `0x41414141` (watching for the resulting illegal-instruction exception), then refined timing to reach a **34.2% success rate** (roughly one success every 3 attempts) in the best glitch region. The wider lesson for evaluators: "Secure Boot enabled" and "Flash Encryption enabled" do not end a physical-access assessment. Note on scope/fidelity: the original 2020 CVE-2020-13629 EM attack applied only to ESP32 silicon **revisions 0 and 1** (not rev 3.x / "V3"). The blog states this crowbar reproduction targets a custom TAoFI board, but does not explicitly restate which silicon revision it runs on - treat the rev-0/1 caveat as the safe assumption unless verified on hardware. ## Technique & setup **Target.** Espressif ESP32 SoC on Raelize's custom `TAoFI-Target` board, with Secure Boot and Flash Encryption enabled (plus other security features). The attack leverages the ESP32 ROM **UART bootloader**, which cannot be disabled; in Bootloader Mode an OTP bit (`DISABLE_DL_DECRYPT`) normally blocks reading decrypted flash, so the goal is to run that bootloader's functionality (or arbitrary code) in **Normal Mode** instead. **Rig.** ChipWhisperer-Husky injects the crowbar glitch (a fast MOSFET short-to-ground on VCC) into the ESP32's `VDD3P3_CPU` and `VDD3P3_RTC` domains. A **Raspberry Pi Pico** drives the FI state machine and produces the more complex triggering the Husky's built-in trigger could not (Raelize note the Husky's native triggering is "somewhat limited"). An Espressif **ESP-Prog** (FT2232H) handles UART comms; `esptool.py` (imported as a Python module) loads the SRAM payload via Download Mode. Notably they **under-volt** `VDD3P3_CPU`/`VDD3P3_RTC` below Espressif's recommended 3.3 V from a lab supply - they had "less luck" glitching at the nominal voltage. **Attack chain.** (1) Strap into Bootloader Mode; (2) use the UART bootloader to load an SRAM payload containing a watchdog-reset command plus a data section of 1,000 pointers; (3) switch to Normal Mode; (4) trigger the **warm watchdog reset** while keeping power applied, so SRAM contents are retained; (5) **inject the glitch while ROM code is copying the real bootloader from external flash** on top of the retained SRAM; (6) on success an attacker-controlled pointer lands in the CPU PC. **Trigger & timing search.** Flash activity (e.g. the SPI CS line) marks when ROM is copying the bootloader, defining the trigger. Glitches were swept across a **~161,000 ns window** from that moment. The identification campaign was ~8,000 experiments in ~3 h, glitch length 1,000– 5,000 ns, delay 0–161,000 ns. **Success detection.** During identification the payload's 1,000 pointers are all `0x41414141`; loading that into PC produces a distinctive `IllegalInstruction` exception (`epc1=0x41414141`) on the serial line - an unambiguous "glitch hit" signal. Results plotted with their `TAoFI-Analyzer`. For the real exploit, the pointer is changed to `0x40080000` and SRAM is staged with Xtensa **shellcode** that calls ROM `ets_printf` to dump flash bytes over serial (extensible to a full flash dump). **Observed reliability.** A first single success appeared ~73,000 ns after trigger; further exploration found two productive regions around **~71,800 ns and ~74,000 ns**. Tuning into the ~74,000 ns region drove the success rate to **34.2%** (~1 in 3). Raelize note some TAoFI students reached "very close to 100%" on their boards, so the rate is improvable. **Failure modes / honesty caveats.** Raelize state plainly they **do not know exactly what fault is induced** - they have hypotheses, not proof. They also stress real-world variability: identical scripts/tooling/target sometimes failed for some students, fixed only by **swapping target boards** - minor per-chip hardware variation, plus the error-prone "spaghetti" of wiring, materially affects success. Initial identification/exploitation with lab-grade tooling took **weeks**; only once the exploit existed could trainees reproduce it in **hours**. ## Relevance to our work ESP32 is one of the most widely deployed connected-embedded SoCs (Wi-Fi/BLE), and shows up in medical-adjacent and IoT designs, so this is directly relevant: it is a concrete, documented demonstration that **"Secure Boot + Flash Encryption enabled" is not a closed finding** when physical access is in scope. For our threat modeling it reinforces a checklist of implementation weaknesses to probe on any boot chain - un-disable-able ROM bootloaders, SRAM data retention across warm resets, ROM trust assumptions during flash copy, and per-rail under-voltage sensitivity - independent of the crypto's correctness. The takeaway that an EM attack reproduces as a **voltage** attack (and vice versa) also warns us not to assume an EM-only mitigation closes the FI surface. **Reproduce candidate:** yes - strong. This is among the best-documented reproduce targets in our corpus: a defined attack chain, published glitch parameters, open helper tooling (`TAoFI-Target`, `TAoFI-Analyzer`), and a quantified success rate. It is an excellent first real glitching project to build crowbar-FI muscle. **Rough cost/effort:** ChipWhisperer-Husky (~$1.5–2k class) + a Raspberry Pi Pico + ESP-Prog + a lab PSU + an ESP32 target/dev board. Bench effort is the real cost: expect **weeks** to stand up and characterize from scratch (Raelize's own figure), even though, with a known-good recipe and board, a session can land in **hours**. Budget for board-to-board variability - have several target chips on hand. Authorization: use only our own ESP32 boards in our own lab; this technique requires no third-party hardware to practice. ## Source post (verbatim) Paul Gédéon - 2026-06-05 07:42 UTC · [Raelize ESP32 crowbar glitch](https://www.linkedin.com/feed/update/urn:li:activity:7468567820340101120/) > Secure Boot and Flash Encryption are not magic force fields. > > Raelize’s ESP32 crowbar-glitch writeup shows the uncomfortable part of embedded security: the signature check can be correct, flash encryption can be enabled, and the chip can still be pushed into executing the wrong thing at exactly the wrong moment. > > The target was an ESP32 with Secure Boot and Flash Encryption enabled. The attack used a ChipWhisperer-Husky to inject a crowbar glitch into the ESP32 voltage domains during boot. > > The chain is clever: > > Boot into UART bootloader mode. > Load a payload into SRAM. > Trigger a watchdog reset while keeping power supplied, so SRAM contents are retained. > Return to normal boot mode. > Glitch the chip while ROM code is copying the bootloader from external flash. > Redirect execution to attacker-controlled code in SRAM. > Access unencrypted flash contents while the chip is running in normal mode. > > > The important detail: this does not “break” the cryptography. > > It attacks the implementation around it: reset behavior, SRAM retention, ROM assumptions, voltage domains, and the exact timing of the boot process. > > Raelize first proved control by loading 0x41414141 into the Program Counter and watching for the expected illegal-instruction exception. After timing refinement, they found useful glitch regions around 71.8 µs and 74 µs after the trigger, with one region reaching a 34.2% success rate. > > That is what makes the writeup worth reading. It is not “we glitched it and it worked.” It is a practical evaluation workflow: setup, payload, timing search, success classification, failure modes, and exploitation. > > For security evaluators, the lesson is simple: > > “Secure Boot enabled” and “Flash Encryption enabled” are not the end of the assessment. > > If physical access is in scope, the bench still gets a vote. > > Source: https://raelize.com/blog/espressif-systems-esp32-using-a-crowbar-glitch-to-bypass-encrypted-secure-boot/ > > #HardwareSecurity #EmbeddedSecurity #FaultInjection #ESP32 #SecureBoot #FlashEncryption #ChipWhisperer #IoTSecurity ## Key references - <https://raelize.com/blog/espressif-systems-esp32-using-a-crowbar-glitch-to-bypass-encrypted-secure-boot/>