Schutz der Java-Klassenbibliothek

Library Encryption entspricht dem unteren Layer-Kommando encode – es wird lediglich ein geschütztes Archiv erzeugt, weder die Laufzeitumgebung wird kopiert noch ein Anwendungsstartskript erstellt.

1. GUI-Bedienung

  1. Wählen Sie auf der Anwendertyp-Seite Library Encryption aus. Falls ein direkt startbares Lieferpaket gewünscht ist, sollten stattdessen Java Application, Spring Boot oder Tomcat WAR ausgewählt werden.

    Library Encryption auswählen

  2. Wählen Sie die Eingabesource JAR, die Java-Version, die mit der tatsächlichen Laufumgebung übereinstimmt, sowie die Zielplattform aus und entscheiden Sie sich anschließend für den Einfach- oder Fortgeschrittenen Modus. Die ausgehende Klassenbibliothek enthält keine vlxjre-Einträge, doch diese Auswahl dient weiterhin dazu, die zugehörige Laufzeitidentität des Archivs zu bestimmen; vermischen Sie die Ausgaben für verschiedene Plattformen nicht, um die Anzahl der Erzeugnisse zu verringern.

    Wählen Sie die Bibliothek-JAR-Datei, die Java-Version, die Zielplattform und den Modus aus

  3. Im Einfachmodus wird die Eingabesource JAR gescannt, wobei automatisch die vom Library Encryption unterstützten Scanner, ZIP-overlay-Einstellungen sowie Vorschläge für Archivendungen angewendet werden. Alle .class-Einträge in der Eingabesource JAR werden weiterhin verschlüsselt, während andere Ressourcen unverschlüsselt bleiben.

  4. Im Fortgeschrittenen Modus können Einstellungen nach Bedarf vorgenommen werden:

    • Disable JIT for protected methods: Stellt sicher, dass geschützte Methoden nur im Interpreter ausgeführt werden.
    • Append scanner ZIP overlay: Stellt öffentliche Ressourcen sowie Metadaten-Stubs für Tools zur direkten Analyse des zentralen Verzeichnisses eines ZIP-Archivs bereit;
    • Compatibility scan…: Scannt auf Kompatibilitätsrisiken wie ZIP-Zugriff, Annahmen bezüglich Endungen, JNI/Native-Klassen sowie das Lesen von Bytecode zur Laufzeit.

  5. Auf der Ausgabeseite wird der vollständige Dateinamen für die Ausgabe ausgewählt, in der Regel mithilfe von .p4jx; .jar wird nur verwendet, wenn das Integrationsprogramm explizit den Nachnamen .jar erfordert. Die Auswahl oder Scan-Empfehlungen unter Archive suffix auf der fortgeschrittenen Seite synchronisieren den Nachnamen .p4jx/.jar für die ausgewählten Dateien. Überprüfen Sie die Java-Version, die Zielplattform, JIT, scanner overlay und klicken Sie anschließend auf Run protection.

    Einsatzzeiten für einzelne Plattformen verwenden den ausgewählten exakten Dateipfad. Wenn mehrere Zielplattformen ausgewählt werden, erstellt die GUI unterhalb des Verzeichnisses der Datei Unterverzeichnisse nach Plattformen, in denen die entsprechenden Archivdateien gespeichert werden.

2. Anwendbare Szenarien

  • Schutz eigener JARs, die als Bestandteil anderer kontrollierter P4JX-Anwendungen dienen;
  • Ladet das P4JX-Archiv über einen vorhandenen Starter;
  • Erfordert eine eigene Verwaltung des vollständigen Lieferverzeichnisses für fortgeschrittene Integrationen.

Falls das Ziel eine direkt ausführbare gewöhnliche Anwendung, Spring Boot oder Tomcat ist, verwenden Sie die entsprechenden Paketierungs-Befehle.

3. Grundlegende Befehle

p4j encode library.jar library.p4jx

Es können auch Abkürzungen verwendet werden:

p4j library.jar library.p4jx

encode schreibt den vom Benutzer bereitgestellten vollständigen Dateinamen für die Ausgabe; daher sind beide folgenden Fälle im P4JX-Format:

p4j encode library.jar library.p4jx
p4j encode library.jar library.jar

4. ZIP overlay

p4j encode library.jar library.p4jx \
  --zip-overlay scanner

overlay enthält ausschließlich öffentliche Ressourcen, Verzeichnisse sowie Metadaten-Strukturen, um Tools zu unterstützen, die das zentrale Verzeichnis eines ZIP-Archivs direkt analysieren können. Es gibt die tatsächlichen Schutzmechanismen nicht preis und verwandelt P4JX auch nicht in ein gewöhnliches JAR.

5. Laufzeitanforderungen

Die untere Schicht encode erzeugt nicht vlxjre – der Anwender muss daher eine VLX-Laufzeitumgebung bereitstellen, die mit der bei der Kodierung verwendeten Identität übereinstimmt. Vermeiden Sie Folgendes:

  • Das Laden mit herkömmlichen OpenJDK/Oracle JDK.
  • Das Kopieren von lib/modules oder nativen Bibliotheken aus einem Archiv einer anderen Version.
  • Die Mischverwendung von Laufzeitumgebungen unterschiedlicher Zielplattformen, JDK-Trainingslinien oder Kodierungsaufgaben mit den Archiven.

Für normale Lieferprojekte sollte vorzugsweise die obere Paketierungsanweisung verwendet werden, um diese Beziehungen automatisch aufrechtzuerhalten.

6. Lizenz

Bei der Erstellung einer Archivdatei muss eine von dem Server ausgestellte Lizenz erfolgreich abgerufen und eingebettet werden. Offizielle Konten und Testmodi folgen dem gleichen Archivvalidierungsprozess. In automatisierten Umgebungen sollten Passwörter nicht in den exportierten Task-Skripten hardcodet werden.