>
curriculum/Embedded Systems
section 10 of 184 min read

10. Bootloaders and Field Updates

A device that cannot be updated is a device that cannot be fixed. Field updates are not a "nice-to-have," they are how you ship safe products in 2026.

10.1 What a bootloader is

The bootloader is the first code that runs after reset. Its job is to:

  1. Set up minimal hardware (clock, RAM).
  2. Decide which application to run (which slot, which version).
  3. Verify that application's integrity (CRC, signature).
  4. Optionally wait for an update over USB/UART/BLE/Wi-Fi.
  5. Jump to the application.

A typical Cortex-M boot chain:

rendering diagram...

10.2 Single-bank vs dual-bank

Single-bank. Erase application, write new one, jump. Simple. Risky: if power fails mid-write, the device is bricked.

Dual-bank (A/B). Two equal slots. Run from A; download into B; verify; switch the active flag; reset; bootloader runs B. If B fails self-test on first run, fall back to A. This is the gold standard for fault-tolerant updates. Tesla, smart speakers, smart locks, and most modern IoT devices use it.

plaintext
+------+---------+---------+
| Boot | Slot A  | Slot B  |
| 32 KB| 480 KB  | 480 KB  |
+------+---------+---------+

10.3 Update protocols

  • USB DFU. USB-IF standard class for device firmware update. Plug into a PC, run dfu-util, flash. Common on STM32, Nordic, Raspberry Pi Pico (RP2040 has UF2 mass-storage variant).
  • Serial bootloader. UART-based "load Intel-hex over /dev/ttyUSB0." Used on AVR (avrdude), MSP430 (BSL), most legacy MCUs.
  • OTA over BLE. Nordic SoftDevice DFU: pair, push image in chunks, reboot. Used in fitness trackers, smart locks.
  • OTA over Wi-Fi. ESP-IDF has built-in OTA, dual-bank, signed. Particle, Tuya, Espressif, Microsoft Azure DPS all build on this.
  • OTA over cellular. LWM2M, FOTA via carrier. Used in fleet trackers, smart meters.
  • A/B with delta. Send only the diff to save bandwidth. zlib, bsdiff, jojodiff variants.

10.4 Secure boot chain

rendering diagram...

Each stage verifies the next using a public key. The root of trust is a public-key hash burned into eFuses or a secure element at manufacturing. Even if attackers replace flash contents, the chain refuses to run them because the signature does not match.

Anti-rollback counter prevents downgrading to an older signed-but-vulnerable version. Stored in monotonic counter / fuses.

10.5 Bootloader exploits, real ones

  • TI MSP430 BSL bypass. The factory bootloader was protected by a 16-byte password stored in flash 0xFFE0-0xFFFF, the same region as the interrupt vector table. Attackers shorted certain pins during reset and exploited timing leakage to brute-force the password byte-by-byte.
  • ESP32 secure boot bypass via fault injection. Researchers (LimitedResults 2019, raelize 2020) used voltage glitching at the right moment during signature check to skip the verification branch and run unsigned firmware. ESP32 v3 hardware patched the check; older v1/v2 chips remain vulnerable.
  • NXP LPC FlashMagic recovery. A debug pin held during reset enters ISP mode, allowing flash reflash even on locked chips. Fix: blow the IRC fuse.
  • Nordic nRF52 APPROTECT bypass. Using a single voltage glitch during boot, researchers reset the read-protection flag and dumped firmware over SWD. Nordic added "secure" approtect in later silicon revisions.
  • STM32 RDP1 to RDP0 downgrade. Setting RDP from level 1 to 0 erases flash, unless you can glitch around the erase step. Several public glitches achieved this.

The pattern is consistent: bootloader code paths are short and security-critical, attackers have unlimited tries, and a single misplaced fault produces total compromise. Hardening involves redundant checks, randomized timings, glitch detection, and pulling debug interfaces low or fusing them off.

10.6 OTA security

Unsigned OTA = remote firmware compromise. Mandatory mitigations:

  • Signed images. Manifest with image hash + ECDSA signature. Bootloader verifies before booting.
  • Encrypted images (optional). Prevents reverse engineering of the bits in transit.
  • Anti-rollback. Monotonic counter, refuses older signed versions.
  • Authenticated channel. TLS/DTLS, certificate-pinned. Otherwise the update server can be spoofed.
  • Hardware root of trust. Public key in eFuses or secure element, not in updateable flash.
  • Fail-safe fallback. If new image fails to boot N times, revert to previous slot.

When all of those are present, you have meaningful defense. Skip any, and you are running on hope.