We are announcing a partnership with Malva.RE, a French specialist in static malware analysis. Their analysts use VBReFormer to decompile the malicious Visual Basic 6 binaries they encounter.

This is not a coincidence: it answers a precise problem that few tools actually address.

A blind spot in modern tooling

Reverse engineering has come a long way on contemporary targets. For .NET, dnSpy or ILSpy return code almost identical to the original. For native binaries, the decompilers bundled with analysis suites produce readable pseudo-C.

Visual Basic 6 falls between the two. A VB6 executable compiled to native code is indeed x86, but a very particular kind of x86: the author's logic is buried under calls into the MSVBVM60.dll runtime, with conventions specific to the VB engine — BSTR string handling, reference counting on COM objects, SAFEARRAY arrays, On Error handling compiled into recognisable but verbose sequences.

The result is a correct disassembly whose reading requires mentally reconstructing what the original VB code did. On a payload designed to slow analysis down, that overhead is paid in hours.

What decompilation changes

Getting back to VB level, rather than staying at instruction level, shifts the analyst's work. In practice:

  • Runtime calls become readable again. A sequence of __vbaStrCat and __vbaStrMove calls reads as string concatenation rather than a list of addresses.
  • Project structure reappears. Forms, modules, classes and user controls regain their boundaries: you know which part of the code belongs where.
  • The interface is rebuilt. On payloads that display a window — fake update, fake installer, decoy — recovering the form and its controls tells you directly which social scenario was used.
  • Embedded resources are extracted. Icons, strings, .frx files: all of it feeds attribution and correlation between campaigns.

None of this replaces dynamic analysis or the analyst's judgement. It removes the most thankless step: getting from runtime noise to actual logic.

Why VB6 keeps coming back

We covered this in a previous article. In short: the runtime ships with Windows 10 and 11, the format is poorly covered by recent tooling, and the engine layer complicates reverse engineering. A language from 1998 therefore still offers, in 2026, a cost-to-stealth ratio that remains attractive to an attacker.

It is precisely that imbalance — many samples, few tools — that this partnership aims to correct on the defensive side.

What the partnership brings

Field feedback from Malva.RE feeds directly into our roadmap. Malicious binaries are, by construction, the most hostile cases: obfuscated code, deliberately degraded structures, anti-analysis attempts. A decompiler that holds up on those samples holds up all the more on ordinary business software.

Version 7, scheduled for September 2026, pushes P-Code reconstruction, type inference and variable-name recovery — three areas that matter especially when analysing a binary for which no documentation exists.

A word on usage

VBReFormer is an analysis and recovery tool. Its use falls under interoperability, maintenance and defensive analysis, on binaries you own or are authorised to analyse. That is the framework Malva.RE works within, and the one set out in our licence terms.

Further reading