REA Investigated: Comment fonctionne l’ingénierie inverse assistée par l’IA

Qu’est-ce que REA—et pourquoi les gens y prêtent attention ?

Vous pouvez utiliser une application tous les jours sans savoir comment ses fonctionnalités fonctionnent en arrière-plan. REA donne aux assistants IA un moyen d’enquêter sur ce comportement—même lorsque le code source d’origine n’est pas disponible.

REA (Reverse Engineer Anything) est le projet open-source sur morluto/rea qui connecte les agents IA aux workflows d’analyse de logiciels. Il expose les opérations d’analyse via une interface de ligne de commande—des commandes de terminal typées—et un serveur d’outils pour les applications IA compatibles. Un agent est une application IA qui peut utiliser des outils dans une tâche multi-étapes. REA fournit l’accès aux outils d’analyse, pas au modèle IA sous-jacent.

La distinction est importante : enquêter sur une application terminée, écrire une implémentation similaire et récupérer son code source d’origine sont des réalisations différentes. L’utilité de REA dépend des preuves recueillies, des vérifications appliquées et des responsabilités qui subsistent. « Anything » est le nom du projet, pas une garantie que chaque produit peut être fidèlement recréé.

Ingénierie inverse : apprendre à partir du programme terminé

L’ingénierie inverse signifie comprendre le fonctionnement de quelque chose en examinant le résultat fini. Pensez à une machine sans ses plans de conception originaux : inspecter ses pièces et son comportement peut soutenir une nouvelle conception, mais ne vous donne pas les plans originaux du concepteur. De même, comprendre le comportement d’un logiciel ne récupère pas le code source que ses développeurs ont écrit.

Pour un exécutable natif, la forme prête pour le processeur d’un programme, un compilateur traduit le code source en instructions machine. Ce sont des opérations que le processeur comprend. La compilation peut également optimiser le programme, en réorganisant ou en combinant le travail tout en préservant son comportement prévu. Le résultat est un logiciel exécutable, pas une archive compressée du projet source.

Le désassemblage présente les instructions machine sous forme d’assembleur lisible. La décompilation va plus loin, en déduisant une logique de niveau supérieur ressemblant à la source appelée pseudocode. Des outils comme Ghidra fournissent les deux vues :

1) Forward production path:
Original source
       ↓
Compile / optimize
       ↓
Native executable

2) Separate analysis path:
Native executable
       ↓
Disassembly / decompilation
       ↓
Assembly / inferred pseudocode
  Original names, comments and structure may be missing
       ↓
Behavior to verify

Cas de code natif : la compilation produit l’exécutable ; l’analyse déduit une vue lisible et un comportement à vérifier. Il n’y a pas de chemin inverse garanti vers les fichiers source originaux.

La perte d’information est inégale. Les commentaires et de nombreux noms peuvent disparaître, tandis que les chaînes de texte, certains noms et les métadonnées descriptives restent. L’optimisation peut rendre les structures source familières difficiles à reconnaître. Différentes implémentations source peuvent également produire un comportement machine similaire, donc une reconstruction plausible n’a pas besoin de correspondre à l’expression originale du programmeur.

Toute application n’est pas du code machine natif. Le JavaScript empaqueté peut contenir du code source lisible ou du code minifié, raccourci pour la distribution. Lire du matériel ressemblant à du code source déjà présent dans un paquet est différent de déduire du pseudocode à partir d’instructions machine. Ce qui survit détermine les questions que l’analyse peut répondre.

Comment REA transforme une question en boucle de preuves

L’enquête DX-Ball du projet a commencé par une question pratique : comment la position horizontale de la brique à l’écran détermine-t-elle le panoramique sonore, l’équilibre entre l’audio gauche et droit ? La première vue du décompilateur a montré un appel qui convertissait un nombre, mais omettait l’entrée et le calcul qui le sous-tendaient. Ce n’était pas suffisant pour expliquer la position du son.

La vue des instructions a révélé l’entrée manquante et l’arithmétique. L’inspection de la fonction qui l’appelait a montré que l’entrée était la coordonnée d’écran de la brique. La lecture des valeurs stockées a fourni les nombres fixes du calcul et le paramètre qui mettait à l’échelle le panoramique.

Le résultat était une règle concrète : à l’échelle habituelle, le centre de l’écran correspond à un panoramique centré, tandis que les positions de chaque côté décalent l’équilibre vers la gauche ou la droite. Le projet de reconstruction pouvait alors écrire cette règle en C et la comparer avec la fonction d’origine.

