Project 03 · live demo

SKL-OTA, live

Send updates to virtual ESP32s and try to break them. Your browser downloads the real signed firmware builds and runs the same signature and checksum checks a device does. Tampered or damaged updates get refused. Broken builds install and then undo themselves.

← All projects · SKL-OTA on GitHub

Devices
Rollout

Send an update

Every device starts on build 1. Pick an update to send.

Virtual ESP32

build 1
App slot A
App slot B
  1. Manifest
  2. Signature
  3. Download + SHA-256
  4. Self-test

Last update: none yet

Update server

this site, /static/ota-demo/

The manifest as the device received it

Nothing sent yet.

Network

What’s real here, and what’s acted out

Real

  • The release files are the actual firmware builds of the Demo sketch, signed with SKL-OTA’s release tool.
  • Your browser checks each manifest’s ECDSA P-256 signature over skl-ota|board|build|size|sha256 against the demo’s public key, the same message the ESP32 checks.
  • It downloads the compressed image, inflates it, and compares its SHA-256 with the signed one.
  • Tampering and damage are done to those real bytes before the checks run, so a refusal means the check actually failed.

Acted out

  • Running the firmware. A browser can’t execute ESP32 code, so the slots, restarts, self-tests and rollbacks are a simulation of what the ESP32 bootloader and SKL-OTA do. Each build behaves the way the real one does.
  • Timing. A real device stays up 1 minute and has 10 minutes to pass its self-test. Here it’s seconds.
  • The fleet. Your browser downloads each release once and gives every virtual device its own copy to check. The staged rollout is what an update server can do with SKL-OTA’s request headers.

Want to see it on real hardware? examples/Demo runs the same six updates on an ESP32 on your desk, with your PC as the server.