dkta0/forkseer
GitHub: dkta0/forkseer
Forkseer 结合静态分析、LLM 假设生成与 Foundry fork 模拟,将智能合约安全工具从「发现可疑模式」推进到「验证可利用漏洞」,专为白帽安全研究和负责任披露设计。
Stars: 0 | Forks: 0
# Forkseer
通过基于 fork 的验证,进行 AI 辅助的智能合约漏洞发现。
Forkseer 是一个开源研究项目,用于监控智能合约、生成漏洞假设,并通过确定性的本地 fork 模拟来验证这些假设。
它不是一个黑帽攻击机器人。它专为白帽安全研究、负责任的披露以及可复现的漏洞赏金报告而设计。
## 问题
智能合约安全工具擅长发现已知模式,但在将这些发现连接为具体的漏洞利用路径方面表现薄弱。
LLM 擅长阅读不熟悉的代码并生成假设,但在证明正确性方面能力有限。
Forkseer 结合了两者:
- 静态分析
- 源码和部署检查
- LLM 辅助的漏洞假设生成
- 基于 fork 的漏洞模拟
- 可复现的概念验证报告
目标是缩短从“这看起来可疑”到“这是一个已验证、可报告的漏洞”之间的时间。
## 非目标
Forkseer 不是:
- 三明治机器人
- 抢跑机器人
- 盗窃自动化系统
- 通用的 MEV 搜索器
- 人工安全审查的替代品
- 未经授权的资金提取系统
## 目标用户
- 智能合约安全研究员
- 漏洞赏金猎人
- 协议安全团队
- 审计机构
- 白帽救援组织
- 监控自身部署的 DeFi 开发者
## 高层架构
```
Contract Sources / Deployments
↓
Contract Classifier
↓
Static Analysis Layer
↓
LLM Hypothesis Engine
↓
Fork Simulation Harness
↓
Exploitability Scoring
↓
Responsible Disclosure Report
```
## 核心工作流
1. 导入合约源码或 bytecode。
2. 对合约类型进行分类:
- token
- vault
- AMM
- 借贷市场
- 质押合约
- 跨链桥
- oracle 适配器
- proxy
- router
3. 运行确定性分析器:
- Slither
- Aderyn
- Semgrep
- 自定义规则包
4. 要求 LLM 基于以下内容生成漏洞假设:
- 代码
- 分析器输出
- 协议文档
- 已知漏洞类别
- 威胁模型
5. 将假设转化为 fork 模拟测试。
6. 针对本地 fork 运行模拟。
7. 仅输出已验证的发现。
8. 生成负责任的披露报告。
## 漏洞发现生命周期示例
```
Potential issue:
"Vault withdraw path performs external transfer before accounting update."
Hypothesis:
"Attacker may be able to reenter withdraw() and drain vault shares."
Validation:
- create fork test
- deploy attacker contract
- seed vault state
- execute exploit transaction
- compare attacker balance before/after
- compare vault invariant before/after
Output:
- severity estimate
- affected contract
- exact transaction trace
- minimal PoC
- recommended fix
- disclosure report
```
## 初始漏洞类别
第一个版本应重点关注高信号漏洞类别:
- 未初始化的 proxy
- public 或保护薄弱的初始化程序
- 缺失的访问控制
- 不安全的 `delegatecall`
- 任意外部调用
- vault/token 流程中的重入
- oracle 操纵
- 陈旧的 oracle 读取
- 错误的小数位假设
- 签名重放
- 失效的 EIP-712 域隔离
- 不受限制的铸币/销毁
- 错误的份额计算
- 与 fee-on-transfer token 不兼容
- 对闪电贷敏感的定价
- 不安全的升级授权
- 暴露的 sweep/rescue 函数
## 设计原则
### 确定性验证优先于 AI 置信度
LLM 提示“这可能被利用”并不算是一项发现。
一项发现需要通过测试、模拟或形式化推理进行可复现的验证。
### 默认遵循白帽原则
该项目应为以下方面进行优化:
- 负责任的披露
- 漏洞赏金提交
- 协议自有的监控
- 仅限本地的概念验证生成
不应为以下方面进行优化:
- 隐蔽性
- 未经授权的提取
- 抢跑受害者
- 自动化的主网执行
### 先做窄,后扩展
第一个版本应目标明确地处理好少量漏洞类别,而不是试图理解所有的 DeFi。
### 人工介入报告
系统可以生成报告,但在披露之前,每一份提交都必须由人工进行审查。
## 提议的模块
```
forkseer/
├── ingest/ # source, bytecode, deployment, ABI ingestion
├── classify/ # contract type classification
├── analyze/ # static analyzer integrations
├── hypothesize/ # LLM-generated exploit hypotheses
├── simulate/ # Foundry/Anvil fork simulation
├── score/ # severity and confidence scoring
├── report/ # markdown/Immunefi-style report generation
└── rules/ # vulnerability rule packs
```
## MVP 范围
MVP 不需要监控 mempool。
第一个有用的版本应该:
- 接受一个合约地址
- 从区块浏览器获取已验证的源码
- 检测 proxy 模式
- 运行静态分析器
- 生成排序后的漏洞假设
- 生成 Foundry 测试骨架
- 运行 fork 模拟
- 输出 markdown 报告
## 伦理边界
本项目仅供授权的安全研究使用。
如果已验证的漏洞影响了线上资金,适当的下一步是通过协议发布的安全流程、漏洞赏金平台或受信任的白帽协调渠道进行负责任的披露。
参见 [ETHICS.md](./ETHICS.md)。
## 状态
设计阶段。
参见 [ADR-0001](./docs/adr/0001-ai-assisted-smart-contract-vulnerability-sentinel.md)。
标签:C2, DLL 劫持, Web3安全, 云安全监控, 大语言模型, 智能合约审计, 自动化漏洞挖掘, 静态分析