Registration procedure

A common mistake many developers make when designing their application registration procedure is placing the entire registration key check into a separate function that returns an easily understandable value:

function CheckRegistration(const RegNumber: String): Boolean; begin if RegNumber='123' then Result:=True else Result:=False; end; procedure TForm1.Button1Click(Sender: TObject); begin ... if not CheckRegistration(RegNumber) then exit; Application.CreateForm(TForm2, Form2); Form2.ShowModal; ... end;

With this approach, an intruder does not even need to understand the key verification algorithm. They can simply modify the code at the beginning of the check procedure so that it always returns a valid registration result:

function CheckRegistration(const RegNumber: String): Boolean; begin Result:=True; exit; ... end;

A much more effective approach is to integrate the registration key validation directly into the main application logic, so that the key verification algorithm cannot be separated from the calling procedure. We also recommend “blending” the application logic with the registration check procedure so that the program fails if the verification is bypassed. For the example above, this can be implemented as follows:

function CheckRegistration(const RegNumber: String): Boolean; begin if RegNumber='123' then begin Application.CreateForm(TForm2, Form2); Result:=True end else Result:=False; end; procedure TForm1.Button1Click(Sender: TObject); begin ... Form2:=nil; if not CheckRegistration(RegNumber) then exit; Form2.ShowModal; ... end;

If the CheckRegistration function is implemented in this way, an intruder will have to analyze the registration key verification code in detail in order to bypass it. If the application is protected with VMProtect, we recommend virtualizing both the CheckRegistration function and the TForm1.Button1Click procedure. To make cracking even more difficult, you can enable the “Ultra” protection mode to combine code mutation with subsequent virtualization.

Checking registration keys

Another critical mistake developers make is implementing registration key validation incorrectly. Often, the entered key is simply compared with the correct value. A cracker can easily identify the correct key value by tracing the arguments passed to the string comparison function:

var ValidRegNumber: String; ... function CheckRegistration(const RegNumber: String): Boolean; begin if RegNumber=ValidRegNumber then Result:=True else Result:=False; end;

To avoid this situation, we recommend comparing key hashes instead of the actual key values. A hash function is irreversible, so a cracker cannot retrieve the original key value from the hash. As a result, they must spend significantly more time analyzing the program because multiple code fragments need to be examined, not just the registration check procedure:

var HashOfValidRegNumber: Longint; ... // Example of using Peter Weinberger's PJW hashing algorithm function HashPJW(const Value: String): Longint; var I:Integer; G:Longint; begin Result:=0; for I:=1 to Length(Value) do begin Result:=(Result shl 4)+Ord(Value[I]); G:=Result and $F0000000; if G<>0 then Result:=(Result xor (G shr 24)) xor G; end; end; function CheckRegistration(const RegNumber: String): Boolean; begin if HashPJW(RegNumber)=HashOfValidRegNumber then Result:=True else Result:=False; end; ... initialization HashOfValidRegNumber:=HashPJW(ValidRegNumber); end.

When protecting the application with VMProtect, both the HashPJW and CheckRegistration functions should also be protected to make reverse engineering more difficult.

Saving check results

Even developers who spend a significant amount of time implementing registration procedures often fail to properly protect the result of the registration process itself. The example below uses a global variable to store and control the application’s registration state before invoking the serial number verification procedure. For an intruder, locating a global variable is extremely easy — they simply compare the data segments BEFORE and AFTER registration. Incidentally, the popular ArtMoney program uses the same principle.

var IsRegistered: Boolean; ... procedure TForm1.Button1Click(Sender: TObject); begin ... if not IsRegistered then IsRegistered:=CheckRegistration(RegNumber); if not IsRegistered then exit; ... end;

To avoid this issue, we recommend storing all registration-related verification results in dynamically allocated memory. In this case, scanning data segments for modified memory blocks BEFORE and AFTER registration becomes ineffective. Here is a simple example demonstrating how to store the result in dynamically allocated memory:

