Reading ESP32 Boot Output for Security Issues

BootIntel

The ESP32 family is one of the easiest device classes to security-audit from UART alone. Espressif's ROM bootloader is unusually chatty, and the second-stage bootloader spelled out by ESP-IDF is just as verbose. Between them, the first 50 lines of output usually contain enough to grade the device's security posture without ever opening a debugger. Here's the field guide.

Two bootloaders, two baud rates

Every ESP32 boots through a fixed sequence:

ROM bootloader in mask ROM. Emits at 74880 baud. Prints reset reason, chip revision, eFuse summary, then loads the second-stage bootloader from flash.
Second-stage bootloader from flash (the part ESP-IDF compiles for you). Usually switches to 115200 baud immediately. Prints ESP-IDF version, partition table, secure-boot/flash-encryption status, chosen application partition, then jumps to app_main.
Application. From here the format depends entirely on the firmware author.

If your terminal is at 115200 only, you miss the ROM banner. That's where chip revision and pre-second-stage eFuse state appear — both load-bearing for vulnerability scoping. Web Serial handles the rate switch cleanly; screen does not without manual reconnect.

The ROM banner — what each line means

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13260
ho 0 tail 12 room 4
load:0x40080400,len:3036
entry 0x40080638

rst:0xN is the reset reason. 0x1 is power-on, 0xC is brownout (often a power-supply problem, not a security issue), 0xE/0xF are watchdog resets (firmware crash recovery — worth investigating).
boot:0xN is the boot mode. 0x13 is the normal SPI flash boot. 0x3 is download mode — if you see this in a shipped device, the strap pins are wrong and the device boots into a flashable state on every power-on. Critical finding.
SPIWP:0xee is the SPI flash write-protect GPIO state. 0xee means default (none); custom values imply the vendor configured a write-protect pin worth investigating for hardware-level attack surface.
mode:DIO / DOUT / QIO is the SPI flash mode. QIO is fastest. Mode mismatch between bootloader and application is a common "works on bench, bricks on field" failure that can also indicate a downgrade attack.

Chip revision matters for CVEs

ESP32 chip silicon has shipped in several revisions. Some have known hardware vulnerabilities documented by Espressif and patched only in later revisions or by mitigated firmware. The ROM emits something like:

ets Jun  8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57   <- ROM date pins silicon revision
chip is ESP32-D0WDQ6 (revision 1)

Revision 1 on classic ESP32 has the well-known CVE-2019-15894 (cache-attack key recovery) — relevant if the device uses ESP32's flash encryption. Revision 3 fixes it. BootIntel pins the chip revision from the boot output and flags known silicon-level CVEs automatically.

The second-stage bootloader — the security disclosure layer

I (29) boot: ESP-IDF v5.1.2 2nd stage bootloader
I (29) boot: compile time Mar 12 2026 18:42:11
I (29) boot: chip revision: v3.0
I (32) boot.esp32: SPI Speed      : 40MHz
I (37) boot.esp32: SPI Mode       : DIO
I (41) boot.esp32: SPI Flash Size : 4MB
I (46) boot: Enabling RNG early entropy source...
I (51) boot: Partition Table:
I (55) boot: ## Label            Usage          Type ST Offset   Length
I (62) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (70) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (77) boot:  2 factory          factory app      00 00 00010000 00100000
I (85) boot:  3 ota_0            OTA app          00 10 00110000 00100000
I (93) boot:  4 ota_1            OTA app          00 11 00210000 00100000
I (100) boot: End of partition table
I (104) boot: Secure boot disabled.
I (109) boot: Flash encryption disabled.

Every line is a finding source:

ESP-IDF version. Matches against the ESP-IDF security advisory list. Versions before 4.4.7 / 5.0.6 / 5.1.4 carry unpatched issues depending on enabled features.
Factory partition still present. Shipping with the factory app intact means OTA rollback to a known build is possible — fine if the factory build is hardened, dangerous if it's the original engineering build with debug consoles enabled.
Secure boot disabled. The single largest finding on most shipping ESP32 devices. Without secure boot, any actor with flash access can replace the bootloader with a malicious one. ESP-IDF supports secure boot v2 (RSA-PSS); enabling it is one sdkconfig flag and one eFuse burn.
Flash encryption disabled. Without it, the flash chip is a plaintext dump of firmware + Wi-Fi credentials + any stored secrets. SPI flash readout is a $5 hardware operation.

JTAG and USB-Serial-JTAG state — easy to miss

On ESP32-S3 and -C3, the chip includes a USB-Serial-JTAG bridge accessible over the native USB port. By default it's enabled until an eFuse is blown. Boot output mentions it cryptically:

I (123) cpu_start: Pro cpu up.
I (124) cpu_start: Single core mode
I (125) cpu_start: Pro cpu start user code
I (138) usb_serial_jtag: Console output set to USB-Serial-JTAG.

If you see USB-Serial-JTAG in a shipping device, an attacker with a USB-C cable has bus-level debug access. The fix is eFuse DIS_USB_JTAG (S3) or DIS_USB_SERIAL_JTAG (C3) — irreversible. JTAG-on-shipping-firmware is a critical finding; BootIntel flags it automatically.

Wi-Fi credential leaks

ESP-IDF's default esp_wifi log level is INFO, which prints the SSID during connection. Some firmware also prints the PSK in plaintext at VERBOSE level. Look for:

I (3458) wifi:connecting to ssid "OfficeWiFi", channel 6, bssid 04:18:d6:...
D (3459) wifi:PSK "shared-key-here"

If your boot log shows the PSK in the clear, the device is logging secrets to anyone with serial access. Severity is "deploy a new build immediately."

What BootIntel detects on ESP32 boot logs

ESP-IDF version → ESP-IDF security advisory list
Chip revision → silicon-level CVEs (e.g., CVE-2019-15894)
Secure boot v1/v2 enabled, disabled, or not configured
Flash encryption enabled, disabled, partial
USB-Serial-JTAG state on S3/C3
Factory partition presence + OTA rollback exposure
Wi-Fi SSID + PSK leaks in boot output
RTC slow-clock / brownout reset patterns suggesting hardware tampering
Tasmota / ESPHome / ESP-NOW protocol hints in the application stage