[原创]algokiller-plugin —— 一个让 LLM 老老实实看证据的 ARM64 trace 逆向工具链-AI 助力安全-看雪安全社区

[原创]algokiller-plugin —— 一个让 LLM 老老实实看证据的 ARM64 trace 逆向工具链

发表于: 10小时前 250

[原创]algokiller-plugin —— 一个让 LLM 老老实实看证据的 ARM64 trace 逆向工具链

之安

10小时前

250

项目地址：[见底部]
当前版本：v0.9.5，MIT 许可，macOS（Apple Silicon / Intel）

先把项目状态说清楚：目前处在 v0.9 持续迭代阶段，核心路径稳定，边角细节还在打磨。我自己每天在用、也在改，所以欢迎试用，也欢迎在 issue 区交流——尤其是真实样本和 case，比单纯的代码 review 价值大得多。

为什么写这个

直接把一段 trace 粘给 LLM 让它分析算法，结果大家应该都熟悉：

看见一段 add mul 就说"这里在做 SHA256"
看见个 0x12345678 就说"这是密钥"
你质疑它，它先道歉，然后换一套同样自信的说法继续讲

问题不在模型能力——问题在 LLM 没有"证据 vs 推断"的概念。它把一切都压到同一个自信档输出，错得理直气壮。

这个项目想解决的事情就一句话：

不让 LLM 直接看原始 trace，让它通过工具看；不让它直接下结论，让它留下推理痕迹。

能做什么、不能做什么

适用场景：手上有 GB 级 ARM64 trace（GumTrace 出的），想问类似这些问题——

这个 32 字节密文是哪个算法产出的，密钥从哪里来
X-Sign / token / 设备指纹在 trace 哪几行被拼出来
一段 VMP handler 在做什么，opcode 表大概什么形状
某个 buffer 从分配到释放，途中谁写过它

不在范围内（避免预期错位）：

不替代 IDA / Binary Ninja / Ghidra 的静态分析视角，它是 LLM 助手不是分析平台
不做一键脱壳、不做一键还原算法
不替你下结论，它把证据排好、把推断分档，结论由分析者本人下
VMP 还原是严肃工作，不会"按一下就过"

整体结构

三层，自下而上：

底层：ak_search C 引擎，14 个子命令
mmap 整个 trace 文件、BMH 字符串匹配、行号倒排索引、daemon 模式常驻 IPC。目标是 GB 级 trace 也能毫秒级查询。

中层：MCP server，25 个工具
把 ak_search 包装成 stdio JSON-RPC 工具。协议遵循 MCP 2024-11-05，所以 Claude、Cursor、Codex 都能直接接入。Python 标准库实现，零外部依赖。

上层：Hypothesis Ledger 反幻觉机制
强制 LLM 把假设、证据、置信档、证伪条件全部显式记账，最终报告里高置信结论必须带 [H<n>] 回溯标记。这是项目里最核心的设计。

底层的 ak_search 引擎核心三个子命令（match / context / daemon）和配套采集器 GumTrace，都来自 @lidongyooo 的 AlgoKiller 项目。本仓库在这个底子上扩展了 11 个子命令、做了反幻觉机制、并打包为 Claude plugin。先去原作仓库 star 一下，那是整套方法论的源头。

几个有代表性的工具

不挨个列 25 个，挑几个能体现设计思路的：

`regflow` —— 寄存器演化追踪

逆向最高频的问题之一："这个值哪来的？"。给一个寄存器 + 一个行号，回溯它最近 N 步的赋值链：

