Comment fonctionne Protector4J
Protector4J protège votre code source Java en convertissant les fichiers jar en fichiers jarx cryptés privés. Nous adoptons plusieurs approches pour garantir la sécurité de votre application à la fois au niveau JVM et binaire, offrant ainsi une protection d'application de haute résistance.
Les problèmes avec l'obfuscation du code
En raison de la sémantique élevée du bytecode JVM, il est extrêmement facile à analyser et à lire. Il est facile d'analyser sa logique d'exécution en utilisant le débogage dynamique. Écrire un outil de débogage dynamique n’est pas une tâche très compliquée. L’obscurcissement n’est donc pas une solution de protection fiable.
Les problèmes avec le chiffrement de classe
En raison de l'existence du mécanisme de pièce jointe de la JVM, tout le code dit crypté qui n'a pas été détaché du fonctionnement normal de la JVM peut être facilement lu à l'aide des outils de pièce jointe. Il s’agit donc de la solution de protection la plus inefficace.
Les problèmes liés à la protection des machines virtuelles
La protection contre la virtualisation est la méthode de protection du code la plus sécurisée, mais en raison de son impact significatif sur les performances, elle ne peut pas être appliquée à tout le code d'un programme. Il ne peut protéger que le code critique, tandis que les autres codes comportent toujours un risque d'exposition. En ciblant d'autres parties du code, on peut obtenir des informations fonctionnelles sur la partie virtualisée du code.
Les problèmes avec la compilation AOT
La compilation AOT est difficile à configurer et à compiler, et elle a une forte probabilité d'échec. Même si la compilation réussit, la logique du code passe uniquement de la représentation en bytecode à la représentation en code machine. Sa logique opérationnelle inhérente existe toujours sans aucune protection particulière. Si l’on peut comprendre son propre mécanisme de compilation et d’exécution, il est toujours possible de procéder à de l’ingénierie inverse du code lisible.
Déobfuscation avec vlx-vmengine
Déobfusquer le code Java avec le moteur d'exécution du bytecode JVM vlx-vmengine
Moteur d'exécution du bytecode JVM écrit en Java/Kotlin
Le débogage dynamique Java traditionnel ne peut être effectué que sur la base du code source, et sans code source ni fichiers de classe Java obscurcis, le débogage dynamique est impossible. L'exécution des programmes Java est basée sur la JVM et la JVM utilise le bytecode comme base d'exécution. Nous utilisons Kotlin pour construire un moteur d'exécution de bytecode JVM, qui peut être utilisé avec des IDE modernes, tels que IDEA, pour déboguer des programmes Java au niveau du bytecode afin d'observer le comportement d'exécution du programme.
Ingénierie inverse de GraalVM NativeImage
Pour les programmes Java qui sont entrés dans l’ère de la compilation binaire, leur code peut-il être facilement compilé de manière inverse, tout comme à l’ère du bytecode ? Quelles sont les caractéristiques des fichiers binaires compilés par NativeImage ? La force de la compilation binaire est-elle suffisante pour protéger le code important ? Afin d'explorer les problèmes ci-dessus, j'ai récemment écrit un outil d'analyse NativeImage qui a atteint un certain niveau de dérivation inverse.
Piratage d'une application Java chiffrée avec jhsdb (débogueur HotSpot)
Une solution pour la protection du code Java consiste à chiffrer les fichiers de classe. De telles solutions chargent des fichiers de classe ou jar cryptés via un chargeur de classe personnalisé. En raison de l'existence du mécanisme d'attache de la JVM, cette méthode n'est pas efficace et peut être facilement piratée avec les outils inclus dans le JDK.
Extraction des informations de classe Java à partir de binaires compilés AOT
AOT est également considéré comme une solution pour la protection du code Java, mais malheureusement, de nombreux programmes Java ne peuvent désormais plus être séparés du framework. En raison de la complexité du framework, même les programmes compilés par AOT doivent inclure des informations de classe dans le fichier binaire final généré, et les fichiers de classe sont en fait soigneusement disposés dans la zone de ressources du fichier binaire.
Qu'est-ce qu'un fichier JARX
Le fichier JARX est notre format de fichier d'archive propriétaire, qui utilise le même algorithme de compression Deflate que l'algorithme de cryptage Zip et AES pour crypter les données.
La meilleure solution de protection de code Java au-delà de l'obfuscation
Le chiffrement de votre code protège votre propriété intellectuelle et améliore grandement la sécurité de vos applications. Cela rend le vol d'adresse IP, la falsification de code et la découverte de failles de sécurité si complexes et si coûteux qu'un espion occasionnel armé d'un décompilateur Java gratuit ne suffira pas.
Alternative Excelsior JET
Protector4J est bien plus qu'un remplacement d'Excelsior JET