Nous annonçons un partenariat avec Malva.RE, spécialiste français de l'analyse statique de malware. Leurs analystes utilisent VBReFormer pour décompiler les binaires Visual Basic 6 malveillants qu'ils rencontrent.

Ce rapprochement n'est pas fortuit : il répond à un problème précis, que peu d'outils traitent réellement.

Un angle mort de l'outillage moderne

La rétro-ingénierie a considérablement progressé sur les cibles contemporaines. Pour du .NET, dnSpy ou ILSpy restituent un code quasi identique à l'original. Pour du natif, les décompilateurs des suites d'analyse produisent un pseudo-C lisible.

Visual Basic 6 échappe à ces deux catégories. Un exécutable VB6 compilé en code natif est certes du x86, mais un x86 très particulier : la logique de l'auteur y est noyée dans les appels au runtime MSVBVM60.dll, avec des conventions propres au moteur VB — gestion des chaînes BSTR, comptage de références sur les objets COM, tableaux SAFEARRAY, gestion d'erreurs On Error compilée en séquences reconnaissables mais verbeuses.

Résultat : un désassemblage correct, mais dont la lecture demande de reconstituer mentalement ce que faisait le code VB d'origine. Sur une charge malveillante conçue pour ralentir l'analyse, ce surcoût se paie en heures.

Ce que la décompilation change

Remonter au niveau VB, plutôt que de rester au niveau instruction, déplace le travail de l'analyste. Concrètement :

  • Les appels au runtime redeviennent lisibles. Une séquence d'appels à __vbaStrCat et __vbaStrMove se relit comme une concaténation de chaînes, et non comme une suite d'adresses.
  • La structure du projet réapparaît. Formulaires, modules, classes et contrôles utilisateur retrouvent leurs frontières : on sait quelle partie du code appartient à quoi.
  • L'interface est reconstruite. Sur les charges qui affichent une fenêtre — fausse mise à jour, faux installeur, leurre — retrouver la form et ses contrôles renseigne directement sur le scénario social employé.
  • Les ressources embarquées sont extraites. Icônes, chaînes, fichiers .frx : autant d'éléments qui alimentent l'attribution et le rapprochement entre campagnes.

Aucun de ces points ne remplace l'analyse dynamique ni le jugement de l'analyste. Ils lui font gagner l'étape la plus ingrate : passer du bruit du runtime à la logique réelle.

Pourquoi VB6 revient dans les campagnes

Nous avons détaillé ce phénomène dans un article précédent. En résumé : le runtime est présent d'origine sur Windows 10 et 11, le format est peu couvert par l'outillage récent, et la couche moteur complique la rétro-ingénierie. Un langage de 1998 offre donc, en 2026, un rapport coût-discrétion qui reste intéressant pour un attaquant.

C'est précisément ce déséquilibre — beaucoup d'échantillons, peu d'outils — que ce partenariat cherche à corriger côté défense.

Ce que le partenariat apporte

Les retours de terrain de Malva.RE alimentent directement notre feuille de route. Les binaires malveillants sont, par construction, les cas les plus hostiles : code obfusqué, structures volontairement dégradées, tentatives d'anti-analyse. Un décompilateur qui tient sur ces échantillons tient a fortiori sur du logiciel d'entreprise ordinaire.

La version 7, prévue pour septembre 2026, pousse la reconstruction du P-Code, l'inférence de types et la reconstitution de noms de variables — trois axes qui comptent particulièrement lorsqu'on analyse un binaire dont on ne possède évidemment aucune documentation.

Un mot sur l'usage

VBReFormer est un outil d'analyse et de récupération. Son usage relève de l'interopérabilité, de la maintenance et de l'analyse défensive, sur des binaires que l'on possède ou que l'on est autorisé à analyser. C'est le cadre dans lequel travaille Malva.RE, et celui que rappellent nos conditions de licence.

Pour aller plus loin