IOT fuzz 现状
根据先前的 iot安全背景知识,我们总结过，嵌入式设备大概分为I型，II型，III三型，其中I型和II型比较接近现有的传统PC计算机，起码是有分为内核态和用户态的，换句话说，I型和II型嵌入式固件多少是有检测机制的(segment fault ,etc)，这些设备其实可以用传统的fuzz技术来进行测试。
然而，对于III型嵌入式固件(monolithic firmware)而言，它是没有分成内核和用户态的，所有的程序都集成到了一个程序当中。这类程序通常没有相应的检测机制（节省空间），安装这种固件的嵌入式设备，通常资源都是有限的，对于fuzz来说，无疑是晴天霹雳。
- 资源有限导致fuzz效率很差
- 没有检测机制导致fuzz无法捕捉到相应的错误
具体而言，fuzz依靠Observing exit status（查看返回的错误代码），Catching the crashing exception（hook exception handler），Leveraging mechanisms provided by the OS（借助os提供的保护机制）。
针对上面提到的两个主要毛病，有许多有代价的解决方案。
解决方案
1. Static Instrumentation
prerequisites：源码和编译工具链
在有源码和编译工具链的情况下，在源码里插入检测机制，重新编译.<br
个人感觉这种办法没啥用，因为嵌入式设备厂商一般不开放源代码,如果是内部人士，或许可行
2. Binary Rewriting
prerequisites: 固件和设备
在获取固件的情况下，对firmware的二进制文件插入相应的检测技术，其实难度还挺大的（😀。
3.Physical Re-Hosting
prerequisites: 源码, 编译链, 不同设备
将源代码重新编译到其他设备上，其他设备可能拥有更高算力。
4.Full Emulation
全模拟，把固件的所有行为都模拟一遍。
实际上模拟固件要花费的经力还挺大的。特别是外设模拟
5.Partial Emulation
退而求其次，只模拟固件，不模拟外设
6.Hardware-Supported Instrumentation
利用硬件支持的调试接口(例如，UART)，可以利用高级接口获取更多的运行时信息，辅助fuzz发现crash。
题外话
在我读的What You Corrupt Is Not What You Crash: Challenges in Fuzzing Embedded Devices论文中，论文作者提出了6种启发式方法，其实对于这些个启发式方法的实现，这些个方法，是基于模拟器修改的，在模拟器的基础上增加了一个额外的监控器，包括Segment Tracking，Format Specifier Tracking，Heap Object Tracking，Call Stack Tracking，Call Frame Tracking，Stack Object Tracking
其实感觉吧，也算是Emulation的延申吧。
另外，在读Discovery and Identification of Memory Corruption Vulnerabilities on Bare-metal Embedded Devices时，作者通过binary rewriting方法插入检测机制，还算比较有趣。
µSBS: Static Binary Sanitization of Bare-metal Embedded Devices for Fault Observability跟上面的一篇文章讲得是同一个东西，哈哈哈哈，这种情况还是比较罕见的，但是不得不承认，看完后对于它的实现原理有了更深入的了解。
之后应该会针对这个工具的实现原理进行一个细致的分析，并重写得到一个新的解析器。