This curriculum's red thread: every feature is also an attack surface.
10.1 Locked-down JTAG and the voltage glitch
Every modern microcontroller has a debug interface — JTAG (5 wires) or SWD (2 wires on Cortex-M). With debug access, you can dump flash, set breakpoints, single-step. Vendors include fuses or lock bits that disable debug after manufacturing. But the lock check is just a flip-flop sampled by some logic during boot. A well-placed voltage glitch (drop Vcc for 50 ns at the right moment) can corrupt the lock-check logic, and the chip happily continues into debug-enabled state. Researchers have extracted firmware from "secure" STM32, NXP, and Espressif chips this way. Mitigations: redundant lock checks at multiple times in boot, code-signing of firmware, anti-glitch detectors that monitor voltage and clock and reset on anomaly.
10.2 UART bootloader code injection
Most microcontrollers have a built-in bootloader triggered by holding a pin (BOOT0, BOOT1, etc.) at reset. The bootloader speaks UART, USB, or another protocol and accepts a firmware-load command. Bootloaders have historically had exploitable bugs: integer overflows in the length parser, stack overflows in the protocol handler, missing authentication. Once exploited, attackers can dump flash, write arbitrary code, or pivot into the system. Famous example: the original ESP8266 bootloader had bugs that allowed firmware extraction and unauthorized writes. Mitigation: signed firmware, secure boot, locking the bootloader after first deployment.
10.3 Side-channel attacks on AES on Cortex-M
When a Cortex-M chip runs AES, its instantaneous power consumption depends on which key bits and which data bits it is XORing. Probe the power rail with a fast oscilloscope, take 1000 traces of encryption, do Differential Power Analysis (DPA), and you can recover the AES key in minutes. Demonstrated repeatedly against bare-metal AES implementations on STM32 and PIC. Mitigations: constant-time crypto, masked implementations (each key bit is split into shares), dedicated AES hardware accelerators (most modern Cortex-M include one), and PCB layout that adds noise to the power rail.
10.4 Cold-boot attacks and reset
When you reset a chip, what happens to the contents of its RAM? On 8086 and most older systems, RAM is not cleared at reset — the data persists for seconds (or milliseconds at high temperature, much longer at cryogenic temperatures). So an attacker can: power off, briefly, then power on into a different boot path that reads the RAM, recovering keys/passwords from the previous session. Cold-boot attacks were demonstrated on full disk encryption on PCs in 2008 (by Halderman et al.) and remain effective. Modern mitigations: clear RAM at boot before handing control to the OS, store keys in dedicated registers that are zeroed at reset, use TPMs.
10.5 Clock glitching and instruction skip
Inject a brief, faster clock pulse than the chip is designed for — say, a 2 ns spike on a chip running at 50 MHz (20 ns period). The CPU's flip-flops have timing margins; violate them and a flip-flop misses an edge, latching the wrong value. Result: an instruction is skipped or executed wrong. Aim this at the right instruction in a password-check loop and you can bypass the check. Used against smartcard PINs, against secure-boot signatures, against the lock-check in microcontrollers. Mitigations: PLL-based clock that filters spikes, redundant security checks, glitch-detect circuits.
10.6 Interrupt-timing leaks
When an interrupt fires, the time before the ISR runs depends on what instruction the CPU was on, what bus cycle, what cache state. Measuring this jitter can leak information. Old attacks against TLS/SSH key generation exploited interrupt-timing variations. Mitigation: deterministic interrupt latency (Cortex-M has 12-cycle worst-case interrupt latency by design, partly to address this), constant-time crypto.
10.7 The big picture
Every chip in this chapter sits inside a real product somewhere. Every locked feature is something an attacker wants to unlock. Voltage glitches, clock glitches, electromagnetic injection, optical (laser) injection, decapping and probing — all are tools in the hardware-security playbook. Knowing the architecture (where the lock register lives, when it is checked, what the boot path looks like) is the prerequisite for both attack and defense. Chapter 24 dives deeper into specific attacks; the skills you build reading 8086 and 8051 and Cortex-M datasheets are exactly the skills you need to attack or defend them.