$ ak_search regflow trace.log --reg x0 --line 1234567 --steps 6
1234567  mov x0, x1          ← 当前
1234120  ldr x1, [sp, #0x40]
1234089  bl   sym_kdf
1234050  mov x0, x19
...

把"猜测"变成"陈述"——这个差别会贯穿整篇文章。

`fold` —— Block-aware 折叠

ARM64 编译器优化产生大量循环展开，trace 里会有重复 basic block。fold 识别相同 BB 序列折叠成 [BB @ 0x1234 × 47 次]，循环边界和计数完整保留。

实测一个真实 trace 115 MB → 1.1 MB，信息无损。这一步是让 LLM context 能塞下完整流程的前提，不然几百兆 trace 怎么塞都不够。

`constscan` —— 95 套加密常数 + verdict 分级

扫 MD5 T 表、SHA-256 K 表、SM3 round constants、AES S-box、DES SP-box、ECC 曲线参数、HMAC ipad/opad、CRC 多项式等 95 套常数。但关键不在数量，而在分级：

real —— 命中常数，且周围有真实的 hash/cipher 指令上下文
weak —— 命中常数，但上下文可疑（可能是 init 期拷贝、可能是字面量）
alu_only —— 字节命中，但周围全是 ALU 指令，大概率误报

不做分级 = 默许 LLM 看见 "SHA256 命中" 就下结论。实际上很多 trace 命中 SHA256 K 表，只是因为某段静态字符串的字节序列恰好相同。分级是反幻觉链路上必要的一环。

`cryptoinstr` —— ARM Crypto Extensions

ARM64 硬件加密指令：AESE / AESMC / SHA256H / SHA1C / SM3PARTW1 / SM4E / PMULL 等。这类指令的存在 = 算法的硬证据，可信度高于任何常数命中。iOS 应用近年大量走硬件路径，这个工具基本是必备项。

`hexblock` —— 结构化的 call+args+ret 包

把一次函数调用打包成完整 JSON：

{
  "call": "sym_aes_encrypt",
  "args_regs": {"x0": "0x16fdff200", "x1": "0x16fdff240", "x2": "0x10"},
  "args_mem": {"x0": "00 11 22 33 ...", "x1": "<疑似 16 字节密钥>"},
  "ret_mem": "ab cd ef 01 ..."
}

LLM 拿到的是函数边界的完整证据，不需要自己拼 hexdump——拼 hexdump 这一步 LLM 出错率非常高。

Hypothesis Ledger：反幻觉机制

这是整个项目和市面其他"LLM 逆向插件"差异最大的部分，所以稍微展开讲。

问题

LLM 推理是多轮的：看见证据 A，假设 X；看见证据 B，假设加强；看见证据 C，矛盾，推翻……

但 LLM 没有"显式假设"概念——每一轮都把过程蒸馏成新结论。结果就是前后矛盾你都察觉不到：第 1 轮"这是 SM4"，第 5 轮变成"这是 AES"，它自己都不会主动声明改了主意。

解法

强制每条假设进 ledger，必须填三件事：

置信档：已确认 / 高置信推断 / 推断猜测
证据：trace 行号 + 工具调用 ID + 原文摘录
证伪条件：如果这条假设不成立，应该能看到什么相反证据

最终报告里所有"高置信推断"档的陈述，必须带 [H3] [H7] 这种回溯标记，否则 write_artifact 直接拒绝输出。

七道闸门

一条假设要"结案"成高置信，server 端硬验 7 项：

引用的 trace 行号能在原文件 verbatim 命中
evidence_excerpt 必须是工具真实返回过的内容
至少 2 个不同来源（杜绝单点证据）
创建时间早于结案时间（防止伪造时间线）
必须填证伪条件，否则不允许结案
conclude(high) 必须先通过独立蓝军 sub-agent
最终报告里引用的 [H<n>] 必须真的结过案

这 7 项不是 prompt 里的"温馨提示"——是 Python handler 里的硬验证，LLM 绕不过去。

蓝军 sub-agent

最关键的一道：高置信结案前，主 agent 必须 spawn 一个独立 context 的 hypothesis-reviewer。它完全不知道主 agent 的推理过程，只拿到假设 + 证据列表，独立调工具复核后给 PASS / FAIL。

同一个 LLM 自己审自己等于没审；换一个独立实例审，能挑出相当一部分过度自信的结论。这是红蓝军演练思路在 LLM 上的复用。

反漂移注入

每次工具返回都附 30 行的 discipline_reminder；每 20 次调用附完整 200 行的规则段。原因是 LLM 对长 context 末尾的指令记得清楚，中间的会语义模糊，而逆向分析常常一聊 50–100 轮工具调用，纪律必须周期性强化。

实战流程

密文还原

slash 命令：/algokiller:ciphertext <trace> <task>

典型路径：bind_trace → trace_lint 体检 → trace_search 关键字（密文前 8 字节 hex）→ constscan + cryptoinstr 扫加密证据 → 命中后 hexblock 还原 call → regflow / producer 反查密钥来源 → 假设入 ledger → 凑齐 7 道闸 → write_artifact 出报告。

VMP 还原（v0.9.5 新增）

VMP 公认的硬骨头——SKILL 里写了 4 阶段方法论，每一阶段都有客观判据：

A. 识别（三个 AND 条件）：高频 dispatcher loop（top callee 占比 > 30%）+ 计算跳转 / 跳转表 + VM context 结构清晰
B. opcode schema 还原：100 个 opcode 全过一遍频率统计，每个 opcode 至少 2 处独立命中，0 ghost opcode
C. handler 逐一翻译：每个 handler 走 round-trip emulator 验证，必须填证伪条件；每 10 个触发一次蓝军复核
D. 业务级闭环：单指令等价 + 单 basic block 等价 + 业务输入输出 bit-for-bit 一致

四步不全过，不允许在报告里写 "VMP 已还原"。这块写得比较严格，因为 VMP 真的不能差一点点。

通用 trace 分析

/algokiller:general <trace> <task>，开放问题工具自选，但高置信结论照样走 ledger 流程。

几个可能会被问的问题

为什么不直接用 frida-trace？

frida-trace 是函数级输出，没有寄存器快照、没有内存读写。本插件 25 个工具里至少 15 个需要这些字段，根本无法降级兼容。

吞吐量也差一个数量级——frida-trace 函数级大概 1k–10k 次/秒（每次进 JS runtime），GumTrace 走 Stalker transformer 直接拼字节流写文件，能跑到几十万 IPS。差异不是百分比是数量级。

大 trace 卡不卡？

首次启动 ak_search daemon 时 mmap 整个文件 + 建行号索引（GB 文件 1–2 秒），之后所有查询走 tab 协议 IPC，毫秒级。一次会话几百次工具调用，总开销 = 一次 mmap。

Linux 能用吗？

C 引擎 make 应该能通过，但插件层只在 macOS 验证过。Linux 用户欢迎试，遇到问题在 issue 区交流。

怎么试

Claude Code / Claude Desktop

claude plugin marketplace add icloudza/algokiller-plugin
claude plugin install algokiller@algokiller-suite

装好之后直接在 Claude 里说："用 algokiller ciphertext 模式分析 /path/to/trace.log，还原 X-Sign 密文 a3b2c1..."。

Cursor

仓库根目录有 .cursor/mcp.json，在 Cursor 里打开项目，Settings → Tools & MCP，启用 algokiller。

Codex

cp examples/mcp/codex.config.toml ~/.codex/config.toml
# 编辑文件，把 /ABS/PATH 替换为仓库绝对路径

重启 Codex。

MCP 连通性验证

printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{}}}' \
  '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
  | python3 server/algokiller_mcp.py

