OTA Update
Shipping new firmware to a deployed device over the network. The mechanism that keeps a fleet patchable is also the most direct path to running your own code on every unit.
OTA update is the delivery of new firmware to a device already in the field, over whatever network it has. It is the only realistic way to fix a bug in a fleet of a hundred thousand units, and it is simultaneously the most valuable target on the device: whoever controls the update channel controls the firmware, permanently, on every unit that listens.
How it normally works
1. Check device asks a server "is there a newer version?"
2. Manifest server answers with version, download URL, size, hash, signature
3. Download device fetches the image, usually into a spare partition
4. Verify hash and signature checked before anything is trusted
5. Apply mark the new slot bootable, reboot into it
6. Confirm new firmware proves it works, or the bootloader rolls back
Most modern designs use A/B partitions: two full firmware slots plus a small state area recording which is active and which is being trialled. The running image writes the update into the inactive slot, so a failed download or a power cut halfway through leaves the working image untouched. After reboot the new image must actively confirm itself; if it crashes or never confirms, the bootloader falls back. ESP-IDF calls the state esp_ota_mark_app_valid_cancel_rollback; other stacks use the same idea under different names.
What has to be true for it to be safe
Every one of these is a step that gets skipped in the field:
- The image is signed, and the signature is checked before use. Not a checksum. A CRC or SHA-256 alone proves the download was not corrupted, not that the vendor produced it.
- The verification happens before the image is trusted, not after it boots. Verifying in the new firmware itself is circular.
- The transport is authenticated. Plain HTTP for the manifest or the image means any network position rewrites both. TLS with proper certificate validation, and ideally pinning, closes it.
- Downgrade is refused. Serving a genuine, correctly signed, but old and vulnerable image is a valid attack. Rollback protection compares a monotonic version counter (often burned into fuses) and refuses to go backwards.
- The manifest itself is signed. A signed image behind an unsigned manifest still lets an attacker choose which signed image you get, which is the downgrade attack again.
How it gets broken
- Plain HTTP. Still extremely common on consumer IoT. A machine in the path substitutes the manifest, points the URL at its own server, and the device installs anything.
- Signature checked but the key is on the device. A symmetric MAC or a shared secret means the "verification" key can be extracted from any single unit and used to sign firmware for the whole fleet. Signing must be asymmetric: only the public key belongs on the device.
- Verification that can be skipped. A single conditional branch in the bootloader, patchable if flash is writable and the boot chain is not itself verified.
- No downgrade protection. The easiest and quietest attack, because every artifact involved is genuine.
- Hash checked, signature not. The hash comes from the manifest, and the manifest came over the same channel as the image.
On ESP32 specifically
esptool writes images, the partition table declares the OTA slots plus the otadata state partition, and secure boot signs the bootloader and application so an unsigned image will not run at all. Flash encryption is orthogonal: it protects confidentiality at rest and does not by itself authenticate an update.
Pitfalls
- An update path that works is a liability; an update path that does not work is a bigger one. Devices with no OTA at all are the ones still running the 2016 firmware.
- Rollback protection and field recovery are in tension. Burning a version counter into fuses is irreversible, and a bad release can permanently strand a fleet.
- Testing the update mechanism only on the happy path. Power loss mid-write, a truncated download and a corrupted slot are the cases that decide whether you brick devices.
What it pairs with
secure-boot establishes the trust the update chain relies on, tls protects the transport, and firmware covers what is actually being shipped.
Further reading
Used in these courses
**Advanced.** Hijack the update channel: map the OTA flow, MITM a channel with no TLS or pinning, exploit missing or weak firmware signing, and push a malicious image fleet-wide - the attack that correct Secure Boot stops.
ESP32 Secure Boot & Flash Encryption Hardening**Intermediate** course (recommended pre-requisite: the offensive twins `esptool-basics` + `esp32-efuse-summary`). You take over a stock ESP32 product, threat-model it, burn the right eFuses in the right order, enable Secure Boot v2 + Flash Encryption + NVS Encryption, lock down JTAG and UART download mode, then prove your hardening survives the offensive playbook in the final lab. 10 lessons + 1 lab. **One defensive course that breaks three offensive chains at once.**