Depuis des années, nous recevons le même message de la part d'utilisateurs déçus par un décompilateur : « mon application n'a pas été récupérée ». Dans la quasi-totalité des cas, la cause est la même — une confusion entre les deux modes de compilation de Visual Basic 6. Cet article explique cette distinction fondamentale, car elle détermine à elle seule si, et comment, votre application pourra être décompilée.

Deux modes de compilation, deux mondes

Visual Basic 6 propose deux façons de produire un exécutable, réglables dans les options du projet :

  • Le P-Code (pseudo-code) : le code est traduit en instructions intermédiaires compactes, interprétées à l'exécution par la machine virtuelle VB (MSVBVM60.dll). L'exécutable est plus petit, mais a besoin de l'interpréteur pour tourner.
  • Le Code Natif : le code est compilé directement en instructions machine x86, comme le ferait un compilateur C++. Le compilateur peut analyser de larges blocs pour supprimer les redondances et optimiser le résultat.

Ces deux approches produisent des binaires radicalement différents. Un décompilateur conçu pour le P-Code est incapable de traiter du Code Natif, et inversement. C'est là que se joue la déception : beaucoup d'utilisateurs achètent un décompilateur P-Code, puis découvrent que leur application avait été publiée en Code Natif.

La bonne question à se poser

Avant tout achat ou toute tentative, demandez-vous : « mon application est-elle compilée en Code Natif ou en P-Code ? » C'est le point de départ. Un outil qui ne précise pas quel mode il prend en charge doit éveiller votre méfiance.

Quelle est la proportion réelle de chaque mode ?

Dans la réalité, le Code Natif domine très largement : environ 90 % des applications VB6 sont publiées en Code Natif. Plusieurs raisons l'expliquent :

  • C'est le réglage par défaut du compilateur VB6 ;
  • Les applications natives s'exécutent presque aussi vite que du C++, ce qui n'est pas le cas du P-Code ;
  • Les développeurs ont rarement une raison de revenir au P-Code une fois le projet livré.

Le P-Code, bien que plus simple à décompiler grâce à sa nature de haut niveau, reste donc marginal. C'est précisément pour cela que les décompilateurs uniquement P-Code sont aujourd'hui largement obsolètes.

Notre choix avec VBReFormer

C'est ce constat qui a guidé le développement de VBReFormer : la priorité absolue a été mise sur la décompilation du Code Natif, le mode qui concerne la grande majorité des applications réelles. VBReFormer traite les deux modes, mais c'est sa capacité à reconstruire du Visual Basic lisible à partir de code machine x86 qui fait la différence sur le terrain.

En résumé : identifiez le mode de compilation avant tout, méfiez-vous des outils qui restent flous sur ce point, et partez du principe qu'il y a 9 chances sur 10 que votre application soit en Code Natif.