デコンパイラ

逆コンパイラは、実行可能ファイルを高水準ソースコードに変換するコンピュータプログラムです。したがって、高水準言語を低水準言語に変換する一般的なコンパイラとは逆のことを行います。逆アセンブラが実行可能ファイルをアセンブリ言語に変換するのに対し、逆コンパイラはさらに一歩進んで、コードをCやJavaなどの高水準言語に変換します。これにはより高度な技術が必要です。逆コンパイラは通常、元のソースコードを完全に再構築することができないため、難読化されたコードが頻繁に生成されます。それでも、コンピュータソフトウェアのリバースエンジニアリングにおいて重要なツールであることに変わりはありません。

デコンパイラという用語は、実行可能プログラム (コンパイラからの出力) を(比較的)高級言語のソース コードに変換する プログラムに最もよく適用されます。このソース コードは、コンパイルされると、元の実行可能プログラムと同じ動作をする実行可能ファイルを生成します。比較すると、逆アセンブラは実行可能プログラムをアセンブリ言語に変換します(アセンブラは、それを実行可能プログラムに再度アセンブルするために使用できます)。

逆コンパイルとは、逆コンパイラを使用する行為であるが、逆コンパイラの出力を指すこともある。これは、失われたソースコードの回復に使用できるほか、コンピュータのセキュリティ、相互運用性、エラー修正にも役立つ場合がある。^[1]逆コンパイルの成功は、逆コンパイルされるコードに含まれる情報の量と、それに対して実行される分析の洗練度によって決まる。多くの仮想マシン（Java仮想マシンや.NET Framework 共通言語ランタイムなど）で使用されるバイトコード形式には、逆コンパイルを非常に実現可能にする広範なメタデータと高レベル機能が含まれていることが多い。デバッグデータ、つまりデバッグシンボルを適用すると、変数や構造体の元の名前、さらには行番号を再現できる場合がある。このようなメタデータやデバッグデータがない機械語は、逆コンパイルがはるかに困難である。^[2]

一部のコンパイラおよびコンパイル後のツールは難読化されたコードを生成します (つまり、逆コンパイルが非常に難しい出力、または逆コンパイルするとわかりにくい出力が生成されます)。これは、実行可能ファイルの リバース エンジニアリングを困難にするために行われます。

デコンパイラは通常、バイナリ実行ファイルからソースコードを（再）作成するために使用されますが、特定のバイナリデータファイルを人間が読み取り、編集可能なソースに変換するデコンパイラもあります。^{[3] [4]}

逆コンパイラの成功レベルは、さまざまな要因によって左右されます。これには、ソース言語の抽象化レベルが含まれます。オブジェクト コードに明示的なクラス構造情報が含まれている場合、逆コンパイル プロセスが促進されます。記述情報、特に命名の詳細も、コンパイラの作業を高速化します。さらに、最適化されていないコードは、最適化によって元のコードからの逸脱が大きくなる可能性があるため、逆コンパイルが速くなります。^[5]

デコンパイラは、一連のフェーズで構成されていると考えることができます。各フェーズは、デコンパイル プロセス全体の特定の側面に貢献します。

最初の逆コンパイル段階では、入力マシンコードまたは中間言語プログラムのバイナリファイル形式をロードして解析します。アーキテクチャ (Pentium、PowerPC など) やエントリポイントなど、入力プログラムに関する基本的な事実を検出できる必要があります。多くの場合、Cmainプログラムの関数に相当するもの、つまりユーザーが記述したコードの開始部分を見つけることができるはずです。ランタイム初期化コードは除外されますが、これは可能な限り逆コンパイルしないでください。シンボルテーブルとデバッグデータがある場合は、それもロードされます。フロントエンドは、コードにリンクされている場合でも、使用されているライブラリを識別できる場合があります。これにより、ライブラリインターフェイスが提供されます。使用されているコンパイラを判別できれば、コードイディオムを識別するのに役立つ情報を提供できます。^[6]

次の論理段階は、マシンコード命令をマシンに依存しない中間表現（IR）に分解することです。たとえば、Pentiumマシン命令は

移動eax , [ ebx + 0x04 ]     

IRに翻訳されるかもしれない

eax : = m [ ebx + 4 ] ;   

慣用的なマシン コード シーケンスとは、命令の個々のセマンティクスからその組み合わせたセマンティクスがすぐには明らかでないコードのシーケンスです。逆アセンブリ フェーズの一部として、または後の分析の一部として、これらの慣用的なシーケンスを既知の同等の IR に変換する必要があります。たとえば、x86 アセンブリ コード:

    cdq eax ; edx は符号拡張≠edi,edi +(tex)push xor eax , edx sub eax , edxに設定されます                 
         
         

翻訳すると

eax := abs(eax);

いくつかの慣用的なシーケンスはマシンに依存しません。また、1 つの命令のみを必要とするシーケンスもあります。たとえば、はレジスタをクリアします(ゼロに設定します)。これは、 などのマシンに依存しない簡略化規則を使用して実装できます。 xor eax, eaxeaxa = 0

