前言

在取證分析中，對(duì)內(nèi)存的分析通常是還原事件的重要步驟。以前對(duì)內(nèi)存工作的分析主要集中于那些駐留在內(nèi)核空間中的信息，如進(jìn)程列表、網(wǎng)絡(luò)連接等，特別是在Microsoft Windows操作系統(tǒng)上，但是這項(xiàng)工作主要關(guān)注的是Linux用戶空間進(jìn)程，因?yàn)樗鼈兛赡苓€包含有價(jià)值的調(diào)查信息。由于許多進(jìn)程數(shù)據(jù)位于堆中，所以這項(xiàng)工作首先集中在對(duì)Glibc堆實(shí)現(xiàn)的分析，以及如何將堆相關(guān)信息存儲(chǔ)在使用此實(shí)現(xiàn)的Linux進(jìn)程的虛擬內(nèi)存中。

到目前為止，從內(nèi)存取證的角度來(lái)看，堆通常被認(rèn)為是一個(gè)大的內(nèi)聚內(nèi)存區(qū)域，這使得在內(nèi)部識(shí)別相關(guān)信息變得相當(dāng)困難。我們?yōu)榛诜治鼋Y(jié)果的內(nèi)存分析框架Rekall引入了Python類，并允許訪問(wèn)堆中包含的所有塊及其元信息。

此外，基于這個(gè)類，我們已經(jīng)開(kāi)發(fā)了6個(gè)插件，支持研究人員分析用戶空間進(jìn)程，其中有4個(gè)插件提供了常用的分析功能，比如在塊中查找信息或引用，并將塊轉(zhuǎn)儲(chǔ)到單獨(dú)的文件中以進(jìn)行進(jìn)一步的調(diào)查。目前這些插件已被用于對(duì)用戶空間進(jìn)程中的堆內(nèi)數(shù)據(jù)結(jié)構(gòu)進(jìn)行逆向工程，你可以點(diǎn)此處，查看這些插件如何簡(jiǎn)化整個(gè)分析進(jìn)程。其余兩個(gè)插件則是這些用戶空間進(jìn)程分析的結(jié)果，而且還負(fù)責(zé)提取zsh shell的命令歷史記錄和密碼管理器KeePassX的密碼輸入信息。

由于內(nèi)存表示運(yùn)行中的系統(tǒng)的當(dāng)前狀態(tài)，它包含有關(guān)瀏覽器歷史記錄、輸入命令、運(yùn)行中的網(wǎng)絡(luò)連接、加載的驅(qū)動(dòng)程序以及活動(dòng)進(jìn)程的信息，因此我們才可以對(duì)以前的活動(dòng)進(jìn)行詳細(xì)的分析。雖然這些信息大部分位于內(nèi)核空間，可以使用Rekall和Volatility等各種現(xiàn)有解決框架進(jìn)行取證，但也有很多信息位于用戶空間，例如，用戶空間進(jìn)程的堆通常是各種數(shù)據(jù)的豐富來(lái)源，而根據(jù)具體應(yīng)用程序的不同，它可能包含憑證、IP地址、DNS名稱或命令歷史。但是，在Linux環(huán)境中，這些信息還不是容易提取的。

為了有效和可靠的識(shí)別和提取這些信息，研究人員需要查看與該進(jìn)程相同或至少類似的堆的視圖，以此來(lái)了解數(shù)據(jù)所在的位置，比如什么樣的數(shù)據(jù)類型會(huì)存儲(chǔ)在什么位置、哪些數(shù)據(jù)占用多少內(nèi)存量。否則，取證人員對(duì)數(shù)據(jù)結(jié)構(gòu)不理解，只能摸著石頭過(guò)河，因?yàn)樗行畔⒍嘉挥诙褍?nèi)，只能將堆作為一個(gè)大內(nèi)存區(qū)域來(lái)處理，這樣效率就太低了。

為什么解析用戶空間進(jìn)程堆

