夜雨聆风无广，个人探索。本文不是工具百科，而是一份仍在继续的真实试用记录，如果有更好用的工具或更成熟的方法，也欢迎分享交流。
之前总觉得，别人已经在用 AI 自动理解二进制了，自己还在 IDA 里逐行啃伪代码，多少有点“大家都登月了，我才刚出村”。
但真正把插件装进 IDA、接上模型，并用同一个函数反复对照后，我的结论没有那么夸张：
AI 已经能明显减少第一轮阅读、公共代码识别和分析记录整理的机械工作，但离“替我完成逆向分析”还很远。
我实际碰了四种不同形态的能力：
IDA MCP + Codex：让 AI 主动查询反编译、汇编、调用者、常量和基本块，再由人工批准后修改 IDB； Gepetto：让大模型直接解释、注释和重命名当前函数； RevEng.AI：上传二进制，在云端进行函数相似性、符号候选、AI Decomp 和整合分析； VirusTotal AI：根据脚本或样本信息生成分诊摘要。
为避免每个工具各说各话，我尽量围绕同一个练习样本 manalyze.exe （Gepetto安装文档里的测试用二进制文件）和同一个函数 0x14000F190 展开。这个函数后来被验证为 MSVC std::string 的按长度赋值/扩容例程，很适合观察不同工具能把“它大概是字符串处理”推进到什么程度。
一、我想验证的不是“有没有 AI”，而是能不能进入真实流程
我主要关注几个问题：
我也给自己定了一条底线：
AI 输出可以作为假设、导航和草稿，但只有能回到机器码、控制流、数据流、调用关系或运行时行为的内容，才算分析证据。
二、IDA MCP：不只是解释函数，而是把验证过程串起来
这是这轮试用中智能程度最高、也最接近真实分析流程的一种形态。
Gepetto 和 RevEng.AI 更像各自完成一个固定动作，而 IDA MCP 可以让 AI 按要求主动查询反编译、汇编、调用者、被调用函数、常量和基本块，并把证据按层次组织起来。
我先要求它只读分析 0x14000F190，不修改 IDB。
它最终给出的直接证据包括：
对象 +0x10 是当前长度，+0x18 是容量； 容量小于 0x10 时使用对象内 16 字节缓冲区，即 15 字符的 SSO； 容量足够时更新长度、执行 memmove(data, src, count) 并补零； 容量不足时按 max(count | 0xF, old_capacity + old_capacity/2) 增长； 大块分配采用 32 字节对齐，并保存原始分配指针； 函数共有 95 条指令、27 个基本块、147 个调用者； 调用者以 "arg" 和长度 3 调用，还把 strerror() 等 C 字符串的扫描长度传入。
这些证据把结论从“像字符串缓冲区”推进到高置信度的：
msvc_string* __fastcall msvc_string_assign_n( msvc_string* self, const char* src, size_t count);
更重要的是，它明确区分了直接证据和推测：函数行为与 MSVC std::basic_string<char>::assign(const char*, size_t) 完全吻合，但在缺少 RTTI 或原始符号的情况下，具体库身份仍属于强推断。
在我确认后，MCP 才把经过验证的结果写入 IDB：
新建 msvc_string 结构体； 将函数改名为 msvc_string_assign_n； 设置 self、src、count 参数类型； 添加 12 处关键路径注释； 重新反编译并检查代表性调用者。
 |  |
