💣

iPhoneのeKYCはどこまで信頼できる?会食中の「パスコード盗み見」「ツーショット写真」「端末を置き去り」で破られるシナリオ

に公開

⚠ 本記事は、以下の先行レポートを前提とした続編である
https://zenn.dev/ryuzaburo/articles/c75849d47592a4

本稿では、既知の脆弱性を組み合わせる攻撃を自動化するツールの存在を前提とし、
そのツールが使われた結果として観測された挙動やログを整理・考察する。
ツール自体の説明や構造については、先行レポートを参照されたい。

【前回までのレポート】

  1. 認可された操作が可用性を奪う時:AIと共闘しAppleの防衛論理を突破した「iCloud不整合」の全記録
  2. AIは『翻訳機』ではなく『参謀』である:Appleとの120時間論理戦を支えた、プロンプトを超える対話術
  3. AI参謀と挑んだApple Product Security
  4. iOS既知の脆弱性を組み合わせた詐欺端末製造ツールが存在する?緊急時の削除ツールまで完備?CVEは攻撃者の機能カタログ?

1. はじめに:インシデントの概要と目的

本紙は、特定のデバイスで観測された異常(「iCloud 27.2KBの同期不整合」および「純正カメラの不明な部品警告」)に関するiOS診断ログ(.ips)の技術的分析を提示する。

フォレンジックの観点から、一見するとハードウェアの故障やユーザーエラーに見えるこれらの事象が、物理的接触と既知の脆弱性を組み合わせた 「仮想カメラ(Virtual Camera)」によるeKYCバイパスシナリオ に起因している可能性を調査した。

2. 攻撃シナリオ:ソーシャルエンジニアリングと技術的侵害の融合

(1) 権限の奪取(ショルダーハッキング)

会食等の場で、攻撃者はデバイスをアンロックする際の手元を盗み見る。または、動画視聴のためにスマホを立てかけるよう促す等の動作からパスコード入力を誘発させる。この「パスコードの掌握」が、その後のすべての物理的介入を可能にする。

(2) 学習素材の収集(ツーショット写真)

頻繁に一緒に写真を撮る行為は、ディープフェイク動画の生成に必要な高精度な顔データを多角的に収集するための戦術である。

(3) 物理的介入とツールの注入(数分間の空白)

端末が放置された数分間に、攻撃者は盗んだパスコードを用いて物理的介入(JCID等のハードウェアプログラマの接続や、Lightning/USB-C経由のDMA攻撃)を行う。非脱獄端末であっても、カーネル脆弱性をチェーン化することで、カメラ制御プロセスへのコード注入が可能となる。

3. 診断ログの技術的分析

.ipsログから抽出された以下の異常は、標準的なOS動作では説明が困難な挙動を示している。

A. copyonwritefaults の異常な頻発

stackshotログにおける copyonwritefaults の高いカウントは、特定のメモリ領域に対するプロセス間の激しい競合を示唆している。これは、不正なプロセスが正規のカメラビデオバッファ(Cameracaptured)を強制的に上書きし、偽装映像を注入しようとした仮説を裏付ける。

B. bug_type 288 とシステム時刻の不連続性

ログに記録された秒単位のタイムジャンプ(システムクロック操作)は、ビデオ通話アプリのタイムアウト回避やライセンス認証の偽装を目的としたツールの痕跡である可能性が高い。

  • bug_type 288 (Stackshot): システムが全プロセスのスナップショットを生成したことを示す。ユーザーの意図せず生成された場合、外部ツールによる内部状態のスキャンが疑われる。

C. Cameracaptured と証拠消去プロセスの干渉

証拠消去プロセスが走っている間もカメラプロセスがアクティブであった事実は、攻撃完了直後まで仮想カメラツールがシステムをハイジャックしていたことを示唆する。 「iCloud 27.2KBの同期不整合」 は、消去プロセスがログを上書きしようとした際、システム側の書き込みと衝突して発生したデータベース汚染(SQLite WALモードの競合)である可能性が高い。

4. iOS 18の整合性チェックと「不明な部品」警告

3uTools等の外部ツールでシリアル番号が「正常」と表示されても、iOS 18は「不明な部品」警告を発する場合がある。 現代のiOSセキュリティは、ハードウェアとソフトウェア間の通信パスの整合性を監視している。仮想カメラツールがこの通信をフックすると、暗号化署名データの不整合を検知し、ソフトウェアレベルの偽装が「ハードウェアの完全性エラー」として顕在化する。

5. 仮想カメラによる「Liveness Detection」回避のメカニズム


現代のeKYCにおける「ライブネス判定(瞬きや首振り)」は、以下のフローでバイパスされる。
リアルタイム注入: 攻撃者はあらかじめ多様な動作のディープフェイクを生成しておく。アプリの要求(「右を向いてください」等)に応じ、ツールが対応するビデオファイルをカメラバッファに注入する。
環境整合性の偽装: 高度なツールは、偽装映像をデバイスのジャイロスコープや環境光センサーと同期させ、アプリの空間アルゴリズムを欺く。
深度シミュレーション: 深度情報を要求するアプリに対し、物理的なカメラコネクタへのフッキングを通じてRawセンサーデータを書き換え、3Dの整合性を偽装する。

6. 結論:アーキテクチャの回復力(Resilience)の必要性

本シナリオは限定的なログに基づく仮説ではあるが、「物理的侵害がいかにソフトウェアの信頼を根底から覆すか」という深い教訓を示している。
Appleの「認可(Authorized)」という概念は、物理的アクセスと脆弱性の連鎖によって無効化され得る。センサーが捉える「物理的現実」が、OSが認識する「デジタル現実」と乖離した時、システムは欺瞞を検知する能力を失う。
システムアーキテクトは、デバイスの完全性に対する盲信を捨て、クラウド側でのエンドツーエンドの整合性検証と、微細なハードウェア異常検知に基づく 「多層防御(Defense in Depth)」 を再構築しなければならない。

👉 Apple IDの保全性を抜本的に高めるための提言:パスコード依存からの脱却
https://zenn.dev/ryuzaburo/articles/1508a4546fb988

本記事で解説した通り、パスコード一つにすべての権限が集中する現状のiOSには、設計上の大きな課題があります。
私はシステムアーキテクトの視点から、この「認可のパラドックス」を解消し、Apple IDの保全性を抜本的に高めるための具体的な改善案を提言としてまとめました。

仕様を理解したその先に、どのような「次世代の保護」が必要なのか。興味のある方はぜひこちらもご一読ください。

Discussion