Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

DSCRETE: Automatic Rendering of Forensic Information From Memory Images via Application Logic Reuse

论文下载

本文是一篇内存取证方面的文章,来自普渡大学dongyan xu老师的团队,发表于2014年的USENIX Security上,是当年两篇best student paper之一。

一作saltaformaggio已经连续几年在四大上发表了和内存取证相关的文章,近两年的文章和Android有关。

  • 本文描述了一种通过自动化重用程序代码,从内存镜像中恢复出属于该程序的可以被人理解的数据(图片、pdf、文档文件等)的技术-DESCRETE。
  • 和磁盘取证不同,内存取证最大的难点在于内存中的数据是碎片化的,同时并没有普适的连续的结构化信息(类比磁盘取证中各种文件的格式信息)可以利用。但是,在内存中存在着大量的有利用价值的数据,这些数据一般以无法直接被人理解的数据结构的形式保存于内存中,而不同的应用程序所定义的数据结构也是不尽相同,这就给自动化取证带来的极大的挑战。本文的主要目的就是解决如何对这些content of data structure fileds进行取证的问题。
  • 作者认为,对于这些应用程序内部维护的数据结构,一般在应用程序中都已经带有针对这些数据的“解释器”,这样的解释器负责将这些碎片化、抽象的数据结构组合成人能够直接理解的数据呈现形式(比如,一个图像处理软件在读入一个图片文件时,会将图片文件转化成该软件的一些内部的数据结构,然后通过系统的GUIAPI将这些内部数据结构绘制成能够显示在屏幕上的“图片”)。通过利用这些应用程序自带的“解释器”,就能够完成对内存数据的自动化“解释”,从而取证得到人可以理解的信息。

下图是DESCRETE的一次标准的取证流程:

Fig

  • 简单的说,DESCRETE的目的是寻找到一个测试函数P,P可以用来对内存镜像中的数据进行测试,判断输入的数据是否能够通过P来转换成人可以直接理解的信息。

首先,DESCRETE需要获得取证对象的创造程序的binary,DESCRETE会利用这个binary进行一些学习,从而制造出能够在内存镜像中扫描该应用程序内部数据结构的scanner。学习的第一步是运行该应用程序,确保在内存中有需要取证的数据结构的出现,以及完成一次对这些数据结构的解释输出(例如对于一个图像处理软件,需要先读入一些图片文件,然后将这些图片显示在屏幕上)。在这个过程中,DESCRETE会监控该应用程序对外部库接口以及系统API的调用,尤其是那些会将数据输出到磁盘或是其他设备上的接口。DESCRETE同时还会记录这些接口调用发生时栈和堆上的数据,供后续分析使用。在完成执行之后,descrete的使用者可以通过观察log下来的系统接口的输出,标记那些自己感兴趣的数据。之后使用传统的slicing技术,将所有和该数据生成过程有关的指令全部分离出来。

通过第一步,通过分析插装后的log记录,我们获得了很多个测试函数P的候选,下一步是确定测试函数P的截止点(closure point)。根据作者的定义,一个截止点是符合以下两个要求的一条指令:

  1. 截止点需要直接的对待取证数据结构进行操作。
  2. 在截止点之后的所有指令,对待取证数据结构的操作都基于该指令完成。符合以上两点的截止点能够确保我们在截止点出对待取证数据结构进行修改,就能够直接影响到最终输出的信息。这一步的筛选最终会产出多个截止点,根据作者的实验,截止点的个数一般在30以下,最多不超过102.

由于DESCRETE是一个全自动的取证工具,在过程中不应该有人的介入,所以接下来需要对第二步筛选出来的截止点进行自动化的测试,以此来选出真正能够使用的截止点。在这一步中,DESCRETE会使用不同于第一步的数据输入重新执行这个应用程序,当执行到一个候选截止点时,程序会fork出一个子进程,子进程初始化时,截止点所使用的数据指针会被替换,指针会被指向第一步提取出来的数据。然后子进程继续运行,当且仅当子进程顺利指令完毕并且输出和第一步相同的信息时,表示这个子进程对应的截止点是可用的,同时也意味着一个可用的P被发现了。

最后一步就是使用我们发现P去取证内存镜像,取证的过程和第三步类似。不同的是,在替换截止点数据时,使用的是待取证的内存镜像,对于镜像中的每一个字节,都会有一个子线程去验证。由于数据的特殊性,能够顺利执行完毕的子线程往往意味着成功完成了一次取证。当数据输出过程过于简单时,也会发生有很多子线程均完成执行的情况,这种时候需要人工介入对结果进行筛选。

作者使用了10款不同的真实的应用程序对DESCRETE进行了测试:

Fig

上面的表格显示了选取的10款应用程序的名字、调用的接口、取证人员关心的数据类型、调用接口时的数据大小、测试函数P候选占整个程序代码的比例、发现的截止点候选个数、能够顺利执行完毕的截止点个数、人工验证后正确的截止点个数。

Fig

上面的表格显示了在试验中,应用程序的名字、待取证的数据结构名称、数据大小、该数据结构的实例个数、DESCRETE输出结果的个数、True Positive、False Positive、False Negative。