G.O.S.S.I.P 阅读推荐 2022-11-02 AutoMap

今天推荐的论文 What You See is Not What You Get: Revealing Hidden Memory Mapping for Peripheral Modeling 来自G.O.S.S.I.P的老朋友——OSU的林志强教授所在的研究团队，发表于刚刚结束的RAID 2022，是一篇针对嵌入式设备固件模拟执行（emulation）的研究论文

在嵌入式设备开发中，同桌面计算机最大的不同之一在于开发者需要对硬件资源进行直接管理（而中间往往没有OS），所以经常会涉及到peripheral也就是我们常说的“外设”的一些操作。下图展示了常见的一些嵌入式设备的外设通信模型。在实际使用中，每一类外设都会在内存中划定一块区域（地址范围），用来作为它们同MCU通信的中间地带。MCU在执行固件代码时，通过读写特定的地址上的值，就实现了同外设的交互。这些特定地址上的基本单元，在嵌入式开发里面被叫做寄存器（register，注意这种寄存器和桌面、服务器端的CPU上的寄存器差别）。

安全分析人员经常会使用模拟器来模拟执行嵌入式固件，其中最让人头疼的部分莫过于和外设交互这部分的模拟——外设的执行逻辑并没有体现在任何指令中，单纯一条I/O指令完全反映不出可能的行为模式。所以很多嵌入式固件模拟分析的工作都试图用一些技巧性的方式来弥补这方面的不足。实际上，现在已经有非常多的同类工作（见下表），那它们存在的不足之处是什么呢？

本文作者指出，在实际的实现过程中，模拟器常常会不正确地模拟嵌入式设备的一些行为。本文讨论的主要问题就是其中一种“奇异”的行为：在嵌入式设备外设的寄存器中，有一些特定的寄存器之间存在隐性关联关系，一旦其中的一个寄存器发生了变化，其余的也会跟着关联变化，而且这种变化不需要经过MCU的任何干预。作者把这种现象命名为hidden memory mapping，可以想象，在模拟执行分析时，如果模拟器不知道hidden memory mapping的存在，那么在对一个特定的寄存器进行操作后，并不会去把其他相关寄存器也更新一遍，这可能会导致模拟结果谬以千里。作者顺手就指出了两个常见的系统——P2IM和𝜇EMU的问题：

既然知道了问题所在，为了解决这个痛点，作者在Unicorn模拟器的基础上实现了名为AutoMap的系统。按照下图的示意，AutoMap为模拟器准确处理hidden memory mapping增加了一个中间层，可以基于领域知识（domain knowledge）来处理寄存器的隐式关联变化。

在AutoMap的实现方面，作者考虑了三款不同的MCU，包括来自Nordic Semiconductors家的NRF52832，以及意法半导体出品的STM32F103和STM32F426。作者展示了NRF52832在时钟外设上的寄存器依赖：

在实验测试中，作者针对这三款MCU的多个固件进行了分析，发现“写入单个寄存器，影响多组寄存器”的现象普遍存在，有时候受影响的寄存器的数量还蛮多的（下图）：

在结合了AutoMap系统之后，因为模拟执行更为准确了，也方便分析人员准确发现更多问题。作者把𝜇EMU和AutoMap结合起来，在进行fuzzing test的时候效果明显更好：

如果大家对AutoMap系统感兴趣，不妨去尝试一下，作者已经公布了代码：

开源项目：https://github.com/OSUSecLab/AutoMap

论文PDF：https://web.cse.ohio-state.edu/~lin.3021/file/RAID22.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-11-02 AutoMap