Vous avez un exécutable Visual Basic et vous avez besoin d'y voir quelque chose. Deux familles d'outils s'offrent à vous, et elles ne font pas le même travail : l'une vous montre les instructions, l'autre tente de reconstruire l'intention. Choisir la mauvaise coûte des heures.
Ce que fait un désassembleur
Un désassembleur traduit les octets du fichier en instructions lisibles. La correspondance est directe : à chaque séquence d'octets correspond une instruction et une seule. L'opération est donc fidèle et sans perte — le désassemblage d'un binaire valide réussit toujours.
Ce qu'il ne fait pas : deviner. Il vous rend des instructions machine, pas des noms de variables, pas des structures de contrôle, pas la logique métier de l'auteur. La lecture reste entièrement à votre charge.
Ce que fait un décompilateur
Un décompilateur va plus loin : il tente de reconstituer du code source à partir de ces mêmes instructions. Cela suppose de reconnaître des motifs, d'inférer des types, de retrouver des boucles là où il n'y a que des sauts.
C'est donc une opération partielle et faillible. Ce que le compilateur a supprimé — les noms des variables locales, les commentaires, les constantes repliées — ne revient pas. En échange, ce qui revient est directement lisible.
Désassembleur
Sortie : instructions. Toujours complète, jamais fausse.
Vous lisez ce que la machine exécute. À vous de reconstituer le sens.
Décompilateur
Sortie : code source reconstruit. Partielle, parfois approximative.
Vous lisez une intention. À vous de vérifier qu'elle est exacte.
Sur un binaire Visual Basic, la question se pose deux fois
Visual Basic 5 et 6 produisent deux sortes d'exécutables, et l'écart entre désassemblage et décompilation n'est pas le même dans les deux cas.
En P-Code, le bytecode est de haut niveau : ses instructions correspondent à des opérations du langage, typées. Le désassemblage est déjà presque lisible, et la décompilation en est un prolongement largement mécanique.
En code natif, le binaire est du x86 produit par le compilateur optimisant de Visual C++. Le désassemblage donne des instructions machine ; passer de là à du Visual Basic demande un travail d'un autre ordre. Le détail est traité dans P-Code ou code natif : ce que votre binaire rend.
Concrètement, voici la différence sur une affectation d'une seule ligne. Un binaire natif ne contient pas l'affectation : il contient les appels au runtime qui la réalisent.
push offset aBonjour ; littéral conservé
mov eax, [ebp-18h]
push eax
call __vbaObjSet ; export de MSVBVM60.DLL
mov edx, eax
lea ecx, [ebp-4]
call __vbaStrCopy
...
call __vbaFreeStr
Private Sub Command1_Click()
Text1.Text = "Bonjour"
End Sub
Les deux sorties décrivent le même code. La première est exacte et coûte à lire ; la seconde est reconstruite et se lit d'un coup d'œil. Notez que le nom de la procédure et celui du contrôle sont revenus : ce sont des informations que le format conserve, indépendamment du mode de compilation.
Lequel vous faut-il ?
Cela dépend entièrement de ce que vous voulez obtenir, et la réponse n'est pas toujours « un décompilateur ».
Et en pratique, les outils font souvent les deux
La distinction est nette en théorie, moins dans les produits. La plupart des outils Visual Basic embarquent un désassembleur et posent une couche de reconstruction par-dessus : vous disposez des deux vues dans la même fenêtre, et vous basculez de l'une à l'autre quand la reconstruction devient douteuse.
C'est la bonne façon de travailler : lire le code reconstruit pour aller vite, revenir au désassemblage quand un passage ne tient pas debout. Les outils disponibles, leur approche et leur état sont recensés dans l'histoire des décompilateurs Visual Basic.
VBReFormer publie la couverture réelle de sa reconstruction, fonction par fonction et instruction par instruction, avec les dénominateurs : 1 153 correspondances documentées. Et la version gratuite vous dira en quelques secondes de quel format relève votre binaire et ce qu'il contient — c'est la première question à régler avant de choisir un outil.