论文Summary02——Fuzzing

github地址：https://github.com/lannan/Westworld

背景

没考虑库文件和远程平台执行

平时的符号执行要求I/O环境和库文件，但是无法（准确）处理调用库文件或者程序在远程平台（如SmartThings）执行的情况

API闭源 & 传统的对API的处理

IoT平台下有很多用于实现自动化的IoT app，app和平台通过API进行交互（如app从平台获取测试到的温度数据、登录信息等），收集这些信息
For uninterpreted functions, classical symbolic execution either sets the return variables as new symbolic inputs [54], or applies function modeling

还没有针对IoT app的符号执行

大多是针对其他平台和语言的程序，把无法符号执行的程序转为对应的中间程序进行符号执行

官方手动测试麻烦，需要自动化

左边设置动作条件，右边模拟实际环境输入

挑战

挑战1：API闭源

fuzz platform API的定义：通过fuzz API的参数确定参数和返回值之间的关系

很难分析参数范围，如果返回的是对象，记录对象中所有变量有难度

解决：不去分析

不分析sysAPI参数y和返回值O之间的关系。而是分析O.m和其ISI符号变量x的关系

挑战2：精度和完整性的平衡

动态符号执行能够克服API闭源的一些缺点（就像动态能过一些静态保护一样，有一定的去不确定性），但是动态的普遍缺点是只会执行部分路径，对路径少的小程序（如APP）影响较大

解决：选择性fuzz

找到导致missing的代码段，fuzz这些代码段。物联网fuzz的特点：是对temperature、home mode、开关等有限的离散值进行fuzz（和之前想的一样），而其他程序输入的范围很大

挑战3:本地和远端的通信代价

解决：boosted generational search

在一个测试请求中包装多个测试输入。app请求平台给的环境数据可能是条件语句的条件，决定了某个分支是否执行。识别存储环境数据的变量作为符号执行的符号输入。

挑战4：语言的特性

如闭包、内置结构体，这个之前groovy也有提及

Methodlogy

符号执行种类的选择

符号执行，一条路径对应一条符号表达式，用约束求解器求解
动态符号执行分2类（concolic testing/execution-generated testing）
适合用第一类

整体设计

一个APP负责收集path condition，另一个负责选择性fuzz
app发到web interaction（selenium web自动化测试框架实现），用于模拟登录平台，安装app，触发事件
之后发一个testing requests to run app on cloud
之后 logs本地分析

第一步 收集path condition 新生成app类似插桩的思想

1.识别entry point，每个设备有一个handler

2.识别符号输入，用户输入和环境变量识别

环境变量也作为符号输入，之前只是输入作为。环境变量作为符号且要尽量地遍历所有值才能不漏path，使用具体值会遗漏路径。

3.Instrumentation 针对不同的语句和变量，增加对应的语句和符号变量形成转换app

如果API的参数包含符号变量，将他的返回值记录为临时符号变量TSV，对返回值进行选择性fuzz确定和符号变量的关系
对变量的处理：
识别、替换环境变量、初始化符号变量
对于赋值语句的处理：
function、if、for、switch、while、闭包的处理

第二步 选择性fuzz seg-fuzzing app:加一个for循环遍历符号变量确认两者间的关系（code-segment summary）

对API返回值（TSV）进行选择性fuzz确定和符号变量的关系 ，而且是为了弥补动态的completeness不足，识别导致missing的代码片段，fuzz这些片段完善path覆盖情况

1.步骤

对应上文加一个for循环遍历符号变量确认两者间的关系

第一步：找到插入for的位置。

通过Lengauer-Tarjan algorithm找起点、log点、终点（post-dominate : CFG中到n的每条路都要经过m）

第二步：for循环的编写：实现遍历值。

插入的循环是为了遍历符号的值（作者把每个环境变量的可能取值写入了一个文件中）也能处理for语句，如果条件语句包含符号变量，则枚举可能的值。如果条件语句包含TSV，找到它对应的ISI，枚举ISI的值
takes 10 times of loop iterations to obtain their relation

2.可行性分析：

符号输入有三类：

第一类 只有少许值的，如Location mode:Home Away Night，枚举所有取值
第二类 不太多的，小于2^32，如湿度有101个值。划分为n份，每份随机选m个。如果涉及与常量比较的条件语句，选取大于等于和小于这个常量的值
第三类 大量或无限的，比如电话号码和location id。Based on our evaluation，都没用作ISI

而且据他们观察，一个app包含的TSV不超过3个，而且一个TSV有感的ISI不超过3个，且ISI一般属于第二类，因此可行

第三步 远程路径探索

有两种方法vanilla generational search boosted generational search

1.vanilla generational search 取反所有路径约束

如果条件中包含TSV，则它前面的约束，不加入之后的约束和这里TSV对应的summary P

案例

2.boosted generational search

不是算法创新，文中所说：请注意，提出的增强代际搜索不是一种新的搜索策略，而是一种解决远程执行导致的通信成本挑战的加速方法。参考文献35，36是本节算法

这种方法也是取反，只是在testing request上有所创新？
对于Fig9的3个first-generation path，第一个方法 need 3 testing requests，而本方法只需要一个testing request

实验：

dataset :

1.随机选取官方app和三方app
2.由于官方和三方的比较简单，还手动写了几个又复杂条件语句（如在条件中加入API、用户输入、）的app
3.还手动写了几个插入不同bugs的app

其它点

The number of ISI values selected for fuzzing