Comment fonctionne Protector4J?

Problèmes de la solution actuelle de protection du code Java

Avant de comprendre le fonctionnement de Protector4J, apprenons d'abord les problèmes qui existent dans d'autres solutions de protection du code Java.

Obfuscation de code

En raison de la nature sémantique élevée du bytecode JVM, il est très facile à analyser et à lire. Avec le débogage dynamique, sa logique d’exécution peut être facilement analysée, l’obscurcissement n’est donc pas une solution de protection fiable.

Pour plus d'informations, veuillez vous référer à l'article :https://protector4j.com/articles/the-issues-of-code-obfuscation/

Chiffrement de fichiers de classe

En raison de l'existence du mécanisme de pièce jointe JVM, tout le code dit crypté qui n'a pas été détaché du JRE normal peut être facilement obtenu via les outils de pièce jointe. Il s’agit donc de la solution de protection la plus inefficace.

Pour plus d'informations, veuillez vous référer à l'article :https://protector4j.com/articles/the-issues-of-class-encryption/

Protection VMP

La protection contre la virtualisation est la forme de protection du code la plus sécurisée, mais en raison de son impact important sur les performances, elle ne peut être appliquée qu'au code critique d'un programme. Un autre code reste toujours exposé au risque d'exposition. En ciblant d’autres parties du code, le pirate peut toujours obtenir des informations fonctionnelles du code virtualisé.

Veuillez vous référer à l'article pour plus de détails spécifiques: https://protector4j.com/articles/the-issues-of-vm-protection/

Compilation AOT

La configuration et la compilation de la compilation AOT sont très difficiles et il existe une forte probabilité d'échec de la compilation. Même si la compilation réussit, la logique du code est uniquement transformée de la représentation en bytecode en représentation en code machine, et sa logique inhérente existe toujours sans aucune protection particulière. Si l’on peut comprendre son mécanisme de compilation et d’exécution, le code lisible peut toujours faire l’objet d’une ingénierie inverse.

Pour plus d'informations, veuillez vous référer à l'article :https://protector4j.com/articles/the-issues-of-aot-protection/

Comment fonctionne Protector4J?

Nous avons défini un format de package de compression privé : JARX

Pour protéger le code Java, nous avons créé un format de document compressé privé appelé JARX et l'avons intégré au runtime JVM. Un fichier JAR traité par Protector4J est transformé au format JARX.

Nous avons apporté des personnalisations et des modifications profondes à la JVM

Grâce à une étude approfondie de la JVM, nous y avons apporté de profondes personnalisations et modifications. Nous avons supprimé tous les mécanismes supplémentaires et appliqué beaucoup de renforcement et d'optimisation au niveau de la sécurité binaire. Cela empêche les pirates d'utiliser les méthodes existantes pour exporter les informations de votre classe. Nous pensons qu'avec la solidité actuelle, l'application cryptée protégée par Protector4J dispose d'un haut niveau de sécurité. Cependant, la bataille entre fissuration et anti-fissuration est toujours une amélioration constante. Nous continuerons d'améliorer nos solutions de cryptage et de protection pour renforcer constamment la sécurité de l'application.