Abstract
P1: 介绍fuzz driver
目前方法：静态code analysis，在闭源上有问题
- 信息有限
- API之间的语义关系复杂(Q: the semantic relations among API functions are complex yet their correctness needs to be ensured.)
P2:
本文: APICraft
collect-combine
利用静态-动态消息(headers, binaries, traces)来获取控制、数据依赖
实验: - 5 attack surfaces from the macOS SDK
效果：
+64% code coverage
142 vulnerabilitues, 54 assigned CVE
1. Intro
关键：answer the questions of what information to extract and how to utilize it
自下而上合成fuzz驱动，collect-combine策略
这里collect指收集目标SDK消费者程序的执行轨迹，只收集API函数间的数据，并不是收集全部数据
combine指组合这些trace，考虑到所需属性可能相互冲突，基于多目标遗传算法的策略优化，满足一组预定义的指标
2. Roadmap
2.1
用例子展示了trace合并的基本策略和为何需要多个目标
3. Methodology
4. Implementation
- 写了tracing tool，能处理GUI
- 使用typeII hook，因为直接在二进制上识别退出比较难，不能只识别ret
- 轻量hook：function interposition，将hook代码包装为一个和hook target具有相同原型的函数
5. Evaluation
要回答的问题
- 能否为商业化SDK target生成fuzz driver
- 被生成的driver的效率
- 每个组件的贡献
- 能否找到新的vulnerabilities
数据集: five attack surfaces in macOS SDK as the targets, which are Image, Font, PDF, Audio, and RTF
工具：
我们使用patched honggfuzz [5, 20]，收集目标二进制库的基本块覆盖率
从开放的互联网资源 [21-29] 中随机收集从中选择种子进行实验。
使用 honggfuzz 内置的语料库最小化功能 [30]。
用libgmalloc [17]而非ASan检测内存损坏问题。
重复: 24hr * 10
Fuzzer选择: APICRAFT 可能会生成多个模糊驱动候选（第一帕累托边界的所有模糊驱动），此时选择在更多目标中得分更高的一项。 如果没有人能在所有三个目标上都做得更好，我们遵循优先顺序 DIV > EFF > COMP。
5.1 Fuzzer Generation
被追踪的每个攻击面的Consumer都是内置的 macOS 应用程序。
准备了手动的trace，保证这些trace覆盖了所有基本功能