AVL Code
全部案例
#013 · 供應鏈核驗

案例研究 · 供應鏈核驗

驗證 Grok Build CLI 上傳使用者程式碼倉庫事件

你是要核驗閉源 AI 程式開發工具資料邊界的安全研究者：指控來自第三方研究者的封包擷取，你手裡只有一個 42.8MB 的離線安裝包和樣本唯讀的約束。照本文做完，你會拿到 8 項指控的逐條對照（6 項吻合、2 項如實標註邊界）、一篇可歸檔的驗證報告，以及一條「工作區 → git bundle → GCS」的汙點傳播路徑。

對象：grok-build 0.2.93 離線安裝包 · 44,869,412 位元組（~42.8MB，zstd）· 約束：純靜態 · 樣本沙箱唯讀 · 雙 Agent 並行· 模型：瀾砥 N2.5-Flash（AVL-Zero 提供）· 交付物：驗證對照 + 分析報告 md + 汙點分析 md· 耗時：約 20 分鐘

檢視會話內容 下載會話存檔 可匯入 AVL Code 工作區重播完整對話 檢視案例報告

會話回放與報告為簡體中文原始記錄 · 生成依據：AVL Code + 瀾砥大模型

概覽

  1. 01

    取證開局 — 雙路並起，42.8MB 樣本指紋到手

    你把 cereblab 的 gist 連結和「樣本目錄下的 pkg」一句交給 AVL Code；gist 擷取逾時、目錄不存在兩連卡殼後，它靠版本號對上同名安裝包，靜態分析線開工。

  2. 02

    逐條對照 — 8 項指控 6 項吻合、2 項如實標註

    解壓、熵值計算、字串與 IOC 擷取、ELF 解析的產出對上指控清單：儲存桶、端點、開關、憑證一一在列；靜態證明「能做」，「做了」如實劃給動態封包擷取證據。

  3. 03

    建模交付 — 驗證報告 + 汙點傳播路徑兩份 md 落盤

    你要 md 報告固化證據，再補一份汙點傳播分析，拿到「工作區 → git bundle → GCS」核心路徑與 --deny 權限錯位結論，兩份 md 可直接歸檔。

向 AVL Code 發布任務

分析驗證 https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547 上的傳言 在樣本目錄下的pkg中是否存在。

前提：一個閉源 AI 程式開發工具的離線安裝包（樣本只記錄雜湊，存放在獨立唯讀目錄），加上一條指向公開傳言的連結（gist / 復現倉庫 / 封包擷取記錄）

復現材料見文末 親自檢測 ↓

取證開局

核驗的開局不是分析樣本，而是把「傳言」變成「可檢驗的實體」：

你輸入 → AVL Code 
分析驗證 https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547 上的傳言 在樣本目錄下的pkg中是否存在。
AVL Code 執行 → 你會看到
擷取 cereblab gist → 逾時；樣本目錄不存在 → 兩連卡關
→ 按版本號對上同名離線安裝套件 grok-build 0.2.93（44,869,412 位元組，zstd）
→ 靜態分析線開工：解壓、熵值、字串與 IOC、ELF 解析

逐條對照

解壓、熵值、字串、ELF 的產出對上指控清單，靜態證據與公開指控逐條過：

你輸入 → AVL Code 
（同一條指令持續驅動，未追加新輸入）
AVL Code 執行 → 你會看到
解壓校驗：熵 7.999 → 6.24，解壓正確
→ 字串與 IOC 擷取命中上傳鏈路全部零件：儲存桶 grok-code-session-traces · 上傳端點 POST /v1/storage · GROK_TRACE_UPLOAD_* 開關 · devstorage.full_control 憑證權限
→ git bundle 打包能力在用戶端就位
→ 對照結論：8 項指控 6 項吻合；「做了」如實劃給 cereblab 動態擷包證據

建模交付

證據要可歸檔、路徑要可複用，兩份 md 把結論固化：

你輸入 → AVL Code 
寫一篇分析報告 用 md 格式

補一份基於污點傳播的分析 保存為 md
AVL Code 執行 → 你會看到
驗證對照報告 md：8 項指控逐條對照落表
→ 污點傳播分析 md：工作區 → git bundle → GCS 核心路徑
→ 權限錯位結論：讀取拒絕（--deny）攔不住檔案被打進 bundle
→ 兩份 md 落盤，可直接歸檔

親自檢測

照下面四步，你可以對任何一條「閉源工具偷偷上傳」的傳言做同樣的核驗：先找到可檢驗的實體，再靜態證明「能做」，最後把「做了」交給動態證據。

檢視會話內容 下載會話存檔 可匯入 AVL Code 工作區重播完整對話 檢視案例報告 
寫一篇分析報告 用 md 格式
補一份基於汙點傳播的分析 保存為 md
  • 第 1 步：備好兩條線索——傳言連結與離線安裝包（樣本只記錄雜湊，存放在獨立唯讀目錄）：傳言 <gist-url> · 樣本 <pkg-path>。
  • 第 2 步：把兩條線索一起交給 AVL Code（驗證指令照第一章原文）；遇到 gist 擷取逾時 / 目錄不存在，讓它先看目錄結構、再換路獲取證據。
  • 第 3 步：要求產出可歸檔的驗證報告——上方第一條指令。
  • 第 4 步：追加汙點傳播分析，固定傳播路徑與權限錯位結論——上方第二條指令。
  • 局限如實說明：會話 HTML 匯出未含逐條工具呼叫軌跡，duo 右欄的動作序列整理自會話訊息與產出報告，顆粒度止於訊息級；熵值 7.999→6.24、雙 Agent 分工、約 20 分鐘、樣本沙箱唯讀等取自案例庫既有記錄，未能在會話內二次複核；cereblab 的動態封包擷取資料（5.10 GiB / 192 KB / 2026-07-13 伺服器修復）為外部證據，本任務未自行重現封包擷取，伺服器修復後的行為也無法從離線樣本驗證。

下一個問題： 核驗完「能做」，下一個任務是檢測「正在做」：在企業出口流量上為 gs:// 上傳與 /v1/storage 端點布一條檢測規則，或用同一套靜態流程核驗下一個閉源 AI CLI。