[[What You Corrupt Is Not What You Crash Challenges in Fuzzing Embedded Devices]] 参考：浅谈固件Fuzz_黑客技术 (hackdig.com)

嵌入式设备分类

  1.  基于 Linux OS 的嵌入式设备：对于初次接触固件漏洞挖掘的读者往往接触的都是这类嵌入式设备，如大部分的摄像头、路由器。
  2. 自定义操作系统的嵌入式设备：可能不存在内存管理单元(MMU)，不过内核和用户层仍然存在逻辑分离。
  3. 没有抽象操作系统的嵌入式设备：编译后的代码系统空间和用户空间是混在一起的，不存在内核与用户层的逻辑分离。
    1. 参考的博客给出了这样一个观点：对这种类型的设备进行 fuzz 似乎本来就比较少见，因为该种类型的设备代码量一般较小，只用逆向说不定都可以还原。

对嵌入式设备 fuzz 的难点

  1. 错误检测：嵌入式设备的防御机制少，即使触发了漏洞，但是系统没有崩溃，fuzz 器就得不到反馈，就以为没有触发漏洞。
  2. 性能和可扩展性：难以并行，每轮都要重启设备
  3. 插桩

后续作者针对错误检测这一个问题，将嵌入式设备分为三类进行测试，将它们的反应分为了 6 种情况。![[What You Corrupt Is Not What You Crash Challenges in Fuzzing Embedded Devices#Observed Behavior]]

启发式方法加强错误检测

  1. 段追踪
  2. 格式说明符跟踪
  3. 堆对象追踪
  4. 调用栈追踪
  5. 调用帧追踪
  6. 栈对象追踪

针对嵌入式设备 fuzz 问题的一些方法

（作者原文中对每种方法都给出了需要的工具和资源）

  1. 静态插桩
  2. 二进制重写
  3. 物理重托管
  4. 全仿真
  5. 部分仿真
  6. 硬件支持的插桩

启示

这篇文章的主要工作在于两部分

  1. 针对嵌入式设备缺乏错误检测机制的实验论证和解决方案
  2. 嵌入式设备 fuzzing 的现状综述

我觉得第一部分就是这篇文章的亮点，切入点很好。其次这篇文章相对于其他开发一套 fuzz 框架，或者提出某种方法的论文学术意味更强，因为工作量主要在实验上，文章最后的启发式发方法更像是展望，而不是一个具体的成果。所以说即使没有一个很好的解决方法，但是提出了问题并且证明了问题的存在也可以写一篇很好的文章。