MARD 論文閱讀分析：很多 Android malware detection 真正缺的，不是再多一個 classifier，而是把可疑一路追成可定罪的證據
論文基本資訊
- 論文標題：MARD: A Multi-Agent Framework for Robust Android Malware Detection
- 作者：Xueying Zeng、Youquan Xian、Sihao Liu、Xudong Mou、Yanze Li、Lei Cui、Bo Li
- 年份：2026
- 來源：arXiv:2604.25264
- 論文連結：https://arxiv.org/abs/2604.25264
- 主題：Android Malware Detection、LLM Agents、Static Analysis、Concept Drift、Mobile Security
這篇 MARD: A Multi-Agent Framework for Robust Android Malware Detection 讀起來有一種很明顯的訊號：很多 Android malware detection 真正缺的，不是再換一個分數更高的 classifier，而是把「語意理解」跟「程式證據」重新接起來。
作者想打的不是傳統 malware detection 會不會再多 1% F1，而是更根本的老問題：模型一旦只吃 API、permission、graph embedding 這些統計特徵，時間一久就會老化；碰到新家族、新包裝、新行為脈絡，concept drift 會直接把你打回原形。 這篇 paper 的回答不是單純把 LLM 塞進 pipeline，而是讓 LLM 當 orchestrator，把 deterministic static analysis engine 當成工具，做出一條可以追因、可讀、可驗的惡意判定證據鏈。
這篇論文要解的核心，不是「LLM 能不能看 APK」，而是「怎麼別讓 LLM 被 APK 淹死」
這點我很買單。很多把 LLM 拿來做 security analysis 的做法，常常第一步就太貪心：把一大堆 decompiled code、call trace、function snippet 直接餵進去，然後期待模型自己看懂。問題是：
- token 成本很容易炸開
- context window 很容易被雜訊吃掉
- 模型雖然能講語意，但未必能在龐大程式上下文裡自己找到真正的關鍵控制流
MARD 的做法比較務實：不是讓 LLM 直接讀完整 APK，而是先用 Apktool、Soot、FlowDroid 這些 deterministic engine 把程式空間壓成可導航的分析底座，再讓 agent 去問對的問題、叫對的工具、追對的線索。
這個 framing 很重要。因為在 malware detection 裡，真正稀缺的往往不是更多文字理解能力，而是把有限 reasoning 預算用在最有嫌疑、最值得追的地方。
作者的架構重點：先粗篩，再追線，再判案
整個 MARD 架構大致可以拆成四層，但我認為核心節奏其實只有三步：
- 先做 deterministic representation：把 APK reverse 成 Manifest、Jimple IR、call graph、API inverted index。
- 再做 macro-level heuristic screening：先看 app 宣稱的功能和它要求的 permission 到底合不合理。
- 最後才做 micro-level forensic tracing：沿著可疑 API 回推觸發路徑、資料流、切片依賴，再交給 Verdict Agent 做整體判定。
換句話說，它不是把多 agent 當噱頭，而是把 agent 拿來實作一個很像人類分析員的流程：先抓不對勁，再縮小範圍，再追證據，最後下結論。
Manifest intent 和 permission mismatch，是便宜但很有用的第一刀
論文裡的 Reconnaissance Agent 先看 app 的 declared intent，再對照它實際要求的 sensitive permissions。這個想法表面上不新，但作者把它放在整個 pipeline 的最前面，而且不是為了直接判惡意，而是為了縮小後面要深挖的 API 搜尋空間。
這個設計我認為很對。因為很多安全系統最容易犯的錯，是把所有程式元素都當成同樣值得分析，最後 token、時間、算力都被平均浪費掉。MARD 這裡的策略剛好反過來：
- 先用 permission/intent mismatch 當風險信號
- 再把這些信號映射回 API inverted index
- 最後只針對縮小後的可疑 API 集合做深度追蹤
你可以把它想成一種 reasoning budget allocator。不是每個 API 都值得 LLM 花腦力，只有那些跟可疑權限、功能語意不對齊的部分，才配得到更昂貴的 forensic tracing。
真正有料的是 Traceability Agent：不是摘要程式，而是把控制流和資料流追成證據
我覺得這篇 paper 最值得看的地方在這裡。很多所謂「LLM 做 malware detection」其實還停在 feature summarization：把 API sequence、permission list、函式片段翻成比較像人話的描述，然後再交給下游模型分類。這樣做不是沒用，但本質上還是在包裝特徵。
MARD 更進一步的地方，是它讓 Traceability Agent 真的去調底層分析引擎，做幾件很關鍵的事：
- Local Context Retrieval：精準抓可疑 API 附近的 Jimple 程式片段
- Trigger Path Search：回推這個 API 到底是被 user action 觸發，還是被 background event 默默喚醒
- Data-Flow Reachability Analysis：把 API 回傳值當 source，看會不會流到 network、storage 等 sink
- Dependency Slicing Extraction：把真正影響關鍵行為的最小依賴子圖切出來，排掉雜訊和假動作
這代表它不是只問「這段 code 看起來可不可疑」，而是更進一步問：
- 這個能力是怎麼被叫起來的？
- 資料最後流去哪？
- 有沒有形成完整的惡意操作鏈？
- 哪些程式依賴真的支撐這個判斷？
這種問法，才真的比較像 malware analysis，而不只是 code captioning。
作者其實在做一件更關鍵的事：把 black-box detection 變成 conviction workflow
論文裡一直強調 interpretable evidentiary chain，我認為這不是行銷詞，而是這篇 paper 最實際的價值。傳統 deep learning 型 malware detector 常見問題是：
- 你知道它判惡意
- 但你不知道它到底看到了什麼
- 也很難判斷它是不是被新型變種、資料漂移或 shortcut feature 帶偏
MARD 想補的不是單純 explainability，而是讓判惡意這件事更接近「可提交的案件」而不只是「分數超過閾值」。Reconnaissance Agent 提供 macro risk，Traceability Agent 提供 control/data-flow 證據，Verdict Agent 再把這些拼成帶 threat category 和 confidence 的最終結論。
對防守方來說，這差很多。因為在實務上，真正麻煩的不只是抓不抓得到 malware，而是你要不要信這個結果、要不要把它升級處置、能不能拿去說服別人。
這篇 paper 打得很準的一個痛點：concept drift 不只是資料老化，而是語意脈絡在變
作者把傳統模型會老化這件事講得很清楚。以前很多方法靠 API call、permission、graph centrality、embedding cluster 等靜態特徵吃飯，短期內可能有效，但 Android 生態和惡意樣本一直變，最後模型會出現很明顯的 performance aging。
我覺得這篇 paper 的洞見在於：這不只是特徵分布變了，而是行為的語意包裝也在變。 同一個惡意目的，可以換新 API、換新觸發方式、換新組裝路徑，甚至故意把惡意動作拆散。這時候如果檢測器還停在固定 feature space，就很容易只剩下記舊招。
MARD 的優勢來自它不只看表面 token 或結構，而是透過 agent + tool 的組合，回頭追：
- 功能宣告和權限要求是否對齊
- 可疑 API 是否真的被關鍵路徑觸發
- 敏感資料是否真的可達外傳或本地落地 sink
- 依賴切片是否構成完整惡意意圖
也就是說，它試著把泛化能力綁回比較穩定的「行為證據結構」，而不是只綁在某一代樣本的表面分布上。
實驗結果好看的地方，不只是 F1 93.46%，而是它撐住了時間跨度
論文裡最亮眼的 headline 當然是：在 CICMalDroid 2020 上，MARD 在 zero-shot、無 task-specific fine-tuning 的前提下拿到 94.35% accuracy、93.46% F1。但我認為更值得看的是它對 concept drift 的耐受度。
作者用 2017 到 2021 的時間切片測長期表現，傳統資料驅動模型的退化很明顯。像 DroidEvolver 的 recall 會從 2018 年的 78.38% 一路跌到 2021 年只剩 8.00%，幾乎等於失能。CL-Malware 雖然靠 continual learning 撐比較久，但到了後段還是掉得很明顯。
MARD 的重點不是永遠第一，而是它在這段時間內維持相對穩定，論文描述其 F1 五年都能維持在 84% 以上。這個訊號很重要，因為它意味著：作者不是只在一個靜態 benchmark 上把題目做熟，而是讓系統對演化中的 Android malware 還保有辨識能力。
另一個有意思的結果：強模型 + 微觀追線，比輕模型瞎保守好多了
論文也做了不同 LLM backbone 的比較，這部分其實很誠實。結果顯示，不是隨便換個 LLM 進來就會好。像 Gemini-3-pro、GPT-5.2、GLM-4.7 這類推理比較強的模型，整體 verdict 品質明顯更穩；但比較輕的模型雖然 recall 很容易衝到 100%，precision 卻會掉得很難看，代表它們傾向把一堆可疑樣本通通打成惡意。
這很像實務上的一種常見故障模式：模型不是看懂了，而是因為看不懂，所以乾脆全部判危險。 這對產品 demo 很漂亮，對 SOC 或 app vetting 現場卻很痛苦，因為 false positive 會直接淹死人。
更關鍵的是，論文把 micro-level autonomous forensics 拿掉之後，表現也顯著變差。這說明一件事：真正有用的不是「LLM 參與過」，而是它有沒有拿到可驗的程式證據，並沿著證據完成判定。
我對這篇 paper 的保留：靜態分析仍然是它的地基，所以地基的盲點還在
雖然我整體喜歡這篇 paper，但還是得說，它的核心能力仍然建立在 static analysis 可見的世界上。這代表幾個潛在限制：
- 如果惡意邏輯高度依賴 runtime loading、native code、dynamic instrumentation，靜態切圖可能看不全
- 如果樣本刻意用反分析技巧把控制流打散，LLM 再聰明也只能在不完整證據上推理
- 「每個 APK 低於 0.10 美元」很吸引人，但真實大規模部署還要看吞吐量、分析延遲、併發成本與失敗重試
所以我會把這篇 paper 的貢獻理解成：它不是終結 Android malware detection，而是把 LLM 在這個問題上的角色，從會說故事的摘要器，拉成會調工具、會追證據、會下結論的分析員。
總結
MARD: A Multi-Agent Framework for Robust Android Malware Detection 最值得看的地方，不是它又做了一個 multi-agent 架構，而是它抓到了 Android malware detection 真的卡在哪：不是單純缺更多特徵，也不是缺一個更大的分類器，而是缺一條能同時保留語意理解、程式可追性與時間泛化能力的分析鏈。
如果要用一句話總結我的閱讀感想，那會是：
很多 Android malware detection 真正缺的，不是再多一個會打分的模型，而是先把「可疑」一路追成「可定罪」的證據。
對做 mobile security、malware research、app vetting、或想把 LLM 拉進靜態分析流程的團隊來說，這篇 paper 很值得看，因為它提供的不是一個漂亮口號，而是一條相對像樣的落地路線。
本文由 AI 產生、整理與撰寫。