一般的に、慣用的なシーケンスの検出は、可能であれば、命令の順序による影響が少ない後の段階まで遅らせるのが最善です。たとえば、コンパイラの命令スケジューリング フェーズでは、慣用的なシーケンスに他の命令が挿入されたり、シーケンス内の命令の順序が変更されたりすることがあります。逆アセンブリ フェーズのパターン マッチング プロセスでは、変更されたパターンは認識されない可能性があります。後の段階では、命令式をより複雑な式にグループ化し、標準 (標準化) 形式に変更します。これにより、変更された慣用表現であっても、逆コンパイルの後の段階でより高レベルのパターンに一致する可能性が高くなります。

サブルーチン呼び出し、例外処理、およびswitch ステートメントに関するコンパイラの慣用句を認識することが特に重要です。一部の言語では、文字列や長整数も広範にサポートされています。

IRにはさまざまなプログラム解析を適用できます。特に、式の伝播は、複数の命令の意味をより複雑な式に組み合わせます。たとえば、

    mov eax ,[ ebx + 0x04 ]加算eax ,[ ebx + 0x08 ]減算[ ebx + 0x0C ], eax   
       
       

式の伝播後に次の IR が発生する可能性があります。

m[ebx+12] := m[ebx+12] - (m[ebx+4] + m[ebx+8]);

結果の表現は高級言語に似ており、マシン レジスタの使用も排除されていますeax。後の分析でebxレジスタが排除される可能性があります。

レジスタの内容が定義され、使用される場所は、データフロー解析を使用してトレースする必要があります。同じ解析を、一時データやローカルデータに使用される場所に適用できます。このようにして、値の定義と使用の関連付けられたセットごとに異なる名前を形成できます。元のプログラムの異なる部分で、同じローカル変数の場所が複数の変数に使用されている可能性があります。さらに悪いことに、データフロー解析によって、実際には決して発生しない、または問題にならない場合でも、2 つの使用間で値が流れる可能性があるパスが特定される可能性があります。最悪の場合、場所を型の共用体として定義する必要が生じる可能性があります。デコンパイラーでは、ユーザーがこのような不自然な依存関係を明示的に解除できるようにして、より明確なコードを作成できます。もちろん、これは変数が初期化されずに使用される可能性があることを意味し、元のプログラムに問題があることを示しています。^{[引用が必要]}

優れたマシンコードデコンパイラは型分析を実行します。ここで、レジスタやメモリの場所の使用方法によって、その場所の可能な型に制約が生じます。たとえば、命令はオペランドが整数であることを意味します。プログラムは、浮動小数点値（特別なライブラリコードを除く）やポインターandに対してそのような演算を使用しません。命令には3つの制約があります。オペランドは両方とも整数の場合もあれば、1つの整数と1つのポインター（それぞれ整数とポインターの結果）の場合もあります。3番目の制約は、型が異なる場合の2つのオペランドの順序から生じます。^[7]add

構造体や配列の認識をトリガーするさまざまな高レベルの式を認識できます。ただし、マシン コードや C などの一部の高レベル言語ではキャストやポインタ演算が自由に行えるため、多くの可能性を区別するのは困難です。

前のセクションの例では、次のような高レベルコードが生成されます。

構造体T1 * ebx ;構造体T1 { int v0004 ; int v0008 ; int v000C ; }; ebx -> v000C -= ebx -> v0004 + ebx -> v0008 ;  
      
         
         
         
    
    

最後から2番目の逆コンパイル段階では、IRをwhileループやif/then/else条件文などの高レベル構造に構造化します。たとえば、マシンコード

    xor eax 、eax l0002:またはebx 、ebx jge l0003加算eax 、[ ebx ] mov ebx 、[ ebx + 0x4 ] jmp l0002 l0003: mov [ 0x10040000 ]、eax  

       
     
     
     
     

     

次のように翻訳できます。

eax = 0 ; while ( ebx < 0 ) { eax += ebx -> v0000 ; ebx = ebx -> v0004 ; } v10040000 = eax ;  
    
      
      

  

非構造化コードを構造化コードに変換するのは、すでに構造化されているコードに変換するよりも困難です。解決策としては、一部のコードを複製するか、ブール変数を追加することなどが挙げられます。^[8]

最後の段階は、デコンパイラのバックエンドで高レベル コードを生成することです。コンパイラがさまざまなアーキテクチャのマシン コードを生成するために複数のバックエンドを持つのと同様に、デコンパイラもさまざまな高レベル言語で高レベル コードを生成するために複数のバックエンドを持つ場合があります。

