项目地址：908K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6m8j5i4t1H3L8U0x3&6x3o6k6Q4x3V1k6f1j5h3W2F1N6q4)9J5k6q4u0W2N6W2)9J5k6q4c8J5j5h3y4W2i4K6u0r3

做 Native 逆向、漏洞研究、协议分析、动态插桩的人，通常都遇到过同一种困境：

比如：

某行里的 x8[31:0] 到底来自哪个立即数、哪个寄存器，还是哪次更早的内存写入？

又或者：

如果手工做这件事，分析过程通常会被拆成几段反复切换的动作：

只要中途碰到这些典型 ARM64 场景，复杂度就会快速上升：

于是问题就从“找位置”变成了“拼语义”，再从“拼语义”变成了“怀疑自己是不是追错了来源”。

Taint-Rev-Trace 的目标，就是把这件事做成一套更高效、更适合真实场景的分析方法。

它是一款面向 ARM Trace 分析的可视化工具，核心围绕四个关键词展开：

如果用一句话来定义它，可以概括成：

一款支持 MCP 调用的 ARM Trace 污点追踪与条件搜索工具。

很多 Trace 工具强调的是：

这些能力当然重要，但它们只能解决“看得到”的问题。真正决定分析效率的，往往是另一个层面：

当你锁定了一个关键值之后，工具能不能帮你快速解释它为什么会是这个值？

Taint-Rev-Trace 要解决的正是这个问题。

它不是传统意义上的前向污点系统。它更适合回答这类逆向里真实高频的问题：

所以它采取的不是“从输入往前传染”的思路，而是：

从技术本质上说，这更接近：

而这也正是它更贴近逆向工作习惯的原因。

这个项目的第一层形态，是可视化界面。

但这里的“可视化”并不是简单加一个文本框，而是围绕实际分析流程来组织界面：

这意味着你不是在一个普通文本查看器里勉强做逆向，而是在一套为 Trace 分析定制的工作台里操作。

对于大体积 Trace，这一点很重要。因为真实场景里最难受的不是“没有功能”，而是功能被拆得太散：

Taint-Rev-Trace 的价值之一，就是把这些动作拉回到了一个统一界面里。

在真实 Trace 分析里，很少有人是“先知道 line_no，再去分析”的。更多时候，你知道的是一个条件：

也就是说，你首先做的不是“追踪”，而是“筛选”。

这就是为什么我更愿意把这部分能力称为 条件搜索，而不只是全文查找。

Taint-Rev-Trace 在这一层的核心能力包括：

为了支撑大文件场景，它的底层不是简单把文件整份读进内存，而是：

这带来的实际意义是：

对逆向来说，这一步是整个方法论的入口。没有条件搜索，后面的污点追踪就失去了高效切入点。

这个项目最核心的能力，依然是 ARM64 反向污点追踪。

但这里的“污点”，不是很多人理解的那种简单布尔传播。它真正做的是：

它关心的不是“这个值有没有被污染”，而是：

这也是为什么它在逆向场景里更有实用性。

它追的是：

而不是粗糙地追整个寄存器。

这是 ARM64 里非常关键的设计。因为真实世界里常见的是：

如果工具粒度过粗，结论看起来完整，实际上往往不准确。

一个反向追踪工具是否有实战价值，不在于它能不能回溯，而在于：

找到定义之后，能不能把这条定义拆成真实可解释的来源结构。

当前这套引擎已经覆盖了 ARM64 中最关键的一批语义：

也就是说，它给你的不是“一条看起来还行的链”，而是一张更接近真实执行语义的来源图。

很多工具的问题是，追踪结果一多就没法看。

Taint-Rev-Trace 这次在结果呈现上做了很关键的整理：

再加上：

这意味着结果不再只是“算出来了”，而是“能看下去、能判断、能复核”。

如果只把这个项目看成一个图形工具，它当然已经足够实用。但它真正的延展性，来自 MCP。

MCP 的意义不是给工具“加一个接口”，而是让这套能力可以被外部环境稳定复用。

对于这个项目来说，MCP 的价值主要体现在三点：