Quatre rôles rendent cette enquête possible.

• Vous définissez la question autorisée.
• L’agent choisit les suites et interprète les résultats.
• REA fournit l’accès aux outils et retourne les preuves.
• Un moteur d’analyse ou un analyseur inspecte l’artefact cible—le fichier ou le package examiné.

Les moteurs natifs incluent Ghidra, Hopper et IDA.

La connexion utilise le Model Context Protocol (MCP), un moyen standard pour les applications IA d’accéder aux outils et systèmes externes. Le serveur MCP de REA est le logiciel exposant ces opérations, pas une machine que vous devez louer. Une compétence fournit des instructions d’enquête pour l’agent ; le serveur fournit l’accès aux opérations elles-mêmes. L’échange principal ressemble à ceci :

Your feature question
         ↓
Agent
         ↕ MCP
REA tool server
         ↕
Analysis engine / parser
         ↕
Target software

Les demandes se dirigent vers la cible ; les preuves reviennent à l’agent, qui les utilise pour choisir la question suivante. L’échange se répète au fur et à mesure que l’enquête progresse.

L’agent coordonne ces suites et connecte le code retourné et les références dans une explication. Les enregistrements de preuves identifient les emplacements des fichiers et du code, séparant les observations des inférences et des conclusions non résolues. Un examinateur peut donc tracer l’explication jusqu’à son matériel de soutien. L’agent peut également rédiger du code candidat et des tests, comme une étape distincte de l’établissement de ce que l’original fait.

Pour toute cible, distinguez l’inspection statique, qui lit les artefacts sans exécuter le programme, de l’observation ou interaction à l’exécution, qui l’examine pendant son exécution. L’endroit où cette inspection se produit est également distinct de l’endroit où le modèle traite ses conclusions. Si l’agent utilise un modèle hébergé, les résultats retournés peuvent quitter la machine d’analyse.

Quels types de logiciels REA peut-il inspecter ?

La visibilité dépend de la cible. Electron empaquète les logiciels de bureau en utilisant des technologies web, tandis que .NET et Android représentent des familles d’applications distinctes avec des chemins d’analyse différents. Chacun expose des informations différentes, comme le montre le tableau :

REA documente une couverture d’artefacts plus large au-delà de ces catégories. Consultez l’aperçu officiel des cibles et la documentation actuelle : les exigences varient selon le moteur, la plateforme d’hébergement, la cible et la version. Ceux-ci décrivent les flux d’inspection disponibles, et non les reconstructions vérifiées de chaque cible.

Une démonstration convaincante n’est pas une reconstruction vérifiée

Les démonstrations publiques donnent une image plus concrète de ce que REA peut faire. Dans une récréation de calculatrice partagée en ligne, l’analyse assistée par IA a produit une version Python de GNOME Calculator. Aux côtés de récréations visibles comme celle-ci, des projets plus étroits comparent un calcul reconstruit directement avec l’original.

Démonstration publique — rapportée en deuxième main
La récréation ressemblait à GNOME Calculator et correspondait à un résultat arithmétique basique. Les problèmes de redimensionnement signalés ont exposé une non-concordance visible qu’une vérification arithmétique réussie ne détecterait pas.

Reconstruction de fonction rapportée par le projet
La vitrine DX-Ball rapporte 3 205 cas de comparaison x86 original pour une fonction de position-à-panoramique sonore, plus des octets compilés correspondants en utilisant un compilateur historique.

La calculatrice démontre une récréation visible ; DX-Ball documente les vérifications d’un calcul spécifique. Chaque résultat répond à une question différente.

Pour DX-Ball, les comparaisons couvraient les positions d’écran et plusieurs forces de panoramique. Elles ont vérifié les valeurs de retour de la fonction C par rapport à celles de l’exécution des instructions originales. Compiler ce C avec un compilateur historique a également reproduit les octets de la fonction. Ce sont deux vérifications distinctes : l’accord sur les résultats testés et l’accord sur la fonction compilée, sans nécessiter le texte source original du programmeur.

GNOME Calculator possède également des capacités avancées, financières et de programmation. La simple comparaison arithmétique laisse ces fonctionnalités non évaluées, plutôt que de montrer si elles fonctionnent ou échouent dans la récréation. Sa source est publique, donc l’examen du code source peut être le point de départ plus direct lorsqu’il répond à votre question de maintenance. La progression utile va de la ressemblance visuelle aux vérifications de comportement sélectionnées, puis aux comparaisons systématiques pour le comportement dont vous avez besoin.

