2023-9-14讨论班

API Fuzz Driver Generation

Fuzz是个框架，Fuzz Driver是要测的序列，所以这里说的是对于API的Fuzz如何生成序列

Fuzzing的关键是构造Fuzz Dirver以及Input Generator

既然Fuzz需要接受输入执行代码，那如何应用到lib等API上？

• API有依赖关系，Data、Control
• 构建符合API语义的代码

相关工作

• 收集用户代码片段，通过call graph构建API依赖关系

  语义更好，收集高质量较难

  • 工作1：首先由一批CFG的执行图，清除无关的api调用得到精简图，将这些图中的公共顶点合并，跑一遍DFS去除环，得到合并后的CFG图和拓扑序

  • 工作2：将用户程序抽象为自动机(程序状态点，函数调用、控制判断为边)，然后简化自动机，合并啥的

    用自动机的原因是他能标识判断的多分支

• 从API文档等构建依赖图，根据图游走构建序列

  覆盖更全，序列较短，语义不足

  • 工作1：期望覆盖更多API依赖图
  • 工作2：初始是单独的API node，通过mutation组装这些node

对于有复杂签名的API暂时没有好的处理方法，例如泛型函数，rust有Trait Bound，Java有基于Interface的约束，C++20有Concept约束。程序可能会生成原来库里没有的函数签名。

Solution表示一种泛型参数的取值，Match是用具体的类型匹配泛型函数，而Mono则是函数的单态化

使用其他API涉及的类型逐步推导更多的Match，然后生成所有可能的单态化函数，删除行为相同的单态化函数（行为用函数调用的方法集表示）。针对优化过的这些单态化函数进行覆盖等操作。

Generative Type Inference for Python（ASE’23）

静态类型推断——coverage比较低

有监督的类型推断：用训练的方式推断——需要大量的优质数据

利用nlp的填空模型填入模型——可解释性欠缺

TypeGen：利用大语言模型对话式地推断——可解释性变好了

• 对象的上下文就是knowledge
  • 代码裁剪：生成对象的类型依赖图->移除和当前要分析的变量无关的变量
• 合法类型
  • 用户定义的类型+python类型+第三方包类型(他们对top10000的第三方库建了一个数据库可以直接拿出来)
• 用这些信息拼起来作为prompt喂给大模型

My Comment：工作量就一两周，还是故事讲得好，有一定的参考意义