Paramètres du mode avancé de Protector4J

Le mode avancé permet de déterminer manuellement le périmètre de protection, les options de analyse de compatibilité ainsi que les paramètres spécifiques au type d’application protégée. Lors du traitement d’une nouvelle application pour la première fois, il est recommandé d’utiliser d’abord le mode simple ou de lancer un balayage de compatibilité sur la page des paramètres avancés, puis d’ajuster les paramètres en fonction des résultats du balayage.

Ce document constitue une explication détaillée du mode avancé présent dans Guide d’utilisation de l’interface graphique. Pour déterminer quels types de fichiers doivent rester non chiffrés, consultez Compatibilité et périmètre de protection; pour écrire des commandes automatisées, suivez les indications de Référence des paramètres CLI.

1. Accéder au mode avancé

1. Sélectionner le type d’application protégée et entrer le nom du fichier JAR/WAR.
2. Sélectionner Version Java incluse ainsi qu’au moins une plateforme cible.
3. Sélectionner Advanced — customise the options yourself dans Mode.
4. Cliquez sur Next pour accéder à la page des paramètres avancés.

Si vous êtes déjà sur la page de confirmation de sortie, vous pouvez cliquer sur Customize… pour retourner à la page des paramètres avancés. Une fois les modifications effectuées, revenez sur la page de sortie pour vous assurer que le résumé reflète bien les nouvelles paramétrisations.

La version Java et la plateforme cible ne sont pas modifiables sur la page des paramètres avancés; si des ajustements sont nécessaires, retournez à la page d’entrée. Les tâches multi-plateformes génèrent une sortie indépendante pour chaque plateforme, et les éléments vlxjre ne peuvent pas être interchangeables.

2. Options générales

Les quatre types d’applications partagent la même zone de paramètres avancés, mais certains paramètres s’appliquent en fonction du type. Library Encryption ne génère pas de script de démarrage, par conséquent aucun paramètre de démarrage JVM n’est utilisé; sa configuration de suffixe d’archive est utilisée pour suggérer et synchroniser les noms de fichiers de sortie.

Les paramètres spécifiques réellement utilisés pour chaque type d’application sont les suivants:

“Il n’est pas exclu cette catégorie” signifie que, par défaut, toute la catégorie d’applications de ce type fait l’objet d’une protection, mais cela ne concerne pas non plus les dépendances tierces. BOOT-INF/lib pour Spring Boot et WEB-INF/lib pour Tomcat restent par défaut en mode normal.

Suffixe d’archivage

Le choix de jar ne modifie que le nom du fichier; son contenu reste au format P4JX. Il ne peut être modifié avec des outils ZIP/JAR ordinaires, ni chargé par un JRE standard. Pour Library Encryption, cette configuration change le suffixe du fichier de sortie en .p4jx/.jar ; si l’utilisateur a spécifié un autre suffixe personnalisé, le nom complet du fichier est conservé.

CLI correspondant:

--archive-suffix p4jx
--archive-suffix jar

Interdiction de la protection des méthodes JIT

L’activation de Disable JIT for protected methods empêche les méthodes protégées d’être compilées par le compilateur JIT, ce qui réduit la surface d’exposition du code machine généré, mais les codes à forte intensité de calcul peuvent ralentir de manière significative. Cette configuration ne concerne que les méthodes protégées et ne passe pas l’ensemble du JVM en mode pure interprétation.

CLI correspondant:

--no-jit

Surcouche ZIP du scanneur

overlay ne expose que des métadonnées relatives aux ressources publiques, aux dossiers et aux classes de protection, sans inclure le corps réel des méthodes. Il est utilisé pour être compatible avec les outils qui lisent directement le répertoire central d’un ZIP, mais il ne peut pas remplacer le layout Spring Boot fat, ni résoudre les problèmes liés à l’analyse d’archives à partir de flux mémoire utilisant ZipInputStream/JarInputStream.

CLI correspondant:

--zip-overlay scanner

Paramètres de démarrage du JVM

Saisissez un paramètre complet par ligne, par exemple:

-Xms512m
-Xmx2g
-Dfile.encoding=UTF-8

Chaque ligne représente une limite de paramètre; ne mettez pas plusieurs paramètres sur la même ligne. Les paramètres seront ajoutés aux scripts de démarrage pour macOS/Linux et Windows; les paramètres de Tomcat seront également intégrés à son chemin de démarrage. La fonction Library Encryption ne génère pas de script de démarrage, par conséquent la case de saisie est indisponible. Pour des exemples plus complets par plateforme, consultez Configuration des paramètres de démarrage de la JVM.