コード生成の直前に、何らかのグラフィカル ユーザー インターフェイスなどを使用して、IR を対話的に編集できるようにすることが望ましい場合があります。これにより、ユーザーはコメントや、非ジェネリック変数名および関数名を入力できます。ただし、これらはデコンパイル後の編集でもほとんど同じくらい簡単に入力できます。ユーザーは、ループをループwhileに変換するなど、構造的な側面を変更したい場合がありますfor。これらは単純なテキスト エディターでは簡単には変更できませんが、ソースコード リファクタリングツールがこの処理を支援する場合があります。ユーザーは、メモリ式を配列または構造体式に変更するなど、型分析フェーズで識別できなかった情報を入力する必要がある場合があります。最後に、誤った IR を修正するか、出力コードをより読みやすくするための変更を加える必要がある場合があります。

ニューラルネットワークを使用したデコンパイラが開発されている。このようなデコンパイラは機械学習によってトレーニングされ、時間の経過とともに精度が向上する可能性がある。^[9]

コンピュータプログラムの大部分は著作権法で保護されています。著作権の保護範囲の正確な範囲は地域によって異なりますが、著作権法は一般に、プログラムに対する一連の排他的権利を著作者（プログラマーまたは雇用者）に与えています。^{[10]これらの権利には、コンピュータの}RAMに作成されるコピーを含むコピーを作成する権利が含まれます（そのようなコピーの作成がプログラムの使用に不可欠である場合を除く）。^{[11]逆コンパイルのプロセスにはそのようなコピーが複数作成されるため、著作権者の許可なしに逆コンパイルを行うことは通常禁止されています。ただし、逆コンパイルはソフトウェアの}相互運用性を 実現するために必要な手順であることが多いため、米国とヨーロッパの著作権法はどちらも、限られた範囲で逆コンパイルを許可しています。

米国では、逆コンパイル訴訟において著作権のフェアユースの抗弁が認められている。例えば、セガ対アコレードの訴訟では、アコレードがセガのゲーム機で使用されているソフトウェアロック機構を回避するために逆コンパイルを行うことは合法であると裁判所は判決を下した。^[12]さらに、デジタルミレニアム著作権法（公法105-304 ^[13]）には、§1201(i)のセキュリティテストと評価と、§1201(f)のリバースエンジニアリングの両方について適切な免除規定がある。^[14]

欧州では、1991 年のソフトウェア指令で、相互運用性を実現するために逆コンパイルする権利が明示的に規定されています。ソフトウェア保護主義者と、学者や独立系ソフトウェア開発者の間で激しい議論が交わされた結果、第 6 条では、いくつかの条件が満たされた場合のみ逆コンパイルが許可されています。

• まず、個人または団体は、逆コンパイルするプログラムを使用するためのライセンスを持っている必要があります。
• 第二に、逆コンパイルは、対象プログラムや他のプログラムとの相互運用性を実現するために必要でなければなりません。したがって、相互運用性に関する情報は、マニュアルやAPIドキュメントなどを通じて容易に入手できるべきではありません。これは重要な制限です。その必要性は、逆コンパイラによって証明されなければなりません。この重要な制限の目的は、主に開発者が製品の相互運用性情報を文書化して公開するインセンティブを提供することです。^[15]
• 3 番目に、デコンパイル プロセスは、可能であれば、相互運用性に関連するターゲット プログラムの部分に限定する必要があります。デコンパイルの目的の 1 つはプログラム構造を理解することであるため、この 3 番目の制限を満たすことは難しい場合があります。この場合も、証明責任はデコンパイラにあります。

また、第6条では、逆コンパイルにより得られた情報を他の目的に使用したり、他人に提供したりしてはならないと規定しています。

全体として、第 6 条で規定されている逆コンパイル権は、ソフトウェア業界で一般的な慣行であると主張されているものを成文化したものです。逆コンパイル権から生じたヨーロッパの訴訟はほとんど知られていません。これは、次の 3 つの意味のいずれかとして解釈できます。

1. ）逆コンパイル権は頻繁に使用されておらず、したがって逆コンパイル権は不要であった可能性がある。
2. ）逆コンパイル権は十分に機能し、法的紛争や
3. ) 違法な逆コンパイルはほとんど検出されません。

2000年に欧州加盟国によるソフトウェア指令の実施に関する報告書で、欧州委員会は2番目の解釈を支持しているようであった。^[16]

• 逆アセンブラ
• バイナリ再コンパイラ
• リンカー（コンピューティング）
• 抽象的解釈
• リソースエディター

• Mocha デコンパイラ
• JD デコンパイラ
• JAD デコンパイラ

• .NET リフレクター
• ドットピーク
• JEB デコンパイラ(Android Dalvik、Intel x86、ARM、MIPS、WebAssembly、Ethereum)
• ギドラ
• IDA Pro には、デコンパイラがオプションの有料機能として含まれています。
• バイナリ忍者
• uncompyle6 (Python バイトコード 1.0 から 3.8)

無料辞書のウィクショナリーで「decompiler」を調べてください。

Wikibooksにはリバースエンジニアリングに関する本があります。