AxProtector Java is the ideal solution to save time and effort when it comes to integrating protection in your Java software. With AxProtector Java, you can protect your software against piracy and reverse engineering in a fully automated fashion.
AxProtector Java is available as a command line tool and can run in continuous integration in an automated build system.
AxProtector Java can hide special CodeMeter commands as honeypot traps in the form of additional methods injected into your code. Any would-be attacker trying to crack all encrypted functions will, at some point, stumble into one of the traps. This would activate the secret command and lock the license – stopping the attacker in his tracks and preventing any further decryption of more functions. On top of these automatically set traps, you can also add your own methods to make for even more alluring honeypots. This clever trick makes AxProtector Java an extremely strong safeguard against the systematic decryption of protected software.
Compared to simple, run-of-the-mill obfuscators, AxProtector Java guarantees a far higher level of security. While standard obfuscation only changes names and scrambles code, AxProtector Java secures the executable code with tough 256-bit AES encryption. This makes it impossible to decompile the protected application on the drive even with the right tools; the code is decrypted in the safe environment of a dongle or a Windows service, making it even harder to reach for would-be attackers than simple obfuscation on the Java level. Without the right license and the right keys, an attacker could not even extract the code from the device’s memory. Hidden traps are set to make the wholescale decryption of all methods impossible in practice: At some point, a trap would be sprung and the license locked, barring the key for any other attempted attacks. But it is not its added security alone that sets AxProtector Java apart from regular obfuscators: As the names of functions do not need to be changed, features like reflection or remoting are available as usual and without having to compromise on security.
AxProtector Java 2nd generation
AxProtector Java 2nd generation represents comprehensive and sophisticated automatic protection for Java SE (J2SE) and Java EE (J2EE) applications. As a software developer, you encrypt classes and methods separately. For performance reasons, it is possible to exclude individual classes and methods.
A security shell, called AxEngine, is added to your Java application. During the first call of your application, an AxEngine method is registered in the runtime environment. This method is executed automatically during the loading of all classes and methods and makes sure that the protected classes and methods are decrypted automatically. AxEngine consists of Java components and native JNI (Java Native Interface) components.
AxProtector Java 1st generation
AxProtector Java 1st generation is still available for compatibility reasons. It encrypts a Java SE (J2SE) application at class level. Every single class is therefore encrypted separately in your Java application. For performance reasons, it is possible to exclude individual classes.
A security shell, called AxEngine, and a wrapper class are added to the Java application. The wrapper is added as the new main class in the application, and is thus executed first. This wrapper class first loads a Wibu class loader, and then the original main class. The Wibu class loader is responsible for the decryption of the protected classes. It uses AxEngine, which consists of Java components and native JNI components.
Security due to usage of JNI
Decryption and most of the security checks are done in the native JNI part of AxEngine. Without a matching license in a CmDongle or a CmActLicense, decryption is not possible. Compared to Java-only solutions, the use of native components increases security significantly. The native components are available for Windows, macOS, and Linux.
AxProtector Java adds state-of-the-art anti-debugging mechanisms to your Java application. The protected application makes sure that it runs in an original Oracle Java virtual machine. A modified or a homegrown virtual machine, which for instance dumps the decrypted classes, would be detected and the decryption of the protected classes would be refused. Debugging interfaces like JVMTI are identified as well.
Usage of CodeMeter API
When compared with the integration of CodeMeter API, AxProtector Java provides a high level of protection with minimal effort. The additional use of CodeMeter API is also possible.
This allows you to further strengthen software protection with the crypto-functions of our API, add data security and protection, and enter specific license queries.
With AxProtector Java, it is possible to encrypt different parts of your Java application using different Product Codes. By creating a license with a subset of all Product Codes, you restrict the usage of your application to the purchased functionality only. When using CodeMeter API, it is also possible to enable or disable graphical elements like buttons or menu entries.
The encryption with different Product Codes offers maximum security. Each Product Code uses a different AES key to encrypt your application. Without a matching Product Code, this key is not available and unauthorized decryption is not possible.
Anti-Reverse Engineering without Licensing
As with any other component of Protection Suite, it is possible to use AxProtector Java 1st and 2nd generation with a Protection-Only License. As a software vendor, you deliver CodeMeter Runtime and a generic license already activated together with your application. The decryption of your application takes place in the native part of CodeMeter Runtime, which improves security standards compared to Java-only solutions.