Journal des modifications

6.0.12 2026-08-02

Prise en charge de JxBrowser 9 et correction d'un plantage des applications protégées qui lèvent une NullPointerException

• Les applications protégées peuvent désormais intégrer JxBrowser 9. --native-compat jxbrowser sélectionne l'une des neuf versions du catalogue intégré, de 9.0.0 à 9.3.1, sur sept plateformes avec Java 17, 21 et 25. L'environnement d'exécution n'accorde l'autorisation d'attachement de thread qu'à la bibliothèque IPC officielle dont le SHA-256 est enregistré pour la version choisie, et vérifie à nouveau le module appelant au moment où un thread s'attache réellement. Les chemins, empreintes et noms de bibliothèque ne sont jamais acceptés depuis la ligne de commande. Sous macOS 26, utilisez JxBrowser 9.0.1 ou une version ultérieure : TeamDev y a corrigé un plantage de Chromium à la création du moteur, et 9.0.0 plante également sur un JDK ordinaire.
• Correction d'une ClassFormatError dans les applications protégées qui lèvent une NullPointerException. Le correctif de 6.0.9 supprimait le message NPE détaillé de la JVM méthode par méthode, ce qui s'est révélé insuffisant : cette fonction analyse le corps des méthodes comme du bytecode standard, et une fois que P4JX les a transformées, aucun indicateur par méthode ne peut garantir que cette analyse reste valide. L'environnement d'exécution désactive désormais ce message de manière inconditionnelle. Le type d'exception, la pile d'appels et tout message fourni par l'application restent inchangés. Les environnements d'exécution JDK 17, 21 et 25 sont reconstruits en VLX 1.0.20 ; JDK 11 n'est pas concerné et reste en VLX 1.0.18, JDK 8 reste en VLX 1.0.12.
• java -version indique maintenant la version de l'environnement d'exécution VLX, ce qui permet d'identifier l'environnement fourni sans le décompresser.
• Les deux champs de version de l'EXE Windows sont désormais validés avant le début de l'empaquetage, au lieu d'échouer en cours de route. Windows stocke chaque composant sous forme d'entier non signé sur 16 bits : chacun des un à quatre nombres séparés par des points doit donc être compris entre 0 et 65535. Laisser les champs vides signifie toujours 0.0.0.0.

6.0.11 2026-07-27

Lanceurs Windows natifs pour les applications protégées

• Ajout de la génération facultative d'EXE Windows natifs pour les packages Java App, les trois dispositions Spring Boot et les packages Tomcat. Des lanceurs console et GUI sont disponibles pour Windows x64, x86 et ARM64, tandis que les scripts de lancement existants restent présents dans chaque package.
• Ajout de réglages CLI et graphiques pour le nom du fichier EXE, le mode, l'icône et les métadonnées de version Windows. Les tâches multiplateformes ne génèrent un EXE que pour les cibles Windows sélectionnées, et les réglages sont conservés dans la version 2 de p4j-task.yml ; les fichiers de tâches de version 1 restent lisibles.
• Intégration du lanceur JExeKit entièrement Win32 avec le vlxjre fourni, le classpath exact et les arguments JVM. Avant de démarrer Java, les lanceurs refusent les chemins sortant du package, les substitutions par points d'analyse et les options non sûres d'agent ou de boot classpath.
• Les modèles JExeKit sont intégrés uniquement sous forme de ressources .jxt chiffrées par AES-GCM et ne sont déchiffrés qu'en mémoire lors de la génération. Chaque lanceur généré porte une signature Ed25519 de statut production sur son bloc de paramètres ; les modifications de l'icône, de la version, du manifeste et des paramètres sont terminées avant la signature Authenticode finale de l'utilisateur.

6.0.10 2026-07-27

Chargement plus rapide des dépendances Tomcat sans modifier la structure du WAR

