Digital Investigation 16 (2016) S11eS24
Contents lists available at ScienceDirect
Digital Investigation
journal homepage: www.elsevier .com/locate/d i in
DFRWS 2016 Europe d Proceedings of the Third Annual DFRWS Europe
Arkadiusz Socała a, *, Michael Cohen b
a University of Warsaw, Krakowskie Przedmiescie 26/28, Warsaw, Poland b Google Inc., Brandschenkestrasse 110, Zurich, Switzerland
Automatic profile generation for live Linux Memory analysis
Abstract
Live Memory analysis on the Linux platform has traditionally been difficult to perform. Memory analysis requires precise knowledge of struct layout information in memory, usually obtained through debugging symbols generated at compile time. The Linux kernel is however, highly configurable, implying that debugging information is rarely applicable to systems other than the ones that generated it. For incident response applications, obtaining the relevant debugging information is currently a slow and manual process, limiting its usefulness in rapid triaging. We have developed a tool dubbed, the Layout Expert which is able to calculate memory layout of critical kernel structures at runtime on the target system without requiring extra tools, such as the compiler tool-chain to be pre-installed. Our approach specifically addresses the need to adapt the generated profile to customized Linux kernels e an important first step towards a general version agnostic system. Our system is completely self sufficient and allows a live analysis tool to operate automatically on the target system. The layout expert operates in two phases: First it pre-parses the kernel source code into a preprocessor AST (Pre-AST) which is trimmed and stored as a data file in the analysis tool#39;s distribution. When running on the target system, the running system configuration is used to resolve the Pre-AST into a C-AST, and combined with a pre-calculated layout model. The result is a running system specific profile with precise struct layout information. We evaluate the effectiveness of the Layout Expert in producing profiles for analysis of two very differently configured kernels. The produced profiles can be used to analyze the live memory through the /proc/kcore device without resorting to local or remote compilers. We finally consider future applications of this technique, such as memory acquisition.
copy; 2016 The Authors. Published by Elsevier Ltd on behalf of DFRWS. This is an open access article under the CCBY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).
Keywords: Memory analysis；Incident response；Memory Forensics； Compilers；Reverse Engineering；Malware；Linux Forensics；Digital Forensic Triaging
Introduction
In recent times, Memory analysis has been used effectively in the wider context of digital forensics, and malware detection (Ligh et al., 2014). In essence, memory analysis strives to make sense of a computer#39;s memory image —— an exact copy of the physical memory used by a running system. As the size of physical memory increases, especially on large servers, memory analysis based triaging techniques are becoming more important (Moser and Cohen, 2013).
At first look, physical memory might appear as a large amorphous and unstructured collection of data. In fact, physical memory is used by the running software to store program state in a highly structured manner. The programmer employs logical constructs such as C structs to collect related data into logical units, representing abstract data types. The compiler than ensures that this struct is laid out in memory in a consistent way, and generates code to access various members of the struct according to this layout.
In order to successfully extract high level information from a memory image, one must extract and interpret the abstract struct objects that the program handles from the amorphous physical memory. In order to do this, one must have an accurate model of the physical layout of the structs and their individual member#39;s data types.
Earlier memory analysis solutions relied on hand constructed layoutmodels for each struct, obtained by trial and error (Schuster and Andreas, 2007). However, struct layouts change frequently between released versions (Cohen, 2015b), and the large number of structs of interest makes such maintenance difficult.
For open source operating systems, one might be tempted to examine the source code and from the source code, theorize the precise memory layout for each struct. However (as explained in detail in Section Layout model), such an analysis is not practical without intimate knowledge of the compiler#39;s layout model. In practice there are many edge cases which are difficult to predict: For example, the compiler may add padding to ensure alignment of various struct members under different conditions.
In order to support debugging tools, which must also extract meaningful information from the program#39;s memory, compilers typically emit the layout models for each struct used in a program into some kind of debugging stream, for example a PDB file, or DWARF streams (DWARF Debugging Information Format Committee, 2010).
The Volatility Memory analysis Framework (The Volatility Foundation, 2014) was the first open source memory analysis framework able to utilize information derived from debugging streams in order to analyze memory images from multiple versions of an operating system. In the Volatility framework, debugging information is converted into a profile specific to a particular version of the operating system. These profiles are embedded inside the tool and allow the user to specify which version of the operating system the image originated from.
On Microsoft Windows systems, debugging symbols are stored in external PDB files which may be downloaded from a central symbol server on d
剩余内容已隐藏，支付完成后下载完整资料
为实时Linux内存分析自动生成概要文件
摘要
Linux平台上的实时内存分析传统上很难执行。内存分析需要对内存中的结构布局信息有精确的了解，通常通过调试编译时生成的符号来获得。然而，Linux内核是高度可配置的，这意味着调试信息很少适用于生成它的系统之外的系统。对于事件响应应用程序，获取相关的调试信息目前是一个缓慢的手工过程，限制了它在快速分类中的作用。我们开发了一个名为Layout Expert的工具，它可以在运行时计算目标系统上关键内核结构的内存布局，而不需要额外的工具，比如预安装编译器工具链。我们的方法特别解决了将生成的概要文件调整为定制的Linux内核的需要，这是迈向通用版本无关系统的重要第一步。我们的系统是完全自给自足的，并允许实时分析工具自动操作的目标系统。布局专家分两个阶段进行操作:首先，它将内核源代码预解析为预处理器AST (pre- processor AST)，该预处理器AST将被裁剪并作为数据文件存储在分析工具的分发版中。在目标系统上运行时，使用运行系统配置将Pre-AST分解为C-AST，并结合预计算布局模型。结果是一个运行系统特定的概要文件与精确的结构布局信息。我们评估了布局专家在生成用于分析两个配置非常不同的内核的概要文件方面的有效性。生成的概要文件可以通过/proc/kcore设备分析活动内存，而不需要使用本地或远程编译器。最后，我们考虑了该技术的未来应用，如内存采集。
关键词：内存分析；事件响应；内存取证；编译器；逆向工程；恶意软件；Linux取证；数字取证分类
介绍
近年来，内存分析在数字取证和恶意软件检测的广泛背景下得到了有效的应用(Ligh et al.， 2014)。从本质上讲，内存分析就是要弄清楚计算机的内存映像，即运行中的系统所使用的物理内存的精确副本。随着物理内存的大小增加，特别是在大型服务器上，基于分类的内存分析技术变得越来越重要(Moser和Cohen, 2013)。
乍一看，物理内存可能表现为大量非固定和非结构化的数据集合。实际上，运行中的软件使用物理内存以一种高度结构化的方式存储程序状态。程序员使用逻辑结构(如C结构)将相关数据收集到逻辑单元中，表示抽象数据类型。编译器然后确保以一致的方式在内存中布局这个结构，并根据这个布局生成代码来访问结构的各个成员。
为了成功地从内存映像中提取高级信息，必须从非晶物理内存中提取和解释程序处理的抽象结构对象。要做到这一点，必须对结构的物理布局及其各自成员的数据类型有一个准确的模型。
早期的记忆分析解决方案依赖于为每个结构手工构建的布置图模型，通过反复试验获得(Schuster and Andreas, 2007)。然而，结构布局在发布的版本之间频繁变化(Cohen, 2015b)，大量感兴趣的结构使得这种维护非常困难。
对于开放源码操作系统，您可能会忍不住检查源代码，并从源代码中推断每个结构的精确内存布局。但是(如章节布局模型中详细解释的那样)，如果不熟悉编译器的布局模型，这样的分析是不实用的。在实践中，有许多难以预测的边缘情况:例如，编译器可能会添加内边距，以确保在不同条件下不同结构成员的对齐。
为了支持调试工具，它还必须从程序的内存中提取有意义的信息，编译器通常将程序中使用的每个结构的布局模型发送到某种调试流中，例如PDB文件或DWARF流(DWARF调试信息格式委员会，2010)。
易变率内存分析框架(易变率基金会，2014)是第一个开源内存分析框架，它能够利用调试流获得的信息来分析一个操作系统的多个版本的内存图像。在volatile框架中，调试信息被转换为特定于操作系统特定版本的概要文件。这些概要文件嵌入到工具中，允许用户指定映像来自哪个操作系统版本。
在Microsoft Windows系统上，调试符号存储在外部PDB文件中，可以根据需要从中央符号服务器下载这些文件(Okolica和Peterson, 2010)。Rekall内存分析框架(Rekall Team, 2014)能够直接从Microsoft调试服务器下载未知内核的调试符号。当在活动模式下运行时，这个特性非常有用，因为Rekall可以将PDB文件直接解析为用于分析运行系统的概要文件。
不幸的是，Linux系统上的内存分析带来了一些实际的挑战。与windows不同，Linux内核通常不是用调试信息编译的(比如DWARF流)，调试信息通常也不是根据调试服务器的需求提供的。为了获得调试信息，必须重新堆积内核，或者内核的某些部分(例如内核模块)，特别是启用调试标志。在基于Debian的系统上，这还需要安装一个linux头文件包，其中包含内核头文件以及内核编译步骤(例如模块)中生成的重要文件。内核模块构建之前(Hertzog和Mas, 2014)。实际上，自定义编译内核的内核头包通常不可用，甚至从未在第一个包中创建过的地方。充其量，事件响应者必须争着为目标系统上正在运行的内核识别正确的内核头包，并希望它匹配。
另一个复杂性是Linux内核的高可配置性。在内核构建过程中，用户可以通过内核的配置系统指定大量的配置选项。这些选项通过定义大量C预处理宏来影响内核构建过程。
Linux内核源代码大量使用预处理宏来定制内核本身的操作，特别是只有当用户启用某些功能时，内核才会将某些字段包含到关键结构中。例如，考虑图1中的代码，它显示了task_struct 的定义，这是一个维护有关运行进程信息的关键结构。
可以看出，只有在设置了特定的配置参数时才会包含一些struct成员。例如，只有在编译内核时支持任务组调度 (Linux内核的一个可选特性)，才会存在sched_task_group指针。类似地，CONFIG_SMP控制包含多个多处理系统使用的字段。
当编译器生成抽象的struct布局模型时，它必须为内存中的每个struct成员分配一个位置，这个位置足够容纳成员的大小、对齐要求以及围绕它的成员的对齐。显然如果某些字段不包含在结构体定义(例如,如果他们实现的功能是不选择的用户),编译器不会保留任何空间,因此结构体成员出现在结构体的定义将位于不同位置在内存中。
内存分析工具在解析Linux内核内存时遇到的主要问题是，内核的配置控制生成的内核结构的布局模型，但是这种配置不是常量。因为Linux用户和分布是免费的重新配置和重新编译内核,每个特定的内核用于给定的内存映像可以有截然不同的配置,因此布局(这是与商业操作系统,比如Windows或OSX,只有少量的正式发布版本在野外发现)。
这个问题的一个解决方案是维护一个公共内核配置的大型存储库。Secondlook产品(Secondlook, 2015)为主要发行版(如Ubuntu、Redhat等)的每个版本维护一个大型概要文件库。尽管这个存储库很大(假设超过14000个概要文件)，但是如果用户重新编译了内核并更改了一些配置选项，那么在存储库中就找不到正确的概要文件。一个完整的存储库必须考虑到配置选项的每一个组合，因此会非常大。
一些记忆分析框架采用了一种不同的方法(Rekall团队，2014;挥发性基础(Volatility Foundation, 2014)要求用户在分析之前为每个目标内核专门构建一个概要文件。通常的过程是获取内核头文件包并使用目标内核的配置来编译启用调试符号测试内核模块。编译器将把所需的调试符号发送到测试内核模块中的DWARF流中。内存取证工具然后解析所需的DWARF信息，以构造一个合适的概要文件来分析特定的内核内存。
图1所示。一个来自Linux内核源代码的结构定义示例。注意，结构中的许多字段都是由内核配置参数决定的。
在事件响应和实时分析上下文中，编译内核模块可能并不总是可能的;服务器很少安装完整的编译器工具链，或所需的内核源代码或头文件。相反，在生产系统上安装开发工具并不总是可能的。如果概要文件不能在目标系统上本地构建，那么分析人员必须在类似的不同系统上安装相关的内核头文件(如果存在的话)，这样才能生成概要文件。然后分析人员必须手动将生成的概要文件复制回目标系统进行实时分析。
这种额外的工作使得实现一个全自动的内存分类系统变得困难(Moser和Cohen, 2013)。一个自动化的系统不能有手工的交互来构建每个被分析系统的概要文件。例如，GRR快速响应工具(Cohen et al.， 2011)能够对大量企业Windows和OSX系统进行复杂的内存分析。然而，对于Linux，它需要为可能遇到的每个内核预先计算概要文件。
理想情况下，可以完全使用运行系统本身的现成信息自动生成概要文件，而无需事先准备。
文献记录了为实现这一目标所做的一些努力(Lin et al.， 2011)。例如，RAMPARSER (Case et al.， 2010)使用动态逆向工程技术来重构结构布局的受限模型(包含关键结构字段的一小部分选定子集)。对于每个结构，通过反向工程导出的操作这些字段的内核函数来重构一组简化的重要字段。(Case et al.， 2010)记录了使用这种方法所遇到的一些挑战，例如，为每个函数生成的汇编代码可能有很大的差异，即使在相同的内核版本中也是如此。因此，必须对该工具进行广泛的测试，以允许该领域中遇到的汇编程序代码的所有可能变化。此外，必须手动检查每个struct成员，以便设计从某些内核函数中推断其偏移量的正确策略。这种对struct成员的手工处理限制了工具的可伸缩性，因为需要为每个struct成员构建详细的模型。
Cohen (2015b)通过开发反汇编器签名模板规范扩展了这一想法。模板允许简明地表示反汇编器匹配规则，同时允许通用规则变体，如汇编代码中使用的精确寄存器的差异。然而，当拆卸发生更剧烈的变化时，这个系统仍然会失败。
这两种方法的主要限制是，识别仅提取几个结构偏移量所需的组装模式所需的手工分析。随着现代内存分析技术扩展了它们对内核数据结构的覆盖范围，越来越多的struct成员变得相关起来，而在运行时手工设计派生这些结构的技术根本无法伸缩。
内核结构布局的可变性可以归因于两个正交维度。一种类型的可变性是由不同的内核版本和应用补丁引入的，而另一种类型的可变性是由用户使用不同的配置选项在特定的发布版本上重新编译内核引入的。本文专门讨论由于配置更改而引入的可变性。理想情况下，自动化解决方案应该能够处理这两种类型的可变性，但是处理重新编译的内核是迈向最终解决方案的重要一步。
问题陈述
我们的目标是改进事件响应中实时分析的特定用例。理想情况下，我们将运行我们的实时内存分析工具，从只读外部媒体(如DVD Rom或只读安装的USB驱动器)，它将有一切需要分类一个任意的Linux系统。这样的用例在Windows systems Cohen (2015a)中已经很常见了，我们的目标是使它与Linux系统一样自动化。
我们假设约束条件如下:
·对于用户来说，在活动系统本身上为正在运行的内核构建特定的定制概要文件是不现实的。特定的目标内核版本是已知的(例如，通过uname命令)。
·目标内核的配置是已知且准确的。这通常可以在/boot/分区中找到。例如/boot/config-3.13.0-61-generic对应于版本3.13.0-61-generic正在运行的内核。
·这个System.map文件是存在的和准确的(或/proc/ kallsyms是可用的)。
当前“本地编译概要文件”方法的主要困难在于，它要求整个编译器工具链在目标系统上可用，包括正确的内核头文件包。然而，在大多数情况下，生产系统的响应者无法在目标系统上安装额外的软件，特别是那些被怀疑受到攻击的系统。
一种可能的解决方案是从目标服务器中删除编译步骤，并在远程服务器上执行。目前，希望执行实时三老化的响应程序需要手动将所需的文件复制到远程系统(类似地配置到目标系统)，创建概要文件，然后在分析之前将概要文件复制回目标系统。这种方法不能扩展，特别是在需要自动远程实时分析时用于快速分类和响应(例如GRR快速响应工具(Various, 2015a, 2015b))。
考虑图2中描述的解决方案，其中包含内核源树的git检出。服务器可以提供接受配置文件的构建服务，然后构建所需的调试模块，最后将概要文件提供给内存分析工具。
这种安排本质上是通过模块编译方法手动创建概要文件的自动化版本:构建服务器使用了本地源存储库构建内核模块，使用提供的配置使用调试符号。然后从DWARF调试流中提取结构布局，并返回到完成概要文件的分类系统。这种系统的主要好处是编译器工具链不是安装在分析目标本身上，而是安装在服务器上，并且可以远程使用。
但是，这种设计仍然有一个主要的缺点，即必须使用概要服务器维护网络访问，在分析每个新的活动系统之前，概要服务器必须是可用的。从远程实时取证的角度来看，这种方法尤其不方便，因为它需要在构建服务器生成概要文件时暂停分析。此外，在构建内核模块之前，仍然需要在服务器上提供内核头包(Hertzog和Mas, 2014)。对于自定义编译内核，必须以某种方式找到相关的内核头包并将其传输到构建服务器。
布局专家
在实时分析工具本身中包含所有必需的信息将更加方便。这样，实时分析工具就可以独立运行，并且能够在没有外部依赖关系的情况下计算自己的概要文件。
图2所示。概要文件构建器服务的可能架构。内存分析系统向服务器发送配置文件和内核版本，服务器用调试符号构建一个测试模块，返回结构布局。
我们开发了一个工具，称为布局专家，它将概要文件生成服务带到另一个层次。布局专家不是使用完整的编译器工具链构建测试模块，而是试图通过本地模拟
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[435561]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
