"コードを書かずに、コードを書く。命令はすでに存在し、我々はただそれを再構成するだけだ。"
セキュリティ領域において、**ROP（Return Oriented Programming）**は特異な存在である。
これは新たな命令を注入するのではなく、既に存在する命令列を再利用することで“別の意味”を作り上げる攻撃技法だ。
この章では、ROPの技術的構造・設計視点・アセンブリ観点からの意味性、
さらにはそれが現代の実行環境に何を突き付けているのかを探る。
ROPとは何か？ — Return Oriented Programming の定義
ROPは、関数リターン命令（RET）を悪用し、任意のコード実行を行う攻撃技法である。
特徴：
- 任意コードの注入ができなくても発動可能（No-Exec環境でも動く）
- バイナリに存在する命令列（＝ガジェット）をチェーン化して動作
- スタック上に配置された“ROPチェーン”により構成される
つまり、コードは書かれない。存在する命令が“再構成”されるだけである。
背景：なぜROPが必要とされたのか？
かつてのバッファオーバーフロー攻撃は、
スタックに任意のシェルコードを置いてジャンプすることで完了した。
しかし、次のような防御技術が登場：
- NXビット（No eXecute）：スタックの実行不可
- ASLR（Address Space Layout Randomization）：コードアドレスの不定化
- Stack Canaries：スタック改竄の検出
これにより、「コードを注入してジャンプする」攻撃は困難になった。
→ 代替手法として登場したのが「既存の命令を繋ぐ」というROPの発想である。
ガジェット（Gadget）とは何か？
ガジェットとは、以下のような短い命令列：
pop rdi
ret
または：
add eax, ebx
ret
特徴：
- 最後に必ず
RETがある - それ以前の命令が“利用可能な効果”を持つ
- 実行中のバイナリ内に既に存在している
ROP攻撃は、こうした**“偶然に存在する命令列”を連結する**ことで、
目的のコードを構築していく。
例：ROPによるsystem("/bin/sh")呼び出し
前提：libcが利用可能、systemアドレス取得済み
ROPチェーン（スタック上に配置）：
-
pop rdi; ret（第1引数に/bin/shのアドレスを入れる） -
&"/bin/sh"（文字列のアドレス） -
system()のアドレス
→ 実行の流れ：
[ESP] → pop rdi; ret
→ "/bin/sh"
→ system
→ RET → pop rdi（→ /bin/sh）→ RET → system("/bin/sh")
これがROPによるシステムコールの組み立てである。
重要な設計視点：スタックが“コード”になる
通常、スタックは一時的な退避領域である。
しかしROPにおいては、スタックは：
- 命令アドレスの配列であり
- 引数の配置空間であり
- 実行フローそのものとなる
設計者は、もはやスタックを**単なる“データ”ではなく、“命令列の構造体”**として扱う必要がある。
防御技術との対話：ROP vs OS構造
ROPは、以下のような防御を回避可能：
| 対策 | 効果 | ROPの回避方法 |
|---|---|---|
| NXビット | スタックの実行不可 | 実行しない、既存命令を使う |
| シグネチャ検知 | 既知のシェルコード検出 | コードを注入しない |
| パッチガード | API改竄防止 | API呼び出しを避ける |
| StackGuard/Canary | スタック改竄検知 | スタック以外の領域を使う、あるいは巧妙に回避 |
→ ROPはOS設計の“前提”を裏切る設計思想に基づいている。
ガジェット探索とツール群
ROPを設計するには、まずガジェットを発見しなければならない。
代表的ツール：
- ROPgadget：ELF/PE解析、自動ガジェット抽出
- radare2：スクリプト制御も可能な高機能逆アセンブラ
- pwntools：ROPチェーンのスクリプト生成支援
- Ghidra, Binary Ninja, IDA Pro：GUIによる高精度逆解析
→ 現代のROPは、“再設計されたアセンブリ”を、道具とともに彫刻する技術となっている。
設計倫理とROP：再構築の美学か、破壊か
ROPはその本質上、セキュリティ領域で語られることが多いが、
一方で以下の問いも提起する：
- どこからが“破壊”で、どこまでが“再構築”か？
- 設計された命令列は、本当にその通りにしか使えないのか？
- 意図された使われ方以外を排除すべきなのか？
→ ROPは、コードの意味と境界を揺さぶる設計思想でもある。
結語：RETのその先へ
アセンブリにおける RET 命令は、
本来、関数からの「終了」を意味する。
しかしROPにおいては、
RETは始まりの命令となる。
- プログラムは、書かれた通りに動くとは限らない
- 設計とは、意味の流通経路の設計でもある
- そして、意味は構造を持てば“再解釈”されうる
"RETを積み重ねよ。意味は既に書かれている。構造こそが、それを再び命令に変えるのだ。"