💻 computer science

Multi-Agent Cooperative Fuzzing for HarmonyOS APIs

本論文は、既存のエコシステムにおけるドキュメントの不足と質の低さを克服するために、Androidコードの検索、マルチモーダルなドキュメント解釈、プロンプト最適化のための強化学習、および自動クラッシュ解析を活用することで、HarmonyOS APIの脆弱性発見を強化するマルチエージェント協調型ファジングフレームワークであるHMFuzzerを提案する。

原著者： Fei Jia, Lei Zhang, Huibing Zhang, Lianhai Liu

公開日 2026-06-24✓ Author reviewed ⓘ

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Fei Jia, Lei Zhang, Huibing Zhang, Lianhai Liu

原論文は CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

あなたは、ロボットに非常に新しいハイテクな家（HarmonyOS）への侵入方法を教えようとしていると想像してください。目的は、鍵や窓の弱点を見つけることです。問題は、その家があまりにも新しいため、設計図がほとんどなく、「ハウツー」動画も存在せず、手元にある数少ない説明書さえも、ロボットがうまく理解できない言語で書かれており、言葉の代わりに紛らわしい図解がたくさん含まれていることです。

この論文は、この問題を解決するために、HMFuzzerと呼ばれる新しいロボット専門家チームを紹介しています。一つのロボットがすべてをやろうとするのではなく、彼らは専門的な探偵部隊のように、連携して動く3人組のチームを使用します。

以下に、彼らのチームの仕組みを、簡単な比喩を用いて説明します。

1. 問題：「マニュアルが欠落した新しい家」

HarmonyOSは、新しいスマートシティのようなものです。そこには、異なるデバイス同士が通信するための何百万ものドア（API）があります。しかし、新しすぎるために以下の問題があります：

これらのドアの使い方を示す例が極めて少ない。
公式のマニュアルは図解や画像が多く、テキストベースのロボットには読めない。
既存のツール（他のロボット）は、どうやって侵入するかを推測しようとしますが、十分な情報がないため、失敗し続けています。

2. 解決策：3エージェント・チーム

HMFuzzerチームは、工程を順に引き継いでいく3つの特化したエージェントで構成されています。

エージェントA：「翻訳者兼整理係」（前処理エージェント）

役割： このエージェントは、乱雑な説明書を取り扱います。マニュアルには（ロボットが理解できない）フローチャートのような図解が多く含まれているため、このエージェントは「超高性能な目」を持つAI（マルチモーダル大規模モデル）を使用して、図解を見てそれを平易なテキストに変換します。
比喩： 混乱を招くスケッチだらけの本を受け取り、ロボットが実際に読めるように、すべての絵に対して詳細な物語の説明を書き起こす司書を想像してください。
権限チェック： このエージェントは「セキュリティガード」のルールも確認します。ロボットが制限区域への侵入を試みて検知されないよう、実際に触れてもよいドアのみをチェックします。

エージェントB：「ドライバー構築者」（ドライバー生成エージェント）

役割： このエージェントは、ドアをテストするための実際の「鍵」（ファズドライバー）を作成します。しかし、HarmonyOS専用の鍵のコピーが存在しないため、このエージェントは賢いアイデアを思いつきます：Androidを見ることです。
比喩： HarmonyOSとAndroidは、服の着こなしは違いますが、家族の系譜は似ている「いとこ」のような関係です。もしロボットがHarmonyOSのBluetoothドアを開ける方法を知る必要があるなら、AndroidがどのようにBluetoothドアを開けるかを見ます。膨大なAndroidの事例を「カンニングペーパー」として使い、HarmonyOSのドアがどのように機能するかを推測します。
「コーチ」（強化学習）： もしロボットが作った鍵が合わなかった場合（構文エラー）、「コーチ」が介入します。単に「間違い」と言うのではなく、コーチはスコアリングシステムを使用して、「次は具体的にこのような形状の鍵を作ってみなさい」と指示します。ロボットは失敗から学び、試行を重ねるごとに鍵を作る技術を向上させます。

エージェントC：「犯罪現場捜査官」（脆弱性分析エージェント）

役割： テストによってシステムがクラッシュしたとき（ドアが詰まったり、窓が割れたりしたとき）、このエージェントが調査を行います。
比喩： 以前のロボットはテキストログだけを見ていました。しかし、HarmonyOSは時として明確なテキストログを出さないことがあります。そのため、このエージェントはクラッシュの写真（スクリーンショット）を撮り、「超高性能な目」を持つAIを使用して、写真で何が起きたのかを記述します。
探偵の仕事： このエージェントは、写真の記述、テキストログ、そして既知の犯罪（脆弱性）のデータベースを組み合わせ、これが「単純なミス」なのか、それとも「真のセキュリティホール」なのかを判断します。また、「思考の連鎖（Chain of Thought）」という手法を用い、結論を出す前にステップバイステップで推論を組み立てます。

