文章总结： 本文介绍了一种名为BinaryAnalysisAgent的AI驱动二进制分析系统，该系统通过将大语言模型与专业二进制分析工具链（如IDAPro）深度结合，构建了一个AI可调用的标准化工具接口。系统基于Agent+Plugin机制，让AI充当分析编排器，根据用户自然语言需求自主选择并调用工具脚本，实现从自然语言到结构化分析结果的闭环。文章重点阐述了其设计哲学与架构决策，包括AI不直接操作GUI、先规划后执行、按需加载知识库、严格的结果验证框架等核心原则，并提供了关键实现细节，旨在为安全研究人员提供一个可复现的、能有效提升逆向工程效率的智能分析框架。 综合评分： 88 文章分类： 二进制安全,逆向分析,AI安全,安全工具,安全开发
【AI自动逆向算法】Binary Analysis Agent：构建AI驱动的二进制分析系统
不歪 不歪
看雪学苑
2026年5月22日 17:59 上海
在小说阅读器读本章
去阅读
创建他的思维模式：我将 AI 当做人，我告诉他方法论、文档、规范、知识库、总结、经验。AI智能的分析出用什么工具、手头有什么工具，如果我提供的工具不满足它的需求，要么它去安装，要么它基于基于已有工具写特定逆向目标的脚本。我沉淀了一套IDA脚本如何写、Frida如何用、Union如何用，什么时机用什么工具等等的本地知识库，所以我没关心过AI怎么去用它们，我训练他，我只要结果。
思维是道，工具是术，思维模式不同，越努力差异越大。
本文记录一种将大语言模型与专业二进制分析工具链深度结合的架构实践——Binary Analysis Agent。系统基于OpenCode 的 Agent + Plugin 机制构建，让 AI 充当”分析编排器”，通过标准化的工具脚本间接操作分析引擎，实现从自然语言到结构化分析结果的闭环。文章重点阐述设计哲学与架构决策，辅以关键实现细节，供安全研究人员参考和复现。
效果
效果说明：
-
简单难度的算法很快就能逆向出来，难度99、100很慢，半天到一天能够逆向出来，破解算法生成注册机。
-
如果只破解不逆向算法，难度99、100也是很快的。
Reverse中打对钩的是我运行AI去分析的题，这三个目前都解出来了：
#
一、为什么用逆向工程来检验 AI 能力？
选择二进制逆向工程作为 AI 能力的测试场，并非偶然，而是经过深思熟虑的结果。
逆向工程是工程领域的”全能铁人三项”。它同时考验阅读理解（从机器码中还原逻辑）、抽象推理（识别算法模式、追踪数据流）、领域知识（密码学、操作系统、编译原理）和系统思维（将零散线索拼成完整图景）。一个 AI 能做好逆向，意味着它在上述每一项上都达到了可用的水平；反过来，任何一项的短板都会直接导致分析失败——没有蒙混过关的余地。
评判标准客观且严格。 逆向的结果对就是对、错就是错：注册机能不能算出正确的 Key，脱壳后能不能还原出可编译的代码，漏洞能不能实际触发。不存在”差不多””言之有理即可”的灰色地带。这比让 AI 写一篇总结或回答一个开放式问题，更能反映真实的智能水平。
难度可以精确调节。 从简单的 CrackMe 到混淆加固的商业软件，逆向目标的难度谱系极其宽广。这让我们能够精准地定位 AI 的能力边界——它到底卡在哪一步？是读不懂汇编、看不穿混淆、还是推理链条不够长？这种细粒度的诊断能力，是通用基准测试很难提供的。
对我的实际工作有直接价值。我日常就需要做逆向分析。如果 AI 能承担其中哪怕 30% 的重复性工作，生产力提升就是实实在在的。这比”AI 能不能通过图灵测试”这类学术问题有意义得多。
简单说：逆向工程是一道难题，而难题是最好的试金石。
二、问题背景
现代二进制分析工具（如 IDA Pro、Ghidra 等）功能强大，但操作门槛高：分析师需要记忆大量 API、手动执行重复性操作、在反汇编/反编译视图间反复切换。与此同时，大语言模型具备理解自然语言和推理分析的能力，却无法直接操作专业工具。
这两者之间存在一个明确的鸿沟：AI 有推理能力但无工具操作能力，工具链有操作能力但无自主推理能力。
Binary Analysis Agent 的设计目标就是填补这条鸿沟——构建一套”AI 可调用的标准化工具接口”，让 AI 模型作为编排器，根据用户自然语言描述的分析需求，自主选择并调用合适的工具操作，最终输出经过验证的分析结果。
三、系统全貌
系统基于 OpenCode 构建，利用其Agent + Plugin 机制实现三件关键的事：
| | | | | — | — | — | | 机制 | 作用 | 解决的问题 | | Agent（Markdown Prompt） | 定义 AI 编排器的角色、行为边界、执行流程 | AI 知道”该做什么、怎么做” | | Plugin（JavaScript） | 环境信息注入、上下文压缩时保留关键状态 | 长对话不丢规则、不丢结论 | | 工具脚本（Python / IDAPython） | 封装具体的分析操作，标准化输入输出 | AI 有手可用 |
用户在 OpenCode 中用自然语言描述分析需求，Agent 自动接管后续所有操作——解析目标、收集信息、制定方案、调用工具、验证结果，全程输出进度和推理过程。
此外还有一个进化命令（Evolve），用于从实际分析复盘中发现改进点，经评估后按严格质量流程实施系统升级。
四、核心架构
┌────────────────────────────────────────────────────────────┐
│ OpenCode 框架 │
│ ┌──────────────────┐ ┌──────────────────────────────────┐│
│ │ Agent Prompt │ │ Plugin ││
│ │ (编排器行为定义) │ │ · 每轮注入环境信息 ││
│ │ · 角色与约束 │ │ · 压缩时保留分析状态 ││
│ │ · 分析执行框架 │ │ · Session 生命周期管理 ││
│ │ · 工具清单 │ │ ││
│ │ · 知识库索引 │ │ ││
│ └────────┬─────────┘ └──────────────────────────────────┘│
└───────────┼─────────────────────────────────────────────────┘
│ idat -A -S"脚本" / $BA_PYTHON 脚本
▼
┌────────────────────────────────────────────────────────────┐
│ 工具脚本（分层） │
│ 基础设施层: 日志、环境变量、JSON 输出、headless 模板 │
│ 业务工具层: thunk 追踪、数据读取、地址解析 │
│ 共享分析层: 段分析、入口点、导入表、字符串、壳检测、场景分类 │
│ 操作层: 13 种查询 + 4 种更新 + 沉淀脚本库 │
│ 独立工具: GUI 自动化、进程 Patch、环境检测、初始分析流水线 │
└────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ 知识库（按需加载，18 份文档） │
│ 分析规划 · 加壳处理 · 密码学验证 · GUI 自动化 · 技术选型 │
│ 动态分析 · Frida Hook 模板 · Unicorn 模板 · 脚本生成规范 │
│ ECDLP 求解 · 进程 Patch 参考 · 验证模式 · 编码规范 · 模板 │
└────────────────────────────────────────────────────────────┘
关键约束：依赖方向严格单向——基础设施 ← 业务工具 ← 共享分析 ← 操作脚本。禁止反向依赖和循环依赖。这条规则确保了每一层可以独立测试和演进，而不会因上游变更引发连锁故障。
五、设计哲学
5.1 “AI 不碰 GUI，只走 CLI”
这是整个系统最核心的设计决策。专业分析工具的 GUI 是为人类设计的交互界面，AI 无法也不应直接操作。系统利用分析引擎提供的命令行 headless 模式，通过 -A -S"脚本路径" 参数让分析引擎加载二进制文件后自动执行指定脚本。
所有分析操作都被封装为”无头”模式：脚本启动 → 等待分析完成 → 执行业务逻辑 → 输出 JSON 结果 → 退出进程。AI 只需要构造正确的命令行调用，就能获取结构化的分析数据。
5.2 “先规划再执行”
系统强制要求分析型需求必须经过”信息收集 → 方案规划 → 执行监控”三阶段框架，不允许跳过任何阶段。AI 在拿到目标后不能直接开始调用工具，而是必须先输出完整方案（场景分类、计划步骤、预计耗时、每步失败后的切换方向），方案可见后方可执行。
这一规则的目的是防止 AI 在复杂分析中”走一步看一步”导致方向错误、反复重试。实践表明，先花 2 分钟规划，往往能节省 20 分钟的无效尝试。
5.3 “渐进式披露”（Progressive Disclosure）
Agent Prompt 是系统中非常宝贵的资源——它决定了 AI 的”注意力”分配。如果将所有规则、策略、细节都塞进主 Prompt，不仅占用上下文窗口，还会分散 AI 的注意力，导致分析质量下降。
系统采用”渐进式披露”策略：主 Prompt 控制在500 行以内，只包含核心规则和触发条件。18 份知识库文档仅在特定场景下按需加载——检测到加壳才读取加壳处理策略，遇到密码学特征才读取密码学验证方案，需要生成脚本才读取脚本生成规范。
主 Prompt（~500 行）：
- 角色与约束
- 分析执行框架（强制）
- 工具清单（精简版）
- 知识库索引表（触发条件 → 文档名）
知识库（18 份文档，按需加载）：
- 分析规划 · 加壳处理 · 密码学验证 · GUI 自动化
- 技术选型 · 动态分析 · Frida Hook · Unicorn 模板
- 脚本生成 · ECDLP 求解 · 进程 Patch · 验证模式
- 编码规范 · 模板 · ...
5.4 “沉淀而非膨胀”
系统不会为了”完整性”而添加功能。每个新增的工具脚本、每条新增的 Prompt 描述都需要经过”四维度量”评估：是否能减少上下文占用、减少对话轮次、提升分析速度、提升结果准确度。
满足条件的脚本经过验证后”沉淀”到脚本库并注册索引。不满足条件的方案被明确拒绝——比如”给简单异或解密写脚本”，因为 AI 自己就能完成这类计算，额外脚本只会增加系统复杂度。
5.5 “假设必须验证”
系统内置了完整的结果验证框架，要求分析结论必须经过验证才能报告给用户。验证手段按可靠性分层：
能否定位到验证函数？
├─ 能 → 函数是否"干净"（纯计算）？
│ ├─ 是 → 模拟执行原函数
│ └─ 否 → Hook 注入参数 + Hook 读返回值
└─ 不能 → 程序类型？
├─ 命令行 → 运行程序，读输出
├─ DLL → 进程内加载调用
└─ GUI → 视觉驱动自动化（截图 → 定位控件 → 操作 → 读结果）
核心禁令：绝对禁止用自己重实现的代码验证自己的结论（作弊式验证）。验证必须让原始程序实际执行，从外部观察结果。
5.6 “不要执着 Python”
系统在技术栈选择上不绑定 Python——什么技术适合就用什么。内置了技术选型决策树：计算密集型（如暴力搜索、大数运算）用 C/C++（10-100 倍性能优势）；算法验证优先模拟执行而非手动重实现；性能不确定时先用 Python 原型验证正确性，必要时转 C 加速。
5.7 “失败快速切换”
同一分析方向连续失败 2 次即强制切换方向，不允许第三次尝试。Agent Prompt 中预定义了常见失败模式和对应的切换方向。累计耗时上限 120 分钟，防止陷入无限循环。
六、关键技术实现
6.1 Agent + Plugin：上下文持久化
长对话中 AI 面临三类上下文丢失问题：规则丢失（多轮后不再遵守约束）、知识丢失（压缩后之前的分析结论消失）、环境丢失（每轮无法感知工具链状态）。
Agent 解决规则问题——每轮对话都携带完整的编排行为定义，确保 AI 始终知道”该怎么做”。
Plugin解决环境和压缩问题——通过 OpenCode 的 Hook 机制在三个时机注入信息：
| | | | | — | — | — | | Hook | 作用 | 触发时机 | | system.transform | 注入环境信息（分析引擎路径、编译器、工具包版本） | 每轮对话 | | session.compacting | 注入分析状态保留提示 + 12 条核心规则 | 上下文压缩前 | | event | 管理 Session 生命周期 | 状态变化时 |
// Plugin 核心结构（简化）
export const BinaryAnalysisPlugin = async ({ directory }) => {
return {
// 每轮注入环境信息
"experimental.chat.system.transform": async (input, output) => {
output.system.push(`IDA Pro: ${config.ida_path}`);
output.system.push(`编译器: ${envCache.compiler}`);
},
// 压缩时保留关键状态
"experimental.session.compacting": async (input, output) => {
output.context.push("必须保留：分析目标、已完成的分析、当前阶段、失败记录");
},
};
};
这保证了即使对话被压缩，AI 仍然记得当前分析到哪了、什么方向已经试过并失败。
6.2 分析执行框架
系统定义了强制执行的六阶段分析框架：
阶段 0: 环境检测（强制，每次分析前）
检测工具链完整性，失败则停止并提示用户安装缺失工具
↓
阶段 A: 信息收集（自动、强制）
单次分析引擎调用完成所有基础信息收集：
段信息、入口点、导入表、字符串、壳检测、场景分类
↓
阶段 B: 分析规划（强制）
根据场景标签加载对应的知识库方案模板，
输出完整方案（步骤、耗时、失败切换方向）
↓
阶段 C: 执行与监控
按方案执行，遵守执行纪律：
- 同一方向连续 2 次失败 → 强制切换
- 单步骤超时 2x → 暂停评估
- 用户不应看到超过 30 秒的无输出间隔
↓
验证阶段: 结果验证
按验证决策树选择验证方式，确认分析结论正确
↓
输出阶段: 格式化输出
区分"事实"与"推测"，标注置信度，记录执行统计
6.3 场景驱动的知识库加载
阶段 A 的信息收集会产生 scene\_tags（场景标签），如 packed、crypto、gui。阶段 B 根据标签加载对应的知识库方案模板：
| | | | | — | — | — | | 场景 | 首选策略 | 关键规则 | | packed（加壳） | 快速脱壳 → 重新分析 | 定位到 OEP 立即 dump，禁止逆向解压算法 | | crypto（密码学） | 快速验证标准性 → 差异定位 → 求解 | 先确认是否标准实现，不匹配再逐步排查 | | gui（GUI 程序） | Hook 关键逻辑优先 → GUI 自动化后备 | 优先 hook 比较逻辑，GUI 自动化是最后手段 | | standard（标准） | 入口分析 → 关键函数 → 深入分析 | |
场景可组合，按优先级处理：先脱壳，再识别密码学特征，最后处理 GUI 交互。
6.4 Headless 自动化
分析引擎的脚本依赖专有模块，不能直接用系统 Python 执行，必须通过命令行工具的 headless 模式加载运行。AI 编排器直接构造命令行调用，通过环境变量传递参数，脚本内部按固定模式运行：
# 所有分析脚本的 headless 入口遵循同一套模板
if is_headless_mode:
auto_wait() # 等待分析引擎完成自动分析
result = business() # 执行业务逻辑
write_json(result) # 输出结构化 JSON
quit(exit_code) # 必须退出，否则进程不会终止
这套模板被封装为公共基础设施，具体脚本只需实现业务函数。依赖注入通过环境变量实现——分析引擎的 -S 机制只支持指定脚本路径，脚本在引擎内部运行时命令行参数被框架接管，环境变量是唯一可靠的跨层传参方式。
6.5 GUI 自动化：视觉驱动 + 优雅降级
当分析目标需要与 GUI 程序交互（如验证结果是否正确）时，系统采用视觉驱动方案：
截图 → AI 视觉模型定位控件 → 获取坐标 → 键鼠操作 → 截图读结果
这个方案的优势是通用性强——不依赖特定 UI 框架（Win32/MFC/Qt/WPF 都适用），只要人眼能看懂，AI 就能操作。
系统内置了多级降级策略，确保在各种环境下都能工作：
视觉驱动（首选）
↓ 视觉模型连续 2 次超时
控件操作（Win32 API 方案）
↓ 控件 ID 未知 或 非标准控件
Hook 注入（直接修改内存）
↓ 地址不确定
进程 Patch（底层内存写入）
↓ 全部失败
用户人工确认
每一级降级都保留了回切能力——降级后每次操作前仍尝试上一级方案，一旦恢复就切回。
5.6 进程 Patch：底层内存操作
对于需要向运行中的进程写入补丁、代码或数据的场景，系统提供了进程 Patch 工具，支持：
- Patch：修改指定地址的字节（如跳转指令改写）
- Write Data/Code：向空闲内存区域写入数据或代码
- Capture：捕获指定地址的内存值（读取中间计算结果）
- Signal：等待特定内存标记出现（同步机制）
- Trigger：通过 GUI 交互触发执行（如点击按钮）
这类操作作为最后手段，仅在常规方法全部失败时使用。
七、进化机制
系统的独特之处在于它有一套自我改进机制——进化命令。核心思想是：从实际分析复盘中发现高价值改进，经用户讨论确认后按严格质量流程实施。
七阶段进化流程
Phase 0: 复盘分析（循环直到无遗漏）
回顾使用过程，统计工具调用次数、手写脚本次数、对话轮次、失败次数，
识别痛点并分析根因
Phase 1: 讨论（必须等用户确认）
对每个候选方案做"四维度量"评估，分为"推荐做/可选做/不建议做"三级
Phase 2: 生成需求文档
包含背景目标、技术方案、实施步骤拆分、验收标准
Phase 3: 审计需求文档（循环直到连续通过）
Phase 4: 确认执行计划 + Prompt 瘦身检查（主 Prompt 行数控制）
Phase 5: 执行任务（严格按步骤，每步 ≤ 200 行代码，逐步验证）
Phase 6: 审计实现（2 轮审计+修复 → 纯审计 → 通过）
实施粒度控制
进化流程中一个关键的工程实践是步骤拆分：需求文档必须将实施拆分为可验证的小步骤，每个步骤代码改动不超过 200 行，必须有明确的验证点。Phase 5 执行时禁止合并或跳过步骤，每步完成后写进度摘要到文件（防止上下文压缩丢失进度）。
反模式防护
进化流程中内置了反模式警告，防止”为了改进而改进”：
| | | | — | — | | 反模式 | 为什么不该做 | | 给简单计算写脚本 | AI 自己就能完成；脚本膨胀占用 Prompt 空间 | | 为了”完整性”加功能 | 用户没遇到的痛点就不是痛点（YAGNI） | | 一次性特化脚本 | 只解决特定目标的问题，不通用 | | 过度封装 | 重复 3 次以上再抽象 | | 在主 Prompt 中保留可提取的详细流程 | 违反渐进式披露 |
八、架构决策回顾
8.1 为什么选择 Prompt 而非代码编排？
AI 编排器的核心逻辑写在 Markdown Prompt 中（约 500 行），而非 Python 代码。这个决策的原因是：
- 灵活性：Prompt 用自然语言描述策略，调整无需重编译
- AI 原生：AI 模型本身就是”执行” Prompt 的引擎
- 渐进式披露天然适配：Prompt 中声明”当 X 发生时读取 Y 文件”，AI 自然理解条件分支
8.2 为什么需要 Plugin？
单靠 Agent Prompt 无法解决长对话中的上下文丢失问题。Plugin 通过 Hook 机制在三个层面提供保障：每轮注入环境信息（AI 始终知道工具链状态）、压缩时保留分析状态（不丢失已发现的结论和失败记录）、Session 生命周期管理（为未来的跨 Session 持久化预留扩展点）。
8.3 为什么需要”共享分析层”？
在原始的三层架构（基础设施 ← 业务工具 ← 操作脚本）中，多种查询类型和独立脚本共享大量分析逻辑（段分析、入口点识别、壳检测、场景分类等）。如果这些逻辑分散在各脚本中，不仅难以维护，还会导致分析结果不一致。引入”共享分析层”将这些逻辑收口到一处，确保一致性。
8.4 为什么选择 OpenCode？
我通过研究 OpenCode 源码学习AI助手原理，所以有感情。能在 OpenCode 上用的 AI 命令，在 Claude Code 上也能用。
九、复现指南
9.1 选择 AI 框架
选择一个支持自定义 Agent、Plugin Hook 和工具调用的 AI 框架。核心需求：
- Agent：Markdown 格式的行为定义
- Plugin：每轮注入信息、压缩时保留状态的 Hook 机制
- 工具调用：执行命令行、读写文件
9.2 搭建工具脚本层
- 基础设施层：统一的日志、环境变量读取、JSON 输出、headless 入口模板
- 业务工具层：thunk 追踪、地址解析、数据读取等共享能力
- 共享分析层：段分析、入口点识别、壳检测、场景分类
- 操作层：查询和更新操作，每种类型返回标准 JSON
9.3 编写 Agent Prompt
-
定义角色与核心约束
-
定义强制的分析执行框架（信息收集 → 规划 → 执行 → 验证）
-
列出工具清单（精简版）
-
建立知识库索引（触发条件 → 文档名）
-
控制总行数，详细策略移至知识库
9.4 实现 Plugin
1.system.transform：每轮注入环境信息
2.session.compacting`：压缩时注入状态保留提示和核心规则
3.event：Session 生命周期管理
9.5 建立知识库
按场景组织，每份文档自包含（不依赖主 Prompt 上下文即可理解）。核心文档：
- 分析规划（场景分类与方案模板）
- 验证模式（验证决策树）
- 技术选型（语言/工具选择决策树）
- 特定场景策略（加壳、密码学、GUI 等）
9.6 建立进化机制
-
复盘流程：统计指标，识别痛点
-
四维度量：上下文、轮次、速度、准确度
-
实施粒度控制：每步 ≤ 200 行，逐步验证
-
沉淀机制：验证通过的脚本注册到索引，优先使用
十、总结
Binary Analysis Agent 的核心思想可以概括为四点：
1.AI 作为编排器，工具脚本作为执行器——AI 不直接操作 GUI，通过标准化的 CLI 接口间接操作分析引擎
2.强制框架 + 场景驱动——信息收集 → 规划 → 执行 → 验证，不允许跳过；按场景加载对应策略
3.Agent + Plugin 实现上下文持久化——Agent 保证规则不丢，Plugin 保证环境和状态不丢
- 经验驱动的持续进化——从实际复盘中发现改进点，经四维度量评估后按严格质量流程实施
这套架构不绑定特定的 AI 模型或分析工具——只要分析引擎提供 CLI 模式和脚本扩展能力，只要 AI 框架支持 Agent/Plugin/工具调用，相同的架构模式就可以复用。其价值不在于某个具体的查询操作，而在于”让 AI 自主编排专业工具、场景驱动按需加载知识、长对话不丢失上下文”这一工程范式的可行性验证。
#
看雪ID：不歪
https://bbs.kanxue.com/user-home-552616.htm
*本文为看雪论坛优秀文章，由 不歪 原创，转载请注明来自看雪社区
第十届安全开发者峰会【议题征集】-欢迎投稿
往期推荐
安卓逆向基础知识之frida Hook
2025 强网杯和强网拟态部分题解
在逆向分析方面-unidbg真的适合 MCP 吗？
AI静态分析，内核模块隐藏 Frida 特征，绕过linker私有结构遍历崩溃链
某安全so库深度解析
球分享
球点赞
球在看
点击阅读原文查看更多
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：看雪学苑 不歪 不歪《【AI自动逆向算法】Binary Analysis Agent：构建AI驱动的二进制分析系统》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论