Migration de Protector4J v5 vers v6

⚠️ Pour la sécurité de votre code, passez à v6 dès que possible

La rétro-ingénierie assistée par IA abaisse rapidement le seuil d’accès à l’analyse de code. La force de protection de v5 n’est plus suffisante face aux menaces actuelles, et y rester expose votre code à un risque de divulgation plus élevé. Nous vous recommandons vivement de migrer vos applications protégées vers Protector4J v6 dans les meilleurs délais.

1. Pourquoi passer à v6

Les outils d’IA facilitent de plus en plus l’analyse du code et la rétro-ingénierie. L’obscurcissement traditionnel du bytecode et le chiffrement simple ne suffisent plus face aux nouveaux enjeux de sécurité.

Afin de mieux protéger le code Java, nous avons entièrement repensé Protector4J v6. Sa nouvelle architecture P4JX met en œuvre plus d’une centaine de mesures de sécurité couvrant le chiffrement du code, le chargement des classes, la validation à l’exécution, l’anti-débogage et d’autres couches. Même avec des outils d’analyse par IA avancés, la rétro-ingénierie du code protégé reste extrêmement difficile.

Par conséquent, v6 diffère sensiblement de v5 par son architecture de protection, sa configuration, sa syntaxe de ligne de commande et son format de sortie.

2. Principales différences entre v5 et v6

Le changement le plus important est que les fichiers chiffrés, les environnements d’exécution et les fichiers de tâche YAML de v5 ne peuvent pas être réutilisés directement avec v6.

3. Configuration simplifiée avec le mode de compatibilité

Une protection plus forte nécessite davantage de paramètres pour le périmètre de protection, l’environnement d’exécution, la disposition, la compatibilité et les plateformes cibles. Pour éviter d’avoir à comprendre tous ces paramètres dès le départ, v6 propose un mode de compatibilité.

Dans l’interface graphique, utilisez le mode Simple (recommandé) :

1. Sélectionnez le type d’application.
2. Sélectionnez le JAR ou le WAR d’origine.
3. Sélectionnez la version de Java et les plateformes cibles.
4. Laissez Protector4J analyser l’application et choisir automatiquement des paramètres de compatibilité prudents.
5. Confirmez le répertoire de sortie et lancez la protection.

Passez en mode Advanced uniquement si vous devez contrôler précisément le périmètre de protection, la disposition Spring Boot, les options JVM, JavaFX ou d’autres paramètres.

En ligne de commande, utilisez --compat-apply. Cette option analyse l’application, applique des recommandations de compatibilité prudentes, puis génère le paquet protégé :

p4j javaapp app.jar dist --compat-apply

Le mode de compatibilité simplifie la configuration, mais ne remplace pas les tests réels. Après la génération, vérifiez le démarrage, les fonctions principales, la réflexion, la sérialisation, l’accès à la base de données et le comportement des frameworks tiers.

4. La syntaxe de ligne de commande a entièrement changé

La CLI v5 dépend d’un fichier de tâche YAML :

p4j -t java -f java-task.yml

v6 peut fonctionner sans fichier de configuration et recevoir tous les réglages sous forme d’arguments de ligne de commande :

# Application Java standard
p4j javaapp app.jar dist --compat-apply

# Application Spring Boot
p4j springboot app.jar dist --compat-apply

# WAR Tomcat
p4j tomcat app.war dist --compat-apply --context /app

# Bibliothèque Java
p4j encode library.jar library.p4jx

Correspondance des types d’application :

Notez que la commande encode de v6 protège toutes les classes de la bibliothèque et nécessite un VLX JRE pour les charger. Elle ne remplace pas à l’identique le fonctionnement de v5, qui convertissait certaines méthodes en code natif tout en permettant l’utilisation d’un JRE standard.

v6 prend toujours en charge les fichiers de tâche, mais vous devez exporter un nouveau fichier p4j-task.yml depuis l’interface graphique v6 :

p4j --task-file p4j-task.yml

N’essayez pas de modifier et de réutiliser un fichier YAML v5. Les formats de tâche v5 et v6 ne sont pas compatibles. Reconfigurez la tâche dans l’interface graphique ou réécrivez la commande à partir de la documentation CLI la plus récente.

Pour toutes les commandes et options, consultez la référence CLI v6.

5. Migrer de v5 vers v6

Suivez ce parcours de migration unique :

Conserver une sauvegarde v5 → retrouver le JAR/WAR d’origine → régénérer avec le mode de compatibilité v6 → tester → basculer

Étape 1 : conserver l’environnement v5

Conservez le répertoire de sortie v5 fonctionnel et sa procédure de démarrage afin de pouvoir revenir en arrière si nécessaire. N’écrasez pas le répertoire v5.

Étape 2 : préparer l’entrée d’origine

Retrouvez le JAR, le JAR Spring Boot ou le WAR d’origine qui n’a pas été chiffré par v5. Le répertoire vlxlib, les JAR chiffrés et le vlxjre générés par v5 ne peuvent pas servir d’entrée à v6.

Étape 3 : régénérer avec v6

Pour une utilisation interactive, commencez avec le mode Simple de l’interface graphique. Pour l’automatisation, utilisez directement les arguments de ligne de commande avec --compat-apply. Écrivez la sortie dans un nouveau répertoire et ne la mélangez pas aux fichiers v5.

Étape 4 : valider la sortie v6

Démarrez l’application avec le fichier généré run.sh, run.command ou run.bat. Publiez le vlxjre généré avec l’application. Ne le remplacez ni par le JRE du système ni par l’environnement d’exécution d’une autre tâche.

Vérifiez au minimum que :

• l’application démarre et s’arrête normalement ;
• les fonctions métier principales fonctionnent correctement ;
• la réflexion, la sérialisation, l’ORM, les proxys Spring et le chargement des ressources fonctionnent correctement ;
• le paquet a été exécuté sur chaque système d’exploitation cible.

Étape 5 : basculer le paquet complet

Après validation, basculez vers l’intégralité du répertoire de sortie v6. Pour les mises à jour suivantes, régénérez également un paquet complet à partir du JAR ou du WAR d’origine, au lieu d’utiliser la mise à jour partielle v5 KeySeed + onlyEncryptJarFiles.

6. Recommandation de mise à niveau

La rétro-ingénierie assistée par IA abaisse rapidement le seuil d’accès à l’analyse du code. Continuer à utiliser v5 augmente donc le risque de divulgation du code. Pour des raisons de sécurité, nous recommandons de passer de v5 à v6 dès que possible.

Effectuez une migration en parallèle : conservez v5 pour permettre un retour en arrière, générez un nouveau paquet avec le mode de compatibilité v6, validez-le, puis basculez l’environnement de production.

Documentation associée :

• Démarrage rapide v6
• Référence CLI v6
• Compatibilité et périmètre de protection v6
• Archive de la documentation v5