庖丁解牛之運行時壓縮器UPack工作原理及實例分析(上)

1基礎知識介紹

運行時壓縮器是軟件逆向工程中常見課題；了解運行時壓縮，需要掌握基本的PE文件格式，操作系統的基本知識等。

理解本文內容最好有PE文件基礎知識，對PE文件加載器有一定了解。本文會穿插介紹PE文件基礎知識但重點不在于此。

下圖是PE文件結構部分及在磁盤和加載到內存中的對比，其文件的總體結構未發生變化，但是文件在磁盤和內存中的相對偏移發生了變化。

1.1運行時壓縮器定義

運行時壓縮器是針對可執行文件而言，可執行文件內部含有解壓縮代碼，文件在運行瞬間于內存中解壓縮后執行。

            普通壓縮與運行時壓縮比較

可執行文件的壓縮器稱為“運行時壓縮器”，它是PE文件的專用壓縮器。

1.2運行時壓縮器用途及種類

PE壓縮器使用的目的主要集中于兩個方面：

1. 縮減PE文件的大小

2. 隱藏PE文件內部代碼與資源

PE壓縮器種類：

1. 單純用于壓縮普通PE文件，比如UPX,ASPack等

2. 對源文件（PE文件）進行較大變形、嚴重破壞PE頭、意圖不純的壓縮器，例如用于惡意程序（virtus,Trojan,worm等），比如UPack,PESpin等。

2 初探UPack壓縮文件

UPack的制作者對PE頭有深刻認識，UPack以對PE頭的獨特變形技法而聞名。UPack在剛出現時，許多PE實用程序無法正常運行。導致許多惡意代碼制作者使用UPack壓縮惡意代碼發布。

         本文以UPack 0.39版本壓縮的notepad.exe為例，詳細介紹UPack對PE文件的壓縮過程，尤其對PE頭部及代碼重置的關鍵技術做了詳細介紹。

         UPack對notepad.exe做運行時壓縮，如下圖所示

  由上圖可知notepad.exe程序有原來的66560個字節變成了44908個字節，文件大小有了變化，同時由圖中輸出信息可知文件的輸入表，資源信息等也發生了變化。

2.1壓縮文件檢測

  被UPack壓縮后的文件，文件頭部和文件內容發生了變化，對導致許多安全軟件認為壓縮文件有可能包含病毒特征，會直接報毒，下圖是利用QQ傳輸原始notepad文件和壓縮notepad文件時，QQ自檢會認為被UPack壓縮后的文件包含病毒特征。

下圖是利用IE瀏覽器下載壓縮文件和正常文件，IE插件給出的提示信息。 

下圖是利用多掃描引擎對壓縮文件進行檢測，國內很多安全廠商的病毒引擎都認為被UPack壓縮的文件含有病毒特征。

2.2實用工具識別

由于UPack對PE文件頭部做了特殊處理，這樣就會使一些PE實用程序無法正常運行，PEView使用工具加載壓縮notepad文件和原始notepad文件時，對文件識別也表現不同；由于UPack對notepad頭部做了變形，導致PEView在對壓縮notepad解析時找不到正常的文件結構而加載失敗。

3深度剖析UPack壓縮原理

經過UPack壓縮后的文件，其頭部和節部分的內容都發生了變化，貌似已經不再符合PE文件格式要求。

3.1二進制文件對比

典型的PE文件頭，其中數據按照IMAGE_DOS_HEADER、DOS Stub、IMAGE_NT_HEADERS、IMAGE_SECTION_HEADER順序排列。

單獨二進制文件對比發現，文件的大小和文件內容都發生了變化，壓縮后的文件表面上看已經不在符合PE文件規范。如下圖所示，更直觀的對比，文件結構的很多字段都發生了變化，對于一般的實用工具或是調試工具，很難識別出壓縮后文件的文件結構。

3.2重災區---壓縮文件頭

UPack以頭部壓縮著稱，將PE文件頭部變化的面目全非，宛如去韓國整了一次容。

有PE結構可知PE頭部包括了IMAGE_DOS_HEADER、DOS Stub、IMAGE_NT_HEADERS、IMAGE_SECTION_HEADER五部分組成，其中IMAGE_NT_HEADERS有magic、IMAGE_FILE_HEADER、IMAGE_OPTIONAL_HEADER三部分組成。

3.2.1重災區之DOS頭部重疊

重疊文件頭將MZ文件頭（IMAGE_DOS_HEADER）與PE文件頭（IMAGE_NT_HEADERS）巧妙重疊一起，節約文件頭空間。

由PE文件頭部結構可知（需要知道PE文件頭部基礎結構）,IMAGE_DOS_HEADER結構中兩個重要字段e_magic和e_lfanew，第一個字段一般為“MZ”是PE文件最開始的標志，第二個字段標志的是除去IMAGE_DOS_HEADER頭部和DOS Stub部分后IMAGE_FILE_HEADER結構的開始位置。

