新着研究 / LLM / AI Agent
整合した復元結果にも静かな誤り、iOS通信解析でLLMの直接分析と検証可能なツールを比較
Validated Protobuf Extractor
Validated Protobuf Extractorの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
(a) Tile styles 1 and 11
概要
- 二つのLLMがバイナリから復元したprotobufには、構文や復号が通っても型や意味が異なる誤りが残った。
- AIに抽出ツールを書かせ、既知スキーマのコンパイル結果など独立した正解で検証する方式を構築した。
- iPhone 8・iOS 16.7.11への適用であり、端末の送信内容に関する観測を現行iOS全体へ一般化できない。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Validated Protobuf Extractorの仕組み
- 01実行バイナリ
- 02型と項目の抽出器
- 03既知定義で照合
- 04通信の復号を検証
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
通信の二進データを読めても、各値の型や意味が分からなければ送信内容を判断できない。protobufは項目番号と型の定義を必要とし、定義が公開されていない場合は送信プログラムの解析が必要になる。
本研究はiOSの位置サービスを例に、LLMへ直接定義を復元させる方法と、AIが作った専用抽出器を独立に検証する方法を比較する。見た目の整合性と正しさが一致しない作業で、どこへ検証の手掛かりを置くかが主題である。
手法
直接分析では、二モデルが逆アセンブルだけを参照し、項目番号、名前、型、入れ子の定義を再帰的に復元する。正解定義は見せず、後から独立に検証した抽出器と項目単位で照合する。例えば整数の符号や格納方式が違うだけで、同じバイト列から別の値が出る誤りを調べる。
専用Extractorは、書き込み関数の制御フローをたどり、到達可能な呼び出しと引数から定義を復元する。既知スキーマを当時に近いコンパイラでARM64へ変換し、完全に復元できるかを確認する。さらに過去の手動定義と取得通信へ照合する。AIがコードを書くことと、そのコードの正解を保証することを別工程に置く。
新規性
もっともらしい定義が生成できたかではなく、復号時に黙って捨てられる値や誤ったラベルまで検査する。上位の参照誤りが大きな下位構造を読めなくする点も、個々の型の精度と分けて数えている。
AIの解析能力の評価に加え、正解を作れる人工バイナリを検証基盤へ使う実装を示す。検証には人の逆解析と測定も必要で、AIの出力を別のAIに賛同させるだけの確認ではない。
従来手法との違い
17の起点定義に含む7,788項目で、スカラー項目の正しい復元はClaude 86.1%、Codex 79.1%。入れ子全体まで正しいメッセージ参照は57.8%と52.0%だったと報告する。起点ごとの重複を含む集計である。
一方、Extractorは関連する二バイナリ全体を単一コアで計約130秒で処理した。直接LLM解析は約五日かかったが、抽出器の開発・検証費用はこの実行時間に含まれないため、開発からの総費用比較とは異なる。
実験結果
実通信では15起点に属する1,057インスタンスを調べた。対象定義の7,407項目中、出現したのは806項目、10.9%にとどまる。著者は、取得通信だけの動作確認では誤りの大半を見逃すと説明する。
LLMとExtractorが型で食い違う413件はバイナリで確認して抽出器を支持し、三者が一致する50件の無作為確認でも一致したと報告する。通信適用は脱獄したiPhone 8のiOS 16.7.11という特定条件で実施されている。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案として、社内の旧形式データを移行する際に、LLMが出した解釈をそのまま採用せず、検証可能な変換器へ落とし込む工程に使う。入力は仕様が一部不明な二進形式、出力は項目定義と復号結果、照合記録である。
既知値を含む小さなデータを作り、負数、大きい整数、空配列、入れ子の例を通す。普段のログでエラーが出ないことだけを根拠にせず、誤りが静かに通る条件を先に露出させる。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案では、既知仕様から正解付きの入出力を作り、AI生成の抽出・変換ツールへ隠した状態で評価する。基準は人が確認した少数の完全な定義とし、番号、型、名前、配列、符号を個別に照合する。
通常値に加えて境界値を使い、値の欠落と意味の変化を検出する。未対応を明示して停止する挙動も確認し、実記録の網羅率を数える。解析時間だけでなく、検証用正解の作成と保守に要する時間も導入判断へ含める。
限界と課題
直接分析の結果は対象バイナリ、モデル、プロンプト、解析環境に依存する。著者の抽出器による参照も開発時の逆解析に支えられており、検証基盤の用意が不要になったという結論ではない。
編集上の確認点は、別のコンパイラやOS版で抽出規則が変わる場合の検出である。論文が観測した位置情報や識別子の送信は特定端末と条件の結果として読む必要がある。現行製品の挙動や全利用者の追跡可能性を、この一実験だけで断定しない。
出典
元のタイトル・要旨を確認する（英語）
Decoding What iOS Location Services Send to Apple: An LLM Is an Unreliable Analyst but a Useful Toolmaker
Reverse engineering the data formats used by mobile software is skilled and slow, and using AI to assist with it is attractive. We evaluate this for the protobuf messages that an iPhone sends to Apple's location services. Working from Apple's binaries, we use two frontier models (Claude Opus 4.8, Codex GPT Sol 5.6) to reconstruct the schemas of protobufs observed in network traffic. The great majority of the schemas contain substantial errors, and these are hard to detect because the schemas are internally consistent. Direct AI use is therefore unsuitable for forensic and privacy analysis. AI can, however, write reliable analysis tools when their output can be validated. We use Claude to write a Python tool, Extractor, that reliably recovers protobuf schemas from Apple binaries. We validate it against binaries compiled from schemas with known answers, previously published schemas, and network measurements. We demonstrate the use of Extractor to decode and analyse the location services network traffic of a jailbroken iPhone 8 (iOS 16.7.11).
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。収集：2026-10-16