はじめに

iOSのセキュリティ研究・脱獄界隈で、こんな短い投稿が流れることがある。

Dyld interposing PAC bypass on iOS 26.1.

たった一文に dyld / interposing / PAC / bypass と、専門用語が4つも詰まっている。分解するとこうなる。

用語	意味
dyld	iOS/macOS の動的リンカ（実行時にライブラリを繋ぐ）
interposing	関数を横取り（フック）する技術
PAC	Apple のチップ（A12 以降）のポインタ改ざん防止機能
bypass	その防御を回避する

つまり「iOS 26.1 で、PACという防御をかいくぐって関数フックができた」という報告だ。

この界隈では dyld / fishhook / Frida / Substitute / ElleKit / PAC / AMFI といった単語が一緒に飛び交う。初見だと「結局これは何の話をしているのか」が掴めない。

👉 この記事のゴールは、これらを1枚の地図として理解することだ。個々のツールを覚える前に、まず「そもそも何の世界の話か」から入る。

❗ なお本記事は概念の整理が目的で、動作する回避コードや攻撃手順は扱わない。

全体像：iOSアプリが動く「層」を一枚で

個別ツールに入る前に、舞台を先に見せる。iOSのアプリは単体では動かない。

アプリのコードは、Appleが用意したシステムのライブラリ（Foundation / UIKit など）の上に乗っている
それらを実行時に繋ぎ合わせるのが dyld（動的リンカ）
さらに下に カーネル（XNU） があり、全体を Appleのセキュリティ機構（PAC / AMFI など）が固めている

ここで対立の構図が見えてくる。

関数フック ＝この層のどこかに割り込む行為（攻める側）
PAC / AMFI ＝その割り込みを防ぐ仕組み（守る側）

👉 この1枚で「dyld もフックも PAC も AMFI も、同じ土俵（アプリが動く層）の話」だと分かる。冒頭の投稿は、この土俵で「攻める側が守る側を一時的に上回った」という報告だった。

登場人物の地図：攻める側と守る側

6つの用語を、役割で2グループに仕分けると一気に整理できる。

攻める側（フックする道具）：fishhook / dyld interposing / Frida / Substitute・ElleKit
守る側（防御機構）：PAC / AMFI

この記事では、まず**攻める側（フックとは何か・どの層に刺すか）を見て、次に守る側（PAC / AMFI）**を見る。最後に両者がなぜ衝突するかを整理する。

フックとは何か

関数フックとは、ある関数の呼び出しを別の関数に差し替える技術だ。

例えば、ファイルを開く open() を、自作の my_open() に差し替える。

my_open() の中で「引数を記録する」「結果を書き換える」「本物の open() を呼ぶ」といったことができる。

これができると、こういうものが作れる。

API監視（どの関数がどう呼ばれたか）
ログ取得・デバッグ
動作の改変（チート、機能追加）
Frida のような動的解析ツール
脱獄ツールの「tweak（改造）」

👉 フックは「アプリの外から挙動をのぞき見・書き換えする」ための基本テクニックだ。問題はどの層に、どうやって割り込むかで、ここが道具ごとに違う。

フックの3レイヤ：攻める側の住み分け

「フック」とひとくちに言っても、割り込む層が違う。攻める側の4つはここで住み分けている。

① シンボルテーブル書き換え（fishhook）
アプリが「外部の関数」を呼ぶとき、実際のアドレスは実行時に dyld が表（シンボルテーブル）へ書き込む。fishhook はこの表の中身を自分の関数に差し替える。自分のアプリ（や埋め込んだSDK）の中で完結し、脱獄は前提にしない。

② dyld interposing（__interpose）
「この関数を、この関数に差し替えてください」と dyld に正規の形で申告する仕組み。専用セクション（__DATA,__interpose）に差し替えペアを置くと、dyld が読み込み時に適用する。冒頭の投稿が指していたのはこの経路だ。

③ 実行中のメモリ書き換え / トランポリン（Frida / Substitute / ElleKit）
動作中の関数の本体（コード）を直接書き換える、あるいは入口に「飛び先」を仕込む（トランポリン）。任意のプロセスに広く効かせられて強力だが、その分ハードルが高く、実機では脱獄環境やそれ相当の権限を前提にすることが多い。

