AOTコンパイルの問題

AOT コンパイルは Java コードをネイティブ コードに変換し、Java プログラムの実行速度を大幅に向上させます。 Java コードをマシンコードに変換することで、Java コードを保護するという目標を間接的に達成します。

Java プログラム、特にさまざまなフレームワークに基づくプログラムの場合、多くの動的機能が含まれるため、AOT コンパイルは大きな課題になります。同時に、ダイナミズムを犠牲にするために、コンパイルされたバイナリ ファイルには大量のクラス ファイル情報が含まれる場合があります。次の記事では、コンパイルされたバイナリ ファイルをスキャンしてクラス情報を取得するプロジェクトを紹介します。 https://protector4j.com/articles/extract-java-classes-information-from-aot/

バイナリ プログラムにクラス ファイル情報が含まれていない場合でも、その実行ロジックは同じように存在します。唯一の違いは、表現が特別な保護なしでバイトコードからマシンコードに変更されたことです。コンパイルと実行のメカニズムを理解できれば、可読コードをリバース エンジニアリングすることは可能です。以下の記事ではそんなプロジェクトを紹介しています。 https://protector4j.com/articles/graalvm-nativeimage-reverse-engineering/

結論

AOT のコンパイル設定が難しく、コンパイルの難易度が高く、コンパイルが失敗する可能性が高くなります。コンパイルが成功した場合でも、コード ロジックはバイトコード表現からマシンコード表現に変更されるだけです。その固有の動作ロジックは、特別な保護なしで依然として存在します。独自のコンパイルと実行メカニズムを理解できれば、可読コードをリバース エンジニアリングすることは可能です。