带你搞懂符号执行的前世今生与最近技术( 二 ) _符号执行

然而将程序转换为IR需要计算能力并且对程序执行过程引入了开销；然而一些实现过程放弃了翻译而直接工作在机器代码上，这种解决方案除了性能上的优势，同时在执行器无法怎样解释指令时，会帮助提升鲁棒性。然而在另一方面，这种解决方案会导致执行器被限制在了一种特定的架构之中。另一种基于源码的执行器在实际中并不是那么广泛使用，因为大多数情况下只能得到二进制文件。
binary-only符号执行仅仅针对二进制文件的符号执行添加了许多挑战：缺少源代码，将程序翻译为IR需要可靠的反汇编器；由于静态反汇编的挑战，大多数实现都是在运行态按需进行反汇编。当源码不可得时，针对架构的支持同样也是重要的，此时交叉编译不可行。尤其针对嵌入式设备来说，缺少对多架构的支持是不可行的。
无需翻译的执行器除了面对复杂实现带来的可维护问题外，还面临可移植性问题。将程序翻译为中间语言的执行器需要可靠的反汇编器，已经有大量的工作来确定翻译器的准确性。基于源码的执行器可以较容易的获得IR 。
基于二进制文件的符号执行对于高性能以及多架构支持具有更迫切的需求。
最先进解决方案下面描述最先进的符号执行实验方案以及他们各自对应解决的问题。
angr

文章插图

一个经典的符号执行翻译器，使用VEX，Valgrind框架的翻译器和IR 。目标程序在运行时被翻译。其中一个优化，angr可以在Unicorn，基于qemu的快速CPU模拟器，上执行不涉及符号数据的计算。
由于基于VEX，agnr固然可以支持所有VEX能够处理的架构，因为angr核心由Python/ target=_blank class=infotextkey>Python语言实现，所以他速度慢但是很通用。
s2e

文章插图

由于想要将基于源代码符号执行覆盖范围拓展到目标程序依赖以及操作系统内核，创造了s2e 。为了实现这个目的，s2e在qemu仿真器内执行整个操作系统并且将其与KLEE链接为了符号化执行相关代码。
这个系统相当复杂，包括被测试程序的多重翻译：

QEMU是一个二进制文件翻译器，比如在通常操作中，他讲目标程序从机器代码翻译为一种中间表示即TCG ops，然后将其重新编译为针对host CPU的机器码。
当执行是设计符号化数据时，S2E使用的修改过的QEEMU不再将TCGops重编译为机器代码，他将其翻译为LLVM bitcode，随后将其传递给KLEE 。
KLEE符号化解释执行LLVM bitcode，然后将结果的具体情况回传给QEMU 。

此系统可以很灵活的处理不同处理器架构，并且可以支持针对操作系统全层面的计算跟踪。然而他需要付出一下代价：S2E是一个具有庞大代码基础的复杂系统。并且两部分翻译，从机器码翻译为TCG ops和从TCG ops翻译为LLVM bitcode损害了他的性能。与angr针对用户态程序来比较，S2E需要更多的设计建立以及运行，但是提供了一个更加全面的分析。
QSYM

文章插图

QSYM在性能上有极大的增强，他不将目标程序翻译为中间语言。他在运行态时向x86机器码内进行插桩来向二进制文件内添加符号追踪。具体来讲，他应用了Inter Pin，一种动态二进制插桩框架，来向目标程序内插入hook代码。在hook内部，他和程序运行的实际代码等价的运行符号代码。
这种方式产生了一种针对x86程序的非常快速并且鲁棒性很强的符号执行引擎。然而，这个系统固然会被限制在x86框架内，并且实现是繁琐的，因为他需要处理在计算中可能出现的任何指令。并且将其迁移到其他架构将会有很大的困难。
symcc