自动化补丁情报与发现框架
一个用于检测 Windows 内核驱动程序补丁中漏洞修复的语义分析引擎。AutoPiff 使用保守的 YAML 规则,以高精度和可解释性识别安全相关的代码变更。
AutoPiff 分析易受攻击版本与已修补版本之间的差异,自动检测:
ExFreePool 后的空值赋值)memcpy 前的长度校验)ProbeForRead/ProbeForWrite)Vendor releases 500 driver updates/year
├── 490 are feature/performance/cosmetic changes
├── 8 are minor bug fixes
└── 2 are silent security fixes (no CVE assigned)
Without automation: Manually review 500 to find 2
With AutoPiff: Review 10 high-scorers to find 2
安全补丁通常在没有 CVE 分配的情况下发布。手动逆向分析每一个驱动更新来找出与安全相关的部分是不可行的。AutoPiff 通过自动呈现重要的变更来解决这一问题。
总计:每个驱动对 4-12 小时缩短至 2-5 分钟
┌─────────────────────────────────────────────────────────────────┐
│ AutoPiff 自动化的部分 │
│ ├── 找到针:"此函数在 ExFreePool 附近发生变更" │
│ ├── 分类:"看起来像释放后使用修复" │
│ └── 排序:"得分 5.5 - 值得调查" │
├─────────────────────────────────────────────────────────────────┤
│ 仍需手动(您的专业判断) │
│ ├── 确认可利用性:"我能否实际触发它?" │
│ ├── 根因分析:"为什么存在漏洞?" │
│ ├── 漏洞利用开发:"如何到达这个汇点?" │
│ └── 影响评估:"现实风险如何?" │
└─────────────────────────────────────────────────────────────────┘
AutoPiff 并非要取代漏洞利用研究,而是通过自动化侦察阶段,使其在规模上可行。
1. 静默补丁检测
2. 一日漏洞研究
3. 厂商安全审计
4. 历史 CVE 语料库构建
AutoPiff 作为 Karton 管道运行,包含 8 个顺序阶段和一个并行的 DriverAtlas 分流分支。每个阶段都是通过 Redis/RabbitMQ 通信的独立微服务。
graph LR
sources["WinBIndex<br/>VirusTotal"]:::src --> s0["Stage 0<br/>Monitor"]
s0 --> s14["Stages 1-4<br/>Patch Differ"]
s0 --> triage["DriverAtlas<br/>Triage"]:::triage
s14 --> s5["Stage 5<br/>Reachability"]
s5 --> s6["Stage 6<br/>Ranking"]
s6 --> s7["Stage 7<br/>Report"]
s6 --> s8["Stage 8<br/>Alerter"]
triage --> alerts["MWDB Tags<br/>+ Alerts"]:::triage
classDef src fill:#1a1a2e,stroke:#e94560,color:#eee
classDef triage fill:#1a1a2e,stroke:#e9a345,color:#eee
classDef default fill:#16213e,stroke:#0f3460,color:#eee
AutoPiff 包含 22 个类别共 58 条规则。完整规范请参见 Docs/semantic_rules.md,技术参考请参见 Docs/SEMANTIC_RULES_REFERENCE.md。
规则引擎跟踪 8 个汇点组中的 50 多个危险 API 符号:
memory_copy: RtlCopyMemory, memcpy, memmovepool_alloc: ExAllocatePool, ExAllocatePoolWithTagpool_free: ExFreePool, ExFreePoolWithTaguser_probe: ProbeForRead, ProbeForWriteio_sanitization: RtlULongAdd, RtlSizeTMultexceptions: __try, __exceptstring_copy: strcpy, wcsncpyrefcounting: InterlockedIncrement/Decrement发现结果使用可配置模型评分(rules/scoring.yaml):
final_score = semantic_score + reachability_bonus + sink_bonus - penalties
评分组成部分:
门控:
git clone https://github.com/splintersfury/AutoPiff.git
cd AutoPiff
docker compose up -d
包含 MWDB、仪表盘和监控的完整生产环境栈,请参见 driver_analyzer。
pip install pyyaml
from services.karton_patch_differ.rule_engine import SemanticRuleEngine
engine = SemanticRuleEngine('rules/semantic_rules.yaml', 'rules/sinks.yaml')
hits = engine.evaluate(func_name, old_code, new_code, diff_lines)
编辑 rules/semantic_rules.yaml 以添加或修改规则:
rules:
- rule_id: my_custom_rule
category: bounds_check
confidence: 0.85
required_signals:
- sink_group: memory_copy
- change_type: guard_added
- guard_kind: length_check
plain_english_summary: Added length validation before memory copy.
AutoPiff 生成附加到 MWDB 样本的 JSON 报告:
{
"pairing": {
"driver_new": {"sha256": "...", "version": "2.0.9.0"},
"driver_old": {"sha256": "...", "version": "2.0.8.0"},
"decision": "accept",
"confidence": 0.95
},
"semantic_deltas": {
"deltas": [
{
"function": "HandleIoctl",
"rule_id": "null_after_free_added",
"category": "lifetime_fix",
"confidence": 0.88,
"sinks": ["pool_free"],
"final_score": 5.5,
"why_matters": "Pointer is now set to NULL after freeing memory."
}
],
"summary": {
"total_deltas": 1,
"top_score": 5.5,
"match_rate": 100.0
}
}
}
AutoPiff/
├── Docs/ # Design docs and specifications
├── ghidra/scripts/ # Ghidra headless scripts
│ └── autopiff_reachability.py # Reachability BFS + decompilation export
├── rules/
│ ├── semantic_rules.yaml # 58 detection rules
│ ├── sinks.yaml # 50+ dangerous API symbols
│ └── scoring.yaml # Scoring model configuration
├── schemas/ # JSON schemas for each stage
├── services/
│ ├── karton-patch-differ/ # Stages 1-4: diffing + semantic analysis
│ ├── karton-reachability/ # Stage 5: call-graph + decompilation
│ ├── karton-ranking/ # Stage 6: scoring
│ ├── karton-report/ # Stage 7: report generation
│ ├── karton-driver-triage/ # DriverAtlas attack surface triage
│ ├── autopiff-alerter/ # Stage 8: Telegram alerts
│ ├── driver-monitor/ # Stage 0: version polling
│ └── dashboard/ # Web UI
├── tests/unit/ # 137 unit tests
├── docker-compose.yml
└── README.md
AutoPiff 旨在与 driver_analyzer 配合使用,后者提供了完整的生产基础设施(MWDB、Karton、MinIO、仪表盘)。driver_analyzer 的 docker-compose 文件直接构建 AutoPiff 服务:
# In driver_analyzer/docker-compose.yml
karton-driver-patch-differ:
build:
context: ../AutoPiff
dockerfile: services/karton-patch-differ/Dockerfile
volumes:
- ../AutoPiff/rules:/app/rules:ro
安装说明请参见 driver_analyzer README。
MIT 许可证 - 详情请参见 LICENSE。
| 阶段 | 手动工作量 | 使用 AutoPiff | 节省时间 |
|---|
| 版本配对 | 5-15分钟/驱动 | 自动 | ~100% |
| 反编译 | 2-10分钟/二进制 | 批量并行 | ~95% |
| 函数匹配 | 30-60分钟/对 | 即时 | ~100% |
| 识别安全变更 | 2-8小时/对 | 数秒 | ~99% |
| 初步分类与排序 | 1-2小时 | 即时 | ~100% |
| 报告生成 | 30-60分钟 | 即时 | ~100% |
| 阶段 | 服务 | 功能 |
|---|
| 0 | driver-monitor | 轮询 WinBIndex 和 VirusTotal 以获取新驱动版本,上传至 MWDB |
| 1-4 | karton-patch-differ | 版本配对,Ghidra 反编译,函数匹配,语义规则评估 |
| 5 | karton-reachability | Ghidra 调用图 BFS,从 IOCTL/IRP 入口点到变更函数,完整反编译导出 |
| 6 | karton-ranking | 根据可达性、语义严重性和攻击面评分 |
| 7 | karton-report | 生成结构化 Markdown 报告,上传至 MWDB |
| 8 | autopiff-alerter | 对得分 >= 8.0 的发现发送 Telegram 告警 |
| — | autopiff-driver-triage | DriverAtlas 攻击面评分(与 1-4 并行),标记 MWDB 样本,Telegram 告警 |
| 类别 | 检测示例 |
|---|
bounds_check | 在 memcpy 前添加长度检查 |
lifetime_fix | ExFreePool 后空值赋值 |
user_boundary_check | 添加 ProbeForRead/ProbeForWrite |
int_overflow | 使用安全数学辅助函数 |
state_hardening | 互锁引用计数操作 |
ioctl_input_validation | 分发处理程序中的新大小/类型检查 |
pool_type_hardening | 迁移至 NonPagedPoolNx |
privilege_check | 添加 SeSinglePrivilegeCheck |
| 变量 | 描述 | 默认值 |
|---|
MWDB_API_URL | MWDB Core API 端点 | http://mwdb-core:8080/api/ |
MWDB_API_KEY | 用于上传的 MWDB API 密钥 | (必填) |
KARTON_REDIS_HOST | Karton 的 Redis 主机 | karton-redis |
AUTOPIFF_GHIDRA_TIMEOUT | Ghidra 反编译超时(秒) | 900 |
VT_API_KEY | 用于驱动监控的 VirusTotal API 密钥 | (可选) |
TELEGRAM_BOT_TOKEN | 用于告警的 Telegram Bot 令牌 | (可选) |
TELEGRAM_CHAT_ID | 用于告警的 Telegram 聊天 ID | (可选) |
AUTOPIFF_SCORE_THRESHOLD | Telegram 告警的最低分数 | 8.0 |
DRIVERATLAS_SCORE_THRESHOLD | 分流告警的最低攻击面分数 | 8.0 |
| 文档 | 描述 |
|---|
Docs/semantic_rules.md | 语义规则规范:规则的构成以及每个类别检测的内容 |
Docs/SEMANTIC_RULES_REFERENCE.md | 规则引擎、评估逻辑和评分的技术参考 |
Docs/reachability.md | 可达性标记规范:从分发入口点开始的调用图 BFS |
Docs/reporting.md | 报告输出规范和格式 |
Docs/decisions.md | 设计决策与理由日志 |
rules/semantic_rules.yaml | 全部 58 条检测规则 (YAML) |
rules/sinks.yaml | 50 多个危险 API 符号,按类别分组 |
rules/scoring.yaml | 评分模型配置 |
schemas/ | 每个管道阶段输出的 JSON schema |