在Linux進(jìn)程的上下文中，以前對(duì)用戶空間分析的重點(diǎn)僅限于在整個(gè)進(jìn)程內(nèi)存或整個(gè)堆或堆棧中搜索特定模式。例如，為了重建Linux bash shell的命令歷史記錄，Rekall的bash 7插件在堆中搜索一個(gè)主題標(biāo)簽，后跟一個(gè)字符串格式的Unix時(shí)間戳(例如#1471572423)。但是，如果感興趣的信息沒(méi)有以易于檢測(cè)的方式進(jìn)行標(biāo)記，則簡(jiǎn)單的模式匹配將失敗。

當(dāng)研究者在內(nèi)存中標(biāo)識(shí)某個(gè)字符串并試圖標(biāo)識(shí)對(duì)該字符串的引用時(shí)，即使存在間接引用，這種模式匹配搜索也可能失敗。如果字符串是結(jié)構(gòu)或?qū)ο蟮囊徊糠?，并且不在開(kāi)頭，而感興趣的指針直接引用結(jié)構(gòu)而不是字符串，則可能出現(xiàn)這種情況。為了能夠找到這些引用，你就必須知道該結(jié)構(gòu)的開(kāi)頭，這就需要了解其字段的大小以及字符串在結(jié)構(gòu)中的位置。但是，這些細(xì)節(jié)通常在"黑箱分析"中不可用。

在本文中，我們實(shí)現(xiàn)解析用戶空間進(jìn)程堆的步驟分為5步：

1.通過(guò)分析Glibc堆的實(shí)現(xiàn)，總結(jié)一些可以讓調(diào)查人員能夠執(zhí)行手動(dòng)堆分析的信息，其中重要的信息是關(guān)于堆結(jié)構(gòu)的排列方式以及它們通常位于內(nèi)存中的位置;

2.證明一些塊可能隱藏在內(nèi)存中的某個(gè)位置，為此我們提出了一種檢索它們的算法;

3.這些算法已被用于開(kāi)發(fā)一個(gè)名為HeapAnalysis的Python類，它可用于實(shí)現(xiàn)特定的堆分析插件?；谶@個(gè)類，我們開(kāi)發(fā)了支持取證人員分析堆及其塊的插件;

4.我們會(huì)解釋如何通過(guò)應(yīng)用這些插件收集相關(guān)信息來(lái)分析用戶空間進(jìn)程的數(shù)據(jù)，類似于我們對(duì)Windows用戶空間進(jìn)程的分析;

5.對(duì)結(jié)果的進(jìn)一步分析是兩個(gè)插件，***個(gè)插件從zsh shell(版本5.2)進(jìn)程的堆中收集所有已執(zhí)行的命令，第二個(gè)插件從堆中提取所有可檢索密碼條目的標(biāo)題、用戶名、URL和注釋字段的密碼管理器KeePassX(版本0.4.3)。

HeapAnalysis類和所有提到的插件都支持×86和×64架構(gòu)。

除了本文之外，我們還發(fā)布了一份技術(shù)報(bào)告，其中包含更多技術(shù)細(xì)節(jié)和代碼列表。

本文的文章目錄結(jié)構(gòu)：

1.Glibc分析章節(jié)詳細(xì)介紹了使用Glibc堆實(shí)現(xiàn)的用戶空間進(jìn)程的堆;

2.在Plugin實(shí)現(xiàn)章節(jié)中，我們對(duì)開(kāi)發(fā)的堆分析插件進(jìn)行了概述;

3.插件的評(píng)估章節(jié);

4.實(shí)踐應(yīng)用章節(jié)提供了詳細(xì)的應(yīng)用分析;

5.總結(jié)章節(jié);

對(duì)用戶空間進(jìn)程堆進(jìn)行解析的研究歷史

到目前為止，對(duì)用戶空間應(yīng)用的分析還沒(méi)有得到足夠的重視，這正是我們此次研究的動(dòng)機(jī)，另外關(guān)于該主題的文獻(xiàn)目前還非常少，Linux內(nèi)存取證arena的現(xiàn)有文獻(xiàn)主要涉及內(nèi)核主題，如Urrea, 2006, Case et al., 2010 和 Ligh et al. (2014). 。

少數(shù)例外是Leppert(2012) 和Macht(2013)的研究，他們都專注于基于Linux的移動(dòng)設(shè)備的Android操作系統(tǒng)，并分析應(yīng)用程序和它們的堆數(shù)據(jù)。但是，他們的分析主要集中在堆中包含的序列化Java對(duì)象上，而不是堆對(duì)象的管理方式上。除此之外，還有對(duì)插件cmdscan 和bash 的研究，它們分別從Windows的cmd和Linux的bash shell中提取命令歷史記錄。然而，這些插件的使用都是基于以下的事實(shí)：在這些情況下，只需將堆視為一個(gè)大內(nèi)存區(qū)域就可以識(shí)別信息了，另一項(xiàng)相關(guān)工作是對(duì)記事本堆的分析。據(jù)我們所知，這是唯一使用任何堆細(xì)節(jié)的示例，而且與大多數(shù)先前的工作一樣，它也與Windows相關(guān)。

