leHACK 2025
Comment Espilon est né
Notre talk à leHACK 2025, où le projet a été présenté pour la première fois.
Un firmware, n'importe quelle capacité. L'appareil n'embarque qu'un loader, un cœur crypto et un transport. Tout le reste, un driver de capteur, un nœud de réseau, un module de recon, arrive en module signé, relocalisé en IRAM à l'exécution, chiffré en transit, et effacé au déchargement. Pas de reflash. Pas de clair. Pas de monolithe.
Architecture
Trois repos indépendants, une seule chaîne de confiance.
Tu pilotes tout depuis C3PO, un serveur Python Qt6. Il parle au firmware via un canal ChaCha20-Poly1305 transportant des messages protobuf. Le firmware vérifie et charge les modules en IRAM, les exécute sous un watchdog par module, et les efface une fois terminés.
Depuis C3PO, tu ouvres une session chiffrée vers un appareil, tu pousses un module signé, et il tourne sous son propre watchdog. Charger un capteur de température ou un nœud mesh, c'est exactement le même flux que charger n'importe quoi d'autre. Le firmware n'a jamais eu besoin de le savoir à l'avance.
Les trois composants
Chacun son repo, chacun son rôle.
Firmware v0.2.0 · bientôt
La cible ESP32. Vide par conception.
- N'embarque qu'un loader, un cœur crypto et un transport
- Les capacités arrivent en modules, relocalisés en IRAM
- Transport chiffré, jamais de clair sur le fil
- Construit sur ESP-IDF / FreeRTOS, en C
- Connectivité GPRS pour les déploiements terrain
- Embarque ESPM comme composant synchronisé
ESPM v0.2.0 · bientôt
Le moteur de modules. Un composant ESP-IDF, autonome.
- Relocateur ELF 32 bits : Xtensa et RISC-V
- Vérification de signature
HMAC-SHA256avant tout chargement - Table syscall d'environ 90 fonctions, la seule API que voit un module
- Watchdog par module : un module qui se fige est tué
- Gestionnaire de panic conscient des modules
- Persistance NVS pour l'autoload au démarrage
C3PO v0.2.0 · bientôt
Le serveur opérateur. Là où tu bosses vraiment.
- Application de bureau Python Qt6
- ChaCha20-Poly1305 sur TCP
- Messages encadrés en protobuf
- Signe et envoie les modules vers les appareils
- Keystore par appareil, déclencheur OTA
- Compilateur et injecteur de modules
Même moteur, plein de métiers
Ça a commencé comme un outil de red team. Le design modulaire s'est révélé bon à bien plus que l'offensif.
Domotique
Pilote capteurs et actionneurs, un module par appareil, automatise les corvées. Ton hardware, tes règles. Sans compte cloud obligatoire.
Labo en kit
Monte un banc de test hardware en quelques minutes. Change de comportement en chargeant un module, sans reflasher à chaque essai.
Comms chiffrées
Chaque lien est en ChaCha20-Poly1305 par défaut et les modules sont signés avant de s'exécuter. Jamais de clair sur le fil.
Réseaux décentralisés
Construis des réseaux d'appareils qui ne dépendent du cloud de personne. Les nœuds se parlent entre eux ; la topologie, c'est toi qui la dessines.
Déploiement terrain
Connectivité GPRS et modules over-the-air pour des nœuds loin de ton bureau. Pose-les et mets-les à jour à distance.
Offensif
Oui. Des modules offensifs aussi : Wi-Fi, recon, un C2 chiffré. C'est par là que le projet a commencé. Aujourd'hui c'est une capacité parmi d'autres.
Outils complémentaires
Construits en parallèle du framework pour la recherche embarquée.
Espilon Monitor v0.1.0
Moniteur série universel pour appareils embarqués.
- Multi-port, sortie colorée, un seul terminal
- Pattern files : ESP32, STM32, Arduino, FreeRTOS, Zephyr
- Hooks Python sur correspondance (ntfy, Slack, Discord, SQLite)
- Prêt pour la CI : --wait-for / --timeout
- Mode daemon + flux d'événements JSON
- Aucune dépendance à l'exécution, libserialport intégré
SimSift
Outil forensique portable pour cartes SIM et données cellulaires.
- Tourne sur ESP32, sans PC
- Lit l'IMSI, l'ICCID, le répertoire et les métadonnées SMS
- Détecte les attaques par downgrade et les redirections suspectes
- Mode scan passif pour les opérations terrain
Par où commencer
Documentation, code source et communauté. Tout ce qu'il faut pour builder avec le framework.