Probleme mit der AOT-Kompilierung
Die AOT-Kompilierung übersetzt Java-Code in nativen Code und verbessert so die Ausführungsgeschwindigkeit von Java-Programmen erheblich. Das Ziel, Java-Code zu schützen, wird indirekt durch die Umwandlung in Maschinencode erreicht.
Für Java-Programme, insbesondere solche, die auf verschiedenen Frameworks basieren, stellt die AOT-Kompilierung aufgrund der Einbeziehung vieler dynamischer Funktionen eine große Herausforderung dar. Um Kompromisse bei der Dynamik einzugehen, kann die kompilierte Binärdatei gleichzeitig noch eine große Menge an Klassendateiinformationen enthalten. Der folgende Artikel stellt ein Projekt vor, das kompilierte Binärdateien durchsucht, um Klasseninformationen zu erhalten. https://protector4j.com/articles/extract-java-classes-information-from-aot/
Auch wenn das Binärprogramm keine Klassendateiinformationen enthält, ist seine Ausführungslogik weiterhin auf die gleiche Weise vorhanden. Der einzige Unterschied besteht darin, dass die Darstellung ohne besonderen Schutz vom Bytecode zum Maschinencode geändert wurde. Wenn man seinen Kompilierungs- und Ausführungsmechanismus versteht, ist es immer noch möglich, lesbaren Code zurückzuentwickeln. Der folgende Artikel stellt ein solches Projekt vor. https://protector4j.com/articles/graalvm-nativeimage-reverse-engineering/
Fazit
Die Konfiguration der AOT-Kompilierung ist schwierig, die Kompilierungsschwierigkeit ist hoch und die Wahrscheinlichkeit eines Kompilierungsfehlers ist hoch. Selbst wenn die Kompilierung erfolgreich ist, ändert sich die Codelogik nur von der Bytecode-Darstellung zur Maschinencode-Darstellung. Seine inhärente Betriebslogik existiert weiterhin ohne besonderen Schutz. Wenn man seinen eigenen Kompilierungs- und Ausführungsmechanismus versteht, ist es immer noch möglich, lesbaren Code zurückzuentwickeln.