3. 結果：彼らは何を見つけたのか？

彼らの新しい部隊をHarmonyOS 5.0でテストした結果、他のツールが見逃していた本物のセキュリティホールを発見しました。

大きな成果： 彼らは、SVG画像（アプリで使用される小さなグラフィック）の処理に関する特定の脆弱性を見つけました。彼らは、バッファを破壊するほど長い数字の列（ティーカップの中に海水を注ごうとするようなもの）をシステムに送り込むテストを作成しました。その結果、システムはクラッシュし、セキュリティ上の欠陥が明らかになりました。
効率性： 彼らのチームは、単に力任せにテストするのではなく、よりスマートにテストを行ったため、他のツールよりも少ないコンピューターメモリを使用しました。
汎用性： 彼らはこのチームを他のシステム（PyTorchやTensorFlowなど）でもテストし、そこでも新しいバグを発見しました。これは、彼らのチームがHarmonyOSだけでなく、一般的なものを壊すことにおいて優れていることを証明しています。

まとめ

要約すると、この論文は、以下の3つのステップで動くスマートな3部構成のロボットチームについて述べています。

画像主体の分かりにくいマニュアルを、画像をテキストに変換することで読み解く。
より良いテスト用の鍵を作るために、似た構造を持つ古いシステム（Android）からアイデアをコピーする。
スクリーンショットとログを分析して、真のセキュリティホールを調査する。

彼らはこのツールを HMFuzzer と呼び、他のツールでは見ることができなかったHarmonyOSの脆弱性を、学習と改善を繰り返しながら見事に発見しました。

技術要約：HarmonyOS APIのためのマルチエージェント協調型ファジング

1. 問題提起

マイクロカーネルベースであり、統一されたAPIフレームワークを持つHarmonyOSは、ヘテロジニアスなデバイス間で大規模な展開を実現している。しかし、そのセキュリティは、特にそのAPI内における攻撃対象領域（アタックサーフェス）の拡大によって脅かされている。既存のファズツールは、以下の3つの主要な課題により、HarmonyOSを効果的にテストすることに苦慮している：

例題の不足： 成熟したエコシステムとは異なり、HarmonyOSには公開されているAPI使用例が乏しいため、自動化ツールが論理構造を理解することが困難である。
ドキュメントの制限： 公式の開発者ドキュメントは品質が低いことが多く、画像が多く含まれ、テキストとワークフロー図（フローチャートやシーケンス図など）が混在しているため、機械判読可能な形式での意味抽出を妨げている。
クラッシュ分析の困難さ： HarmonyOS APIのマイクロカーネルアーキテクチャと非同期的な性質により、クラッシュ特性が従来のOSとは異なる。既存の重複排除および分類アルゴリズムはしばしば失敗し、異なる脆弱性を誤って統合したり、単一の脆弱性を断片化したりする。

2. 手法：HMFuzzerフレームワーク

著者らは、最小限の人間の介入で脆弱性の特定を自動化するために設計された、マルチエージェント協調型ファジングフレームワークであるHMFuzzerを提案している。このフレームワークは、以下の3つの協調エージェントを統合している：

A. 前処理エージェント（Preprocessing Agent）

このエージェントは、ドキュメントおよび権限の障壁を克服するために入力データを準備する：

マルチモーダル意味論的アライメント： 画像主体のドキュメントに対処するため、このエージェントは3つのマルチモーダル大規模言語モデル（LLM）であるQwen、Llama、Geminiを用いて、APIワークフロー図（JPG/PNG）をテキスト記述に変換する。テキストベースのLLM（DeepSeek）がこれらの記述を融合して最終的かつ正確なテキスト表現を作成し、それがファイルパスを介して元のドキュメントとアライメントされる。
権限抽出： 権限不足による誤検知を防ぐため、エージェントは公式ドキュメントから権限要件（名称、説明、レベル、モード、有効性）を自動的に抽出し、対応するAPIに割り当てられる設定ファイルを生成する。

B. ドライバ生成エージェント（Driver Generation Agent）

このエージェントは、クロスプラットフォームの知識を活用することで、HarmonyOS特有の例題の欠如に対処する：

Android知識ベース（RAG）： HarmonyOSとAndroidの設計の類似性を認識し、システムは厳選された231個のAndroidサンプルコード（UI、ストレージ、ネットワークなどをカバー）をベクトルデータベースに埋め込む。検索拡張生成（RAG）を使用し、システムはセマンティックに類似したAndroidコードスニペットを抽出し、HarmonyOSドライバ生成のための学習データを補完する。
プロンプト最適化のための強化学習（RL）： ドライバの品質を向上させるため、エージェントはRLスキームを使用して、プロンプトテンプレート（CRISPE、CO-STARなどの基準に基づく）を動的に選択および変異させる。報酬関数（ $R$ ）は、構文の正しさ、エラー（警告、構文、意味、リンカ、プリプロセッサ）の最小化、および生成時間のバランスをとる。
構文検証： 生成されたドライバはArkCompilerを使用してコンパイルされる。構文チェックに失敗したドライバは、RLによって選択されたプロンプトのガイダンスに従って自動修復を行うために、エージェントに返される。

