[[What You Corrupt Is Not What You Crash Challenges in Fuzzing Embedded Devices]]
参考:浅谈固件Fuzz_黑客技术 (hackdig.com)
嵌入式设备分类
- 基于 Linux OS 的嵌入式设备:对于初次接触固件漏洞挖掘的读者往往接触的都是这类嵌入式设备,如大部分的摄像头、路由器。
- 自定义操作系统的嵌入式设备:可能不存在内存管理单元(MMU),不过内核和用户层仍然存在逻辑分离。
- 没有抽象操作系统的嵌入式设备:编译后的代码系统空间和用户空间是混在一起的,不存在内核与用户层的逻辑分离。
- 参考的博客给出了这样一个观点:对这种类型的设备进行 fuzz 似乎本来就比较少见,因为该种类型的设备代码量一般较小,只用逆向说不定都可以还原。
对嵌入式设备 fuzz 的难点
- 错误检测:嵌入式设备的防御机制少,即使触发了漏洞,但是系统没有崩溃,fuzz 器就得不到反馈,就以为没有触发漏洞。
- 性能和可扩展性:难以并行,每轮都要重启设备
- 插桩
后续作者针对错误检测这一个问题,将嵌入式设备分为三类进行测试,将它们的反应分为了 6 种情况。![[What You Corrupt Is Not What You Crash Challenges in Fuzzing Embedded Devices#Observed Behavior]]
启发式方法加强错误检测
- 段追踪
- 格式说明符跟踪
- 堆对象追踪
- 调用栈追踪
- 调用帧追踪
- 栈对象追踪
针对嵌入式设备 fuzz 问题的一些方法
(作者原文中对每种方法都给出了需要的工具和资源)
- 静态插桩
- 二进制重写
- 物理重托管
- 全仿真
- 部分仿真
- 硬件支持的插桩
启示
这篇文章的主要工作在于两部分
- 针对嵌入式设备缺乏错误检测机制的实验论证和解决方案
- 嵌入式设备 fuzzing 的现状综述
我觉得第一部分就是这篇文章的亮点,切入点很好。其次这篇文章相对于其他开发一套 fuzz 框架,或者提出某种方法的论文学术意味更强,因为工作量主要在实验上,文章最后的启发式发方法更像是展望,而不是一个具体的成果。