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