type PBoolean = ^Boolean; var IsRegistered: PBoolean; ... procedure TForm1.Button1Click(Sender: TObject); begin ... if not IsRegistered^ then IsRegistered^:=CheckRegistration(RegNumber); if not IsRegistered^ then exit; ... end; ... initialization New(IsRegistered);

These are some of the simplest ways to utilize built-in protection mechanisms. Real-world implementations of registration procedures, registration key verification, and result storage are limited only by the developer’s creativity. However, understanding these common mistakes is essential in order to avoid them while designing your own protection system.

The cornerstone principle of VMProtect is to provide effective protection of application code from examination by making the code and logic extremely difficult to analyze and crack. The main software protection mechanisms used by VMProtect are virtualization, mutation, and combined protection, which involves mutating the application code followed by virtualization.

The crucial advantage of the virtualization method used in VMProtect is that the virtual machine executing virtualized code fragments is embedded directly into the protected application's resulting code. Therefore, an application protected with VMProtect does not require any third-party libraries or modules to function. VMProtect also allows the use of several different virtual machines to protect different code fragments within the same application, making the cracking process even more complicated, as a hacker must analyze the architecture of multiple virtual machines.

The application code mutation method used in VMProtect is based on obfuscation — a process that adds various excessive or “garbage” instructions, “dead” code sections, and random conditional jumps to the application code. It also mutates original instructions and transfers execution of certain operations to the stack.

The key difference between VMProtect and other software protectors is its ability to protect different parts of the code using different methods: one part of the code can be virtualized, another part can be obfuscated, and critical fragments can be protected using the combined method.

Another unique feature of VMProtect is the embedding of watermarks into the application code. Watermarks make it possible to reliably identify the original owner of a leaked or hacked copy of the software and therefore take appropriate action against them.

VMProtect is available in 3 editions:

• Lite;
• Professional;
• Ultimate;

The below table lists differences in functionality of certain VMProtect editions:

During dynamic analysis, the target application is executed within a debugger environment. This allows the debugger to monitor and control nearly every aspect of the program’s execution in real time. By stepping through the application instruction by instruction, a cracker can gradually bypass protection mechanisms one at a time, including license verification routines, serial number generation algorithms, integrity checks, and anti-tampering procedures. Dynamic analysis often also involves monitoring file system activity, system services, registry access, network ports, API calls, and communication with external devices or servers used by the protected application.

The primary tools used to protect applications against cracking attempts are software protectors. Most protection systems rely mainly on packing and/or encryption of the original executable code, with special emphasis placed on securing the unpacking and decryption routines themselves.

However, such an approach is often insufficient to provide strong and reliable protection. If an application is protected only by packing, a hacker can usually obtain the original unpacked executable by creating a memory dump immediately after the unpacking process completes. In addition, many automated tools already exist for bypassing or removing protection implemented by popular commercial protectors. Similar problems apply to encrypted applications: once a valid license key is obtained — often through legitimate purchase — a cracker may be able to decrypt protected code sections and analyze them without major difficulty.

Some software protectors incorporate various anti-debugging techniques designed to interfere with dynamic analysis. However, each anti-debugging mechanism introduces additional overhead and may negatively affect the performance and stability of the protected application. More importantly, anti-debugging methods are only effective against dynamic analysis and provide little or no protection against static analysis. Furthermore, most anti-debugging techniques used by modern protectors are already well known, thoroughly documented, and extensively studied by reverse engineers. As a result, numerous utilities and plugins have been developed specifically to bypass or neutralize such protections automatically. Monitoring tools and system activity analyzers are generally unaffected by built-in anti-debugging mechanisms.

More advanced and effective methods of software protection include obfuscation and virtualization, both of which significantly complicate analysis of the protected application’s code. The effectiveness of these methods is largely based on the human factor: the more complex, confusing, and resource-intensive the protected code becomes, the more difficult it is for a reverse engineer to understand the program’s internal logic and ultimately bypass its protection.

