Protection des bibliothèques Java

Library Encryption correspond à la commande de niveau inférieur encode : elle ne génère qu’un seul archive protégée, sans copier l’environnement de exécution ni créer de script de démarrage d’application.

1. Opérations GUI

  1. Sélectionnez Library Encryption sur la page du type d’application. Si vous avez besoin d’un paquet livrable pouvant être démarré directement, choisissez plutôt Java Application, Spring Boot ou Tomcat WAR.

    Sélectionner le chiffrement de la bibliothèque

  2. Sélectionnez le JAR d’entrée, la version Java correspondant à l’environnement de chargement réel ainsi que la plateforme cible, puis choisissez le mode simple ou le mode avancé. La sortie des bibliothèques ne contient pas vlxjre, mais ces choix servent néanmoins à déterminer l’identité de l’environnement de exécution associé à l’archive; évitez de mélanger les sorties de différentes plateformes afin de réduire le nombre de produits.

    Sélectionner le JAR de la bibliothèque de classes, la version Java, la plateforme cible et le mode

  3. Le mode simple scanne le JAR d’entrée et applique automatiquement les suggestions de scanner ZIP overlay et d’extension d’archive pris en charge par Library Encryption. Il chiffrera également tous les éléments .class présents dans le JAR d’entrée, tandis que les autres ressources resteront non chiffrées.

  4. Le mode avancé permet de configurer les paramètres selon les besoins:

    • Disable JIT for protected methods: Permet de faire en sorte que les méthodes protégées ne soient exécutées que dans l’interpréteur;
    • Append scanner ZIP overlay: Fournit des ressources publiques et des stubs de métadonnées aux outils qui analysent directement le répertoire central du ZIP;
    • Compatibility scan…: Détecte les risques de compatibilité tels que l’accès au ZIP, les hypothèses sur les extensions, les classes JNI/natives et la lecture du bytecode au moment de l’exécution.

  5. Sur la page de sortie, sélectionnez le nom complet du fichier de sortie, ce qui se fait généralement avec .p4jx ; .jar est utilisé uniquement lorsque l’application intégrée exige explicitement l’extension .jar. Les suggestions de sélection ou de scan sur la page avancée via Archive suffix appliquent automatiquement les extensions .p4jx/.jar au fichier sélectionné. Vérifiez la version Java, la plateforme cible, le JIT, les paramètres scanner overlay, puis cliquez sur Run protection.

    Les tâches monoplateforme utilisent le chemin de fichier exact sélectionné. Lorsque plusieurs plateformes cibles sont choisies, l’interface graphique crée des sous-dossiers par plateforme dans le répertoire contenant le fichier, afin de générer des archivages distincts pour chacune.

2. Scénarios d’application

  • Protéger ses propres JAR qui font partie d’autres applications P4JX gérées.
  • Chargement de l’archive P4JX à l’aide d’un lanceur existant;
  • Intégration avancée nécessitant une gestion manuelle du répertoire de livraison complet.

Si l’objectif est une application ordinaire exécutable directement, Spring Boot ou Tomcat, utilisez les commandes de compilation correspondantes.

3. Commandes de base

p4j encode library.jar library.p4jx

On peut également utiliser des abréviations:

p4j library.jar library.p4jx

encode écrit le nom de fichier de sortie complet fourni par l’utilisateur; par conséquent, les deux cas suivants sont tous deux au format P4JX:

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 ne contient que des ressources publiques, des dossiers et des fichiers métadonnées de base, afin de permettre la compatibilité avec les outils qui analysent directement le répertoire central du ZIP. Il ne révèle pas les vraies méthodes de protection, ni ne transforme P4JX en un JAR ordinaire.

5. Exigences en temps de exécution

Le niveau inférieur encode ne génère pas vlxjre ; l’utilisateur doit fournir un environnement de exécution VLX correspondant à l’identité utilisée lors de l’encodage. Il ne faut pas:

  • Utiliser un OpenJDK/Oracle JDK ordinaire pour le chargement;
  • Copier lib/modules ou les bibliothèques natives à partir d’un paquet issu d’une autre version;
  • Mélanger les environnements de exécution de différentes plateformes cibles, lignes de formation JDK ou tâches d’encodage avec l’archivage.

Pour les projets de livraison ordinaires, il est préférable d’utiliser les commandes d’empaquetage de niveau supérieur pour maintenir automatiquement ces relations.

6. Licence

Il est impératif d’obtenir avec succès une licence émise par le serveur et de l’incorporer lors de la génération de l’archive. Les comptes professionnels et le mode d’essai suivent le même processus de vérification des archives. Dans les environnements automatisés, il ne faut pas coder de manière statique les mots de passe dans les scripts de tâche exportés.