On nous pose parfois la question : pourquoi VBReFormer se concentre-t-il exclusivement sur Visual Basic 5 et 6, sans toucher au .NET, au C# ou au VB.NET ? La réponse tient en une phrase : parce que c'est là qu'est le vrai problème. Décompiler du .NET est aujourd'hui une commodité gratuite ; décompiler du code natif VB6, non.

Le .NET se décompile presque parfaitement — et gratuitement

Si vous devez lire le code d'un assembly .NET (C#, VB.NET, F#), n'achetez rien. Des outils gratuits et excellents font le travail mieux que n'importe quelle solution payante : dnSpy, ILSpy ou dotPeek reconstruisent un code quasi identique à l'original, en quelques secondes.

Pourquoi est-ce si facile ? Parce que le .NET ne compile pas vers du code machine, mais vers un langage intermédiaire (IL/CIL) accompagné de métadonnées riches : noms de classes, de méthodes, de variables, types, signatures — tout est conservé dans l'assembly, sauf obfuscation volontaire. Le décompilateur n'a presque qu'à « re-typographier » ces informations. La partie difficile a déjà été faite par le format lui-même.

Le code natif VB6, c'est l'exact opposé

Un exécutable Visual Basic 6 compilé en Code Natif ne contient aucune de ces métadonnées. C'est du code machine x86 brut : les noms de variables locales n'existent plus, les types sont à inférer, la structure est noyée dans les appels au runtime MSVBVM60.dll. Reconstruire du Visual Basic lisible à partir de ça relève de la rétro-ingénierie profonde — un tout autre métier que de re-formater de l'IL. Nous détaillons cette différence dans nos articles sur le P-Code et le Code Natif et sur la récupération de code source perdu.

Pourquoi la spécialisation gagne sur le problème dur

Un couteau suisse qui « fait aussi » le .NET n'apporte rien : sur ce terrain, il est battu par des outils gratuits. La vraie valeur est ailleurs — dans la profondeur sur le problème réellement difficile. C'est le choix de VBReFormer : se concentrer sur le VB5/6 et y aller loin.

  • Reconstruction du code depuis les instructions machine x86 (Code Natif) ;
  • Récupération des appels runtime (MSVBVM60.dll) et de plus de 15 000 déclarations d'API Win32 ;
  • Récupération intégrale de l'interface (formulaires, contrôles, ressources) ;
  • Édition de l'interface directement dans le binaire, sans code source.

Notre recommandation, en toute honnêteté

Le bon outil pour le bon problème :

  • .NET / C# / VB.NET → dnSpy, ILSpy ou dotPeek, gratuits et remarquables. Ne payez pas pour ça.
  • Visual Basic 5 / 6 (P-Code ou Code Natif) → c'est un problème spécialisé, et c'est exactement celui que VBReFormer résout. Vous pouvez l'essayer avec la version gratuite.

Recommander un outil gratuit là où il est meilleur n'est pas une faiblesse : c'est le réflexe d'un éditeur qui connaît son domaine. Le nôtre, c'est le VB6 — le dernier bastion où la décompilation reste un art.