L’option correspondante du CLI doit être réutilisée:

--jvm-option -Xms512m --jvm-option -Xmx2g

3. Vérification de compatibilité et recommandations pour les applications

Pour les quatre types d’applications, vous pouvez cliquer sur Compatibility scan… pour scanner les entrées actuelles. Lors de l’acceptation des résultats, l’outil intégrera les recommandations pertinentes pour ce type d’application dans les paramètres actuels, notamment:

• Ajout de classes qui doivent rester non chiffrées;
• Activation du surcouche ZIP du scanneur;
• Ajustement du suffixe d’archivage;
• Activation de JavaFX/WebView pour les applications Java ou Spring Boot;
• Sélection du layout pour Spring Boot;
• Sélection de 9 ou 10.1 pour Tomcat.

La fonction « Library Encryption » n’applique automatiquement que les suggestions de surcouche ZIP du scanneur et de suffixe d’archivage. Conçue pour protéger toutes les classes présentes dans le JAR d’entrée, elle ne prend pas en charge l’exclusion de classes; si le scan révèle des éléments tels que des classes JNI/natives qui doivent rester non chiffrés, le rapport indiquera clairement qu’il faut les placer dans un JAR ordinaire ou utiliser un mode d’emballage d’application prenant en charge une protection sélective.

Il est possible de continuer à modifier les paramètres après avoir accepté les suggestions. Le scan conservera les règles d’exclusion existantes et ne désactivera pas automatiquement JavaFX, même en l’absence de détection de ce dernier. Annuler la boîte de dialogue signifie ne pas appliquer les suggestions.

Les risques au niveau du code identifiés dans le rapport de scan, tels que les agents, JNI, les chargeurs de classes personnalisés ou la modification du bytecode en temps de exécution, ne peuvent généralement pas être résolus simplement en activant un interrupteur. Il est nécessaire d’ajuster les limites du code selon Compatibilité et périmètre de protection et de procéder à des tests pratiques.

4. Paramètres de l’application Java

Main class

Lire le Main-Class présent dans le manifest du JAR d’entrée si cette case est laissée vide. Seul le nom de classe complet doit être indiqué lorsque le manifest ne contient pas de classe principale ou lorsqu’il est nécessaire de remplacer la classe de démarrage par défaut, par exemple com.example.Main.

CLI correspondant: --main com.example.Main.

Classes to exclude

Toutes les classes de l’application sont protégées par défaut. Les classes ou packages figurant dans cette liste restent non chiffrés; ils conviennent aux DTO, entités, classes de configuration, classes de pontage JNI, ainsi qu’aux classes qui nécessitent des améliorations de la part du framework ou la lecture du bytecode réel. Le format des règles est décrit dans “Périmètre de protection et règles d’exclusion”.

JavaFX runtime

Pour les applications JavaFX ordinaires, cocher Bundle JavaFX into the packaged runtime. Pour WebView, plusieurs options sont disponibles:

• Auto: à inclure en cas de détection de javafx.scene.web ;
• Include: inclusion obligatoire de fx-webkit ;
• Exclude: à exclure obligatoirement.

WebView ajoute environ 40 MB. La GUI télécharge les ressources en fonction de la version Java et de la plateforme cibles; utilisez la CLI lorsque vous devez spécifier un répertoire JavaFX local hors ligne.

CLI correspondants: --javafx, --javafx-webview et --no-javafx-webview. Auto n’ajoute pas d’option obligatoire pour WebView; le packager en décide en fonction des références de l’application.

5. Paramètres Spring Boot

Main class

Lire Start-Class en laissant ce champ vide pour lire le Manifest. Saisir le nom complet de la classe si vous souhaitez remplacer la classe de démarrage.

CLI correspondant: --main com.example.Application.

Layout

Si l’analyse de compatibilité recommande explicitement fat, ne forcez pas l’utilisation de p4jx-fat après avoir activé uniquement le ZIP overlay. Pour plus de détails sur la configuration, consultez Assurer la protection des applications Spring Boot.

CLI correspondante: --layout p4jx-fat, --layout fat ou --layout separate.

Protect dependency JARs…

Les dépendances présentes dans BOOT-INF/lib ne sont pas protégées par défaut. Seules les dépendances propriétaires propriétaires doivent être cochées; ne chiffrez pas les paquets de frameworks tiers tels que Spring, Tomcat, les outils de journalisation ou les drivers de base de données. Les JAR signés apparaîtront comme non sélectionnables, car toute modification endommagerait leur signature.

