Firmware et objets connectés : la rétro-ingénierie par agents

Le 20 octobre 2026, 404 Media a décrit une vague de bricolage logiciel d'un genre nouveau : en un week-end, des particuliers ont remplacé le système de leur TV connectée par du code écrit avec des agents ou issu de la rétro-ingénierie, pour retirer publicités et logiciels imposés ; d'autres ont ressuscité des objets connectés devenus inutilisables ou retiré les pubs d'un babyphone¹. REA, le serveur MCP de rétro-ingénierie devenu viral début octobre, a concentré l'attention. Rien n'indique pourtant que les projets TV reposent sur lui. Sur un firmware, REA fait un travail plus modeste, qui sert surtout une équipe sécurité.

Ce que REA fait sur un firmware

REA ne réimplémente aucun extracteur. Il pilote deux outils existants : Binwalk 3.1.x pour inspecter les régions d'une image, Unblob 26.6.x pour l'extraction explicite, fournis par l'utilisateur. Sa documentation précise que ce premier jalon firmware est vérifié sous Linux x64 et qu'il n'exige ni appareil, ni droits root, ni montage, ni émulation, ni exécution des programmes extraits². REA rend les régions, les résultats d'extraction et des passages de relais vers l'analyse native : un ELF trouvé dans le système de fichiers extrait se sélectionne ensuite séparément pour une analyse par Ghidra³. L'extraction garde le bac à sable Landlock d'Unblob activé, et REA ne relance jamais avec --no-sandbox en cas d'échec².

L'agent obtient une carte de l'image (chargeur, noyau, systèmes de fichiers), puis la liste des fichiers extraits, puis le pseudocode des binaires qu'on lui demande de suivre. Un extracteur manquant pour un format donné apparaît dans le rapport avec son nom, et les résultats partiels restent disponibles². Le travail d'interprétation reste celui de l'analyste.

Deux usages sains pour une entreprise

Le premier est défensif. Avant de brancher une caméra, une borne, un automate ou un boîtier réseau sur le réseau de l'entreprise, une équipe peut extraire son firmware et chercher les identifiants codés en dur, les clés privées embarquées, les services ouverts par défaut, les domaines contactés et les bibliothèques obsolètes. C'est la même démarche que pour un binaire fournisseur livré sans code source, appliquée au matériel. Le Cyber Resilience Act couvre d'ailleurs les produits matériels comportant des éléments numériques : ses obligations de signalement s'appliquent aux fabricants depuis le 11 septembre 2026 (voir CRA et SBOM).

Le second relève de la continuité. Un équipement dont le fabricant a cessé le support, ou disparu, continue de tourner dans un atelier ou un bâtiment. Comprendre son firmware permet de documenter son comportement, de l'isoler correctement, ou de préparer son remplacement. Le DISCLAIMER de REA cite la préservation logicielle parmi les usages légitimes⁴. La logique rejoint celle du logiciel métier orphelin, traitée dans éditeur disparu, code source perdu.

Les risques réels

Le premier risque tient au code réécrit. Mike Nolan, qui étudie la politique de l'open source, a confié à 404 Media qu'il est devenu « so easy to recreate the functionality that you want », tout en rappelant que maintenir un logiciel demande un travail considérable¹. Un firmware régénéré par un agent peut contenir des défauts que son auteur ne sait pas diagnostiquer. Sur un objet physique, un bug se traduit par une surchauffe, une porte qui reste ouverte ou une alarme muette. Une entreprise n'installe pas un firmware réécrit sans tests, sans revue et sans plan de retour arrière.

Le second risque tient à l'analyse elle-même. L'extraction statique décrite plus haut ne lance rien. L'étape suivante (émulation, flashage d'un appareil, interaction avec un équipement connecté) change de nature : le DISCLAIMER de REA rappelle que ces opérations peuvent modifier l'état d'un appareil et que l'autorisation d'inspecter un fichier ne vaut pas autorisation d'intervenir sur l'appareil ou sur le système d'un tiers⁴. REA n'est pas un bac à sable : confinez l'analyse, comme expliqué dans REA n'est pas un sandbox.

Le cadre

Démonter un produit acheté pour comprendre son fonctionnement est un mode d'obtention licite d'un secret d'affaires au sens de la directive (UE) 2016/943, sauf engagement contractuel valide contraire ; le principe figure à l'article L151-3 du Code de commerce⁵. Le droit d'auteur sur le logiciel embarqué, les clauses de licence, les mesures techniques de protection et les conditions d'utilisation des services en ligne de l'objet restent des questions distinctes. Le panorama est dans clean-room ou reverse engineering.

Questions fréquentes

REA extrait-il un firmware ?

Oui, en pilotant Binwalk et Unblob sous Linux, sans exécuter le firmware ni brancher d'appareil. Les binaires extraits passent ensuite à Ghidra.

Les projets de TV « libérées » utilisent-ils REA ?

Rien ne l'établit. Let's Data Science, qui rapporte l'article de 404 Media, décrit des projets menés avec des agents de code et ne dit pas que REA a servi pour les téléviseurs.

Un firmware réécrit par IA est-il fiable ?

Pas sans tests. Les défauts y ont des conséquences physiques, et la maintenance demande des compétences que la génération ne donne pas.

Peut-on auditer un objet avant achat ?

C'est une bonne pratique avant tout déploiement en nombre, sur un exemplaire de test et avec le firmware publié par le fabricant quand il l'est. Un point d'attention à faire valider par votre juriste : sur un exemplaire d'évaluation ou un firmware téléchargé, vérifiez que vous êtes bien utilisateur légitime et ce que permettent les conditions du fabricant.

L'offre AI Cyber de SFEIR analyse en boîte blanche le code source dont vous disposez et, pour les équipements tiers que vous déployez, leur comportement observable, en environnement confiné.

Sources

1. 404 Media, 'Reverse-Engineer Anything' Is the New Wild West of AI, 20 octobre 2026, rapporté par Let's Data Science, AI Reverse-Engineering Wave Hits TVs, IoT Devices and Desktop Apps — letsdatascience.com.
2. morluto/rea, docs/firmware-analysis.md — github.com, consulté le 21 octobre 2026.
3. morluto/rea, README, section « What you can analyze » — github.com, consulté le 21 octobre 2026.
4. morluto/rea, DISCLAIMER.md — github.com, consulté le 21 octobre 2026.
5. Directive (UE) 2016/943 sur la protection des secrets d'affaires, article 3 — eur-lex.europa.eu ; Code de commerce, article L151-3 — legifrance.gouv.fr.