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安全, 云安全监控, 大语言模型, 智能合约审计, 自动化漏洞挖掘, 静态分析