修改后仍然是 95 条指令、27 个基本块、147 个调用者和 15 个关键常量，调用集合、控制流以及复制、补零、释放顺序均未变化。区别只是伪代码开始显示 self->size、self->capacity、self->storage.heap，调用者也能显示 msvc_string_assign_n(self, src, count)。
这次 MCP 的真正价值不只是“给出一个更准确的名字”，而是完成了：
收集上下文 -> 区分证据与推测 -> 提出修改 -> 等待确认 -> 写入 IDB -> 回归验证
它更接近一个受分析人员控制的编排和 IDB 维护层。缺点也很明确：任务边界必须说清楚，修改 IDB 前必须人工确认。如果只丢一句“分析整个程序”，它同样可能输出一篇很长但无法验证的报告。
三、Gepetto：最轻量、最容易进入日常使用的函数助手
1. 函数解释确实能减少首次阅读成本
Gepetto 对 0x14000F190 的解释是：函数管理动态缓冲区，容量不足时重新分配，复制数据，释放旧缓冲区，并在末尾补零。它还给出了 StringBufferAssign 这个候选名称。
这个总结虽然不够精确，但抓住了主干。它让我从“这是什么函数”迅速进入“它是不是某种字符串赋值例程”的验证阶段。
真正节省的不是逆向本身，而是建立第一个可验证语义假设的时间。
2. 重命名候选有用，但不应全部接受
Gepetto 给出了 newCapacity、allocBase、alignedBuffer、bufferToFree 等变量名。
候选列表比直接批量写入更合理，因为分析人员可以逐项检查。但这些名称只来自当前函数上下文，未必考虑调用者、真实对象布局和编译器实现。
我更认可的流程是：
AI 提供候选名 -> 人工核实 -> 选择性接受
3. “可读代码”有时反而更难读
Gepetto 生成代码时，会把解释直接塞进标识符，出现类似 Extract_the_current_buffer_capacity_from_index_3 的超长名称。
单看名称信息很多，放回完整函数后却让条件表达式横向膨胀。它只是把“无语义的短变量”换成了“过度解释的长变量”。
因此，Gepetto 最适合做函数摘要、候选命名和局部注释，不适合被当成自动源码恢复器。
切换到 DeepSeek 后，一次函数解释、重命名和代码生成组合的记录成本约为人民币 0.01 元。结合国内网络下更直接的接入体验，它是这轮工具中最容易日常使用、性价比也最高的一个。
四、RevEng.AI：真正有差异化的是函数语料库
1. 从插件排障到完整上传
RevEng.AI 的试用比最初预想更完整。创建分析时，插件会上传完整二进制。练习样本 manalyze.exe 是公开样本，因此选择了 Public；真实恶意样本、客户样本或未公开文件必须先确认授权和云端数据边界。
提交后约十分钟完成远端分析与同步：3467 个函数同步了远端结果，另有 797 个本地函数不在远端分析中。这也提醒我，云端分析并不等于覆盖 IDA 中的全部函数。
 |  |