当前内置的 trace-search-mcp 已经不是简单试验品，而是一套完整的 MCP 工具面。

它覆盖了主程序后端可表达的核心能力：

这意味着外部客户端不依赖图形界面，也能完成一整条分析链路：

当前项目已经支持通过图形界面中的 Tools/工具 菜单管理 MCP，并支持 一键全局安装 到已检测到的 MCP 客户端，例如：

这件事的意义非常现实：

一旦搜索、按行读取、污点追踪这些能力都可以被程序调用，这个项目就不再只是一个单机 UI 工具，而更像一个可以被外部系统编排的分析底座。

这对于后续接入自动化脚本、编辑器插件、团队内部平台，甚至智能体辅助分析，意义都很大。

如果只说“这个工具支持污点和 MCP”，其实还是太抽象。真正值得讲的是：这些能力落到什么场景里最有价值。

当你已经通过 Trace 发现某个 JNI 接口、解密逻辑或关键返回值时，可以：

这能显著减少手工翻 Trace log 和反复核对数据来源的时间。

这类场景里很常见的就是：

而这些恰恰是 ARM64 反向污点最擅长解释的部分。再结合 MCP，就可以把“先搜热点、再追关键寄存器”的流程接入 AI 辅助分析链路中。

MCP 是此工具最值得期待的方向之一。

以前很多Agent在逆向中效果不理想，根本原因是：

而现在，借助本工具 MCP，在外部系统中可以：

结合一些逆向分析的通识，与类似于ida-pro-mcp这样的协同mcp进行分析；结合样本总结出的复用方法论，这将会比单纯分析 Trace log 更能解决问题。

这个题目其实刚好对应了项目最关键的四个维度：

它不是泛日志工具，也不是泛架构分析器。它明确服务于 ARM 架构 Trace 分析，尤其适合 ARM64 相关场景。

这是项目最核心的分析引擎。它解决的是“关键值来源解释”的问题，而不是表面的命中标记。

这是项目的高频入口能力。没有条件搜索，就很难在海量 Trace 里高效找到值得追踪的目标。

这决定了项目不只是本地工具，还能进入集成开发环境、命令行、脚本平台和智能体工作流。

也正因为这四点组合在一起，它不只是一个查看器，也不只是一个分析脚本，而是一套更完整的 ARM Trace 分析工作台。

Taint-Rev-Trace 它已经形成了一条清晰的方法链：

如果你需要的是：

那么 Taint-Rev-Trace 想提供的，正是你所需要的。

拿不到结构化、可验证、可回跳原文的底层分析结果

某行里的 x8[31:0] 到底来自哪个立即数、哪个寄存器，还是哪次更早的内存写入？

一款支持 MCP 调用的 ARM Trace 污点追踪与条件搜索工具。

当你锁定了一个关键值之后，工具能不能帮你快速解释它为什么会是这个值？

找到定义之后，能不能把这条定义拆成真实可解释的来源结构。

• 手上已经有了一份执行 Trace
• 文件很大，几百 MB 是常态，数 GB 也并不少见
• 你真正想回答的问题并不泛，而是非常具体

• 某个解密入口的关键参数是谁构造出来的
• 某个崩溃地址是如何一步步算出来的
• 某个结构体字段是在什么时候被写脏的
• 某个返回值为什么会在这里演化成当前字节序列

• movk 的部分覆盖
• csel 的条件双分支
• w 写导致 x 高 32 位清零
• ldr/str 的内存回溯
• 多次 store 对同一片内存的字节级覆盖

• 可视化界面
• 条件搜索
• 污点追踪
• MCP 调用

• 能打开大文件
• 能搜索
• 能跳转

• 当前寄存器值是谁写出来的
• 这个地址是怎么被构造的
• 这段字节流来自立即数、内存、参数，还是函数返回值
• 某次 load 对应的到底是哪几次 store

• 从目标值出发
• 沿 Trace 反向回溯
• 把来源整理成一张可以解释、可以跳转、可以复核的图

• 反向切片
• 来源追踪
• 面向解释的数据流重建