如果不考慮取證，僅對(duì)堆進(jìn)行的基礎(chǔ)研究，特別是對(duì)Linux進(jìn)程堆及其管理方式的研究，僅有Ferguson(2007) 對(duì)Glibc的堆實(shí)現(xiàn)進(jìn)行了研究。然而，以前的研究更多的關(guān)注于如何利用堆，因此目前還沒(méi)有足夠的信息來(lái)讓我們?cè)趦?nèi)存取證場(chǎng)景中從堆中收集所有相關(guān)信息。

Cohen(2015)的研究是***個(gè)通過(guò)一組Windows操作系統(tǒng)分析工具來(lái)解決這一問(wèn)題的項(xiàng)目。雖然Windows的堆實(shí)現(xiàn)與來(lái)自Glibc的堆實(shí)現(xiàn)之間存在一些相似之處，例如，在兩種情況下，分配的塊前面都有一個(gè)至少包含塊大小的結(jié)構(gòu)，但它們?cè)诩?xì)節(jié)上有所不同。

Glibc分析

在本章節(jié)中，我們從內(nèi)存取證的角度介紹了我們對(duì)Glibc堆實(shí)現(xiàn)的最重要分析結(jié)果，更詳細(xì)的信息可以從我們的技術(shù)報(bào)告中獲得。

不同的堆實(shí)現(xiàn)

我們的堆實(shí)現(xiàn)對(duì)象是Glibc 2.23版，它基于Wolfram Gloger的ptmalloc2 ，不過(guò)除此之外還有其他各種堆實(shí)現(xiàn)，其中大多數(shù)都是在某個(gè)操作系統(tǒng)或應(yīng)用程序的上下文中使用的。應(yīng)用程序開(kāi)發(fā)人員還可以決定是實(shí)現(xiàn)自己的堆還是使用其他現(xiàn)有堆實(shí)現(xiàn)，例如Firefox等Mozilla產(chǎn)品。然而，這樣的進(jìn)程可能無(wú)法使用本文介紹的信息或工具進(jìn)行分析。

Glibc堆概述

本節(jié)會(huì)介紹Glibc堆實(shí)現(xiàn)中使用到的最重要的對(duì)象和結(jié)構(gòu)。圖1顯示了一個(gè)正在運(yùn)行的進(jìn)程的堆布局，重點(diǎn)關(guān)注一下各個(gè)元素之間的引用。從***層和最重要的層級(jí)開(kāi)始，塊包含實(shí)際的用戶或進(jìn)程數(shù)據(jù)。這些數(shù)據(jù)是通過(guò)malloc調(diào)用顯式分配的，或者通過(guò)類的實(shí)例化上下文中的新調(diào)用隱式分配的。這些塊位于特定的內(nèi)存區(qū)域，除了分配表示當(dāng)前正在使用的塊之外，還會(huì)分配一些正在使用但將來(lái)不再使用的釋放塊。當(dāng)一個(gè)塊被釋放時(shí)，塊本身或至少其數(shù)據(jù)在大多數(shù)場(chǎng)景中仍保持與之前相同的位置，并且其數(shù)據(jù)(除了稍后要解釋的一些修改之外)也不會(huì)被刪除或覆蓋。

Glibc堆概述

***層級(jí)是arena，Ptmalloc2通過(guò)幾種數(shù)據(jù)結(jié)構(gòu)來(lái)進(jìn)行管理，主要有arena,heap,chunk三種層級(jí)。

Arena

