VB Decompiler vs VBReFormer: Blind P-Code & Native Code Comparison

Blind-test results: usefulness to an analyst and to AI

The headline score is a pairwise relative utility score. The more useful output on the same input receives 10/10; the other score shows how far it trails. It is not a percentage of original source code recovered.

Read 7.1/10 correctly: on this Native Code input, the competing product retained about 71% of the measured analytical utility of the better result. It does not mean that 71% of the original source was recovered. Likewise, winner=10 does not mean perfect decompilation.

Download the scored component data (CSV)

Why usefulness is the primary metric

Native Code and P-Code compilation both remove information from the original source. A byte-for-byte comparison rewards textual resemblance even when the result is awkward, incomplete or misleading. The practical question for reverse engineering is different: which output makes it easier to determine what the program does and to reconstruct working logic?

1. Freeze the rules before opening the inputs. Filenames, sizes and SHA-256 hashes were recorded first. Neither input was inspected with another decompiler, disassembler, strings utility or source repository.
2. Capture each normal product workflow. Both products ran on the same host and each tool was allowed its best available normal code view and navigation into internal procedures.
3. Score two independent tracks. Human utility asks how quickly and reliably an analyst can understand behavior. AI readiness asks how much faithful, machine-usable context is available for explanation or code reconstruction.
4. Measure the relative gap. Coverage contributes 25%, semantic clarity 30%, visible behavior and side effects 20%, navigation 15%, and machine usability 10%.
5. Prevent a misleading 10/10. Every score also carries an absolute viability marker: none, weak, usable or strong. If both outputs are useless, both receive 0/10; if they tie, both receive 10/10.

What “AI reconstruction readiness” does and does not prove

This first publication evaluates the quality of input available to an AI model. A fully validated AI benchmark additionally requires isolated prompts, at least three runs per product output, fixed model/version/settings, compilable reconstructions and identical behavioral tests against a ground-truth oracle. Those multi-run behavioral tests have not yet been completed, so the results are explicitly labeled readiness, not proven reconstruction accuracy.

Feature comparison for real analyst workflows

The benchmark above measures recovered-code utility only. The following table separately covers navigation, investigation, editing, extensibility and deployment. This avoids hiding a product's useful workflow feature inside a code-quality number.

What was observed in the blind samples

Reproducibility identifiers

The test executables themselves are not redistributed from this page. Their hashes make it possible to identify the exact inputs if they are supplied independently.

Limitations and update policy

• Two blind binaries are meaningful evidence, not a universal sample of every compiler option, obfuscator, ActiveX dependency or coding style.
• The Native Code result is based on matched procedures including DisasmInitialize, GetCRCOfProc and EncryptByte. More matched samples will strengthen the whole-binary estimate.
• No original source or behavioral oracle was available, so neither product's output is certified as semantically identical to the unknown source.
• The current AI score evaluates input readiness. It will be updated separately when isolated multi-run reconstruction, compilation and behavioral testing are complete.
• This is a version-specific snapshot. Any later release must be tested separately before its capabilities can be included.