Les problèmes de la compilation AOT

La compilation AOT traduit le code Java en code natif, améliorant considérablement la vitesse d'exécution des programmes Java. Elle atteint indirectement l'objectif de protéger le code Java en le convertissant en code machine.

Pour les programmes Java, en particulier ceux basés sur divers frameworks, la compilation AOT représente un défi majeur en raison de l'inclusion de nombreuses fonctionnalités dynamiques. En même temps, afin de composer avec le dynamisme, le fichier binaire compilé peut encore contenir une grande quantité d'informations de fichiers Class. L'article suivant présente un projet qui scanne les fichiers binaires compilés pour obtenir les informations de classe. https://protector4j.com/fr/articles/extract-java-classes-information-from-aot/

Même si le programme binaire ne contient pas d'informations de fichiers Class, sa logique d'exécution existe toujours de la même manière. La seule différence est que la représentation est passée du bytecode au code machine, sans aucune protection spéciale. Si l'on peut comprendre son mécanisme de compilation et d'exécution, il est toujours possible de rétro-ingéniérer un code lisible. L'article suivant présente un tel projet. https://protector4j.com/fr/articles/graalvm-nativeimage-reverse-engineering/

Conclusion

La configuration de la compilation AOT est difficile, la difficulté de compilation est élevée et la probabilité d'échec de compilation est élevée. Même si la compilation réussit, la logique du code ne change que de représentation bytecode à représentation en code machine. Sa logique opérationnelle inhérente existe toujours sans aucune protection spéciale. Si l'on peut comprendre son propre mécanisme de compilation et d'exécution, il est toujours possible de rétro-ingéniérer un code lisible.