Problèmes avec 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. Il atteint indirectement l'objectif de sauvegarde du code Java en le convertissant en code machine.

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

Même si le programme binaire ne contient pas d'informations sur le fichier de classe, 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 particulière. Si l’on peut comprendre son mécanisme de compilation et d’exécution, il est toujours possible de procéder à une ingénierie inverse du code lisible. L'article suivant présente un tel projet. https://protector4j.com/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 la compilation est élevée. 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 à une ingénierie inverse du code lisible.