AI 系統記憶體鑑識
調查被妥協 AI 系統的記憶體鑑識技術,涵蓋 GPU 記憶體分析、模型權重萃取與執行期狀態復原。
概觀
AI 系統的記憶體鑑識將傳統數位鑑識延伸至機器學習工作負載獨特的執行期環境。AI 系統在推論與訓練期間於 CPU 與 GPU 記憶體中維持複雜狀態:模型權重、優化器狀態、注意力快取(KV 快取)、中間激活值、分詞器組態,以及動態載入的適配器權重。當 AI 系統被妥協——無論透過模型竄改、未授權微調或執行期操縱——記憶體鑑識為調查人員提供擷取當下系統實際狀態的快照。
傳統記憶體鑑識工具如 Volatility 為 CPU 可定址記憶體與作業系統成品設計。然而 AI 工作負載將關鍵狀態分散於 GPU VRAM、統一記憶體架構,以及需要專門萃取技術的框架管理記憶體池。本文涵蓋 AI 系統記憶體鑑識的端到端流程,從擷取、分析到報告。
重要性不容忽視:若攻擊者在未修改磁碟檢查點的情況下修改了記憶體中的模型權重,只有記憶體鑑識調查能揭露竄改。同樣地,若攻擊者於模型服務管線中注入於執行期修改輸出的惡意程式碼,記憶體分析可能是復原注入邏輯的唯一途徑。
AI 系統的記憶體架構
CPU 記憶體佈局
AI 服務框架(vLLM、Triton Inference Server、TorchServe)於 CPU 記憶體維持數類資料:
- 模型組態:超參數、分詞器詞彙、生成參數
- 請求佇列:待處理推論請求含完整提示詞文字
- 回應緩衝區:交付給客戶端前的生成輸出
- 框架元資料:排程狀態、批次組成、記憶體配置映射
- 日誌緩衝區:最近推論事件的環形緩衝區
GPU 記憶體佈局
GPU VRAM 含計算活躍元件:
- 模型權重:定義模型行為的參數張量,通常為量化格式(FP16、INT8、INT4)
- KV 快取:活躍生成會話的鍵值注意力快取,含模型對進行中對話的「工作記憶」
- 激活張量:前向傳遞期間的中間計算結果
- CUDA 圖:為優化推論路徑預編譯的計算圖
統一記憶體與 NVLink
現代 GPU 架構支援統一虛擬定址(UVA),CPU 與 GPU 記憶體呈現為單一位址空間。透過 NVLink 連接的多 GPU 系統透過張量並行或管線並行分散模型權重,意味完整模型狀態可能散佈於多個 GPU。
記憶體擷取技術
CPU 記憶體取證
標準記憶體取證工具適用於 AI 系統狀態的 CPU 部分。Linux 系統上主要方法:
# Method 1: /proc filesystem capture (requires root)
AI_PID=$(pgrep -f "vllm.entrypoints")
cp /proc/${AI_PID}/maps /evidence/proc_maps_$(date +%s).txt
# Focus on heap regions where model configs and request data reside
grep "heap" /proc/${AI_PID}/maps
# Method 2: Using gcore for a complete process core dump
gcore -o /evidence/ai_server_core ${AI_PID}
# Method 3: Using LiME (Linux Memory Extractor) for full system memory
# insmod lime.ko "path=/evidence/full_memory.lime format=lime"上述方法依序為:(1) 透過 /proc/{pid}/maps 擷取執行中程序的記憶體對應檔,並針對 heap 區域採取特定擷取,heap 中含模型組態與請求資料;(2) gcore 產生完整程序核心傾印(會短暫暫停程序,需與營運團隊協調);(3) LiME 核心模組擷取整個系統記憶體。
GPU 記憶體取證
GPU 記憶體取證更複雜,因 GPU VRAM 無法從主機 CPU 程式碼直接定址。主要方法是透過模型物件 API 萃取。
GPUMemoryCapture 資料類別含 capture_time、gpu_device、tensors 字典(名稱 → 形狀/dtype/雜湊/資料路徑)、gpu_info、cuda_memory_stats。
capture_gpu_state(model, output_dir, device_id) 擷取模型完整的 GPU 常駐狀態以供鑑識分析:
- 呼叫
torch.cuda.synchronize(device_id)確保所有 CUDA 操作完成 - 迭代所有參數(
model.named_parameters()):將參數搬至 CPU、計算 bytes 的 SHA-256、以 torch.save 存檔 - 為每個參數記錄形狀、dtype、device、雜湊、資料路徑、requires_grad、大小
- 同樣處理所有緩衝區(
model.named_buffers(),如批次正規化的 running means、variances) - 擷取 GPU 資訊(名稱、總記憶體、運算能力)與
torch.cuda.memory_stats - 將清單寫入
capture_manifest.json
KV 快取萃取
KV(鍵值)注意力快取因含模型對活躍會話中所有處理符元的計算表示,鑑識價值特別高。萃取 KV 快取可揭露正在處理哪些提示詞,以及模型運作的對話上下文。
extract_kv_cache_forensics(kv_cache, output_dir) 對每層 (keys, values) 張量對:擷取序列長度(形狀為 (batch, num_heads, seq_len, head_dim) 或更早維度)、計算 keys 與 values 的 SHA-256、以 torch.save 存檔。回傳含每層資訊與總快取符元數的分析結果。
分析記憶體擷取
權重完整性驗證
最關鍵的分析是將擷取的權重與已知良好的參考總和檢查碼比對。任何差異指出模型竄改或未授權更新。
verify_weight_integrity(capture_manifest, reference_hashes) 比較擷取的模型權重雜湊與參考總和檢查碼:
- 計算擷取/參考名稱集合的差異以找出遺失或額外項目
- 對每個匹配名稱比對 SHA-256,若不符記錄於 mismatches(參數名、預期雜湊、擷取雜湊、形狀、dtype)
- 總體狀態為 VERIFIED(無不符且無遺失)或 COMPROMISED
偵測被注入的適配器權重
取得模型服務系統存取權的攻擊者可能注入 LoRA 適配器權重以修改模型行為,而不改變基礎模型權重。此做法在鑑識上隱匿,因基礎模型雜湊仍會與參考匹配。
detect_unexpected_adapters(model, expected_adapter_names) 掃描模型尋找未預期的 LoRA 或適配器模組:
- 迭代所有模組,若型別名稱含 lora/adapter/prefix/prompt_tuning/ia3 等關鍵字則視為適配器
- 預期清單內為 expected_adapters,否則為 unexpected_adapters
- 另外掃描可疑命名參數(含 inject/hook/patch/backdoor 等關鍵字),加入 suspicious_modules
執行期勾子偵測
PyTorch 的勾子(hook)機制允許程式碼攔截前向與反向傳遞。攻擊者可註冊修改模型輸出而不改變權重的勾子。鑑識分析應列舉所有註冊的勾子。
enumerate_model_hooks(model) 列舉模型所有已註冊的前向與反向勾子:
- 攻擊者可用勾子來根據觸發輸入修改特定輸出、透過側通道外洩資料、選擇性繞過安全過濾器
- 對每個模組檢查
_forward_hooks、_backward_hooks、_forward_pre_hooks - 記錄模組名稱、勾子 ID、勾子函式字串、來源檔案
- 總計所有勾子數量
AI 框架的程序記憶體分析
Python 物件復原
AI 服務系統通常以 Python 程序執行。傳統記憶體鑑識可輔以 Python 特定分析以從 heap 復原物件。
# Use py-spy to get a snapshot of the Python process state
py-spy dump --pid ${AI_PID} > /evidence/python_state.txt
# For deeper analysis, use gdb with Python extensions
gdb -batch -ex "source /usr/lib/python3.11/gdb_helpers.py" \
-ex "py-bt" -ex "quit" -p ${AI_PID} > /evidence/python_backtrace.txtpy-spy 可在不停止程序的情況下擷取所有執行緒的呼叫堆疊;gdb 配合 Python 擴充提供更深入分析。
從記憶體復原請求資料
通過服務管線的推論請求在記憶體中留下可於請求處理後仍能復原的痕跡。這些痕跡存在於:
- 垃圾回收器追蹤物件中的 Python 字串物件
- 框架請求佇列資料結構
- HTTP 伺服器緩衝區(若使用 HTTP 型服務)
- 分詞器編碼/解碼緩衝區
調查工作流程
階段 1:現場保存
- 記錄當前系統狀態(執行中程序、網路連線、GPU 使用率)
- 依易失性順序擷取易失證據:先 GPU VRAM、然後 CPU 記憶體、最後磁碟
- 記錄所有系統時間戳並與 NTP 同步
階段 2:記憶體取證
- 使用上述技術執行 GPU 記憶體擷取
- 使用 LiME 或 /proc 檔案系統取得 CPU 記憶體
- 為每個 AI 服務程序擷取程序特定記憶體
- 以總和檢查碼驗證擷取完整性
階段 3:分析
- 將權重雜湊與參考總和檢查碼比對
- 掃描未預期的適配器模組或勾子
- 分析 KV 快取以取得特定互動的證據
- 於 CPU 記憶體搜尋攻擊者活動的成品
階段 4:關聯
- 將記憶體發現與其他鑑識工作流程的日誌分析交叉比對
- 將發現對應到 MITRE ATLAS 技術
- 以記憶體成品建立妥協時間線
挑戰與限制
AI 系統記憶體鑑識面臨數項獨特挑戰:
- 記憶體易失性:GPU 記憶體極度易失。VRAM 內容隨每個推論請求變化,且 GPU 記憶體無持久儲存或交換空間。
- 規模:大型語言模型可能在多個 GPU 上佔用 100+ GB VRAM。擷取並分析此量資料需要顯著儲存與運算資源。
- 加密:部分 GPU 架構支援記憶體加密(AMD SEV-SNP、NVIDIA Confidential Computing),阻擋從主機直接讀取記憶體。
- 框架不透明性:深度學習框架管理自己的記憶體池,使得無框架特定知識時難以將原始記憶體位址對應到有意義的資料結構。
- 量化成品:以量化格式(INT4、INT8、FP8)服務的模型需要量化方案的知識才能正確解釋權重值。
參考資料
- Ligh, M. H., Case, A., Levy, J., & Walters, A. (2014). The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux, and Mac Memory. Wiley.
- MITRE ATLAS. (2024). Adversarial Threat Landscape for Artificial Intelligence Systems. https://atlas.mitre.org/
- NVIDIA. (2024). CUDA C++ Programming Guide: Unified Memory. https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#unified-memory-programming
- NIST. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. https://doi.org/10.6028/NIST.AI.100-1