Contents

Obfuscation restrictions

VB Decompiler, armed with a unique obfuscation technology, effectively conceals data left behind by the compiler in our research on decompiling Visual Basic 5.0 and 6.0 applications. Modern programming languages often store significant amounts of metadata and debugging information within compiled files, making it easier for crackers to locate desired functions within your program. To counter this threat, we've developed an obfuscator specifically designed for Visual Basic applications.

The Obfuscation Process: A Closer Look

The obfuscator works by breaking down the entire program into its constituent parts, including forms, modules, classes, and controls like buttons and text fields. Each form is then dissected into individual controls with associated events. Next, information about functions and procedures, as well as events tied to each object in the program, are gathered. During this process, the obfuscator checks for dependencies between objects and synchronously alters their names to make it challenging to determine which function belongs to a particular module or class.

As a result, finding specific forms like frmTrial or frmRegistration within the program becomes significantly more difficult.

Limits of Visual Basic 5.0 / 6.0 Application Obfuscation: Key Considerations

The algorithm employed by the obfuscator is complex and designed to analyze object dependencies, but it still doesn't support everything. Consequently, in some cases, you'll need to prepare your program beforehand for the obfuscation process. The points discussed below apply exclusively to the obfuscation of Visual Basic 5.0 / 6.0 applications.

1. The obfuscator does not support design-time references to other objects, which can lead to issues during runtime.

For instance, consider a scenario where you have a TreeView control that relies on an associated ImageList. If the name of this ImageList object is hardcoded into the properties of your TreeView, any attempts to obfuscate will result in errors, as the original reference remains intact. This limitation also applies to database-related components, such as DataSets

This issue can easily be resolved by moving the assignments to Runtime from the Design-time, just by moving these assignments to the Form_Load event:


The same correction needs to be applied for each same instance. Fortunately, there are usually only a few such cases in most projects.

2. Early object declarations are not supported (LateCall calls)

This limitation typically doesn't affect the majority of VB6 projects, but it's essential to keep it in mind. If you're working with forms as classes and creating copies of form objects, you might be familiar with this scenario:


In such cases, the VB6 compiler inserts the name frmMain directly into the code of the Form_Load function. Since our obfuscator only modifies data and not code, this insertion remains invisible after obfuscation. Unfortunately, this leads to a program termination with error.

Unfortunately, it's impossible for us to support such calls in obfuscator of VB Decompiler, as we need to disassemble and decompile the entire code of all functions. Despite having this capability, decompilation is an extremely time-consuming process. For large projects, it can take over half an hour just to decompose the entire codebase. Moreover, we also need to analyze references to objects and rename them, which adds even more processing time.

Given these technical constraints, we decided not to implement full decompilation and code analysis in obfuscator of VB Decompiler, especially since this would only address the issue within too rare cases in Visual Basic 5.0 / 6.0 apps and wouldn't provide any benefits for most customers.