Obfuscation works by deliberately “entangling” the application’s code through insertion of excessive or misleading instructions, dead code, unnecessary jumps, altered control flow, and other transformations intended to complicate analysis. Virtualization takes this concept even further by transforming original machine code into bytecode executed by a dedicated interpreter that emulates a custom virtual machine with its own architecture and instruction set. As a result, virtualization introduces a high and often irreducible level of complexity into the protected code. When implemented correctly, virtualized code does not contain explicit mechanisms capable of restoring the original machine instructions. The key advantage of virtualization lies in the fact that virtualized code fragments are never directly converted back into native machine instructions during execution, making recovery of the original application logic substantially more difficult for a cracker.

Reverse engineering of virtualized code is therefore reduced to analyzing the architecture of the virtual machine, developing a custom disassembler or analysis framework for the processor architecture emulated by that virtual machine, and finally analyzing the resulting disassembled bytecode. A properly designed virtual machine can make the creation of such analysis tools extremely difficult and time-consuming. The primary disadvantage of virtualization is relatively low execution speed compared to native machine code. For this reason, virtualization is usually applied only to security-critical parts of the application that are not highly sensitive to performance overhead.

Many modern software protectors still pay insufficient attention to high-quality obfuscation and virtualization, or implement these technologies poorly. As a result, experienced crackers are often able to bypass such protections using automated or semi-automated tools. Another common weakness of many protection systems is their reliance on undocumented Windows APIs and low-level operating system behavior, which may cause compatibility problems on newer versions of Windows or in environments where security technologies such as DEP (Data Execution Prevention) are enabled.

Bytecode – the code generated after transcoding instructions of the physical processor into instructions of the virtual machine.

Virtualization – a process that transforms a portion of the application’s executable code into instructions of a virtual machine with an architecture, instruction set, and operational logic unknown to a potential attacker. Virtualized code fragments are executed directly by the virtual machine interpreter without being translated back into the native machine code of the physical processor. In practice, reverse engineering of virtualized code usually requires building a custom disassembler or analysis environment capable of understanding the architecture emulated by the virtual machine, followed by extensive analysis of the resulting disassembled code.

Virtual Machine – a software-based execution environment that directly interprets and executes bytecode inside the protected application.

Watermarks – a unique array of bytes generated for each individual user, allowing reliable identification of the legal owner of a leaked or hacked copy of the software.

Mutation – the process of replacing an original instruction with an equivalent instruction or a sequence of instructions that produces the same result while altering the structure of the code.

Obfuscation – a collection of methods and techniques intended to complicate analysis and reverse engineering of program code. Depending on the programming language used to develop the protected application, different obfuscation techniques may be applied. Obfuscation of applications written in interpreted languages such as Perl, PHP, and similar languages is typically performed by modifying the source code: removing comments, renaming variables to meaningless identifiers, encrypting string constants, and restructuring logic. Obfuscation of Java and .NET applications involves transforming the bytecode executed by the virtual machine. Obfuscation of compiled native applications relies on modifying machine code instructions: the obfuscator may insert “garbage” instructions, dead code, random jumps, misleading execution paths, and unnecessary operations. Original instructions may also be mutated, some operations may be transferred to the stack, and various structural or, less commonly, mathematical transformations may be applied. Reverse engineering of obfuscated code attempts to restore the original program logic, which can become an extremely time-consuming task when obfuscation is implemented correctly.

Protector – software designed to protect other applications from unauthorized analysis, modification, cracking, or redistribution. Most modern protectors do not modify the original source code of the protected application directly, but instead pack, encrypt, virtualize, or otherwise transform the executable code. The primary focus is usually placed on protecting the unpacking, decryption, or execution mechanisms themselves.

Entry Point – the initial memory address from which execution of the loaded application begins.

Packing – a method of protecting program code by compressing executable files and/or libraries using specialized or non-standard algorithms. Protected code fragments are compressed by the packer and later unpacked fully or partially on the user’s system during application execution.

Encryption – a protection method that secures parts of an application’s code using strong cryptographic algorithms. Software protected by encryption often requires the end user to enter a valid activation code or license key in order to remove restrictions imposed on the unregistered or trial version of the application.

While software protection may serve different purposes, the foundation of any effective protection system is safeguarding the application against analysis. Resistance to reverse engineering is what ultimately determines the overall strength and effectiveness of the protection.