Open-source ESP32 platform

One firmware. Any capability.

A modular ESP32 platform. The firmware ships nearly empty; you push capabilities as signed modules at runtime, encrypted by default. Home automation, a quick lab, a decentralized network, a red-team op. Same engine, different modules.

One firmware, any capability. The device ships with just a loader, a crypto core and a transport. Everything else, a sensor driver, a mesh node, a recon module, arrives as a signed module, relocated into IRAM at runtime, encrypted in transit, and wiped on unload. No reflashing. No plaintext. No monolith.

Architecture

Three independent repos, one chain of trust.

You drive everything from C3PO, a Python Qt6 operator server. It talks to the firmware over a ChaCha20-Poly1305 channel carrying protobuf messages. The firmware verifies and loads modules into IRAM, runs them under a per-module watchdog, and wipes them when they are done.

C3PO

Python operator server · Qt app
TCP
ChaCha20-Poly1305
protobuf

Firmware

ESP32 · loader + crypto + transport only
signed .ELF
relocated to IRAM

Modules

Loaded at runtime · zeroed on unload
Components

The three components

Each is its own repo, with its own job.

Firmware

v0.2.0 · Jun 13

The ESP32 target. Empty by design.

  • Ships with just a loader, crypto core and transport
  • Capabilities arrive as modules, relocated into IRAM
  • Encrypted transport, no plaintext on the wire
  • Built on ESP-IDF / FreeRTOS in C
  • GPRS connectivity for field deployments
  • Embeds ESPM as a synced component

ESPM

v0.2.0 · Jun 13

The module engine. A standalone ESP-IDF component.

  • 32-bit ELF relocator: Xtensa and RISC-V
  • HMAC-SHA256 signature check before any load
  • ~90-function syscall table, the only API a module sees
  • Per-module watchdog: freeze a module, it gets killed
  • Module-aware panic handler
  • NVS persistence for autoload at boot

C3PO

v0.2.0 · Jun 13

The operator server. Where you actually work.

  • Python Qt6 desktop app
  • ChaCha20-Poly1305 over TCP
  • protobuf-framed messaging
  • Signs and ships modules to devices
  • Per-device keystore, OTA trigger
  • Module compiler and injector
Use cases

Same engine, many jobs

It started as a red-team tool. The modular design turned out to be good at a lot more than offense.

Home automation

Drive sensors and actuators, one module per device, automate the boring stuff. Your hardware, your rules. No cloud account required.

Domotics

Lab in a box

Stand up a hardware test bench in minutes. Swap behaviours by loading a module instead of reflashing for every experiment.

Lab

Encrypted comms

Every link is ChaCha20-Poly1305 by default and modules are signed before they load.

Crypto

Decentralized networks

Build device networks that don't phone home to anyone's cloud. Nodes talk to each other.

Mesh

Field deployments

GPRS connectivity and over-the-air modules for nodes that live far from your bench.

Field

Offensive ops

Yes. Offensive modules too: Wi-Fi, recon, an encrypted C2. It's where the project started.

Red team
Companion tools

Built alongside the framework for embedded research.

Espilon Monitor

v0.1.0

Universal serial monitor for embedded devices.

  • Multi-port, color-coded, one terminal
  • Pattern files: ESP32, STM32, Arduino, FreeRTOS, Zephyr
  • Python hooks on match (ntfy, Slack, Discord, SQLite)
  • CI-ready: --wait-for / --timeout
  • Daemon mode + JSON event stream
  • No runtime deps, libserialport vendored

SimSift

Portable forensic tool for SIM cards and cellular data.

  • Runs on ESP32, no laptop required
  • Reads IMSI, ICCID, phonebook, SMS metadata
  • Detects downgrade attacks and suspicious re-routes
  • Passive scan mode for field ops