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

项目地址：[见底部]
当前版本：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",
"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 命中

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-291195.htm

tql

大佬，API Error: The model has reached its context window limit.  这种情况要怎么搞

大佬，API Error: The model has reached its context window limit.  这种情况要怎么搞

Migc

大佬，API Error: The model has reached its context window limit. 这种情况要怎么搞
字面意思吧 要/compact 一下