Auto Unstrip 先把目标函数命名为较泛化的 assign。它比 sub_14000F190 好一点，但单靠这个名字仍不足以确定对象类型和具体语义。
2. Function Similarity 最有价值的新证据
对目标函数执行 Match Function 后，RevEng.AI 返回了多个来自不同二进制的 std::basic_string 候选：相似度约 97.5% 至 98.5%，名称置信度为 97.6%。
这组结果的价值不在于“AI 说它是字符串”，而在于几层信息能够互相支撑：多个独立二进制都匹配到 std::basic_string，实现相似度很高，候选名称也形成了共识，本地伪代码又确实包含 SSO、容量增长、复制、补零和旧缓冲区释放。
因此，可以较有把握地把它归类为 C++ 标准字符串库的赋值/扩容辅助函数，而不是程序独有的核心逻辑。
但这类匹配不能证明候选二进制属于同一家族。公共 CRT、STL、加密、压缩和壳代码的高相似匹配，首先应该用来排除噪声。只有多个罕见函数、调用关系、常量、配置结构、协议和动态行为共同吻合，才能形成更强的同源证据。
最合适的证据表述是：
多源高相似匹配 + 高置信符号共识 + 本地伪代码与调用者验证。
3. AI Decomp 更像功能草图，而且出现了明显幻觉
AI Decomp 正确概括了“短字符串内联复制，长字符串分配新缓冲区并释放旧缓冲区”的整体流程，右侧代码也确实比 Hex-Rays 伪代码更像人类源码。
但仔细比较后，问题非常明显：
把 this 错误理解成 allocator<char>*； 返回类型也写成了 allocator 指针； 生成了无法成立的 length.limit； 编造了 copy_inline、allocate_buffer、processed_data、threshold 等函数和字段； 省略了真实存在的长度溢出、异常和大块分配检查； 生成结果甚至不能直接编译。
所以这次 AI Decomp 的特点是：语义概括更清楚，代码真实性反而低于 F5。 它不是“恢复出的源码”，而是 AI 根据反编译结果写出的一份功能草图。
4. Portal 的价值需要分层看
Portal 把 Overview、Functions、Match / Diff、Sandbox、Memory 和 Agents 报告整合在一个工作台中。
我的实际价值排序是：
Overview 中的架构、节、导入、编译器、熵和加壳判断，用 DIE、PEStudio、LIEF 或 Manalyze 也能获得。真正有差异化的还是函数级语料库和 Match / Diff。
Agents 中的 Triage、Threat Report 和 Capabilities 都是衍生结论，不是新证据。当前练习样本甚至显示 No behaviours detected yet 和空 Threat Score，此时生成威胁报告的增量价值很低，还可能根据静态线索过度推断。
五、VirusTotal AI：适合快速分诊，不适合定性
我查看了 VirusTotal 对一个 PowerShell 脚本的 AI 代码解读（该功能介绍的博文中提供的）。该文件只有 1/63 个安全厂商标记为恶意，AI 将它判断为良性，并概括出创建目录、下载 Postman CLI、解压、移动文件和异常处理等行为。
这类输出适合在样本队列中做第一轮压缩：先告诉我应该重点看下载地址、执行参数、持久化还是凭证行为。
但合法安装脚本和恶意下载器可能具有非常相似的动作。最终仍要检查下载域名与载荷、混淆和隐藏执行、投递来源、沙箱行为以及其他检测结果。
所以它更像静态分诊和摘要助手，不是恶意性裁判。因为这轮只看了平台已有结果，没有继续和它交互或做函数级查证，我暂时把它放在四种工具的最后。
六、智能程度和性价比：我的主观排序
这里不做复杂打分，只说实际用下来的感觉。
这个排序不是说排名靠后的工具没有价值，而是它们擅长的问题不同：
单个函数快速看懂，性价比最高的是 Gepetto + DeepSeek； 关键函数要分析得最深，性价比最高的是 IDA MCP + Codex； 一次处理大量函数、排除公共库代码，RevEng.AI 最值； 面对大量待筛样本，只想先获得行为摘要，VirusTotal AI 最省事。
如果只谈“最聪明”，我目前的主观感受是：
IDA MCP + Codex > Gepetto + DeepSeek > RevEng.AI > VirusTotal AI
其中 RevEng.AI 的 Function Similarity 很强，但 AI Decomp 拉低了整体印象；Gepetto 的能力没有 MCP 深，却胜在便宜、直接、随手能用。
七、我现在会怎么把 AI 放进真实样本分析
我更倾向于下面的流程：
传统工具产生事实 -> AI 压缩信息并提出假设 -> 相似性平台补充语料库线索 -> IDA/MCP 查证控制流与调用者 -> 人工批准命名、类型和注释 -> AI 整理报告草稿 -> 人工确认结论
具体分工是：
FLOSS、capa、PE-sieve、沙箱负责产生可追溯的事实和线索； IDA、调试器和内存状态负责确认关键调用链与真实副作用； IDA MCP 负责证据收集、上下文扩展以及经过审批的 IDB 改善； Gepetto 负责轻量函数摘要和候选命名； RevEng.AI 负责公共组件识别、符号候选、函数相似性和版本差异； VirusTotal AI 负责样本和脚本的初步分诊； AI 报告负责整理，不负责替代证据。
至于本地模型，我目前的选择很简单：暂时不会专门在自己的电脑上部署一个小模型来承担主要分析工作。
原因是本地部署还要考虑显存、速度、模型更新和维护，而小模型在复杂逆向任务上的效果未必能超过现在可直接调用的 DeepSeek 或 Codex。只有两种情况下我会重新考虑：一是样本不能上传云端，必须完全离线；二是以后有大量重复任务，云端调用成本明显高于本地维护成本。
在目前阶段，更实用的做法是把原始样本和动态执行留在隔离虚拟机里，只把确认允许分享的伪代码或带来源的工具结果交给 AI 分析。
八、结论
如果把期待设成“AI 自动替我逆向”，会让人失望。
但如果把它们拆开看，AI 已经能在三个位置提供实际价值：
阅读前的压缩：概括函数或脚本，快速建立假设； 分析中的导航：识别公共代码、寻找相似函数、扩展调用上下文； 分析后的沉淀：把确认过的结构、类型、命名、注释和报告写回工作环境。
真正不能交出去的是证据判断。机器码、控制流、数据流、调用者、运行时状态和样本来源，仍然决定最终结论。
所以回到标题的问题：AI 真能替你逆向吗？目前还不能。
它可以帮我快速理解函数、寻找相似代码、整理证据并改善 IDB，但不能替我判断哪些是事实、哪些只是看起来合理的幻觉。真正决定分析结论的，仍然是对机器码、控制流、调用关系和运行时行为的人工验证。
更准确地说，AI 现在不是逆向分析人员的替代者，而是一个已经能够真正提高效率、但必须接受验证和约束的分析助手。
