AsmRAG 論文閱讀分析：很多 malware detection 真正缺的，不是再多一個高分分類器，而是把作怪的那段邏輯找回來
本文由 AI 產生、整理與撰寫。
論文基本資訊
- 論文標題：AsmRAG: LLM-Driven Malware Detection by Retrieving Functionally Similar Assembly Code
- 作者：ElMouatez Billah Karbab
- 年份：2026
- 來源：arXiv:2604.23196
- 論文連結：https://arxiv.org/abs/2604.23196
- DOI：10.48550/arXiv.2604.23196
- 主題：Malware Detection、RAG、Assembly Analysis、Explainable Security、Obfuscation Resilience、SOC
這篇 paper 最值得看的地方，不是它把 malware detection 又包成一次 LLM demo，而是它直接瞄準一個藍隊現場其實很痛的老問題：很多模型不是不會判惡意，而是判了之後根本交不出能讓分析師採信的證據。
傳統深度學習惡意程式偵測器常常給你一個高分數，但 SOC 真正缺的不是分數，而是到底哪段邏輯有問題、像哪一類家族、為什麼這次混淆後還能說它惡意。AsmRAG 要補的，就是把「分類器說你有毒」改成「我把最像的惡意邏輯片段找給你看」。
這篇論文在解什麼問題？
作者的出發點很清楚：現在很多 malware detector 靠的是全域特徵，例如 byte n-gram、opcode 統計、entropy、整體影像化特徵，或更大顆的 end-to-end deep model。這些方法有兩個老毛病：
- 可解釋性差：它只能告訴你「像惡意」，但很難告訴你是哪段程式邏輯像。
- 容易被語法層混淆干擾：dead code insertion、register substitution、control-flow flattening 這種招數，不一定改變惡意行為，卻很容易把表面特徵拉歪。
所以這篇 paper 的核心主張其實很直白：
如果惡意程式真正重要的是功能語意，而不是表面長相，那偵測系統就不該只做整體分類，而應該去檢索「功能上相似的惡意 assembly 片段」。
換句話說，AsmRAG 把 malware detection 從「黑盒分數判斷」改寫成「證據導向的語意檢索」。這不只是模型換皮，而是整個任務 framing 變了。
AsmRAG 的核心想法：不是先問這支 binary 像不像惡意，而是先問哪個 function 最值得當證據
作者不是直接把整個 binary 丟給 LLM，而是拆成函式級（function-level）做語意表示。這樣做有兩個好處：
- 可以把分析重心放回真正執行惡意邏輯的局部區塊，而不是被整支程式的大量 boilerplate 稀釋。
- 就算攻擊者在整體檔案層級塞很多噪音，只要核心惡意函式的語意還在，就還有機會被拉回同一個鄰域。
整條流程大致可以拆成幾層：
- 先從 binary 中抽出 assembly functions。
- 用 code-specialized LLM 把每個 function 轉成 semantic embeddings。
- 把既有惡意樣本做成可搜尋 knowledge base。
- 推論時，不是看整體檔案分數，而是找出最像已知惡意邏輯的「anchor function」。
- 再把這個 anchor 與檢索回來的惡意證據片段對齊，生成人能看懂的 forensic explanation。
這裡最關鍵的不是 RAG 三個字，而是它把 retrieval object 從文件段落換成了 assembly-level malicious logic。這件事一改，系統就不再只是「用 LLM 幫分類講講話」，而是開始接近「拿檢索到的程式語意證據去支撐判斷」。
作者怎麼處理混淆問題？關鍵在 semantic manifold，不在表面字串
這篇 paper 一直反覆強調一個概念：semantic invariance amidst syntactic variance。意思是說，攻擊者可以把 assembly 的表面長相改很多，但如果真正的資料流、狀態轉移與惡意意圖沒變，語意上它還是同一件事。
作者的做法不是硬做 canonicalization，把所有 assembly 正規化到失去細節，而是盡量保留語意，再讓 embedding 模型去學「不同寫法但功能相同」的接近性。這個思路的重點是：
- 不要太早把低階細節磨平，否則很多攻擊語意會一起被洗掉。
- 也不要只看表面 token 分佈，否則 register 換一下、nop 插一下，距離就飄走。
作者把這件事描述成一種「投影回語意流形」：乾淨惡意樣本與混淆後變種，在原始特徵空間可能離很遠，但在功能語意空間裡應該還要能靠近。
這篇 paper 最有意思的工程點：Density-Weighted Anchor Selection
我自己最喜歡的是它不是只做 nearest-neighbor retrieval，而是進一步設計了 Density-Weighted Anchor Selection，去決定哪個 function 才是真正值得拿來當證據核心的那個點。
這件事很重要，因為一個 binary 裡面可能很多函式都會跟別人「有點像」，但真正有價值的是那個：
- 落在惡意鄰域比較密的地方
- 能代表主要 malicious logic
- 不是被 benign library code 或普通初始化流程稀釋掉的片段
所以 AsmRAG 的想法不是「把所有可疑函式都講一遍」，而是先找出那個最像主犯的 anchor，再把檢索證據繞著它展開。這比起很多 explainable AI 常見的 saliency map 式說明更實用，因為它輸出的不是抽象熱區，而是可對照、可比對、可交接給分析師的 assembly 邏輯片段。
結果怎麼樣？高分不是唯一重點，重點是混淆後還有沒有證據鏈
作者在一個涵蓋 40,814 個 binary、17 個 malware families 的資料集上評估，給出的主結果不差：
- malware detection F1：約 96%～96.5%
- family attribution F1：約 95%
如果只看數字，這當然已經夠漂亮；但我覺得更值得注意的是作者怎麼定義它的價值：當 EMBER、ResNeXt 這種偏 holistic 的 baseline 在 obfuscation 下開始掉分時，AsmRAG 這種語意檢索路線比較能守住。
這裡的訊息不是「以後大家都用 RAG 就好」，而是：
在 malware 分析這種本來就需要證據與可解釋性的工作裡，semantic retrieval 比單純 discriminative scoring 更接近 analyst 真正要用的系統形態。
這篇論文真正補到哪裡？
如果你把這篇放回整個 AI for malware analysis 的脈絡看，它真正補的不是再一次證明「LLM 能看 assembly」，而是補了三個比較實際的缺口。
1. 從 verdict 走向 evidence
很多 detection paper 停在「模型分對了」。但在真實調查裡，分析師接下來會問：
- 哪段邏輯有問題？
- 它像哪個已知惡意家族？
- 這次混淆後到底是哪個部分還暴露了它？
AsmRAG 至少在系統設計上，是往這條路走。
2. 從 file-level 特徵回到 function-level 語意
很多 evasion 技術能騙過整體統計，但比較難完全改掉核心函式的功能角色。AsmRAG 把焦點移到 function-level，就是在切這個面。
3. 從可解釋性口號走向 forensic explainability
很多 XAI 只是在分類器上再貼一層解釋；這篇比較像反過來：先把檢索證據做成一級公民，再讓 explanation 圍繞證據長出來。 這種思路在資安裡通常比較有用。
我怎麼看它的限制？
這篇我覺得方向對，但也有幾個地方要冷靜看。
1. dataset 與真實惡意生態之間還有距離
17 個 malware families、4 萬多個 binaries 當然不算小，但距離真實世界惡意程式生態仍有落差。尤其如果進一步碰到：
- packing / unpacking 鏈
- 多階段 loader
- 只有局部 payload 真正惡意的樣本
- 大量共用開源元件與惡意邏輯混雜
anchor function 是否還那麼穩，值得再看。
2. function extraction 與 disassembly 品質本身就是前提
這類方法有一個很現實的依賴：你得先把函式切得像樣，assembly 還得反得夠乾淨。 如果前面 disassembly 就已經錯很大，後面的 semantic embedding 再漂亮也可能建在歪掉的地基上。
3. RAG 不是免費午餐
要把 function-level knowledge base 維持得好，背後其實有成本：
- 向量庫怎麼更新
- 家族標籤怎麼維護
- retrieved evidence 會不會被污染
- 跨 compiler、跨平台、跨架構時 embedding 會不會漂
所以它比較像是在建立一種 analyst-facing evidence system，而不是一個零維護的魔法分類器。
為什麼這篇對 SOC / malware triage 有意思？
因為這篇在某種程度上碰到了藍隊一直想要但很難拿到的東西：不是只有告警分數，而是跟告警一起交付的程式級證據。
如果這條路做得更成熟，理想中的交付物應該會長得像：
- 這個 binary 可疑
- 最可疑的是哪個 function
- 它跟哪個已知家族的哪段邏輯最像
- 相似點在資料流 / API 用法 / 解密迴圈 / persistence 邏輯哪裡
這種輸出才比較像能進分析流程、進 case management、進 analyst handoff 的東西。也因此我會把它看成是把 malware ML 從「高分分類器」往「可交付調查證據系統」推一步。
總結
AsmRAG: LLM-Driven Malware Detection by Retrieving Functionally Similar Assembly Code 這篇論文真正有價值的，不是它再一次證明 LLM 可以讀 assembly，而是它把惡意程式偵測的重心，從黑盒分數往可驗證證據挪了一大步。
它最值得記住的一句話，我會這樣寫：
很多 malware detection 真正缺的，不是再多一個更高分的分類器，而是混淆完之後，還能把「哪段惡意邏輯在作怪」找回來。
如果你在看的是 SOC、malware triage、binary analysis、或 AI for security 這條線，這篇值得放進你的待讀清單。因為它討論的不是「模型能不能猜」，而是模型能不能拿出夠像證據的東西，讓人真的敢用。