リバースエンジニアリング入門。静的解析と動的解析の基礎を検証環境で安全に学ぶ

リバースエンジニアリングとは、完成した製品やソフトウェアを分解・観察して、その内部の構造や動作の仕組みを後ろ向きに（reverse）解き明かす行為を指します。セキュリティの文脈では、ソースコードが手元にないコンパイル済みのバイナリ、つまり実行ファイルやライブラリを解析し、それが何をしているのかを明らかにする作業がその中心になります。マルウェア解析、脆弱性の調査、不審なアプリの挙動確認、CTF のバイナリ問題など、適用される場面は意外なほど広く、防御を担う側にとっても避けて通れない基礎技術です。

一方で、この技術には独特の難しさがあります。ひとつは技術的な難しさで、人間が読みやすいソースコードは失われ、機械語やアセンブリという「翻訳のしにくい言語」と向き合うことになります。もうひとつ、そしてより見落とされやすいのが法的・契約的な難しさです。解析対象によっては著作権法やソフトウェアの利用規約、不正アクセス禁止法といった複数のルールが絡み、「技術的にできること」と「やってよいこと」が一致しません。

この記事では、静的解析と動的解析という二本柱の考え方、最低限そろえておきたい検証環境、そして実務で必ずぶつかる合法性の判断基準までを、原理から噛み砕いて解説します。読み終えたとき、どこから手をつけ、どこで立ち止まって確認すべきかが自分の言葉で説明できる状態を目指します。

静的解析と動的解析の早見表#

リバースエンジニアリングの手法は、対象を「動かさずに読む」か「動かして観る」かで大きく二つに分かれます。まず全体像を表で押さえます。

重要なのは、どちらか一方で完結することは少なく、両者を行き来しながら理解を深めるという点です。静的解析で「ここで暗号化されたデータを復号していそうだ」と当たりをつけ、動的解析でその瞬間のメモリを覗いて復号結果を確認する、という連携が典型的な流れになります。

なぜソースコードがないのに中身が読めるのか#

リバースエンジニアリングを初めて学ぶ人がまず戸惑うのは、「ソースコードが無いのに、どうして処理内容が分かるのか」という点です。ここを原理から押さえると、以降の話が一気に腑に落ちます。

私たちが書くソースコード（C や Go など）は、人間が読むためのものです。これを実行できる形にする工程がコンパイルで、最終的には CPU が直接解釈できる機械語、すなわち 0 と 1 の並びになります。この機械語には、変数名や関数名、コメントといった「人間向けの情報」の多くが含まれません。コンパイルは情報を捨てながら最適化する不可逆寄りの変換であり、ここが「ソースに完全には戻せない」理由です。

しかし、機械語は CPU の命令セット（x86-64 や ARM など）の仕様に沿った規則的な符号です。規則が分かっていれば、機械語を人間が読めるアセンブリ言語に一対一に近い形で変換できます。この変換を担うのがディスアセンブラです。さらに、アセンブリのパターンから「これは for ループ」「これは if 分岐」といった高水準の構造を推測し、C 言語風の擬似コードに復元するのがデコンパイラです。デコンパイラの出力は元のソースそのものではなく、あくまで「振る舞いが同じになるように再構成した近似」である点には注意が必要です。変数名は local_1c のような自動生成の名前になり、元の意図はこちらで読み解く必要があります。

検証環境のつくり方。隔離が最優先#

リバースエンジニアリング、とくにマルウェア解析を学ぶうえで、技術以前に整えるべきなのが安全な検証環境です。ここを軽視すると、解析対象が手元の端末や社内ネットワークに被害を及ぼします。

基本方針は隔離（アイソレーション）です。解析は使い捨てにできる仮想マシン（VM）の中で行い、ホスト（あなたの普段使いの PC）や本番ネットワークと明確に切り離します。具体的には次のような構成が出発点になります。

ツールについて補足します。静的解析の中心になるのがディスアセンブラ／デコンパイラで、無償かつ多機能なものとして NSA が開発・公開している Ghidra があります。Ghidra は Apache-2.0 ライセンスのオープンソースで、Windows・macOS・Linux で動作し、2026年6月時点の最新は 12.1.2 です。動的解析ではデバッガ（プログラムを一行ずつ止めながら実行できるツール）や、ファイル・レジストリ・通信を記録するサンドボックス、パケットキャプチャツールを組み合わせます。

Ghidraのバージョンやライセンス（Apache-2.0）、対応OSは公式リポジトリで確認できます。ツールは更新が速いため、導入前に最新リリースを確認してください。

静的解析の進め方。文字列と構造から当たりをつける#

静的解析の良いところは、対象を実行しないため比較的リスクが低く、全体像を落ち着いて把握できる点です。実務でも、まず静的解析で「このバイナリは何者か」を見立ててから動的解析に進むのが定石です。

最初の一歩としてよく行われるのが文字列（strings）の確認です。バイナリ中に埋め込まれた可読な文字列を抜き出すと、エラーメッセージ、URL、ファイルパス、ライブラリ名などが見え、対象の性格がうかがえます。たとえば見慣れないドメインや、暗号化・自己複製を連想させる語が並んでいれば、悪性の可能性を疑う材料になります。ただし、文字列が暗号化・難読化されていて何も読めないこと自体が、難読化を施した何かである、という情報になる点も覚えておくとよいでしょう。