Où la promesse « tout » atteint ses limites

L’absence de contexte source peut rendre un composant difficile à interpréter. L’optimisation peut obscurcir sa logique, tandis que l’obfuscation rend délibérément le code plus difficile à comprendre. Les dépendances externes créent un autre écart : certains chemins d’exécution nécessitent des entrées, des services ou des conditions indisponibles lors de l’investigation. Même une analyse minutieuse peut laisser des cas limites non résolus lorsqu’une fonctionnalité repose sur un comportement en dehors du composant inspecté.

Un contrepoids indépendant provient du rapport d’Ishank Choudhary du 14 octobre 2026, couvrant REA 6.4.0. Il a trouvé une structure d’application Electron utile mais a manqué les connexions de préchargement : le code de pont reliant une page Electron aux capacités côté bureau. Il a testé des outils statiques sans moteur d’agent ou d’analyse native ; les conclusions concernent cette version et ce flux de travail, pas chaque version actuelle.

Le rapport a également décrit les relations omises du résumé de l’application en raison des budgets de résultats—des limites sur la sortie conservée. Certains faits sont restés au niveau du fichier sans que leurs connexions n’apparaissent dans le résumé. Une analyse complétée sans correspondance signifiait donc que l’analyse conservée n’avait pas trouvé la relation, non que la fonctionnalité était absente. Ses limites de couverture expliquaient l’omission.

L’effort commence par la configuration du moteur d’analyse et la fourniture de la puissance de traitement et de la mémoire dont il a besoin. L’utilisation du modèle apporte ses propres considérations : le contexte détermine combien de matériel il peut considérer à la fois, tandis que les tokens sont les unités de texte qu’il traite. Les requêtes répétées ajoutent de l’effort, suivies de tests et de réparations humaines après la première sortie. Les factures réelles, les besoins matériels et les délais d’exécution dépendent de la cible et de la question. Mesurer la contribution propre de REA à la vitesse ou à la qualité nécessiterait une comparaison contrôlée.

Applications utiles au-delà de la copie d’une application

Pour les développeurs, les auto-hébergeurs et les équipes de migration, la valeur réside souvent dans la réponse à une question spécifique de maintenance ou de compatibilité. Les scénarios suivants sont illustratifs, et non des déploiements testés ou des résultats de cet éditeur.

🛠️ Développeur / responsable de maintenance

Un responsable comparant deux versions autorisées d’un utilitaire hérité pourrait demander pourquoi un résultat d’importation a changé. REA pourrait aider à localiser la logique d’analyse et guider les vérifications de régression. Si la source complète répond déjà à cette question, commencez par là ; sinon, validez la cause déduite par rapport au comportement modifié.

🏠 Auto-hébergeur

Un auto-hébergeur travaillant avec un ancien format de fichier local pourrait utiliser REA pour comprendre ses champs. Ces résultats pourraient aider à définir un pont de compatibilité implémenté indépendamment. Un remplacement conforme et clé en main pour la dépendance propriétaire nécessiterait toujours des tests de cas non documentés et une vérification des droits applicables.

💼 Équipe commerciale / migration

Une équipe de migration peut avoir besoin de savoir si un comportement d’exportation requis peut être supporté avant de commander une implémentation. REA pourrait aider à établir la faisabilité technique et clarifier ce qui doit être construit. Cette conclusion peut éclairer une décision d’investissement, tandis que les estimations de délai, les engagements de support et la compatibilité complète nécessitent une évaluation supplémentaire.

L’éducation et la recherche en sécurité autorisée peuvent utiliser la même approche. Avant de passer d’une explication à une action supplémentaire, définissez ce qui peut être inspecté, exécuté ou partagé. Cette portée gouverne l’investigation même lorsque la question technique semble simple.

L’accès technique ne règle pas l’autorisation, la confidentialité ou la confiance

La permission d’inspecter un fichier peut différer de la permission de l’exécuter, d’observer son trafic, de publier les résultats ou de réutiliser du matériel protégé. Les droits dépendent de la loi applicable et des contrats : les droits d’interopérabilité conditionnels, y compris ceux aux États-Unis, ne sont pas des règles mondiales, et posséder une copie n’autorise pas toutes les opérations.