• Correction de forts ralentissements au démarrage de Tomcat dus à la relecture et au calcul du hachage de l'intégralité d'un JAR imbriqué protégé sous WEB-INF/lib à chaque chargement de classe. VLX 1.0.17 vérifie désormais une seule fois chaque JAR imbriqué scellé, met en cache sa provenance authentifiée dans la VM et continue de valider chaque classe demandée par rapport à l'index de classes chiffré.
• Suppression de la solution provisoire qui extrayait et montait web-libs. Les fichiers WEB-INF/lib/*.jar restent dans l'archive .p4jx protégée, ce qui préserve la structure WAR d'origine et l'isolation des applications. Les runtimes VLX 1.0.17 pour JDK 11, 17, 21 et 25 sont publiés pour 24 combinaisons de plateformes prises en charge. JDK 8 conserve son chemin ZIP overlay existant et reste sur VLX 1.0.11.
• Correction de l'analyse de compatibilité du fichier module-info.class de l'application. Les descripteurs de module ne contiennent aucun corps de méthode ; ils sont donc automatiquement exclus du chiffrement tout en restant lisibles par les outils d'analyse de descripteurs.
• Les commandes CLI exportées par l'interface graphique peuvent désormais placer --java-version, --target-platform et --create-new-folder après les arguments du packager sous la forme d'un suffixe continu. La forme préfixée existante reste prise en charge.

6.0.9 2026-07-25

Correction d'un plantage pour les applications chiffrées affichant des NullPointerException

• Correction d'un plantage de la JVM pouvant survenir lorsqu'une méthode protégée levait une NullPointerException implicite et que l'application lisait son message ou affichait sa trace de pile. La fonction de « détail NPE utile » du runtime tentait de reconstruire le texte « because ... is null » à partir du bytecode chiffré de la méthode, accédait à une mémoire invalide et faisait planter la VM (observé avec des applications JavaFX FXML). Les méthodes protégées ignorent désormais ce message détaillé et reviennent à une NullPointerException standard ; le type d'exception, la trace de pile et tout message fourni par l'application ne sont pas affectés.
• Les runtimes pour JDK 17, 21 et 25 sont reconstruits en VLX 1.0.16 avec cette correction. JDK 11 n'est pas concerné car la fonction de NPE utile n'existe pas avant JDK 14 et reste en VLX 1.0.15 ; JDK 8 reste en VLX 1.0.11.

6.0.8 2026-07-24

Runtimes Tomcat téléchargés à la demande et valeurs par défaut sûres pour la production

• Correction de l'échec de l'encodeur autoprotégé publié lors de l'empaquetage des WAR Tomcat, car les classes Tomcat contenues dans app.p4jx n'étaient plus visibles comme un JAR physique du classpath. Tomcat 9.0.107 et 10.1.53 sont désormais des artefacts R2/COS immuables et versionnés, sélectionnés selon l'espace de noms Servlet, téléchargés à la première utilisation, mis en cache localement et vérifiés par rapport à un SHA-256 exact et au manifeste des JAR. Les caches altérés sont supprimés puis téléchargés de nouveau.
• Les JAR publics de WEB-INF/lib sont désormais déployés comme ressources Web physiques, isolées par application et liées par hachage. Spring n'a ainsi plus à relire et vérifier l'archive imbriquée pour chaque classe au démarrage.
• Les nouvelles compilations utilisent désormais par défaut le point de terminaison de licence de production https://protector4j.com. Le point de terminaison interne http://10.10.10.16:16002 n'est utilisé que si P4JX_LICENSE_MODE=dev ou -PlicenseMode=dev est explicitement sélectionné.

6.0.7 2026-07-24

Dépendances Tomcat imbriquées et classes dynamiques fiables

• Correction des échecs des WAR Tomcat protégés lors du chargement de classes ou de services depuis WEB-INF/lib/*.jar. Protector4J scelle désormais dans app.p4jx les métadonnées SHA-256 exactes des JAR et des classes imbriqués ; les dépendances inconnues, remplacées ou altérées restent rejetées.
• Correction des échecs de Spring CGLIB et Hibernate Byte Buddy sous JDK 11, causés par l'utilisation d'un marqueur de source propre à JDK 11 par MethodHandles.Lookup#defineClass. La confiance dynamique exige toujours une provenance de classe appelante ou de chargeur vérifiée par la VM ; les chaînes de marqueur, noms de classes, chemins, packages et CodeSource n'accordent aucune confiance.
• Publication des runtimes VLX 1.0.15 pour JDK 11, 17, 21 et 25 sur 24 combinaisons de plateformes prises en charge. Tous ont réussi les contrôles stricts L1-L5, notamment FXML réel, Swing/AWT, le chargement de dépendances Tomcat imbriquées et les cas négatifs de provenance et d'altération. JDK 8 reste en VLX 1.0.11.

6.0.6 2026-07-22

Provenance fiable des définitions de classes

• Correction des échecs de démarrage des applications JavaFX FXML protégées : MethodUtil définit son auxiliaire Trampoline, dont la provenance a été vérifiée par la VM, via defineClass(byte[]). La confiance ne se propage désormais qu'à partir de la provenance de classe ou de chargeur vérifiée par la VM, et non depuis les noms de classes, les chemins, les packages ou les chaînes CodeSource.
• Ajout d'une couverture FXML réelle avec fx:controller, éléments de propriété, injection du Controller et démarrage de WebView, ainsi que des régressions pour les définitions dynamiques fiables, la propagation à deux niveaux, les sources inconnues, les JAR non autorisés et le remplacement de noms protected class.
• Publication des runtimes VLX 1.0.14 pour JDK 11, 17, 21 et 25. JDK 8 reste en VLX 1.0.11.

6.0.5 2026-07-21

Intégrité de l'environnement d'exécution natif JavaFX

• Correction des échecs de démarrage de JavaFX WebView sous Windows (Graphics Device initialization failed / No toolkit found) en plaçant les DLL JavaFX empaquetées dans vlxjre/bin et en alignant la recherche de bibliothèques natives du lanceur.
• La liste d'autorisation chiffrée dans app.p4jx couvre désormais les bibliothèques natives externes. Les fichiers natifs JavaFX doivent correspondre aux valeurs SHA-256 exactes, quel que soit leur chemin, et Glass revérifie le fichier réellement chargé ; les fichiers inconnus ou altérés sont rejetés.
• Publication de nouveaux environnements d'exécution Protector4J pour JDK 11, 17, 21 et 25. Les combinaisons de plateformes JavaFX prises en charge ont réussi L5.1-L5.4, qui couvrent le démarrage de WebView et le rejet des modules JAR, de jdk.jsobject et des bibliothèques natives Glass altérés.

6.0.4 2026-07-21

Intégrité des modules externes et compatibilité du runtime JavaFX

• La confiance basée sur le chemin pour les modules externes a été supprimée. Chaque JAR de module externe doit désormais correspondre exactement à une entrée SHA-256 de la liste d’autorisation intégrée dans app.p4jx ; les fichiers non reconnus ou altérés sont rejetés quel que soit leur emplacement.
• La détection automatique de la fermeture des dépendances à partir de JavaFX module-info.class et l’admission contrôlée des modules JavaFX et JDK épinglés ont été ajoutées, notamment javafx.media et jdk.jsobject.
• Les problèmes de démarrage de JavaFX WebView ainsi que les erreurs E818 / ClassFormatError après la création de la couche de démarrage ont été corrigés sur les versions JDK et plateformes prises en charge grâce aux nouveaux runtimes P4JX.

6.0.3 2026-07-20

Compatibilité du module JavaFX WebView

• Correction de la résolution du module facultatif jdk.jsobject pour les runtimes P4JX pris en charge et reconstruits à partir de la même version JDK/VLX. Un runtime compatible n’est plus rejeté uniquement parce que l’image complète lib/modules contient des octets différents.
• La sélection des artefacts par série JDK et plateforme, la validation exacte du SHA-256 et du nom du module, ainsi que la revérification des dépendances après l’installation sont conservées.

6.0.2 2026-07-20

Compatibilité JavaFX WebView

• Correction des échecs de démarrage de JavaFX WebView en regroupant javafx.media avec javafx.web et en résolvant automatiquement le module jdk.jsobject correspondant exactement à P4JX lorsqu’il est absent d’un runtime allégé.
• Ajout du téléchargement de modules facultatifs, épinglés par SHA-256 et liés à la version, à la plateforme et au runtime, depuis le service public régional. Les runtimes qui contiennent déjà le module ignorent le téléchargement.

6.0.1 2026-07-20

Compatibilité JavaFX

• Correction des échecs de démarrage des fat JAR qui intègrent des classes du runtime JavaFX. L’application automatique des règles de compatibilité laisse désormais non chiffrés les espaces de noms de l’API, de l’implémentation et du pont JNI JavaFX intégrés, évitant ainsi une double attribution avec les modules JavaFX fournis.
• Amélioration des diagnostics de compatibilité et des conseils multilingues pour les applications intégrant un runtime JavaFX.

6.0.0 2026-07-20

Protector4J 6.0 est une version majeure reposant sur une architecture de protection entièrement repensée, et non une simple mise à jour incrémentale de la série 5.x.

Architecture et protection

• Refonte de l’architecture fondamentale de Protector4J et introduction du nouveau moteur de protection P4JX.
• Ajout de près de 100 mesures de protection couvrant la génération des archives, le chargement des classes, l’exécution, l’anti-débogage et l’intégrité des artefacts.
• Renforcement considérable de la résistance à la rétro-ingénierie. La nouvelle architecture vise à rendre le piratage à court terme extrêmement difficile, même avec des outils avancés d’analyse assistée par IA.
• Renforcement des demandes de licence, des téléchargements de runtimes, de la vérification des artefacts et de la sécurité des installateurs multiplateformes.

Expérience produit

• Prise en charge de JDK 8, 11, 17, 21 et 25, avec des processus graphiques de packaging pour les applications Java, JavaFX, Spring Boot et Tomcat.
• Ajout de l’analyse de compatibilité, du chiffrement sélectif des classes, de la protection des JAR de dépendances, de l’importation/exportation des tâches YAML et des générations par lots pour plusieurs plateformes cibles.
• Refonte de l’interface de bureau, désormais disponible en 11 langues avec mémorisation du choix de langue.

Notes de migration

L’utilisation de Protector4J 6.0 diffère sensiblement des versions précédentes. Avant de l’utiliser, consultez à nouveau la documentation la plus récente, puis reconstruisez et migrez dès que possible vos applications chiffrées vers la version 6.0 afin de bénéficier d’une protection renforcée.

Télécharger Protector4J 6.0

Versions précédentes