Obfuscation restrictions
The advanced protection suite DotFix NiceProtect utilizes a unique obfuscation technology that masks data left by the compiler, based on our research in decompilation of Visual Basic, Delphi and Free Pascal applications. Many modern programming languages save significant amounts of metadata and debugging information within compiled files. Although you can secure your code using various methods such as mutation and virtualization, the names of public functions, forms, modules, and controls on forms will still remain visible in the protected file, aiding crackers in locating desired functions within your program. To safeguard against cracking, we have developed an obfuscator for Delphi, Free Pascal and Visual Basic applications. Currently, all versions of Delphi from version 3 to the latest 12 are supported, including the entire Delphi XE branch, as well as Delphi 10 Seattle, Delphi 10 Berlin and Delphi 12 Athens.
How the obfuscator works
The obfuscator works by decompiling the entire program into its constituent parts, including forms, modules, classes, and controls such as buttons and text fields. Each form is separated into individual controls and events bound to them. Then, information about functions and procedures, as well as events associated with each object in the program, is collected. During this process, the obfuscator checks for dependencies between objects and synchronously changes their names to make it difficult to identify which function belongs to which module or class.
As a result, it becomes much harder to find specific forms like frmTrial or frmRegistration within the program.
Limitations of the Visual Basic 5.0 / 6.0 Application Obfuscator
The algorithm used by the obfuscator is complex and designed to analyze object dependencies, but it still does not support everything. As a result, in some cases, the program will need to be prepared beforehand for the obfuscation process. The points discussed below only apply to the obfuscation of Visual Basic 5.0 / 6.0 applications. Let's take a look at these issues.
1. The obfuscator does not support design-time references of some objects to others
For example, you have a TreeView control that has an ImageList property. If the name of the ImageList object is specified in the ImageList property of the TreeView control, then after obfuscation, it will not be changed and the program will exit with an error. The same goes for databases and specifying DataSet's and Recordset's in component properties.
Begin ComctlLib.TreeView TreeView1 Height = 1932 Left = 3600 TabIndex = 3 Top = 1320 Width = 2412 _ExtentX = 4255 _ExtentY = 3408 _Version = 327682 Style = 7 ImageList = "ImageList1" Appearance = 1 End
All of this can easily be resolved by moving the assignments from Design time to Runtime, specifically by moving these assignments to the Form_Load event:
Private Sub Form_Load() TreeView1.ImageList = ImageList1 End Sub
The same action needs to be taken for each assignment of this type. Thankfully, there is typically only a small amount of such code.
2. Early object declarations are not supported (LateCall calls)
Few people take advantage of this opportunity, because this incompatibility will not affect most VB6 projects. Nevertheless, it is necessary to remember about it. If you create copies of form objects (work with a form as a class), then you are likely acquainted with these lines:
Private Sub Form_Load() Dim oForm as New frmMain oForm.Show End Sub
So, in this case, the name frmMain is inserted by the VB6 compiler directly into the code of the Form_Load function. The obfuscator doesn't decompile the code, only the data, so this insertion remains invisible. As a result, the program will terminate with an error after obfuscation. Unfortunately, it isn't possible to support such calls in DotFix NiceProtect due to the need to disassemble and then decompile the code of all program functions. The VB6 compiler supports two types of compilation: P-Code and Native Code. This means that the obfuscator needs to be able to decompile both P-Code and Native Code. Despite having this technologies, decompilation is an extremely slow process. For large projects, decompiling the entire code can take over half an hour. And this doesn't even account for the time spent analyzing references to objects and their renaming. Given these objective reasons, we decided not to use full decompilation and code analysis in DotFix NiceProtect, especially since this can only solve the problem within Visual Basic 5.0 / 6.0 and won't help in any way with obfuscating other languages.