正常应能看到 initialize 响应 + tools/list 返回 25 个工具定义。

当前迭代方向

为了让大家对项目阶段有客观判断，列一下当前的开发重点和已知限制：

平台覆盖：目前重点保 macOS，Linux / Windows 暂未做平台适配测试
trace 格式：只消费 GumTrace 输出格式，其他 emitter 不兼容（不是兼容性疏忽，是格式不够用，前面解释过）
iOS 字面池：adrp + ldr literal pool 的精确检测还在打磨中，欢迎贡献真机样本
加密常数库：95 套是当前进度，ARIA、Camellia、部分国密变体、某些国外冷门算法还在补
文档：英文版相对完整，中文版部分新功能（v0.9.5 VMP 方法论）尚未完整回灌到 README
报告格式：目前输出 markdown，HTML / JSON / 其他格式按需求加

这些不是承诺路线图，只是让大家试用前对项目状态有现实预期。

致谢

整个工具链是站在巨人的肩膀上：

AlgoKiller by @lidongyooo：原始方法论 + ak_search 引擎核心三件套（match / context / daemon），是整套工具链的根
GumTrace by @lidongyooo：配套 ARM64 指令级 trace 采集器，Frida Stalker transformer 实现

本仓库的扩展代码 MIT，原作部分版权归原作者。