❌ 誤解：「フックは一種類」ではない。どの層に刺すかで道具も難易度も変わる。

👉 ①②はアプリ／ローダの仕組みに乗る比較的おだやかな方法、③は動いているコードそのものに手を入れる強い方法、というグラデーションで捉えるとよい。

守る側：PACとAMFI

ここまでが攻める側。ではAppleはどう守っているのか。今回の主役は PAC と AMFI だ。

PAC（Pointer Authentication）

Apple の A12 以降（Armv8.3-A の機能）に載っている、ポインタ改ざん防止の仕組み。関数ポインタや戻り先アドレスに、暗号的な署名を付ける。

例えば攻撃者が printf へのポインタを evil_function に書き換えても、署名が一致しないのでCPUが弾く。ポインタを差し替えるタイプの攻撃・フックにとって、これは大きな壁になる。

AMFI（AppleMobileFileIntegrity）

こちらはコードの素性を守る側。署名のないコードの実行そのものを拒否する。勝手に用意した dylib を読み込ませたり、コード領域を書き換えて実行させたりを止める。

👉 守る対象が違う。PAC はポインタの改ざん、AMFI はコード全体の署名（素性）。この2枚で「ポインタ書き換え」も「コード書き換え」も塞ぐ。

なぜフックはPACと衝突するのか

ここまで来ると、対立がはっきりする。

フック ＝関数ポインタやコードを書き換える行為
PAC / AMFI ＝まさにその書き換えを拒否する仕組み

つまり両者は構造的に真っ向からぶつかる。だから「PACをかいくぐってフックできた」が成果として注目される。冒頭の投稿の "PAC bypass" とは、この壁を一時的に越えたという話だ。

回避を考えるうえで問われるのは、おおまかに次のような点になる（本記事は概念どまりで、手順そのものは扱わない）。

署名が付いたポインタを、どうすれば正当な署名のまま扱えるか
そもそもどの権限が要るか（自アプリ内で済むのか、脱獄やカーネル権限が要るのか）

❗ ここが重要な注意点。冒頭の投稿の一文だけでは、次のことは分からない。

完全なPACバイパスなのか、特定条件だけなのか
脱獄が要るのか、要らないのか
ユーザ権限で済むのか、カーネル権限が要るのか

👉 短い投稿は「壁を越えた」という結果だけを示していることが多い。どの層で・どの権限で・どこまでを確かめないと、すごさの度合いは測れない。

一枚のまとめ：関係図と比較表

最後に、攻める側が刺す層と、守る側の位置を1枚に統合する。

道具ごとの整理はこうなる。

ツール	動作レイヤ	脱獄の要否	PAC / AMFI との関係
fishhook	シンボルテーブル（自プロセス内）	不要（自アプリ内で完結）	直接は衝突しにくい層
dyld interposing	dyld への差し替え申告	場面による	正規経路寄り
Frida	実行中メモリの書き換え	実機は基本要（or 埋め込み構成）	衝突しうる・要対処
Substitute / ElleKit	トランポリン注入	要（脱獄環境の基盤）	衝突しうる・要対処

👉 「脱獄が要るか」「PACとぶつかるか」は、どの層に刺すかでほぼ決まる。上の行ほどおだやか、下の行ほど強力で権限が要る。

まとめ

iOSのフック話は、すべて「アプリが動く層のどこに割り込むか」という1枚の地図に載る
攻める側（fishhook / dyld interposing / Frida / Substitute・ElleKit）は、刺す層で住み分けている
守る側の PAC はポインタの改ざんを、AMFI はコードの素性を検証して弾く
フックは「書き換える」、PAC/AMFIは「書き換えを拒否する」。だから両者は正面衝突し、"PAC bypass" が成果として注目される
ただし短い投稿だけでは どの層・どの権限・どこまで かは分からない。そこを確かめて初めて度合いが測れる

👉 攻防の本質は「署名 vs 書き換え」の綱引き。Appleは毎年 PAC / AMFI などを強化し、研究者はその隙を探す。次に深入りするなら、Frida や ElleKit の公式ドキュメントから、自分が触れる範囲（自アプリ・開発構成）で手を動かすのがおすすめだ。