Frequently Asked Questions

Share:

Java

  • 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'.
  • On encrypting Spring applications Wibu-Systems recommends to customize the following AxProtector options:

    Creating of valid Java class files
    To ensure that Spring on start is properly interpreting your classes and annotations, it is important that AxProtector creates valid Java class files.
    This can be achieved by setting the commandline options -ci and -jff:c. In the AxProtector GUI navigate to the page Advanced Options and check the box controls IxProtector and create valid Java class files.

    Alternative User Message Handler
    If licensing errors occur by default dialogues display the user of the software has to interact with. Since this does not fit for server applications, an alternative User Message Handler exists implementing a different error handling, which does not require user interaction and a graphical user interface.
    For using it you must set the command line option -u:"com.wibu.xpm.MessageHandler".
    In the AxProtector GUI navigate to the page Error messages, check the Box control User message class, and specify the class name com.wibu.xpm.MessageHandler in the respective field.

    Using method encryption
    In some cases, Spring applications may experience problems if the entire class is encrypted. Therefore, it is recommended to use method encryption instead of class encryption.
    1. Export the encryption options as *.xml file.
    in the AxProtector GUI use menu item "File| Export".
    2. Replace in *.xml file:
    <Jar MethodProtectionLicenseList="None" ClassProtectionLicenseList="0" EntryPoint="false" >
    by
    <Jar MethodProtectionLicenseList="0" ClassProtectionLicenseList="None" EntryPoint="true" >
    3. Direct calling of file AxProtector.jar for encryption and transfer of the 
    *.xml Datei.
    e.g..: java -jar AxProtector.jar @protectionSettings.xml
  • 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
    - obfuscation
    - 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.

    Alternative Vorgehensweise:
    For AxProtector version 10.30a and higher specify:
    -jb:60364
  • 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.
    java -Dhttp.proxyHost=proxy.company.local -Dhttp.proxyPort=8080 -jar application.jar

    Alternatively you can download the current WibuVM.jar via your browser: http://wibu.com/files/java/WibuVm.jar.
    You can then store this archive in the Classpath or the /lib/ext directory in your Java installation so that the application can find and load this jar archive.
  • With AxProtector Java 10.20, the encryption of a Java application that contains an 'Index.list' will abort with an error.

    For example, if you were using AxProtector 10.10 and a JAR archive with an 'Index.list', in some cases the manifest was discarded due to a bug in Java. Therefore AxProtector 10.20 will abort the encryption here.

    With the AxProtector release >=10.30 the applications can be encrypted again without errors, even if the Index.list is currently not officially supported.
  • The error 1001 means "FileNotFound".
    It occurred since your WkFirm.wbc file has not been found.

    The WkFirm.wbc file is required for programming licenses and encrypting applications.
    You should have received the file from our sales department when you purchased your Firm Code.

    If you have already successfully encrypted on another system, check if you can find this file there and copy it to the new system.
    This file should usually be located in the following directory:
    C:\Program Files (x86)\WibuKey\DevKit\Bin or C:\Program Files\WibuKey\DevKit\Bin respectively.
To top