【论文分享】SYMBION: Interleaving Symbolic with Concrete Execution

论文来源于:2020 IEEE Conference on Communications and Network Security (CNS)

研究团队:UCSB做angr的团队

今天推荐的是一个工具类的论文。正如题名,文章的工作主要是在符号执行上加了个功能,能够在具体执行和符号执行切换。

要解决的问题

背景

符号执行在分析程序和理解程序上有很大的优势,主要在于其能够生成到达程序某个状态的输入。在计算机安全领域,符号执行被广泛应用在各个领域,比如提高模糊测试的代码覆盖率、逆向恶意软件、发现闭源软件的后门以及自动生成利用。

然而符号执行有严重的状态爆炸问题,导致其无法应用在真实软件中分析。作者总结了现有符号执行存在的两个问题:

  • 缺少环境模型(Missing Environment Model)
  • 缺少数据依赖(Missing Data Dependency)

缺少环境模型可以从三个维度来说,分别是API-level、syscall-level、instruction-level。

API-level指的是库函数,比如strcpy、memcpy这些。一般符号执行引擎都会为这些函数写个模型,当符号执行到这些函数的时候,就会用模型来替代原本的库函数,这样能够避免状态爆炸。但如果遇到了符号执行引擎里没有的库函数,该如何处理呢?有两种方法,一种是自己写模型来替代库函数,另外一种是符号执行这些函数的真实的代码。第一种方法不太现实,如果有非常多的函数需要建模,就非常耗时耗力。第二种方法有可能导致状态爆炸。

Syscall-level指的是系统调用。大部分的符号执行引擎都提供了这个级别的模型,来避免在模拟环境中替代内核。由于系统调用会对系统和用户程序造成影响,这个级别的模型需要完整且精确,否则符号执行就会不可靠。

Instruction-level指的是指令。符号执行引擎支持不同体系结构常用的方法是将代码转换为中间层。然而对于现代的CISC体系结构,比如intelx86就有超过1000个合法指令,并且大部分有副作用。而由于中间层可能不会支持所有的指令就会导致从二进制转换的不准确,这些对符号执行引擎产生了很大的影响。如果出现这种情况,就会生成非法的程序状态,分析结果就会不够可靠。

缺少数据依赖

大部分的符号执行引擎都允许从任意函数开始符号执行。但需要用户去定义开始状态(比如寄存器的值和内存的值),并且还需要正确地表示数据依赖。比如,下图的例子,缺少数据依赖会导致状态爆炸问题。如果地址0x0000555555774000上的数据不存在,符号执行引擎就会将符号遍历存在0x0000555555774008这个地址上。而这个地址上的数值在后面的代码中控制循环终止。一个符号化变量控制循环的次数,就会导致死循环。

image-20210705111916076

再来一个motivating example。如果从main函数开始符号执行,在download_config函数里出现了几个winAPI(11,12,14行)是没有建模过的。这就会导致33行download_config返回的是一个符号化的变量。而这个符号变量又传到了parse_config函数里。然后,xor_key_len是基于这个符号化的参数做运算,所以xor_key_len也是符号化变量。而这个变量又控制循环的次数,所以就会导致循环无法停止。而我们要分析的heavily_packed_function就还没分析就状态爆炸了。

image-20210705112002882

怎么解决的问题

提出了interleaved symbolic execution,其核心思想是在具体执行和符号执行互相切换。主要可以分为三个步骤。

  • 具体执行(initial concrete execution)
  • 符号执行(symbolic execution)
  • 具体执行(re-synced concrete execution)

下图中的缩写表示含义为:

  • CSP:Concrete Starting Point
  • PoI:Point of Interest
  • TP:Target Point

在第一阶段,从二进制的entry开始(CSP),具体执行到PoI处。此时,保存其状态(寄存器及内存的值)

然后,在PoI处切换为符号执行,直到运行到TP。

image-20210705123238477

第三阶段要切换为具体执行。所以需要第二阶段中的符号变量转换为具体值。就是将路径约束和符号变量合在一起求解出一个具体的值,然后存在内存和寄存器里。存在PoI那个节点的状态,然后具体执行到TP处。

image-20210705123639612

解决得怎么样

作者只测试了3个恶意软件。对于这些恶意软件,需要手工分析下PoI在哪里。然后展示了自己工具在分析heavy initialization时候的优势。

感觉结果是写了三个case study。

作者开源了他的实验测试用例:https://github.com/degrigis/symbion-use-cases

总结

发现这篇论文是因为在angr的slack里发现了symbion,感到好奇,就找到这部分文档看了一下,感觉可以用到我的工作里来缓解状态爆炸的问题。

参考链接:

  • angr文档中关于symbion的部分:
    • https://docs.angr.io/advanced-topics/symbion
    • https://angr.io/blog/angr_symbion/(更详细)
  • 论文:https://ieeexplore.ieee.org/abstract/document/9162164
  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

破落之实

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值