Abstract
背景: IoT设备普遍，在IoT上找bug必要；但是fireware复杂而且不标准，因此往往只能用黑盒，但黑盒产生的输入往往无效；使用companion app是一种方法，但是往往只能够产生app-side validation code相关的fuzzing input，这限制了测试能力
本文: 设计DIANE
前提: companion apps中存在一些可以用来辅助生成fuzzing inputs的函数，本文称其为fuzzing triggers。程序逻辑一般是按照输入验证，triggers，数据转换这样的顺序执行的，因此，利用这些triggers能生成不被app-side sanitization code限制，同时也能通过一部分输入检查的输入。
目的：利用companion app来生成输入，但是不被app-side validation code限制
方法：1. 利用静态+动态方法找到fuzzing triggers 2. 利用fuzzing triggers生成输入对IoT设备做检测
实验:
对象: 11 popular IoT devices
效果:
- 找到11 bugs(9个0-day漏洞）
- 证明了某些bugs只有通过triggers才能构建输入并触发
1. Intro
P1: 物联网设备受欢迎；物联网安全漏洞重要且呈现逐渐多发
P2: 物联网安全漏洞存在于软件或者固件中；造成损失很大；例子 Mirai
P3: 已有方法限制：
- 获取设备上运行的固件困难，供货商很少会公开固件
- 打开并分析固件也困难那：固件本身可能有多种格式，并且可能运行在多种架构上，而且常常没有文档记录
- 许多设备本身有阻止硬件调试的功能，这阻碍了动态插桩
P4: 常用黑盒方法，但需要知道要分析的设备接受的数据格式；考虑到IoT设备的差异性，而且很多IoT设备采用的协议并没有文档记录，所以黑盒方法不可行
P5: 许多IoT设备有companion apps，这些apps能够用来辅助生成测试输入；
IoTFuzzer: 获取全部从UI到网络相关或者数据编码相关的路径，然后对每条路径上的第一个函数做fuzzing。
P6: IoTFuzzer的不足：输入是在验证或者数据变换之前做的，所以很多输入就无法通过验证或者数据变化，因此也就会有性能下降。
具体来说，本文的实验表明51%的apps会做输入验证，而IoTFuzzer是无法做under-constrained yet well structured inputs