This error message usually occurs, if the AxProtector components were packed into the JAR archive when building the application or the JAR archive.
Even if, for example, you use Wupi functions and have therefore referenced AxProtector, you must not pack the classes into the JAR archive.
During encryption AxProtector automatically adds the required classes to the specified JAR archive or creates a separate WibuXpm4JRutnime.jar archive containing the required classes when using the AxProtector option '-jos'.
To encrypt Java applications compiled with Java 9 or newer, at least AxProtector version 10.10 is required.
If an older AxProtector Java version is used in conjunction with Java 9, an error (incompatible magic value) occurs.
Only the encryption is affected by this, so there is no need on the user side to update to CodeMeter Runtime 6.60 in order to use encrypted Java 9 applications.
Also, the JVM signature check (option -cag4) is no longer possible with Java 9 due to the new Jigsaw feature.
Instead, we recommend the use of other security mechanisms supported by AxProtector, such as
- Method Extraction
- Encrypt Constants Pool Entries
- Encrypt Method Control Flow
- JVMPI/JVMTI detection
Previous features are still supported compatible for Java versions 6 to 8.
However, an application encrypted with the JVM signature check cannot be started with Java 9. This option must be disabled for use with Java 9 (or OpenJDK).
To fix this problem, the encrypted JAR archive has to be repackaged.
There is an example script that can be adapted to your own application.
Starting with AxProtectorJava 11, scheduled to be release in December 2021, AxProtectorJava will handle this automatically and the workaround is no longer necessary.
The date is set to this value after the encryption to guarantee that several encryptions of the same application are binary identical - otherwise the modification date would be different.
For AxProtector version 10.30a and higher specify:
The cause could be that you are using the Java archive file openejb-javaagent.jar, which is located in the libs directory of TomEE.
This Java archive file in turn loads the instrument.dll library of the Java API. The library installs a JVMTI hook, which is correctly detected by the protected software and leads to this error.
There are the following possible solutions for this:
- First, you should check if you actually need the Java archive file openejb-javaagent.jar. If not, you may be able to do without it and remove it from the libs directory.
- Alternatively, you can also disable the security option "-cag1" (JVMTI detection) during encryption.
The cause of the error is that Java 7 (or lower) is installed on the system.
Since Java 7 is no longer supported by Oracle and AxProtector technology has also evolved, Java 7 for performing encryption is no longer supported.
However, the encrypted application should still be executable with Java 7, if it has been before.
Consequently, this change only affects the software vendor when encrypting and should not affect the end user.
The message "Error: JVMTI SetEventCallBack cannot be used." is displayed because several wibuxpm4j files are loaded into the same process space.
These files try several times to modify the JVM for AxProtector, i.e. to activate a hacking countermeasure. However, these files do not recognize that this has already taken place due to the loading of the library from different paths and therefore run into their own trap.
Please proceed as follows:
Call the encrypted application. Please adjust your proxy information.