2021-7 论文阅读 [PatchScope: Memory Object Centric Patch Diffing]

0.前言

这应该是七月份阅读的最后一篇论文了，这篇论文所讲的东西我之前几乎没有接触过，因此我会尽己所能的去读懂它，介绍他。

首先，这是一篇关于补丁(patch)分析的文章，补丁包含了很大的信息量，对于构成热补丁，程序输入过滤等具有很好的参考价值。然而，解开补丁的神秘面纱，是一件十分困难的事情，开发者通常发布的是二进制程序补丁而非代码补丁，这就使我们很难寻找到与补丁相关的代码修改，更别说对补丁进行细节分析了。

那么之前有什么技术用来分析补丁呢：binary diffing，其基本思想是定义一种代码相似性表征，包括静态特征(控制流图或者调用图)与动态行为(比如系统调用依赖 ==我也不大清楚这是个啥)

大致结果就是这样的

但是一般来说这东西主要用于剽窃代码监测等，对于极小代码量改动的补丁分析效果不佳，此外，定位还只是第一步，作者还希望能通过这些补丁分析出一些细节上的东西，而binary diffing显然不具有良好的可解释性。

1.介绍

我上面究竟写了个啥，时隔一周我也看不大明白了，那干脆重新说一下吧。(系统调用依赖我认为可能就是调用系统API的顺序吧)

话说东汉末年，天下大乱，然而，一颗异星从天际划过，这个世界迎来了我们的穿越者(补丁)，那么我们要做的是什么呢，我们要看的就是这个穿越者会给这个世界带来什么，其所做的行为又有什么含义。

好的，知道了我们的目的，那我们再来看一下原先对于其的分析是怎样做的吧。

方案一：监控历史大事件的发生及其时序，以此来观察穿越者的作用，这种方法也就相当于一种静态分析的方法，官渡赤壁啥的就相当于block，其组合体就相当于程序控制流图之类的东西，我们可以比较在官渡之后是否接着徐州战役来判断大致趋势，从而用来寻找穿越者具体在那个地方起到了作用。但这种方法的问题是什么呢，他只是一种粗粒度的分析，有时候会忽略很多细节，比方说，可能官渡之战乌巢守将并不是淳于琼之类的，这种方法就没法分析出来。

方案二：监控每一个人的行为，就相当于监视两个程序下每一条指令的执行，但是问题是什么呢，比方说穿越者跟本要出门买鸡蛋的曹操聊了一天，结果曹操就只有第二天才能出门买鸡蛋，这样就会多出很多difference，而且有些还并不是那么重要。当然就这样也还好可能，但是当你发现穿越者连着爬了三次山，你能分析出他是去三顾茅庐还是登临碣石么？因此，其主要的缺陷，就是不方便分析补丁的语义。

2.PatchScope

那么作者是怎么做的呢，当然我们在这里就不举上面的例子了。

作者发现

1.各种数据结构对于输入数据的处理一定程度上体现了语义信息

2.为了修复内存损坏漏洞，安全补丁一般会通过增加或更新对于输入的处理方法来应对漏洞。从而就会对内存访问对象序列产生改变。

因此作者提出通过内存访问对象序列来比较补丁不同并分析补丁语义。

在接着往下进行之前，我先来介绍一下作者提出的一些定义

Memory Object: 代表执行过程中用的数据结构，比如int，float，vector，point之类的，由一个三元组表示，mobj = (alloc, size, type)。其中，alloc代表分配变量时的上下文信息，size代表分配的空间大小，type则表示变量的类型如静态变量，堆中变量，栈中变量。

Memory Object Access: 用于表示对于内存对象的访问，用一个五元组表示A(mobj) = (mobj, cc, op, optype, α)，cc代表该内存对象被访问的环境，比方说调用它的函数等，op代表对于数据的操作如移动，计算，调用库函数，optype代表操作类型如读写，a代表与其有关的输入数据。

通过对于内存对象访问序列的比较，我们可以得到大概如下的一个结果，这样我们分析补丁就会容易多了。

那么接下来我们再来讲一下操作的细节，作者将具体操作分为了四部分，分别是：

dynamic taint and execution monitoring 动态污点分析与执行时监控

memory object excavation 内存对象提取

memory object access construction 构建内存访问对象

MOAS alignment 内存对象访问序列对齐

其总体结构如下所示，PoC你可以理解成能够出发那个补丁漏洞的输入

首先来聊一下动态污点分析与执行时监控，该部分是通过一个基于QEMU的系统动态二进制分析平台DECAF实现的，多标签污点分析对于厘清输入数据与内存对象的联系是不可缺少的，对于每一个输入字节，系统都会给与一个独一无二的污点标签，在污染传播过程中，如果一个指令的多个操作数都具有污点标签，那么目的操作数的标签将是其总和，其还对程序运行时状态进行一个分析，用来恢复函数调用栈和提取内存对象，并且关注与内存分配相关的系统调用。

上面那段字你大概都能看明白(不要问我具体实现出来是啥样的。。。我只是个读论文的==)，可能唯一比较疑惑的就是为什么要恢复函数调用栈，这是因为我们发现无论是内存对象还是内存访问，都要求我们记录其上下文环境，因此这个操作也是必要的。

接下来就是内存对象的提取了，作者关注于操纵输入的内存对象的提取，提取的是对象的根指针，什么是根指针呢，根指针对于每一个内存对象来说都是独一无二的，且不会由其他指针派生出来。对于静态变量与堆中变量来说，根指针的提取比较简单，但是对于栈中变量，其根指针的提取就比较困难了，这涉及到了一些指针别名，编译优化的问题。

提取出内存对象之后，我们就要关注于对于其的访问。这一步就是对于MOAS的构建，通过分析上下文和追踪根指针来解决，通过跟踪根指针的数据流动来识别别名指针(比如说看他赋值到了哪个位置之类的)，然后追踪跟根指针有关的计算指令，对于数组等数据结构，观察其操作的内存单元是否基于某个根指针连续来判断是否将其划分为一组。

在上一步，MOAS并没有构建完成，还缺乏op及optype，因此，还需要对指令进行分析，以达到构建的目的，在构建完成后，会将两个MOAS对其以便于分析，作者采用了Smith-Waterman算法，寻找两个MOAS之间的相似区域。MOAS对齐中的一个挑战是内存对象被表示为根指针，对于相同的内存对象，根指针可能不同。因此，作者首先比较两个内存对象的相似性，再去比较其访问的相似性。

3.后记

我好像看不懂我写了个啥

徐州战役好像在官渡之前

学车真累