一般情況下e_lfanew =IMAGE_DOS_HEADER(40)+DOS Stub(vc下A0)=0XE0，也就是說一般e_lfanew字段的值為0XE0，對比UPack壓縮后的文件e_lfanew字段的值變為0X10，如下圖

下圖是一個示意圖文件的DOS頭部壓縮前后發生的變化。文件壓縮后，DOS Stub部分已經消失，被IMAGE_FILE_HEADER結構占據。

3.2.2重災區之IMAGE_FILE_HEADER變形

在IMAGE_FILE_HEADER有一重要字段就是SizeOfOptionHeader；SizeOfOptionHeader表示IMAGE_OPTIONAL_HEADER的大小；修改該值，改變IMAGE_OPTIONAL_HEADER頭部的大小，可插入解碼代碼等內容。

在一般的PE文件中，IMAGE_OPTIONAL_HEADER結構的大小是固定，所以SizeOfOptionHeader字段的值也是固定的，為0XE0，如下圖notepad_origin.exe所示

在經過UPack壓縮后，文件頭部的SizeOfOptionHeader變成了0x148,如下圖所示  

比正常值0XE0要大的多。SizeOfOptionHeader的另一層含義是確定節區頭（IMAGE_SECTION_HEADER）的起始偏移，將該字段的值由0XE0擴大到0x148,無疑增大了IMAGE_OPTIONAL_HEADER結構的大小。

  UPack的基本特征就是把PE文件頭變形，像非洲人的頭發一樣擰麻花，向文件頭適當插入解碼需要的的代碼。增大SizeOfOptionHeader的值后，就在IMAGE_OPTIONAL_HEADER與IMAGE_SECTION_HEADER之間添加了額外空間。向這個額外區域添加解碼代碼，是一種超越文件頭常規理解的巧妙方法。

  二進制查看該額外區域的數據，該區域的起始位置在IMAGE_OPTIONAL_HEADER的結束位置0XD7(為什么是D7位置，后面會介紹)，該區域的結束位置是0x170。

利用調試器查看該區域的部分反匯編代碼如下圖

下圖是IMAGE_FILE_HEADER壓縮前后的格式對比，壓縮后的文件頭部增大。

3.2.3重災區之IMAGE_OPTIONAL_HEADER變形

   對比壓縮前后的文件可知，IMAGE_OPTIONAL_HEADER結構中的NumberOfRvaAndSizes字段的值也變化，該字段表示的是數據目錄的大小，改變該值也是為了向文件頭插入自身代碼。正常文件該字段的大小是0x10，也就是IMAGE_OPTIONAL_HEADER結構中最后一部分有有0x10個IMAGE_DATA_DIRECTORY數組，但是在UPack壓縮有該值變成了0x0A,也就是說少了6個IMAGE_DATA_DIRECTORY結構數組，每個數組占8個字節。從下圖可以看出IMAGE_OPTIONAL_HEADER結構的后半部分IMAGE_DATA_DIRECTORY結構剛好到0Xd7的位置，也即是說從0XD8一直到0x170之間都是作為空閑區域插入代碼。

    下圖是IMAGE_FILE_HEADER壓縮前后的格式對比，壓縮后的DATA_DIRECTORY結構變小。

3.2.4重災區之IMAGE_SECTION_HEADER重疊變形

前面介紹了文件圖的IMAGE_DOS_HEADER、DOS Stub、IMAGE_FILE_HEADER、IMAGE_OPTIONAL_HEADER、DATA_DIRECTORY的變形，接下來就是IMAGE_SECTION_HEADER的變形。

 IMAGE_SECTION_HEADER是文件頭部的最后的一部分。節區的變化包括了節區區域的增加，節區區域的減少，節區數量的增加等。UPack對PE文件的節區也做了變化，下圖是原始notepad文件與壓縮后的notepad文件節區對比

對比兩幅圖，變化前后節區的名稱，虛擬大小，偏移，文件大小，文件起始偏移等都發生了變化。

  查看壓縮后的notepad文件的節區，發現第一個節區與第三節區的文件起始偏移與在文件中的大小完全一致。但是節區內存的起始RVA（VirtualOffset）項與內存大小（VirtualSize）值確不同。根據PE規范，這樣做不會有什么問題（更準確的說，PE規范并未明確指出這樣做不行）。UPck會對PE文件頭、第一節區、第三節區進行重疊。

  根據節區頭中定義的值，PE裝載器會將文件偏移0x10-0x200的區域分別映射到內存中的第一、第三節區。也就是說用相同的文件分別創建出不同位置的、大小不同的內存映像。

  觀察壓縮的節區，文件的頭部區域大小為200字節。相反，第二個節區大小（AD6C）非常大，原文件就壓縮與此。另外需要注意的部分是內存中的第一個節區區域，它的內存尺寸為13000，與原文件的sizeofImage相同。

文件節區壓縮示意圖

也就是說，壓縮在第二個節區的文件映像很可能會解壓縮到第一個節區。文件開始裝入內存后的示意圖如下圖。

http://blog.nsfocus.net/upack-works-case-analysis1/