• 左侧和中部负责大文件 Trace 浏览
• 搜索结果可分页、可跳转、可持续拉取
• 右侧聚焦反向污点分析结果
• 来源概览、来源树和步骤流共同承担“解释结果”的任务
• 顶部 Tools/工具 菜单集成了自动刷新和 MCP 配置能力

• 搜索在一个地方
• 上下文在一个地方
• 追踪又在另一个地方
• 外部自动化还得自己接

• 某个函数名
• 某段字符串
• 某个寄存器模式
• 某个地址常量
• 某类内存访问特征

• 普通文本搜索
• 正则条件搜索
• 大小写敏感与非敏感控制
• 总命中数统计
• 分页获取结果
• 命中行定位与上下文读取
• 搜索结果与后续污点追踪直接联动

• 基于 mmap 读取文件
• 构建行索引
• 对大文件使用更适合的索引策略
• 通过缓存索引减少重复初始化成本
• 仅渲染可见视口内容

• 几百 MB 甚至更大的 Trace 仍然可以顺畅浏览
• 搜索不需要等到全文件处理结束才开始返回结果
• 你可以用“条件”而不是“记忆中的行号”来定位目标

• 以寄存器切片或内存切片为目标
• 沿执行轨迹反向回溯
• 输出带结构、带路径、带上下文的数据来源解释

• 这个值由哪些来源构成
• 每个来源来自什么语义动作
• 哪些来源是确定的，哪些来源只是可能的
• 哪条路径是立即数构造，哪条路径是内存传播，哪条路径带条件

• x8[0:31]
• w9[16:31]
• [x21,#0x10][0:7]

• movk 只改 16 位
• w 写只改低 32 位，并清零高位
• ldrb/strb 只涉及 8 位
• ldrh/strh 只涉及 16 位
• 内存值可能来自多次分段写入

• movk 的部分覆盖建模
• csel 的条件分支来源保留
• adrp + add 的地址构造识别
• w 写导致高 32 位清零的显式建模
• ldr/str 的内存读写回溯
• 多次 store 的字节级覆盖归并

• 来源概览：先看来源类型和大体构成
• 来源树：按分支展开来源结构
• 步骤流：按定义顺序阅读具体过程

• 可跳回原始 Trace 行号
• 可调追踪深度
• 可调输出上限
• 可选剪枝策略

• inspect_content_file
• read_content_lines
• search_content
• replace_content_match
• replace_content_all
• trace_backward
• search_trace_sources

• VS Code
• VS Code Insiders
• Cursor
• Windsurf
• Claude Desktop
• Claude Code
• Codex CLI

• 你不必手工到处改配置文件
• 你不必记住每种客户端的接入细节
• 你可以把项目能力更快带入现有分析环境

• 常量构造
• 寄存器传播
• 内存读写
• 静态地址
• 函数返回值

• 常量拼接
• 地址构造
• 多轮数据搬运
• 条件选择造成的值分流

• 面向 ARM Trace 的分析工具
• 强调污点追踪与条件搜索
• 提供可视化 UI
• 同时支持 MCP 调用与外部集成

1. 在巨大的 Trace 里搜索目标函数、寄存器、字符串或地址
2. 定位到命中点后，再回看上下文
3. 最后沿着定义链一路往前翻，尝试追出数据来源

1. 检查文件和编码
2. 按窗口读取上下文
3. 执行条件搜索
4. 针对命中点做独立或批量污点追踪
5. 消费结果并继续下一步逻辑

1. 用条件搜索先锁定可疑调用点
2. 对关键寄存器或缓冲区切片发起反向污点追踪
3. 快速判断值来源是：
   • 常量构造
   • 寄存器传播
   • 内存读写
   • 静态地址
   • 函数返回值

1. 条件搜索目标
2. 对关键值执行反向污点追踪
3. 返回来源摘要给分析者继续判断

1. 用条件搜索快速定位目标
2. 用反向污点解释关键值来源
3. 用来源树和步骤流提高阅读效率
4. 用深度、上限和剪枝控制分析成本
5. 用 MCP 把这套能力接入更大的外部工作流

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！