Lorsqu’une dépendance est cochée, toutes ses classes sont protégées, mais les règles Classes to exclude permettent néanmoins d’exclure certaines classes ou packages spécifiques pour cette dépendance. Les trois configurations Spring Boot prennent en charge la protection des dépendances.

CLI correspondante: --protect-lib 'company-core.jar,company-domain.jar'. La CLI prend également en charge les expressions globales; la GUI enregistre le nom exact du fichier du JAR sélectionné.

Classes à exclure et JavaFX

L’utilisation est identique à celle d’une application Java. Les règles d’exclusion s’appliquent à la fois aux classes de l’application et aux JAR dépendants sélectionnés pour être protégés. Les applications de bureau Spring Boot + JavaFX peuvent également avoir JavaFX/WebView empaquetés dans l’onglet JavaFX runtime.

6. Paramètres Tomcat

Tomcat version

• Utilisez javax.servlet.* pour choisir Tomcat 9 · javax;
• Utilisez jakarta.servlet.* pour choisir Tomcat 10.1 · jakarta.

Tomcat 10.1 nécessite au moins Java 11. Si vous n’êtes pas sûr, effectuez une analyse de compatibilité; si l’application utilise à la fois javax et jakarta, ne choisissez pas de version de force, mais corrigez d’abord les conflits de dépendances.

Le mode avancé ne propose aucune version prédéfinie; il est nécessaire d’accepter les recommandations de l’analyse ou de choisir manuellement avant de passer à l’étape suivante. CLI correspondante: --tomcat-version 9 ou --tomcat-version 10 ; la CLI permet également auto.

Context path

Saisissez le chemin de déploiement commençant par /, par exemple /app. S’il est laissé vide, /app sera utilisé. Lorsque vous ajoutez une application dans le répertoire de sortie existant de Tomcat, le context path ne doit pas coïncider avec celui d’une application existante.

CLI correspondant: --context /app.

Classes to exclude

La protection par défaut s’applique aux classes sous WEB-INF/classes, tandis que WEB-INF/lib reste par défaut non protégé. En général, il convient d’exclure les Servlet, Filter, Listener, DTO, fichiers de configuration, entités, classes de pontage JNI ainsi que les classes nécessitant des améliorations du conteneur.

7. Champ de protection et règles d’exclusion

Le mode avancé de l’interface graphique assure par défaut la protection de toutes les classes d’applications, en laissant définir les limites du cadre grâce à Classes to exclude. Trois types de règles sont pris en charge:

com.example.SecretService   Seule cette classe est prise en compte.
com.example.service.*       Le package actuel est pris en compte, sans les sous-packages.
com.example.service.**      Le package actuel ainsi que tous ses sous-packages sont pris en compte.

Il est possible de sélectionner depuis l’arbre des classes à l’aide de Choose…, ou d’ajouter manuellement des éléments via Add…. La sélection des packages couvre par défaut le package actuel ainsi que ses sous-packages; pour n’exclure que le package actuel, utilisez .*. L’arbre des classes de Spring Boot affiche également les JAR de dépendances déjà sélectionnés pour la protection.

La structure recommandée est “Frontière publique/entrée du framework → Facade ordinaire ou interface → Implémentation centrale protégée”. Évitez de chiffrer toutes les dépendances tierces ou les points d’entrée des frameworks afin d’élargir le périmètre de protection.

8. Exportation, réutilisation et vérification finale

En cliquant sur Export parameters…, il est possible d’exporter:

• p4j-encrypt-run.sh
• p4j-encrypt-run.bat

Le script d’exportation enregistre les options actuellement analysées, mais ne stocke ni l’adresse e-mail ni le mot de passe du compte. Il est ensuite possible de restaurer la tâche à l’aide de Load Task File en haut de l’interface.

Une fois sur la page de sortie, vérifiez au moins les éléments suivants:

• Saisissez le fichier d’entrée, le type d’application, la version Java et toutes les plateformes cibles;
• Suffixes d’archivage, paramètres JIT, éléments d’overlay du scanner et paramètres JVM;
• JavaFX/WebView, configuration de layout Spring Boot ou version/contexte de Tomcat;
• JAR dépendants protégés ainsi que toutes les règles d’exclusion;
• Dossier de sortie et indication de la création d’un sous-dossier p4jx-xxxx.

Après génération, il est nécessaire d’utiliser des scripts de démarrage intégrés à chaque plateforme cible pour vérifier le démarrage, le balayage du framework, la sérialisation, le reflection, le chargement des ressources et les chemins métier essentiels. Une configuration correcte de la page des paramètres avancés ne prouve que les paramètres de la tâche ont été définis, mais ne remplace pas la vérification du produit final.