Rétro-ingénierie d'applications VB6 : peu de retours, un workflow possible

Le 17 octobre 2026, un contributeur ouvre l'issue #4627 sur le dépôt de REA : il demande la prise en charge de Visual Basic 3, pour retrouver la logique d'un programme d'astrologie des années 1990 dont le source est perdu¹. La demande éclaire un angle mort plus large : les applications Visual Basic encore en production, dont VB6, n'ont pas d'outillage dédié côté agents.

Ce que REA couvre, et ce qu'il ne couvre pas

Au 18 octobre 2026, le README de REA ne mentionne ni VB5 ni VB6 parmi ses cibles². L'issue #4627 concerne une génération plus ancienne : REA rejette les exécutables Windows 16 bits (format NE) et n'analyse pas le p-code VB3, interprété par VBRUN300.DLL. Son auteur résume le problème : un désassembleur natif ne montre que l'interpréteur, pas la logique du programme. Il propose un outil d'inspection des images NE et le branchement de ghidra-vb3, un script PyGhidra publié en mai 2026 qui désassemble le p-code VB3³. La proposition est ouverte, rien n'est intégré.

Un exécutable VB6 est un binaire Windows 32 bits : REA peut le confier à Ghidra comme n'importe quel PE. Il ne sait pas pour autant ce qu'est un formulaire VB6, un contrôle ActiveX ou une procédure événementielle. Nous n'avons trouvé aucun retour public de rétro-ingénierie par agents sur une application VB6 au 18 octobre 2026.

P-Code ou natif : la question à poser en premier

Visual Basic 6 compile au choix en P-Code, un bytecode exécuté par la machine virtuelle de la bibliothèque d'exécution, ou en code natif x86. Le premier conserve des instructions de haut niveau, plus faciles à remonter vers une forme lisible. Le second ne laisse que du code machine, où l'on retrouve les appels à la bibliothèque d'exécution et la logique compilée.

Les deux modes se décompilent en partie. DotFix Software, éditeur de VB Decompiler, revendique la récupération de près de 85 % du code dans une application P-Code typique et jusqu'à 85 % en code natif x86, le reste demandant une analyse et une correction par un développeur⁴. Ces chiffres viennent de l'éditeur et dépendent du programme ; prenez-les comme un ordre de grandeur.

Les outils spécialisés restent la référence

Sur VB6, un décompilateur qui connaît le format des projets Visual Basic (formulaires, contrôles, tables d'objets) fait mieux qu'un décompilateur générique piloté par un agent. VB Decompiler traite VB5 et VB6, en P-Code et en natif⁴. L'agent garde un rôle : relire en masse le résultat, rapprocher les procédures des écrans, proposer des règles métier, et dresser la liste de ce qu'il n'a pas compris.

Un workflow pour rétro-documenter

Identifiez d'abord le mode de compilation de chaque exécutable et de chaque composant. En P-Code, passez par un décompilateur spécialisé et confiez sa sortie à l'agent pour la rétro-documentation. En natif, combinez le décompilateur spécialisé et Ghidra, piloté par l'agent via REA si vous voulez une trace des preuves, pour extraire pseudocode, chaînes et appels.

Dans les deux cas, lisez la sortie avec la discipline décrite dans lire une sortie REA : une règle inférée d'un motif n'a pas la valeur d'une règle lue dans le code. Les fichiers de données de l'application méritent leur propre analyse, voir rétro-documenter un format propriétaire. Puis la réécriture suit la méthode du hub legacy : règles relues par les utilisateurs, golden master alimenté par l'exécutable d'origine, bascule par briques.

Ouvrez les binaires dans un environnement isolé si leur provenance est incertaine : REA laisse Ghidra analyser le fichier avec vos droits, voir REA n'est pas un sandbox. Décompiler votre propre application pour la comprendre relève d'un cadre juridique précis, rassemblé dans clean-room ou reverse engineering.

Questions fréquentes

REA prend-il en charge VB6 ?

Pas dans ses cibles documentées au 18 octobre 2026. Il peut confier l'exécutable à Ghidra, sans connaissance du format Visual Basic. La seule demande liée, l'issue #4627, porte sur VB3.

Peut-on retrouver le source d'une application VB6 ?

Une bonne partie, selon l'éditeur de VB Decompiler, en P-Code comme en natif ; jamais le projet d'origine à l'identique. Le reste se reconstruit à la main, et le livrable utile reste une spécification.

Comment savoir si un exécutable est en P-Code ?

Les décompilateurs spécialisés l'indiquent à l'ouverture. Un même parc mélange souvent les deux modes, d'où l'intérêt de l'inventaire avant toute estimation.

Vers quoi migrer une application VB6 ?

La cible dépend des compétences de vos équipes et du type d'application ; le choix se fait après la rétro-documentation, pas avant.

Une application VB6 critique se traite comme tout patrimoine sans source : inventaire, rétro-documentation, golden master, réécriture. Nos équipes mènent ce parcours avec la Software Factory.

Sources

1. morluto/rea, issue #4627, [Feature] add support for VB3 (visual basic), github.com, 17 octobre 2026.
2. morluto/rea, README, tableau « What you can analyze », github.com/morluto/rea, consulté le 18 octobre 2026.
3. dfl, ghidra-vb3, script PyGhidra de désassemblage du p-code Visual Basic 3, github.com, dépôt créé le 26 mai 2026.
4. DotFix Software, VB Decompiler, page de présentation, vb-decompiler.org, consulté le 18 octobre 2026.