PROTECTION
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.
4