C. 脆弱性分析エージェント（Vulnerability Analysis Agent）

このエージェントは、実行結果を分析して脆弱性を特定する：

クラッシュキャプチャ： 特定のHarmonyOSバージョンにおけるログ収集の制限により、システムはログに加えてクラッシュスクリーンショットをキャプチャする。
マルチモーダル・クラッシュ分析： スクリーンショットはマルチモーダルLLMを介してテキストに変換される。これらの記述は、ログおよび脆弱性知識ベース（既知のCVEを含む）と組み合わされ、Chain-of-Thought（CoT）推論を利用するLLM（DeepSeek）に投入される。
分類： エージェントは脆弱性のタイプを特定し、既知のデータベースと相互検証を行い、未知のクラッシュを手動検証のためにフラグ立てする。

D. ファジングループ

システムは、シード（APIパラメータリスト）がエネルギー値で初期化されるループ内で動作する。LLMはこれらのシードに対して型認識型の変異を行う。シードのエネルギーは、ログ出力（警告、エラー、致命的なエラー）およびスクリーンショット内のクラッシュの有無に基づいて再計算され、次のテストケースの選択をガイドする。

3. 主な貢献

初のHarmonyOS向けファザ： HMFuzzerは、HarmonyOS APIに対してファズテストを適用するために特別に設計された最初のツールとして提示されている。
クロスプラットフォーム知識転送： HarmonyOS特有の例題の不足を補うために、Androidのサンプルコードライブラリを知識ベースとして統合するという斬新な手法。
マルチモーダル・ドキュメント処理： 画像ベースのワークフロー図をテキストに変換し、コード生成との意味論的アライメントを可能にする、マルチモーダルLLMを用いたパイプライン。
RL駆動型ドライバ生成： 構文エラーを修復し、ドライバの妥当性を向上させるために、プロンプトテンプレートを動的に最適化する強化学習メカニズム。
オープンソース実装： 著者らは、実用的な利用とさらなる研究を促進するために、HMFuzzerのコードをオープンソース化している。

4. 実験結果

実験はHuawei Nova 12 Ultraデバイスを用い、HarmonyOS Next 5.0に対して実施され、HMFuzzerをベースラインであるfuzz4ALLおよびTitanFuzzと比較した。

脆弱性の発見： HMFuzzerは、バッファオーバーフローを含む既知のSVG解析の脆弱性（CVE-2024-58115）を検出したが、ベースラインのツールはいずれもこれを特定できなかった。ベースラインは、特定の例題が不足していたため、効果的なSVG関連ドライバを生成できなかった。
ドライバの品質： アブレーション研究において、各モジュールの統合は、利用可能なドライバ数（UD）において段階的な改善を示した：
- ベースライン: 134 UD
- - RL: 157 UD (+17%)
- - RL + Android Examples (AEC): 167 UD (+25%)
- - RL + AEC + Multimodal Generation (MMG): 174 UD (+30%)
LLMの選択： DeepSeekがドライバ生成において最も効果的なモデルであることが特定された。DeepSeekは141回のイテレーションで134個の有効なドライバを生成し、Qwen（160回で72個の有効なドライバ）やChatGPT（236回で106個の有効なドライバ）を上回った。
汎用性： 非HarmonyOSターゲット（PyTorchおよびTensorFlow）でテストした際、HMFuzzerはPyTorchにおいて既知の2つと未知の3つの脆弱性を、TensorFlowにおいて既知の4つと未知の3つの脆弱性を確認した。
効率性： HMFuzzerは、軽量なランダム変異戦略により、TitanFuzzやFuzz4Allと比較して低いメモリ使用量を示した。
複合脆弱性： HMFuzzerによって発見された脆弱性の98.25%が複合脆弱性として特定された。これは、TitanFuzzが見つけた41.5%よりも大幅に高い。

5. 重要性と主張

本論文は、HMFuzzerが、例題の不足やマルチモーダル・ドキュメントの複雑さといったHarmonyOSエコシステムの特有の課題に効果的に対処していると主張している。成熟したAndroidエコシステムを代理知識ベースとして活用し、マルチモーダルLLMを用いてドキュメント解析を行うことで、本フレームワークはドライバ生成の品質と脆弱性発見の効率を大幅に向上させている。著者らは、彼らのアプローチが手動の労力を軽減しつつ、バッファオーバーフローやサービス拒否（DoS）ベクターを含む重大な脆弱性を明らかにすることで、急速に拡大するHarmonyOSエコシステムのセキュリティに貢献していると断言している。