Challenges in Fuzzing Embedded Devices：What You Corrupt Is Not What You Crash
这篇文章发表于NDSS 2018，作者Marius Muench等人来自于欧洲电信学院(EURECOM)。这个团队对于与硬件相关的程序分析颇有研究，在CCS，NDSS等顶级安全会议上发表过多篇相关论文。
一、主要内容：
在程序漏洞分析中，fuzz通常是一种有效的挖掘途径，因此，在嵌入式设备的漏洞研究中，如果能使用fuzz的方式，应该能带来较好的效果。但是，与fuzz普通软件程序不同的是，嵌入式设备固件通常缺少完善的内存检测机制，即使内存发生corruption，也不会立即被检测到，通常会产生滞后的crash或者其他的负面影响，这就会给fuzz带来较大的困难。因此本文具体分析了嵌入式设备fuzz中的难题，并提出了一些启发式的思路，希望能给后来相关的研究做一些铺垫。
本文主要做了两部分工作：1.嵌入式设备fuzz现存问题的分析和归纳;2.提出了解决这些问题的思路和方案。
二、问题归纳：
作者针对生活中的嵌入式设备根据其OS的完善程度分为了三种设备，然后针对三种设备研究了触发memory corruption时的反应。为了准确的确定memorycorruption的时机，作者修改了设备固件，人为地加入了一些漏洞，在fuzz中可以使用特定的输入触发memory corruption，以便于结果的观测和统计。实验结果如下：
实验结果印证了他们的猜测，缺少完善的内存检测机制会使设备产生难以直接观测的负面影响。
另外，嵌入式设备fuzz对于硬件的依赖较大，厂商开源代码很少，工具链缺失等情况都给Fuzz的过程带来较多的困难。模拟化门槛高使得fuzz过程难以并行，效率较低。
三、设计与实现：
为了更好的检测内存状态，作者们提出了一些检测的方法。针对段，堆和栈开发相应的检测工具或者插件，判断内存读写的合法性；针对格式化字符串，判断字符串的只读性等思路，来更好的检测corruption。作者们也设计了实验验证这些思路的可行性，结果显示，使用综合检测的方法可以检测出所有的corruption。
同时，对嵌入式设备依赖较多硬件的情况，作者们也提出了全局虚拟化和局部虚拟化的解决思路，在一定程度上能解决效率的问题。
四、总结：
本文针对现存的嵌入式fuzz困难做了归纳分析，也提出了相应的解决思路，并通过一些简单的实验验证了思路的可行性。但整体上都是一些针对一些用于测试的案例进行验证，并不能直接应用到真实的场景中，另外，提出的几点解决思路在实现上都存在较多的困难，距离可用还有很长的一段路要走。
文丨 BlackMax, DJR, Robin
