逆アセンブラ

逆アセンブラ（ぎゃくアセンブラ、disassembler; ディスアセンブラ）とは、逆コンパイラの一種であるが、実行ファイルまたはオブジェクトファイルの機械語コード（とシンボルテーブルなどの付随情報）を基に、アセンブリ言語のソースコードを生成する、すなわちアセンブラの逆の作用をするものを特に指す。一般の（高水準言語コードを生成するような）逆コンパイラよりも比較的容易である。

**概要**
コンピュータのプロセッサ（CPUやGPUなど）が直接実行できるプログラムは数値の羅列（バイナリ）である機械語であり、人間が直接理解することは困難である。コンピュータの性能が低く、プログラムの規模が極めて小さかった時代では、機械語そのものや機械語に1対1で対応する命令を持つアセンブリ言語（低水準言語）でプログラムが直接書かれていたこともあったが、このようなプログラミング形態はメンテナンス性や再利用性が極めて低かった。コンピュータの性能が向上し、プログラムが大規模化するにつれて、PascalやC言語、あるいはそれらから発展した各種の派生言語のような、人間に分かりやすい高水準言語で書かれることが主流となっていった。機械語は、最終的にプロセッサが直接実行できるネイティブコードであることには変わりないが、低水準言語または高水準言語で書かれたソースコードを、アセンブラやコンパイラ、リンカといったソフトウェアによって機械的に変換して得られたものに過ぎないので、プログラマはソースコードを理解してソフトウェアを開発・メンテナンスすればよい。
すでに機械語に変換されており、元のソースコードも手に入らない場合は、アセンブルとは逆の手順をたどる（逆アセンブルする）ことで擬似的にソースコードを復元することができる可能性がある。ただしプログラミング言語から機械語への変換は一般に不可逆変換であり、APIやABIとしてモジュール外部に公開される一部のメタ情報を除いて、ソースコード内に書かれてあったコメントや、内部的な実装に使われているローカル変数の名前、条件分岐やループの実装に使用されていた構文efn|例えばCの場合、ループを実現する制御文にはfor文、while文、do-while文があり、プログラマは状況や好みによって使い分けるが、これらは本質的には糖衣構文にすぎず、機械語に変換すると同じ結果が生成されることが多い。さらにCには原始的なgoto文とif文を用いてループを書くという選択肢すらある。といったような高度な情報はほとんど失なわれてしまうため、機械語から元のソースコードを完全に復元することは不可能である。

**リバースエンジニアリングツールとしての逆アセンブラ**
秘匿されている、紛失したなどの理由によりソースコードが入手できないプログラムの動作を知りたい場合、プログラムの機械語を人間が直接理解することは困難であるため、より人間に理解しやすいニーモニックに変換して解析の手助けとするために逆アセンブラを利用する。
人間に理解しやすいといっても、それはあくまでも機械語と比べて、という意味である。逆アセンブル結果からプログラムの内部動作を知り、元のソースコードを推定するまでの作業は一種の暗号解読のような困難な作業であり、非常に高度な技能を持つ技術者が膨大な手間と労力をかけて初めて達成されるものである。
ただし、プログラムの動作を解析されると様々な利害が絡むこともあるため、商用ソフトウェアのライセンスには逆アセンブルなどによるリバースエンジニアリングを禁止する文言があることが多く、また契約の場合にも同様である。
しかし、ソフトウェア特許の侵害を立証するために行われる逆アセンブルについては、これを禁止する契約の効力は及ばない。また、ライセンスや契約でリバースエンジニアリングを禁止する法理について日本では、2008年（平成20年）の時点で文化庁でも検討中である。

**デバッガとしての逆アセンブラ**
高水準言語により作成されたソフトウェアのデバッグの手段として逆アセンブラを用いることがある。このためには独立した逆アセンブラを利用することもあるが、デバッガの機能の一部として提供される、ソースコードと機械語と逆アセンブル結果を混合して表示する「混合モード」（Mixモードとも言う）を利用することも多い。
高水準言語は機械語（または仮想機械向けの中間表現）にコンパイルすることによって実行形式を得るが、時としてプログラマが意図した高水準言語のコーディングと、コンパイラが生成したコンパイル結果が一致しないことがある。これは主に、C言語やC++の言語仕様で未定義動作とされている危険なコードを誤って記述してしまったときに、コンパイラの最適化工程におけるアグレッシブな仮定によって発生しやすい。また、コンパイラにはバグがあることもあり、時として間違ったコンパイルを行うことがある規模にもよるが、バグが一切ないソフトウェアはほとんどない。コンパイラもソフトウェアの一種であり、例外ではない。処理系自体の知名度を問わず、複雑な仕様の言語コンパイラや、テストが十分なされていないコンパイラにはバグが混入しやすい。。このような場合は、コンパイル前のソースコードをいくら眺めてもバグの原因を見極めることは困難であるため、実行コードである機械語を直接検証する必要がある。しかし前述の通り、機械語を人間が直接理解することは困難なので、機械語と1対1で対応するニーモニックに変換して表示する逆アセンブル機能をデバッガが提供している。
デバッグシンボル情報が実行形式に付加されている場合は、デバッガは逆アセンブル結果と一緒にソースコードも表示できるためこの機能を持つデバッガを特にシンボリックデバッガまたはソースレベルデバッガと呼ぶ。、プログラマがその意味を理解することは比較的易しい。開発中のソフトウェアのバイナリには通例デバッグシンボル情報が付加されるが、デバッグシンボル情報は巨大なファイルであり、またリバースエンジニアリングに役立つ情報も含まれているため、市場にリリースするソフトウェアのバイナリからは除去するのが普通である。除去したデバッグシンボル情報を保管しておく習慣のある開発組織は、ほとんどないため、エンドユーザー環境で発生したバグを逆アセンブルによって解析することは、時として他人が開発したソフトウェアを逆アセンブルによってリバースエンジニアリングするのと同様の困難を伴う。

**サンプル**
オンライン逆アセンブルサイトを利用すると、個別CPUの命令とみなした逆アセンブルを試すことができる。
例えば、00をZ80 CPUの機械語として逆アセンブルするとnop、VAX CPUの機械語として逆アセンブルするとhaltとなり、i8086 CPUの機械語として逆アセンブルすると00というデータ（命令とはみなされない）となる。00 00をAVR CPUの機械語として逆アセンブルするとnop、V850 CPUの機械語として逆アセンブルするとnopとなり、ARM CPUの機械語として逆アセンブルするとmovs r0, r0、i8086 CPUの機械語として逆アセンブルするとadd %al,(%bx,%si)、i386 CPUの機械語として逆アセンブルするとadd BYTE PTR eax, al、MIPS_architecture#microMIPS CPUの機械語として逆アセンブルするとaddiu s0,sp,0となる。00 00 00 00をMIPS CPUの機械語として逆アセンブルするとnop、MC68000 CPUの機械語として逆アセンブルするとorib #0,%d0となり、Alpha CPUの機械語として逆アセンブルするとhaltとなる。

**脚注**

**注釈**

**出典**

**関連項目**
クリーンルーム設計
*アセンブラ
*コンパイラ
*逆コンパイラ
*機械語
*アセンブリ言語 - ニーモニック
*高水準言語
*データフロー解析
*制御フローグラフ
 ツール群- GNU Binutils- Binary Ninja

**外部リンク**
 アセンブラ・逆アセンブラ - Vector のダウンロードページ