arena對(duì)于32位系統(tǒng)，數(shù)量最多為核心數(shù)量2倍，64位則最多為核心數(shù)量8倍，可以用來(lái)保證多線程的堆空間分配的高效性。主要存儲(chǔ)了較高層次的一些信息。有一個(gè)main_arena，是由主線程創(chuàng)建的，thread_arena則為各線程創(chuàng)建的，當(dāng)arena滿了之后就不再創(chuàng)建而是與其他arena共享一個(gè)arena，方法為依次給各個(gè)arena上鎖(查看是否有其他線程正在使用該arena)，如果上鎖成功(沒(méi)有其他線程正在使用)，則使用該arena，之后一直使用這個(gè)arena，如果無(wú)法使用則阻塞等待。簡(jiǎn)而言之，arena是由malloc_state結(jié)構(gòu)描述的，從本質(zhì)上講，它是屬于一個(gè)或多個(gè)線程的堆空間，而每個(gè)arena都有自己的內(nèi)存區(qū)域，其中包含來(lái)自相關(guān)線程的已分配和釋放的塊。包含在Glibc庫(kù)中的arena被稱為main_arena，因?yàn)樗?**個(gè)或主要線程使用。雖然arena沒(méi)有直接鏈接到每個(gè)內(nèi)存區(qū)域或分配的塊(參見(jiàn)圖1)，但還有其他連接，如指向釋放塊的指針，下一個(gè)arena和頂部塊。這個(gè)頂部塊表示給定arena的剩余可用空間，用于創(chuàng)建新的塊并位于arena的末端。

heap_info

arena下面的一層是heap_info結(jié)構(gòu)，heap的等級(jí)就比arena要低一些了，一個(gè)arena可以有多個(gè)heap，也是存儲(chǔ)了堆相關(guān)的信息。盡管它們的名稱類似，但它們并不描述進(jìn)程的整個(gè)堆或與線程關(guān)聯(lián)的堆，而只描述它們所屬的映射內(nèi)存區(qū)域(由vm_area_struct結(jié)構(gòu)描述)的那部分。更具體地說(shuō)，每個(gè)映射到arena(main_arena除外)的內(nèi)存區(qū)域至少在內(nèi)存區(qū)域的開(kāi)頭都包含heap_info結(jié)構(gòu)的一個(gè)實(shí)例，它保存了該內(nèi)存區(qū)域中當(dāng)前堆部分的大小。

除了大小之外，每個(gè)heap_info結(jié)構(gòu)都包含一個(gè)指向相關(guān)arena(malloc_state結(jié)構(gòu))的指針和一個(gè)指向同一arena內(nèi)的前一個(gè)heap_info結(jié)構(gòu)的指針(請(qǐng)參見(jiàn)圖3)。這樣，所有這些都鏈接在一起。arena指針存儲(chǔ)在于ar_ptr構(gòu)建以及對(duì)prev構(gòu)建中的前一個(gè)heap_info的引用中。與arena相比，heap_info結(jié)構(gòu)不是循環(huán)鏈接，因?yàn)?**個(gè)heap_info的prev字段是null。

不包括arena和heap_info區(qū)域的是mmapping塊，如圖1所示，沒(méi)有從MMAPPED塊到任何其他結(jié)構(gòu)或從堆結(jié)構(gòu)到它們的鏈接。這些塊通常是在分配請(qǐng)求超過(guò)給定閾值(通常為128*1024字節(jié))時(shí)創(chuàng)建的，在這種情況下，塊不包括在main heap或?qū)儆诹硪粋€(gè)arena的任何內(nèi)存區(qū)域中，但是要求操作系統(tǒng)僅為該塊(通過(guò)mmap API調(diào)用)提供專用內(nèi)存區(qū)域，以在此區(qū)域中放置塊。當(dāng)mmap API調(diào)用以頁(yè)面的形式返回內(nèi)存空間時(shí)， MMAPPED塊的最小大小為一個(gè)頁(yè)面(至少為4096字節(jié)或其倍數(shù))，并且可以被一個(gè)頁(yè)面大小整除。釋放MMAPPED塊時(shí)，它正在分配的整個(gè)內(nèi)存空間將從進(jìn)程空間中刪除并返回給操作系統(tǒng)。

Chunk(塊)

chunk為分配給用戶的內(nèi)存的一個(gè)單位，每當(dāng)我們分配一段內(nèi)存的時(shí)候其實(shí)就是分配得到了一個(gè)chunk，我們就可以在chunk當(dāng)中進(jìn)行一定的操作了。不過(guò)為了進(jìn)行動(dòng)態(tài)分配，chunk本身也有一些數(shù)據(jù)(元數(shù)據(jù))，是用來(lái)表示其分配等等的數(shù)據(jù)。

本文我們對(duì)解析用戶空間進(jìn)程堆的動(dòng)機(jī)和歷史，做了一個(gè)簡(jiǎn)要的概述。另外，我們Glibc堆的3層結(jié)構(gòu)也做了一些概述，這些結(jié)構(gòu)是解析用戶空間進(jìn)程堆的關(guān)鍵。