次に、インポートしている関数（その実行ファイルが外部から借りている機能）を見ます。ネットワーク通信やファイル暗号化、プロセス操作に関わるAPIを多用していれば、挙動の方向性が推測できます。そのうえでディスアセンブラ／デコンパイラに読み込ませ、エントリポイントから関数の呼び出し関係をたどり、怪しい処理に焦点を絞っていきます。

静的解析だけで完結しないのは、難読化・暗号化・パッキング（実行時に自分自身を展開する圧縮）といった対抗策があるためです。表面上は意味不明なコードでも、実行時には正体を現します。そこで登場するのが動的解析です。

動的解析の進め方。実行して初めて見える実態#

動的解析は、対象を実際に動かし、その瞬間の振る舞いを観測する手法です。静的解析で読めなかった暗号化済みの設定値や、実行時にだけ復号される文字列、外部との通信先などは、動かしてみて初めて見えることが多くあります。

中心になるのがデバッガです。デバッガを使うと、プログラムを任意の地点で一時停止（ブレークポイント）させ、その時点のメモリやレジスタの中身を覗けます。たとえば「暗号化されたデータを復号した直後」で止めれば、復号後の平文をメモリ上で確認できます。静的解析で「ここで復号していそう」と当たりをつけ、動的解析でその瞬間を捕まえる、という連携がまさにこれです。

通信を伴うマルウェアでは、パケットキャプチャやプロキシで通信先（C2サーバなど）や送受信データを記録します。ファイルやレジストリへの操作を時系列で記録するサンドボックスを併用すれば、「何を作り、何を書き換え、どこへ通信したか」という被害の輪郭が掴めます。

なお、解析を妨害する「アンチデバッグ」「アンチVM」と呼ばれる仕掛けを備えたマルウェアもあります。デバッガや仮想環境を検知すると無害なふりをしたり、自身を終了したりします。こうした対抗を見抜き、いなしていくのは中級以降の課題ですが、入門の段階では「解析されることを前提に作られた検体がある」という事実を知っておくだけでも、挙動が読めないときの戸惑いが減ります。

合法性とライセンス。技術より先に確認すべきこと#

リバースエンジニアリングで最も注意すべきは、技術ではなく合法性です。「できる」と「やってよい」は別物で、ここを曖昧にしたまま手を動かすと、思わぬ形で法令違反や契約違反に踏み込みます。論点を整理します。

第一に著作権です。プログラムは著作物であり、その解析過程ではコードの複製などが生じます。日本では平成30年改正で整備された著作権法30条の4により、「思想又は感情を自ら享受し又は他人に享受させること」を目的としない利用が一定の範囲で認められ、調査解析（リバースエンジニアリング）目的の利用はこれに当たり得ると説明されています。つまり、機能を享受するためではなく仕組みを調べるための解析には、著作権法上の一定の余地があるという理解です。ただしこれは「何をしてもよい」という意味ではなく、適用の可否は具体的な目的や態様によります。

第二に利用規約（EULA・ライセンス契約）です。著作権法上の権利制限とは別に、ソフトウェアの利用規約で「逆コンパイル・逆アセンブルの禁止」が明記されていることがあります。規約は当事者間の契約であり、これに反すれば契約違反の問題が生じ得ます。著作権法で許される余地があることと、その特定のソフトを規約に反して解析してよいことは、別の話だと切り分けてください。

著作権法30条の4を含む「柔軟な権利制限規定」の趣旨と想定事例は、文化庁の平成30年著作権法改正の解説で確認できます。個別ケースの判断に迷う場合は、専門家への相談が前提になります。

第三に不正アクセス禁止法です。これはリバースエンジニアリングそのものというより、解析に付随する行為に関わります。たとえば他人が管理するサーバやサービスに無許可でログイン・侵入して内部を調べるような行為は、不正アクセス行為の禁止等に関する法律に抵触し得ます。総務省の解説によれば、他人の識別符号（ID・パスワード等）を悪用した不正アクセスや、セキュリティホールを突いた無許可アクセスが禁止され、違反には懲役や罰金が定められています。手元のバイナリを解析するだけなら通常はこの法律の対象外ですが、「解析した知識を使って許可のないシステムにアクセスする」段階に踏み込めば、明確に別問題になります。

不正アクセス行為の定義や禁止される行為、罰則の概要は総務省「国民のためのサイバーセキュリティサイト」で確認できます。

実務での判断基準をひとことで言えば、「対象は誰のもので、どの規約と法令が適用されるか」を解析の前に確認する、に尽きます。自分が所有・管理するバイナリ、明示的に許可された対象、CTFなどの競技環境であれば、規約と権利関係を確認したうえで比較的安心して手を動かせます。逆に、他者の製品やサービスを規約・許可の確認なしに解析するのは避けるべきです。学習目的であっても、この線引きは崩してはいけません。

よくある質問#

まとめ#

リバースエンジニアリングは、ソースコードのないバイナリの振る舞いを後ろ向きに解き明かす技術です。静的解析で全体像をつかみ、動的解析で実行時の実態を確かめる、という二本柱の往復が基本になります。そして技術以上に重要なのが、隔離された検証環境を整えることと、著作権・利用規約・不正アクセス禁止法といった合法性の前提を解析の前に確認することです。守るための知識として身につけるなら、まずは自分の管理下にある対象から、安全に手を動かしていきましょう。

関連記事もあわせてどうぞ。バイナリ問題を含む競技で手を動かすなら