如需转载请注明出处，侵权必究。
本文发表于CCS2022，第一作者来自伯明翰大学的博士。
论文提出了第一个能同时rehost(托管)多个设备且与体系结构无关的框架，相对比现有面向汽车固件的rehost，实现了可模拟架构范围和设备间通信两方面的提升，能模拟测试之前工具由于缺乏处理器支持而无法模拟的ECU固件，且MetaEmu能在提供跨架构和通信支持的同时，几乎没有性能损失（与Unicorn对比）。
背景
实现嵌入式设备安全分析的方法主要集中于rehost，即通过将所需的固件模拟在新的宿主上运行，以成规模、低成本的实现特定的分析任务。但由于车辆由CAN链接多个ECU组成，这些ECU使用一些与寻常架构不同的较新的架构（V850/RH850、C166等），因此符号执行等现代分析方法无法用于车载系统的rehost。Ghidra有一个EmulatorHelper用来模拟这里面的一些结构，但不支持外设的处理，性能也不好。
在本文中，作者提出了第一个能同时托管多个设备且与体系架构无关的框架MetaEmu，MetaEmu将广泛可用的处理器和指令集定义Ghidra语言作为输入并自动合成虚拟化执行环境，从而使得MetaEmu有以下两个方面的优势：
（1）可以模拟更多架构的处理器，其中很多依赖于庞大且复杂的开源库，MetaEmu可以将各种架构的指令转化为中间语言；
（2）生成的虚拟执行环境支持多个rehost的固件设备同时执行，是第一个可以深入分析每个rehost固件的状态，进行rehost固件设备相互依赖分析的框架。
框架架构设计
下图是MetaEmu概述，下面将对该框架的主要模块进行介绍。
输入：待模拟的固件
具体而言，需要以下四种输入：
（1）处理器规格：定义寄存器名和基本内存映射；调用约定和基本类型信息；以及如何反编译代码；
（2）执行模式规范：MetaEmu在中间语言上模拟的各种执行模式；
（3）外设规范：通过用户指定和自动的规范与外设交互，使用执行观察者指定外设并通过他们的内省接口附加到模拟器；
（4）观察者列表：为了重放和操作固件状态，用户定义的观察者被附加到模拟器上。观察者具有的功能包括：处理复杂的寻址模式、实现外设的符号求解、通过与上图灰色的协调器通信，允许一个设备向另一个设备提供输入、共享分析结果。
输出：1个Virtual Execution Environments(VXE)
虚拟执行环境，能在其中托管所有输入固件，每个固件有对应的模拟器。
工作流程
（1）先输入待模拟的固件，并包含以上4种输入。
（2）之后，MetaEmu将用户定义的观察者链接到模拟器，以便动态监视和操作固件状态，这些观察者使使用者能够处理复杂的寻址模式并实现外设检查的绕过。
（3）通过连接VEX analyzer，观察者可以实现与其他重新托管的设备的通信，并共享分析事实，从而实现设备分析。
rehost复杂固件面临的挑战 & 解决方法
挑战一 架构支持和中间指令IR优化
基于Gridra的SLEIGH语言定义的中间语言太冗长，过于复杂的IR会导致更为复杂的符号公式，降低符号执行的效率。
文章解决这一问题的核心想法是通过重写获得简化的IR表示，并通过共享缓存记录来分摊开销，具体来说有以下两方面：
a.在用模拟器执行前，通过Equality Saturation（EqSat，编译优化概念）优化IR。
b.在同一固件的所有执行器中共享缓存，记录优化结果，分摊执行优过程中的开销。
最终达到的效果比Ghidra的Lifter和仿真器提高性能400%。
挑战二 缺少分析状态和上下文
在模拟固件时，设备的外设状态可能缺失或不一致，而当外设的状态与固件所期望的状态不匹配可能会导致固件“困”检查循环中，无法继续正常执行（比如，对于RTOS来说，没有外设输入，就没法执行）。
文章通过提供三种类型的外设支持来解决以上问题。对于仅以有限方式与固件交互的外设（比如通过状态检查），论文提出一种自动绕过外设检查的方案。而对于可以重复用于多种不同设备的通用外设框架，MetaEmu提供了用作通用输入源的模型，比如用于模糊化或促进固件间通信的各种定时器。最后，针对一些无法使用自动化或通用方法实现的外围设备，该论文方案通过提供基于观察者的API来手动执行外围操作，即人工实现的外设，如CAN。
其中，论文通过约束求解计算出满足退出检查循环的值来自动绕过外设的检查,主要分为以下几步：
a. 通过符号化执行，监控对MMIO区域的读操作；
b. 对于每个访问，跟踪它的数据流，并构建一个表示读取值约束的表达式树。当跟踪到达依赖于读取值的条件分支时，使用SMT solver求解分支目标,使得退出检查循环；
c. 执行分支，如果它导致我们重新进入检查循环，则使用solver得到的值替换从MMIO寄存器计算出的值。
挑战三 跨设备分析
微控制器的正常运作往往依赖于其他芯片或设备的数据，但是实现跨设备分析存在很大困难。一方面，同一VXE中的各个固件可能来自不同制造商或是基于不同架构；另一方面，跨设备的通信通道缺乏文档化的记录。
文章从两方面分别解决了这两个问题。针对前一个问题，文章提供了广泛的架构支持，和三种编写外围设备模型的方法。针对后一个问题，文章通过一个分析协调器统一了消息传递的接口。具体来说，MetaEmu通过模拟器上绑定的观察者监听模拟器上的寄存器读写，内存读写，程序计数器更改，条件分支和函数调用，从而捕获注册的事件。当事件被捕获后，分析协调器就可以通过统一的接口向其他设备分发事件。也就是说，分析协调器可以作为一个抽象的跨设备信道进行消息传递。
评估
使用性能、实现的灵活性和在现实世界中的可用性三个标准来评估MetaEmu，将MetaEmu与Unicorn和Ghidra仿真器进行对比，文中进行了四组实验，证实了MetaEmu的有效性和高效性，并实验测试了IR优化的实用性能并总结得出值得开启IR优化的情况。
1. Micro-benchmarks:除了一个基准之外，MetaEmu在其他测试集均取得了比Unicorn更高的效率。
2. Deeper Analysis of MetaEmu and Unicorn: MetaEmu在更容易和灵活扩展的同时，具有比Unicorn更高的效率。
3. IR Optimization Performance and Trade-Offs:实验测试IR优化的实际效用。发现是否应用优化取决于所执行的分析类型和分析的程序大小，当运行基于循环的固件、模糊化或执行符号执行时（由于符号公式的大小减小），优化最有意义，否则可能会对性能产生负面影响。
5. Impact of Optimizations on Real Firmware：实验测试IR优化对真实固件的影响。证实在真实固件上，可以有效地减少时间开销，提高性能。
总结
本文作者提出了第一个可支持多个rehost固件相互依赖的分析的框架，该框架能为多种架构合成VXE，并能并行分析多个固件，共享分析信息。此外，作者通过实验证明该工具的灵活性和高效性，证实可以驱动现有托管工具无法支持的真实世界中汽车固件的分析。
Q&A
Q1：为什么需要提供中断支持？
组件异步通信可能通过中断完成，把上下文保存在特征内存区域，然后切换到中断处理例程。MetaEmu提供了许多默认和可配置的中断行为，例如将中断触发器与外围设备关联，并基于指定的寄存器或内存范围执行上下文恢复。
Q2：评估性能和权衡IR优化后，什么情况下适合使用IR优化？
是否应用优化的选择取决于正在执行的分析的类型和正在分析的程序的大小。当运行基于循环的固件、模糊或执行符号执行时（由于符号公式的大小减小）时，优化最有意义，否则可能会对性能产生负面影响。
Q3：存在哪些限制？
1. 对于常见的微控制器，如基于ARM或MIPS的设备，MetaEmu的外设模型较少，这也会使得其很难与QEMU等现有模拟器进行直接比较；
2. 通用外设后端并不完全支持基于直接内存访问的I/O，这使得很难在MetaEmu中使用QEMU派生的外设模型；
3. 可以添加JIT编译器来进一步提升运行时的性能，但当下无法实现一个支持MetaEmu所有不同模式的JIT编译器
Q4：怎么实现通用外设框架的设置？
1. 提供接口拦截调用来屏蔽底层细节，如HAL API；
2. 提供内存或寄存器读写钩子；
3. 便于组合来建模各种外设的特异性。
文案：CBF
排版：YST
戳“阅读原文”即可查看论文原文哦~
复旦白泽战队
一个有情怀的安全团队
还没有关注复旦白泽战队？
公众号、知乎、微博搜索：复旦白泽战队也能找到我们哦~
原文始发于微信公众号（复旦白泽战队）：白泽带你读论文 | MetaEmu
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论