Black Hat Europe 2025 | Offensive Testing Of HarmonyOS NEXT Applications With Harm0nyz3r & DVHA
三句話摘要
HarmonyOS Next安全研究：用AI驅動的源代碼分析與移動應用漏洞識別方法論。 LLM能加速安全研究中的漏洞候選識別，但只有結合領域專家的審慎驗證與完善的反幻覺策略，才能將AI輔助轉化為可靠的、可規模化的代碼安全分析能力。 LLM用於源代碼分析的準確性取決於使用者的領域知識——演講者強調「如果你不知道自己在做什麼，最好別做這件事」，LLM只能輔助自動化，並非替代專家分析；低效的提示會導致大量幻覺，反而增加驗證負擔。
重點整理
重點- 1
LLM用於源代碼分析的準確性取決於使用者的領域知識——演講者強調「如果你不知道自己在做什麼，最好別做這件事」，LLM只能輔助自動化，並非替代專家分析；低效的提示會導致大量幻覺，反而增加驗證負擔。
- 2
三層反幻覺策略比單一模型更有效——使用不同的LLM驗證（如GPT-4與Claude）、多輪投票、針對假陽性的專門提示，以及自動化腳本處理簡單任務，能顯著降低誤報率，但完全消除幻覺仍不可能。
- 3
HarmonyOS Next的沙箱與權限模型介於iOS與Android之間——採用能力模型+SELinux、分級資料保護類型、制限應用程式提取需要越獄，這些設計提高了研究難度，但也意味著應用層漏洞利用空間有限。
- 4
開源工具化與社群透明度是規模化安全研究的基礎——Harmonizer作為Android Drozer的HarmonyOS等價物，整合應用列舉、IPC互動、模糊測試、日誌記錄，讓安全研究員可複製與擴展研究方法。
實用技巧與重點
乾貨- HarmonyOS Next 技術細節：
- 首個不基於Android核心的版本，採用OpenHarmony
- 新核心：Homeman（微核架構、能力型、非Linux）
- 應用語言：ArcDS（TypeScript衍生，編譯到Panda/ABC中間碼）
- 類比對照：HAP ↔ APK、ArcDS ↔ Kotlin/Java、NAPI ↔ NDK
- 權限分級：system-grant、user-grant（需彈窗）、restricted（廠商審核）
- 資料保護：6個資料安全等級，對應不同加密強度
- 主要IPC機制：Ability（類似Activity）、Intent-like、Service Extension、UDMF（推薦的跨應用資料共享）
- AI分析工作流：
- 初篩（Heuristic 1）：輕量級LLM篩選700個倉庫，基於CVE、提交活動、壞習慣評分
- 手工審核：確認篩選結果
- 動態提示生成：根據自動分類（media library、crypto、parser等），生成特定上下文提示
- 並行分析：各倉庫獨立分析，結果聚合
- 反幻覺驗證：不同模型投票、假陽性檢測、結構化輸出（JSON）
- 已識別漏洞案例：
- HTC注入：user-controlled install command → 檔案建立
- 路徑遍歷：URL解析器移除檢查不完整
- Toybox ping記憶體讀取：未初始化記憶體被用於統計
- SQL錯誤轉換為-1的業務邏輯缺陷
- Harmonizer 功能：
- 連接方式：HDC命令執行 + Socket應用互動（類同Drozer架構）
- 應用列舉與權限檢查
- Ability啟動與互動
- IPC與UDMF測試
- 字典與變異模糊測試
- 完整日誌記錄
- 開發環境限制：
- 無官方模擬器（過去有Simulator已停用）
- 開發者帳號需提供銀行卡和身分證（無馬賽克）
- 無Bootloader解鎖、Homeman核心閉源加密
- 無應用提取API（需越獄，如iOS）
- Open Harmony與Harmony OS Next 有重大差異
- 相關工具與資源：
- ABC編譯器：基於Jadex改進（Android常用工具）
- 命令列反彙編器：由華為提供
- 預定發布：DAMM Vulnerable App、Harmonizer（GitHub）
- 計畫中：iOS/Android版本、AI Agent發布、OWASP測試指南更新
結論
結論“LLM能加速安全研究中的漏洞候選識別，但只有結合領域專家的審慎驗證與完善的反幻覺策略，才能將AI輔助轉化為可靠的、可規模化的代碼安全分析能力。”
完整解析
詳細Jorge Wallace代表DECRA cybersecurity團隊分享了為期3-4週針對HarmonyOS Next生態的安全研究方法論，核心策略是將AI語言模型用作「智能代碼分析助手」而非「自動漏洞獵人」。研究起因於團隊原計畫延誤，遂決定改投HarmonyOS Next——華為2024年10月發佈的首個不依賴Android核心的移動系統。面對700個Open Harmony開源倉庫，單靠人力無法逐一分析，於是開發了三階段AI輔助篩選系統。
第一階段（初篩）使用輕量LLM（如Claude）根據CVE歷史、提交模式、安全實踐評分來排序倉庫的漏洞風險等級，生成優先處理隊列。但這一步會產生幻覺，因此團隊進行手工審核確認篩選的合理性。第二階段在確認倉庫後，系統自動分析代碼結構（如識別某倉庫是媒體庫還是加密模組），動態生成針對性提示。例如，媒體庫的分析重點是格式解析漏洞，加密模組則關注金鑰管理。第三階段並行分析各倉庫，之後聚合並反覆驗證。為了對抗LLM幻覺，團隊實施了多層策略：(1)使用不同LLM交叉驗證同一代碼片段；(2)執行專門提示尋找假陽性；(3)限制輸出格式為JSON；(4)對簡單任務改用正則腳本而非LLM；(5)建立投票機制，多輪分析取多數意見。結果表明，即使這樣，幻覺仍存在，但實際漏洞率顯著上升。
真實發現包括：HTC服務的命令注入（用戶可控install參數導致檔案建立）、應用沙箱內的路徑遍歷、Toybox ping因未初始化記憶體讀取而計時異常、SQL錯誤被統一轉為-1導致業務邏輯繞過等。演講者強調，LLM擅長識別業務邏輯缺陷——這是傳統靜態工具難以檢測的——但邊界情況和複雜利用鏈仍需人工驗證PoC。AI在速度上的收益明顯（完整研究週期僅3-4週），但代價是所有LLM發現的候選都需要逐一驗證，這本身是密集的人工工作。
在移動應用層，團隊開發了Harmonizer——HarmonyOS Next版本的Android Drozer工具。HarmonyOS應用架構採用ArcDS語言（TypeScript方言），編譯至Panda中間碼，類同Android的DEX格式。應用沙箱模型融合Android的標準隔離和iOS的細粒度資料保護類型（6個等級對應不同加密強度）。Harmonizer通過HDC連接設備執行殼層命令，同時與應用內Socket通信進行IPC測試、Ability啟動、UDMF資料傳遞模糊測試等。實際測試中發現華為預裝應用的安全問題，如「Hello World」字串出現在生產應用。
展望方面，團隊計畫發布DAMM Vulnerable App（受限環境安全練習應用）與Harmonizer、擴展至iOS/Android、待漏洞披露完成後公開AI Agent源碼、貢獻OWASP移動應用安全驗證標準與測試指南，加入HarmonyOS特定測試用例。演講者也分享了實踐教訓：(1)本地LLM（如開源GPT 120B）成本約5000歐元的服務器，可與ChatGPT匹敵且不涉及雲上隱私外洩；(2)法律與授權限制必須遵守——生產環境代碼分析需明確批准；(3)PoC開發往往是AI分析的主要時間瓶頸，因HarmonyOS難以取得root權限進行自動化驗證。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
