Top-Notch Protection with Translocated Execution

“A wrapper that encrypts software can be circumvented by using a memory dump. You just wait until all parts of the application are decrypted, and then you dump it.” This statement might apply to many simpler products, but not to CodeMeter Protection Suite. This article shows you in detail why Wibu-Systems is the better choice.

The First Layer: AxProtector

AxProtector wraps around each executable and runtime library of your application as a layer of protection. You define whether you want to encrypt all modules or only specific executables. AxProtector is available as a command line tool and can be integrated without much effort into your automatic build system as part of continuous integration.

The executable file is analyzed and encrypted completely by AxProtector. AxEngine – a runtime component that handles decryption when your application is launched – is added to the executable. The Original Entry Point (OEP) is changed to start AxEngine first when the application is started. If the right license is available, AxEngine accesses that license and uses the key in it to decrypt the executable code in the memory. It is a common misconception that this is not allowed, which comes from the fact that poor implementations in the past produced flawed results. For CodeMeter Protection Suite, this has always been the normal course of operations.

Without the right license, that is, without a fitting key, decryption is impossible. This sets AxProtector apart from simpler protection tools that use a set key and make the question of protection a simple yes-no decision.

AxProtector is available for Windows, Linux, x86/x64/ARM, Android and macOS.

Automatic Anti-Dumping Methods

Simple encryption as described above does not do much to protect against memory dumps. This is why AxProtector and, in particular, the AxEngine anti-debugging and anti-dumping mechanisms are integrated as a second layer of protection.

Encrypting the resources of your application is one starting point: The resource section of your software is kept in encrypted form in the executable. It is not decrypted when the application is started, but remains encrypted. When analyzing your software, AxProtector will pinpoint every instance when it accesses these resources. These are then redirected to AxEngine. Your application can use its resources transparently in the background, but a memory dump would only return encrypted resources that cannot be used without the right key for the right license.

A second mechanism is the identification of common hacking tools, like memory dumping or debugging tools. As soon as these are identified, AxEngine will stop the application from loading before any decryption ever takes place. In general terms, this is a “generic debugger scanner”. AxEngine attaches its own debugger to the application. As an application should normally only have one debugger -attached, this is a very simple, but effective way of preventing debugging. Naturally, this method only works once per process space and should only be activated for the executable and not the runtime libraries.

A third mechanism is offered by static (with AxProtector during encryption) and dynamic (with AxProtector during loading) modifications to the executable. Common patterns, like Windows API function calls, are recognized and modified. This is done in a way that makes it extremely labor intensive for automatic dumping and reverse engineering tools to reverse the process.

Most of these methods are implemented for Windows, which reflects the fact that most hacker tools are also used on Windows systems.

IxProtector for Dynamic Decryption in Runtime

IxProtector is the third layer of protection against memory dumps. You define individual functions that are kept in memory in encrypted form like other resources. You can use WupiDecryptCode and WupiEncryptCode to define yourself when which function would be encrypted and decrypted.

A memory dump would normally only produce a set of encrypted functions in this case. For a genuinely complete and executable hack, the hackers would have to decrypt all functions and piece the puzzle back together manually. By increasing the number of encrypted functions and decrypting them dynamically during runtime, you are effectively increasing the effort for the would-be attacker.

IxProtector is available for Windows, Linux x86/x64/ARM, and macOS.

Traps Preventing Static Analysis

Attackers might try to decrypt all functions manually before attempting a memory dump or after they have access to the dump.

They would need the right license for the functions they are trying to hack. As another unique feature of the CodeMeter universe, different licenses come with different keys. If individual functions are assigned to different licenses, they would also be encrypted with different keys. To crack them, the hackers would need the entire key set.

Even in the unlikely case that this ever happens, IxProtector has a fourth protection mechanism: traps that are set to prevent the systematic decrypting of all functions. You include certain functions in your software that are never called in normal operations. At the start of each function, a special lock code is introduced. If a hacker then randomly decrypts this function (while working his or her way through the entire set), the code locks the license and stops the decryption of the remaining functions until it is allowed again by the developer. This is an effective mechanism, especially for CmDongles.

Translocated Execution for Ultimate Protection

Translocated Execution is the fifth, ultimate layer of protection against memory dumps. In addition to stronger security, Translocated Execution offers automatic features that make the integration of IxProtector simpler than ever.

Translocated Execution is an expansion of IxProtector. In contrast to the standard IxProtector, the functions are not decrypted and executed at their original location, but at a different place in memory. The same location is then used for several other functions, one after the other. This makes the process a confusing and complex puzzle for hackers, as it becomes dramatically more difficult to understand which piece goes where. It is a jigsaw puzzle whose pieces keep swapping places and changing form. On top of all this, the specific location where the decrypted code is handled is one that is ignored by most common dumping tools.

Two options are available for decryption:

Automatic decryption
and Manual decryption

When using automatic decryption, you do not have to worry about decrypting your functions. AxProtector automatically injects the required decryption code at the place of the original function. The function can also be kept in cache for a brief time before it is automatically cleared away. Without this optional caching, the function is immediately removed or overwritten once it has been executed.

For additional control or if the original function is too small, you can decrypt your functions manually with WupiDecryptCode and WupiEncryptCode and remove it from cache, as in the original IxProtector. You can choose the best option for your needs individually for each function.

Translocated Execution is available for Windows, Linux x86/x64, and macOS.

High Level Languages

For high level programming languages like .NET and Java, AxProtector .NET and AxProtector Java offer two specialized tools, designed for these specific use cases. The line between AxProtector and the methods of IxProtector is less sharply defined in this case. Methods, functions, and classes are decrypted dynamically during runtime, and traps can be set. In the case of .NET, the decryption happens automatically at a different location in the memory.

Conclusion

CodeMeter Protection Suite guards your software against memory dumps. IxProtector and Translocated Execution equips you with two powerful methods that are easy to integrate and add more layers of protection around your applications.