ネイティブ x86 バイナリの逆コンパイルと比較して、.NET IL コードをソース コードに逆コンパイルする方が簡単なのはなぜですか? (Reflector はほとんどの場合、非常に優れたソース コードを生成しますが、C++ コンパイラの出力を逆コンパイルすることはほとんど不可能です。)
IL に多くのメタデータが含まれているためでしょうか。それとも、IL が x86 命令よりも高度に抽象化されているためですか? いくつかの調査を行ったところ、次の 2 つの有用な記事が見つかりましたが、どちらも私の質問には答えていません。
あなたはすでに最も重要なビットを持っていると思います。
リバース エンジニアリングをかなり簡単にする要素がいくつかあります。
タイプ情報。これは大規模です。x86 アセンブラーでは、変数の使用方法に基づいて変数の型を推測する必要があります。
構造。アプリケーションの構造に関する情報は、il 逆アセンブリでより入手できます。これを型情報と組み合わせると、驚くほどの量のデータが得られます。この時点で、かなり高いレベルで作業しています (x86 アセンブラーに比べて)。ネイティブ アセンブラーでは、データの使用方法に基づいて、構造のレイアウト (およびそれらが構造であるという事実さえも) を推測する必要があります。不可能ではありませんが、はるかに時間がかかります。
名前。物の名前を知っていると役に立ちます。
これらのことを組み合わせると、実行可能ファイルに関する非常に多くのデータがあることを意味します。Il は基本的に、ネイティブ コードのコンパイラよりもはるかにソースに近いレベルで動作します。一般的に言えば、バイトコードが動作するレベルが高いほど、リバース エンジニアリングが容易になります。
C# と IL はほぼ 1 対 1 で対応します。(これは、いくつかの新しい C# 3.0 機能ではそれほどではありません。) マッピングの近さ (および C# コンパイラにオプティマイザーがないこと) により、物事は非常に「可逆的」になります。
ブライアンの正解を拡張する
すべての IL が簡単に逆コンパイルできると思われる場合は、重要な F# プログラムを作成し、そのコードを逆コンパイルすることをお勧めします。F# は多くのコード変換を行うため、実際に出力された IL と元のコード ベースからのマッピングは非常に貧弱です。私見ですが、逆コンパイルされた F# コードを見て、元のプログラムに戻すのは、C# や VB.Net の場合よりもはるかに困難です。