An attacker has physical access to an ESP32-based device. What can they do through its USB serial port, and what protects against it?
Read the whole flash (firmware, Wi-Fi credentials, server addresses, keys) and write their own firmware. Flash encryption makes the dump unreadable, and secure boot makes the chip refuse unsigned firmware.
The same tool that flashes a board also reads it. esptool read-flash 0 0x400000 dump.bin copies the whole flash of a typical 4 MB module to a file. Without protection that dump contains:
- the application, which can be disassembled or simply searched with
stringsfor URLs, server addresses and commands; - the NVS area, where ESP-IDF stores settings, including the Wi-Fi SSID and password by default;
- any keys or certificates the firmware uses to authenticate itself.
Writing works just as easily, so the attacker can replace the firmware with their own, for example one that keeps the device's identity but sends whatever commands they like.
| Protection | Effect |
|---|---|
| Flash encryption | The flash contents are encrypted with a key held inside the chip (in eFuses). A dump shows only ciphertext |
| Secure boot | The bootloader verifies the app's signature before running it. Unsigned or modified firmware does not start |
| Disabling the serial download mode and JTAG (via eFuses) | Removes the easy ways in |
These are one-way settings: once the eFuses are burned they cannot be undone, which is why production devices enable them and development boards do not.
Go deeper:
ESP-IDF — Flash encryption — what is encrypted, development vs release mode.- ESP-IDF — Secure Boot v2 — signature verification of the bootloader and app.