Häufig gestellte Fragen
Teilen:
Java
- Diese Fehlermeldung tritt normalerweise auf, wenn beim Bauen der Anwendung bzw. des JAR-Archives die AxProtector-Komponenten mit in das JAR-Archiv gepackt wurden.
Auch wenn Sie z.B. Wupi-Funktionen verwenden und daher AxProtector referenziert haben, dürfen Sie die Klassen nicht in das JAR-Archiv packen.
Beim Verschlüsseln fügt AxProtector die benötigten Klassen automatisch zum angegebenen JAR-Archiv hinzu bzw. erzeugt bei Verwendung der AxProtector-Option '–jos' ein separates WibuXpm4JRutnime.jar-Archiv, das die benötigten Klassen enthält. - Beim Verschlüsseln von Spring-Anwendungen empfiehlt Wibu-Systems, die folgende Anpassungen an AxProtector-Optionen vorzunehmen:
Erstellen gültiger Java Klassen-Dateien
Damit Spring beim Start ihre Klassen und Annotations korrekt einlesen kann, ist es wichtig, dass AxProtector valide Java Classfiles erstellt.
Dies kann erreicht werden, indem Sie die Kommandozeilen-Optionen -ci und -jff:c setzen.
In der AxProtector GUI müssen Sie dafür auf der Seite Erweiterte Optionen die Optionen IxProtector und Erstellen gültiger Java Klassen-Dateien ankreuzen.
Alternativer User Message Handler
Wenn Lizenzierungsfehler auftreten, werden standardmäßig Dialoge angezeigt, mit der der Nutzer der Software interagieren muss.
Da dies für Server-Anwendungen ein ungeeignetes Verhalten ist, gibt es einen alternativen UserMessage Handler, der ein andere Fehlerhandling implementiert, das keine Nutzerinteraktion oder grafische Oberfläche erfordert.
Diesen können Sie benutzen, indem Sie die Kommandozeilen-Option -u:"com.wibu.xpm.MessageHandler" setzen.
In der AxProtector GUI können Sie dies auf der Seite Fehlermeldungen tun, indem Sie die Option User message Klasse ankreuzen und den Klassen-Namen com.wibu.xpm.MessageHandler angeben.
Verwendung der Methoden-Verschlüsselung
In manchen Fällen kann es bei Spring-Anwendungen zu Problemen kommen, wenn die gesamte Klasse verschlüsselt ist. Daher empfiehlt es sich anstatt der Klassen-Verschlüsselung nur die Methoden-Verschlüsselung zu verwenden.
1. Exportieren der Verschlüsselungsoptionen als *.xml Datei.
In der AxProtector GUI über den Menüeintrag "Datei | Exportieren".
2. Ersetzen in der *.xml Datei:
<Jar MethodProtectionLicenseList="None" ClassProtectionLicenseList="0" EntryPoint="false" >
durch
<Jar MethodProtectionLicenseList="0" ClassProtectionLicenseList="None" EntryPoint="true" >
3. Direktes Aufrufen der Datei AxProtector.jar zur Verschlüsselung und Übergeben der *.xml Datei.
z.B.: java -jar AxProtector.jar @protectionSettings.xml - Um Java-Applikationen zu verschlüsseln, die mit Java 9 oder neuer kompiliert wurden, wird mindestens AxProtector-Version 10.10 benötigt.
Wird eine ältere AxProtector Java-Version in Verbindung mit Java 9 verwendet, kommt es zu einem Fehler (incompatible magic value).
Hiervon betroffen ist nur die Verschlüsselung, es muss also auf Anwender-Seite keine Aktualisierung auf die CodeMeter Runtime 6.60 erfolgen, um verschlüsselte Java 9-Applikationen zu verwenden.
Ebenfalls ist mit Java 9 die JVM-Signaturprüfung (Option -cag4) aufgrund des neuen Jigsaw-Features nicht mehr möglich.
Stattdessen empfehlen wir den Einsatz der anderen, von AxProtector unterstützten Sicherheitsmechanismen, wie z.B.:
- Methodenextraktion
- Konstanten-Pool-Einträge verschlüsseln
- Methoden-Kontrollfluss verschlüsseln
- Obfuskierung
- JVMPI/JVMTI-Erkennung
Bisherige Feature werden weiterhin kompatibel für Java Versionen 6 bis 8 unterstützt.
Eine Applikation, die mit der JVM-Signaturprüfung verschlüsselt wurde, kann mit Java 9 aber nicht gestartet werden. Für einen Einsatz unter Java 9 (oder OpenJDK) muss diese Option abgeschaltet werden. - Das Datum wird nach der Verschlüsselung auf diesen Wert gesetzt, um zu garantieren, dass auch mehrere Verschlüsselungen der gleichen Anwendung binär identisch sind - andernfalls würde sich das Änderungsdatum unterscheiden.
Workaround:
Ab AxProtector Version 10.30a
-jb:60364 - Ursache könnte sein, dass Sie die Java-Archivdatei openejb-javaagent.jar verwenden, die im libs-Verzeichnis von TomEE liegt.
Diese Java-Archivdatei wiederum lädt die Bibliothek instrument.dll der Java-API. Die Bibliothek installiert einen JVMTI Hook, der von der geschützten Software richtigerweise erkannt wird und zu diesem Fehler führt.
Es gibt dafür die folgenden Lösungsmöglichkeiten:
- Zunächst sollten Sie prüfen, ob Sie die Java-Archivdatei openejb-javaagent.jar tatsächlich benötigen. Falls nicht, können Sie eventuell auf diese verzichten und aus dem libs-Verzeichnis entfernen.
- Alternativ können Sie auch die Sicherheitsoption "-cag1" (JVMTI Erkennung) bei der Verschlüsselung deaktivieren. - Die Ursache des Fehlers ist, dass auf dem System Java 7 (oder niedriger) installiert ist.
Da Java 7 nicht mehr weiter von Oracle unterstützt wird und die AxProtector-Technologie sich ebenfalls weiter entwickelt hat, wird Java 7 zum Durchführen der Verschlüsselung nicht mehr unterstützt.
Die verschlüsselte Anwendung sollte jedoch weiterhin mit Java 7 ausführbar sein, wenn sie dies vorher war.
Diese Änderung betrifft folglich nur den Softwarehersteller beim Verschlüsseln und sollte kein Auswirkungen auf den Endanwender haben. - Bitte gehen Sie wie folgt vor:
Aufrufen der verschlüsselten Anwendung. Bitte passen Sie Ihre Proxy Informationen an.
java -Dhttp.proxyHost=proxy.company.local -Dhttp.proxyPort=8080 -jar application.jar
Alternativ können Sie sich über ihren Browser die aktuelle WibuVM.jar herunterladen: http://wibu.com/files/java/WibuVm.jar.
Dieses Archiv können Sie dann im Classpath bzw. dem /lib/ext-Verzeichnis in ihrer Java-Installation hinterlegen, damit die Anwendung dieses Jar-Archiv finden und laden kann. - Um diesen Fehler zu beheben, muss aktuell das verschlüsselte JAR-Archiv neu verpackt werden.
Dafür gibt es ein Beispiel-Skript, dass an die eigene Anwendung angepasst werden kann.
Ab AxProtectorJava Version 11, die für Dezember 2021 geplant ist, wird dies korrekt vom AxProtectorJava gehandelt und der Workaround ist nicht mehr nötig. - Die Meldung "Error: JVMTI SetEventCallBack cannot be used." erscheint, weil mehrere wibuxpm4j-Dateien in den gleichen Prozessraum geladen werden.
Diese Dateien versuchen mehrfach, die JVM für AxProtector zu modifizieren, d.h. genauer gesagt, eine Hacking-Gegenmaßnahme zu aktivieren. Diese Dateien erkennen aber aufgrund des Ladens der Bibliothek von unterschiedlichen Pfaden aus nicht, dass dies eigentlich schon stattgefunden hat und laufen somit in die eigene Falle. - Mit AxProtector Java 10.20 wird die Verschlüsselung einer Java-Anwendung, die eine 'Index.list' enthält, mit einem Fehler abbrechen.
Aufgrund eines Fehlers in Java gab es Fälle, bei denen nach der Verschlüsselung mit AxProtector Java das Manifest verworfen wurde.
Daher wurde mit AxProtector Java 10.20 eine Änderung eingebaut, dass die Verschlüsselung mit einer Index.list in nicht durchgeführt werden kann um diesen Fall abzufangen.
Mit AxProtector Version 10.30 und neuer wird nun nur noch eine Warnung angezeigt, die Verschlüsselung wird aber fortgesetzt, auch wenn die Index.list derzeit nicht offiziell unterstützt wird. - Der Fehler 1001 bedeutet "FileNotFound".
Dieser tritt auf, da ihre WkFirm.wbc-Datei nicht gefunden wird.
Die WkFirm.wbc-Datei wird zum Programmieren von Lizenzen und Verschlüsseln von Anwendungen benötigt.
Die Datei sollten Sie von unserem Vertrieb beim Kauf Ihres Firm Code bekommen haben.
Wenn Sie vorher bereits auf einem anderen System erfolgreich verschlüsselt haben, schauen Sie dort nach, ob Sie diese Datei dort finden und kopieren sie auf das neue System.
Diese Datei sollte normalerweise in folgendem Verzeichnis liegen:
C:\Program Files (x86)\WibuKey\DevKit\Bin bzw. C:\Program Files\WibuKey\DevKit\Bin