La licence MIT de REA couvre le code créé par REA, pas les applications cibles, les actifs protégés ou la sortie générée automatiquement. Les moteurs d’analyse commerciaux ont besoin de leurs propres licences. La clause de non-responsabilité d’utilisation responsable définit les usages prévus et les limites du soutien communautaire sans modifier MIT ; le code source récupéré ne devient pas automatiquement open source ou redistribuable.

⚠️ Avertissement : risques de confidentialité et d’exécution

L’analyse locale peut envoyer les résultats—y compris le code, les identifiants ou les données personnelles—au fournisseur de modèle de l’agent. Vérifiez les données sortantes et les conditions du fournisseur avant d’analyser des cibles confidentielles. REA n’est pas un bac à sable : l’analyse statique peut exposer les vulnérabilités des outils, tandis que l’exécution ou l’interaction avec les cibles peut modifier les fichiers ou affecter les comptes et services. Examinez les opérations réelles et le confinement, pas seulement où les outils s’exécutent.

Utilisez les sources officielles de paquets et de mises à jour, mais examinez aussi les dépendances, la sortie générée, la propriété de la maintenance et la façon dont les correctifs arrivent. Appliquez le même examen aux logiciels des fournisseurs, aux projets open source et aux alternatives générées par l’IA : l’origine officielle, le prix, la disponibilité du code source ou la compilation à partir du code source ne peuvent pas remplacer un historique clair de provenance et d’examen.

Ce que REA signifie pour la propriété des logiciels et le cloud

Reconstruire un logiciel une seule fois ne finance pas son avenir. Quelqu’un doit continuer à corriger les vulnérabilités et préserver la compatibilité. Le support des utilisateurs et le développement du produit nécessitent également un travail continu. Une investigation plus accessible peut compléter le travail des experts ; ces exemples ne montrent pas que les développeurs ou les logiciels payants deviennent obsolètes. Les mises à jour fiables et le support responsable restent des raisons de choisir un produit, même lorsque sa mise en œuvre devient plus facile à comprendre.

Les fournisseurs pourraient réagir en déplaçant davantage de fonctionnalités vers une livraison à distance uniquement, mais les preuves ici n’établissent pas une tendance motivée par REA. La distinction technique est client versus serveur : un navigateur reçoit le code d’interface et les réponses, tandis que la mise en œuvre côté serveur reste normalement avec l’opérateur.

Browser / client: delivered UI and scripts
Inspectable to the extent delivered / authorized
                   ↕
           Requests / responses
                   ↕
Server: application logic and database
Behavior observed ≠ exact private source revealed

Une limite de visibilité, pas une limite de sécurité complète : les ressources du navigateur et les réponses peuvent être examinées ; le code backend reste normalement à distance. Les données exposées et d’autres problèmes de sécurité restent possibles.

Ces réponses API—les données échangées avec le service—peuvent révéler suffisamment sur le comportement d’une fonctionnalité pour informer une nouvelle implémentation. Cette approche repose sur les entrées et sorties observables plutôt que sur l’accès au code backend. Garder le code à distance n’élimine pas non plus les bogues, les données exposées, ou la possibilité d’une investigation autorisée.

Avec SaaS, logiciel en tant que service, un fournisseur exploite l’application.

• L’auto-hébergement d’une application autorisée vous donne plus de contrôle sur le déploiement. Vous assumez alors la responsabilité de la correction et de la gestion de l’accès.
• Les sauvegardes, la surveillance et la récupération font également partie du maintien de cette application en fonctionnement.

Un VPS Ubuntu AlexHost est une option d’infrastructure pour une application examinée ou un pont de compatibilité. L’accès root complet vous donne le contrôle sur le système d’exploitation invité. Il ne sécurise pas automatiquement l’application ni ne rend le traitement du modèle externe privé.

L’essentiel : une investigation plus facile, pas une récupération automatique

Une fenêtre de calculatrice reconnaissable peut être un premier résultat prometteur. Les questions suivantes sont de savoir si le comportement dont vous avez besoin a été vérifié et qui le maintiendra. REA aide à enquêter sur ce comportement ; l’implémentation, la vérification et le fonctionnement fiable restent des travaux distincts.

Pour une lecture plus approfondie, commencez par le projet REA officiel et sa démonstration DX-Ball. Concentrez-vous sur une petite question autorisée et les preuves derrière la réponse. C’est un point de départ plus utile que de demander si l’IA peut copier un produit entier.