让 LLM 真正像一个"安全研究员团队"那样工作:会拆任务、会用 IDA Pro、会跑 Frida、会做 Web 渗透、会自我进化——而不是只会聊天。
仓库链接在最后。
做安全分析的人都知道,一次完整的逆向或渗透任务里有大量重复性劳动:解包、反编译、字符串搜索、初轮壳检测……每换一个目标都要重新拼一遍命令、走一遍流程。研究员真正有价值的判断(这个函数是不是加密入口、这个跳转是不是关键点)反而被淹没在工具调用的琐事里。
OpenSecurity 做的事情很简单:让 LLM 自主接管一次安全分析的全过程——拿到目标文件,自己编排工具链(IDA Pro、Frida、apktool……),一步步推进,最后产出一份可验证的报告。不是停在"我建议你用 IDA 看看",而是真的把 idat 启动起来、跑脚本、读输出、做推理、再决定下一步。
注意,这不是传统意义的自动化(写个脚本批量跑工具)。区别在于:传统自动化是固定流程,遇到意外只能走预定义的错误分支;OpenSecurity 是 LLM 实时推理,根据上一步的输出决定下一步做什么,遇到死路会自己换方向。
它和一般 AI 工具的区别:
后面整个项目的设计,都是在支撑这四个能力。
整个平台构建在 OpenCode 之上(一个开源的 AI 编程 Agent 框架),在其之上做了一层安全分析专用的扩展:
关键决策:LLM 不直接操作 GUI。例如,所有 IDA 操作都走 idat -A -S<script> headless 模式 + IDAPython 脚本。这让 AI 能稳定复现分析过程,而不依赖鼠标点击的时序。
用户给的复合任务(比如"逆向这个 APK,分析它的网络通信加密算法,再用 Web 端的接口验证一下")会被自动拆分:
Coordinator 通过 Task 工具分发子任务,每个子任务由对应的专业 Agent 在独立 session 中执行,结果聚合到父任务目录下。
这是最成熟的一个 Agent。它的工作循环是:
工具脚本采用分层架构,避免重复造轮子:
13 种查询类型 覆盖逆向常用操作:decompile、xrefs_to、xrefs_from、packer_detect、read_data(支持 auto/string/bytes/pointer 四种模式)……
针对 APK/IPA 设计了独立路径:
支持真机交互:通过 adb 启动应用、Frida Hook Java/Native 方法、内存 dump DEX。
覆盖三种分析模式:
知识库里有专门的 Web Cache Poisoning 专题、框架安全速查(Django/Flask/Laravel/Express 常见配置缺陷)。
针对 LLM 应用(ChatGPT-like 服务、AI Agent、RAG 系统)的攻击面:
工具链包括 LLM 模拟器(白盒测试时模拟目标模型)、Playwright 浏览器自动化(黑盒测试时驱动 Web UI)。
这是整个平台最"反常识"的设计:让 AI 自己改进这个平台。
工作流程:
这让平台越用越强:每次实战中发现的模式,会沉淀成可复用的脚本或知识库条目,下次遇到类似场景直接调用。
security-analysis.ts 是整个平台的"操作系统"。它解决了一个 OpenCode 生态里很现实的问题——LLM 的上下文窗口是有限的,但安全分析动辄几小时、几十轮工具调用。
Plugin 的核心机制:
每次 LLM 请求前,Plugin 通过 experimental.chat.system.transform hook 把关键运行时变量注入 system prompt:
Agent 在 prompt 里看到 $PYTHON_CMD 就能直接拼出完整命令,不需要猜路径。
OpenCode 在上下文接近窗口上限时会自动压缩历史。但安全分析的中间状态(IDA 数据库路径、已识别的函数地址、已尝试的失败方向)一旦丢失,整个分析就废了。
Plugin 通过 experimental.session.compacting hook,在压缩发生之前强制注入:
压缩后 LLM 收到的提示是:
上下文刚被压缩。继续分析前必须:1. 重新读取 agent prompt 获取完整规则;2. 恢复 OPENCODEROOT、TASK_DIR 等关键变量。
安全分析中常见的失败模式:LLM 输出一段报告后判断"已完成",停下来等用户。但用户可能在睡觉、在开会、在写别的代码——分析就这么挂在那。
Plugin 监听 session.idle 事件,当主 session 空闲且任务目录存在时,自动发送恢复消息:
你之前的分析是否已经完成了?如果已经完成,请直接输出最终结论。如果尚未完成,请自主继续分析,不要停下来向用户提问。
配合 .persistence.json 控制最大持续时间(默认 6 小时),避免无限恢复。
Agent prompt 里大量使用 {{buwai-rule:片段名}} 引用共享片段:
Plugin 在 system.transform 阶段把占位符替换为 agents-rules/<name>.md 的实际内容。修改共享规则只需改一个文件,所有 Agent 同步生效。带 mtime 缓存,文件改完下次调用立即生效。
tool.execute.before hook 做两件事:
绝对禁止用自己重实现代码验证自己重实现的结果。
逆向出一个加密算法后,很容易陷入自欺欺人:用 Python 重写算法 → 用重写后的代码算 license → 算出来 → "我成功了!"。但如果重写本身就错了,验证就是错的。
正确的验证路径(决策树):
逆向新手最大的陷阱是"我把这个函数从头到尾读懂"。实际上 90% 的场景只需要找到:
绕过优先于逆向。除非用户明确要求分析保护机制本身,否则寻找最短绕过路径:Patch 跳转 > Hook 返回值 > 完整理解算法。
每条结论都必须标注来源:
低置信度的推测不允许直接报告,必须继续验证。
工具与知识库的依赖是单向的:
binary-analysis/ 是基础设施层,其他三个领域可以复用它的脚本和知识库,但反过来不行。这避免了循环依赖和知识库污染。
以一个 CTF reverse 题为例(实际任务目录会持久化所有中间产物):
用户只需要丢一句话:
帮我逆向 /Users/me/Downloads/crackme.exe,找出正确的 license
然后去喝杯咖啡,回来看 report.md。
Plugin 加载时确保 ~/bw-security-analysis/.venv 存在且可用,失败则整个 Plugin 加载失败。所有 Agent 用同一个 $PYTHON_CMD,避免依赖漂移。
每次实战中如果生成了可复用的脚本(比如"针对 VMProtect 3.x 的 OEP 定位"),evolve Agent 会把它沉淀到 scripts/ 并注册到 registry.json。下次遇到类似场景,Agent 直接调用沉淀脚本而不是从头构造。
为了 AI 生成的脚本可维护,制定了严格的 IDAPython 编码规范:
已稳定可用的领域:
需要持续打磨的:
依赖的外部工具:
OpenSecurity 不是一个"AI 替代安全研究员"的项目——优秀的分析仍然需要人的判断和经验。
它做的是把研究员从重复性劳动中解放出来:让 AI 跑那些本来就该脚本化的步骤(解包、反编译、字符串搜索、初轮壳检测),让人专注于策略决策和结果验证。
如果你对项目的某个部分感兴趣(Plugin 机制、某个 Agent 的实现、工具脚本的设计),欢迎在对应目录下深入阅读。每个 Agent 的 prompt 都附带了详细的 knowledge-base/ 文档,按需加载、不堆砌上下文。
这个平台的核心价值在于知识蒸馏——把安全研究员在实战中积累的隐性经验(脱壳套路、算法识别技巧、漏洞利用模式),提炼成可复用的脚本和知识库文档。你贡献的每一次分析经验,都会被蒸馏成所有人共享的资产,让平台越用越强。
延伸阅读:
项目地址:637K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6*7P5h3I4U0x3K6j5&6i4K6u0r3e0%4m8W2L8W2y4W2j5%4g2J5K9i4c8&6
| 层 |
内容 |
谁负责 |
| AI 编排层 |
Agent prompt(何时调用什么工具、如何推理) |
LLM |
| 工具层 |
Python/Bash 脚本(query.py、update.py、initial_analysis.py...) |
工程师维护 |
| 知识库层 |
按需加载的 Markdown(壳处理策略、Unicorn 模板、Frida 速查...) |
evolve Agent 持续沉淀 |
| 模式 |
触发条件 |
工具链 |
| 白盒 |
提供源码目录 |
框架识别 → 源码审计 → 漏洞定位 |
| 黑盒 |
提供 URL |
HTTP 探测 → 攻击面枚举 → 注入测试 |
| 灰盒 |
源码 + URL |
源码引导的黑盒验证 |
.opencode/
├── agents/
│ ├── security-coordinator.md
│ ├── binary-analysis.md
│ ├── mobile-analysis.md
│ ├── web-analysis.md
│ ├── ai-security-analysis.md
│ └── security-analysis-evolve.md
├── agents-rules/
├── plugins/
│ └── security-analysis.ts
├── binary-analysis/
├── mobile-analysis/
├── web-analysis/
├── ai-security-analysis/
└── commands/
用户: "分析这个 APK 的加密协议,对照它的后端接口验证"
│
├─
├─
└─
阶段 A: initial_analysis.py → 拿到段/入口点/导入/字符串/壳检测/场景分类
阶段 B: 读取 analysis-planning.md → 根据场景(CTF/壳/驱动/算法)选方案
阶段 C: 循环执行 → query.py(13 种查询)/ update.py(4 种更新)/ 自定义脚本
阶段 D: verification-patterns.md → 验证结论(Hook/Unicorn/GUI 自动化)
_base.py → 日志、JSON 输出、headless 入口、auto_wait/qexit
↑
_utils.py → thunk 追踪、地址解析、数据读取
↑
_analysis.py → 段、入口点、导入、字符串、壳检测、场景分类
↑
query.py / update.py / scripts/*.py
1. 复盘近期分析任务(读 timeline.log、报告、失败记录)
2. 识别高价值改进点(某个反复踩的坑、某个重复构造的脚本)
3. 提出 candidate(新增脚本 / 修改知识库 / 调整 prompt)
4. 与用户讨论确认(不能私自修改)
5. 按质量流程实施(先测试、再合并、记录变更)
- $OPENCODE_ROOT = /Users/.../.opencode
- $AGENT_DIR = /Users/.../.opencode/binary-analysis
- $SHARED_DIR = /Users/.../.opencode/binary-analysis
- $PYTHON_CMD = /Users/.../bw-security-analysis/.venv/bin/python
- IDA Pro = /Applications/IDA Pro 8.4/idat
- 编译器 = clang (/usr/bin/clang)
- Python 包 = capstone@5.0.3, unicorn@2.1.3, frida@17.2.1, ...
[内核课程]《Windows内核攻防实战》!从零到实战,融合AI与Windows内核攻防全技术栈,打造具备自动化能力的内核开发高手。
最后于 2天前
被不歪编辑
,原因: