樹形結(jié)構(gòu)到遞歸解析實(shí)戰(zhàn))
每個(gè)接觸過(guò)PE文件的人心里大概都有一道坎數(shù)據(jù)目錄、導(dǎo)入表、導(dǎo)出表這些還好說(shuō)到了資源表就有點(diǎn)繞了。我做逆向分析和去殼工作也算有些年頭了最開始卡住我的就是這個(gè)資源表。圖標(biāo)是它管的版本信息是它管的菜單對(duì)話框是它管的就連不少軟件藏著的自定義數(shù)據(jù)也經(jīng)常作為一個(gè)特殊類型資源掛靠在資源表里。所以無(wú)論是做漢化、改圖標(biāo)、提取素材還是做樣本分析過(guò)不了資源表這一關(guān)后面的活兒基本都干不下去。這篇文章我就把資源表的原理、結(jié)構(gòu)和實(shí)操解析完整地講一遍適合剛學(xué)完P(guān)E頭格式、正準(zhǔn)備啃資源表的新手也適合那些一直在用工具改資源卻從沒搞清楚它內(nèi)部長(zhǎng)什么樣的朋友。1. 資源表到底是什么一個(gè)藏在PE里的文件系統(tǒng)1.1 資源表解決了什么問(wèn)題一個(gè)Windows可執(zhí)行程序除了代碼和數(shù)據(jù)還帶著一大堆附屬品窗口左上角的圖標(biāo)、程序名底下的版本號(hào)、右鍵菜單里的文字、開屏彈出來(lái)的對(duì)話框、UAC需要的manifest清單。這些東西形式各異、長(zhǎng)度不一散落在文件里東一塊西一塊顯然不行所以PE格式專門設(shè)計(jì)了一張資源表把這些資源統(tǒng)一管起來(lái)。你可以把資源表想象成一個(gè)圖書館的目錄系統(tǒng)。圖書館要把書分類擺放必須有一套編號(hào)規(guī)則先按圖書分類文學(xué)、歷史、計(jì)算機(jī)再按書名或者作者最后可能還要細(xì)分到具體版本。資源表的組織方式幾乎一模一樣它用三級(jí)樹形結(jié)構(gòu)來(lái)定位任何一個(gè)資源第一級(jí)是資源類型第二級(jí)是資源名稱第三級(jí)是資源語(yǔ)言。你最終想拿到的圖標(biāo)、字符串、版本塊就掛在第三級(jí)目錄下面的葉子節(jié)點(diǎn)上。這個(gè)設(shè)計(jì)最巧妙的地方在于它把資源尋址和資源存儲(chǔ)分開了。資源目錄樹負(fù)責(zé)告訴解析器你要找的東西屬于什么類型、叫什么名字、哪個(gè)語(yǔ)言版本而真正的數(shù)據(jù)塊則散落在文件的任意位置只要記錄下它的RVA相對(duì)虛擬地址和大小就夠了。所以資源表本質(zhì)上是一套索引而不是一個(gè)連續(xù)存放所有資源的大文件。理解了這個(gè)后面看數(shù)據(jù)結(jié)構(gòu)就不會(huì)懵。1.2 三級(jí)樹形結(jié)構(gòu)類型、名稱、語(yǔ)言先看第一級(jí)也就是資源類型。PE規(guī)范里預(yù)定義了一批數(shù)字編號(hào)常見的包括類型號(hào)宏定義含義3RT_ICON圖標(biāo)6RT_STRING字符串表10RT_RCDATA原始數(shù)據(jù)塊14RT_GROUP_ICON圖標(biāo)組16RT_VERSION版本信息24RT_MANIFEST程序清單每個(gè)類型下面又會(huì)掛若干名稱項(xiàng)比如一個(gè)程序可能有三個(gè)不同尺寸的圖標(biāo)它們各自有一個(gè)ID再往下每個(gè)名稱下面還有多個(gè)語(yǔ)言版本比如中文版和英文版的字符串表雖然ID相同但語(yǔ)言不同所以也被區(qū)分為兩個(gè)獨(dú)立資源。在數(shù)據(jù)結(jié)構(gòu)上每一級(jí)都是一個(gè)目錄表IMAGE_RESOURCE_DIRECTORY里面放著一組目錄項(xiàng)IMAGE_RESOURCE_DIRECTORY_ENTRY。第一級(jí)目錄項(xiàng)指向第二級(jí)目錄第二級(jí)指向第三級(jí)第三級(jí)的目錄項(xiàng)再指向真正的資源數(shù)據(jù)條目IMAGE_RESOURCE_DATA_ENTRY。一級(jí)一層逐級(jí)向下最終在第三級(jí)拿到數(shù)據(jù)區(qū)的RVA和大小。微軟為何設(shè)計(jì)成這種固定三層結(jié)構(gòu)而不是簡(jiǎn)單一張大表因?yàn)橘Y源多的時(shí)候樹形結(jié)構(gòu)可以用ID做二分查找效率高得多而且類型、名稱、語(yǔ)言三個(gè)維度的組合本身就很自然地對(duì)應(yīng)了樹的分層。還有個(gè)更實(shí)際的原因多語(yǔ)言軟件很常見如果用扁平結(jié)構(gòu)每種語(yǔ)言的每個(gè)資源都要獨(dú)立一行表會(huì)膨脹得很難看用三級(jí)樹每種資源先按類型歸類再按名稱歸類最后語(yǔ)言作為葉子分叉管理起來(lái)清爽得多。2. 核心數(shù)據(jù)結(jié)構(gòu)逐字節(jié)拆解2.1 IMAGE_RESOURCE_DIRECTORY目錄頭節(jié)點(diǎn)任何一級(jí)資源目錄的起點(diǎn)都是一個(gè)16字節(jié)的結(jié)構(gòu)typedef struct _IMAGE_RESOURCE_DIRECTORY { DWORD Characteristics; // 資源屬性通常為0 DWORD TimeDateStamp; // 資源編譯時(shí)間戳 WORD MajorVersion; // 主版本號(hào) WORD MinorVersion; // 次版本號(hào) WORD NumberOfNamedEntries; // 名稱項(xiàng)數(shù)量 WORD NumberOfIdEntries; // ID項(xiàng)數(shù)量 } IMAGE_RESOURCE_DIRECTORY;這個(gè)結(jié)構(gòu)本身不復(fù)雜真正重要的是最后兩個(gè)字段NumberOfNamedEntries和NumberOfIdEntries。這兩個(gè)值加起來(lái)就是緊跟在目錄頭后面的目錄項(xiàng)IMAGE_RESOURCE_DIRECTORY_ENTRY的總數(shù)。其中前NumberOfNamedEntries個(gè)目錄項(xiàng)使用字符串名稱后NumberOfIdEntries個(gè)使用數(shù)字ID。解析器讀到這個(gè)頭之后立刻就能算出接下來(lái)要連續(xù)讀取多少個(gè)8字節(jié)的目錄項(xiàng)再逐個(gè)處理。初次接觸的人很容易把這個(gè)目錄想成一種容器結(jié)構(gòu)覺得目錄里直接裝數(shù)據(jù)。實(shí)際上IMAGE_RESOURCE_DIRECTORY只是描述節(jié)點(diǎn)狀態(tài)的一個(gè)頭節(jié)點(diǎn)下面真正起作用的是數(shù)組形式的目錄項(xiàng)列表。換句話說(shuō)這個(gè)頭是節(jié)點(diǎn)信息卡數(shù)組才是通向下一層的路標(biāo)。很多工具在顯示資源樹時(shí)展開每一層看到的那些條目就是從這里按順序輸出的。2.2 IMAGE_RESOURCE_DIRECTORY_ENTRY通往下一層的路標(biāo)每個(gè)目錄項(xiàng)固定8字節(jié)結(jié)構(gòu)如下typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY { union { struct { DWORD NameOffset : 31; // 名稱字符串的偏移 DWORD NameIsString : 1; // 最高位1表示名稱是字符串0表示是數(shù)字ID } DUMMYSTRUCTNAME; DWORD Name; WORD Id; } DUMMYUNIONNAME; union { DWORD OffsetToData; // 數(shù)據(jù)條目偏移 struct { DWORD OffsetToDirectory : 31; // 子目錄偏移 DWORD DataIsDirectory : 1; // 最高位1表示指向子目錄0表示指向數(shù)據(jù)條目 } DUMMYSTRUCTNAME2; } DUMMYUNIONNAME2; } IMAGE_RESOURCE_DIRECTORY_ENTRY;這個(gè)結(jié)構(gòu)看著有點(diǎn)嚇人兩個(gè)union字段還帶位域。拆開看其實(shí)清楚得很第一個(gè)4字節(jié)是身份信息告訴解析器這個(gè)資源項(xiàng)叫什么名字。如果最高位是0低16位就是一個(gè)數(shù)字ID比如類型號(hào)為3的表示圖標(biāo)如果最高位是1說(shuō)明名字不是數(shù)字而是一個(gè)字符串低31位就是該字符串的偏移地址。第二個(gè)4字節(jié)是位置信息告訴解析器這個(gè)資源項(xiàng)的下一層在哪。如果最高位是1說(shuō)明這一層下面還有子目錄比如類型后面還有名稱OffsetToDirectory就是子目錄的偏移如果最高位是0說(shuō)明這一層已經(jīng)到了葉子OffsetToData指向真正的IMAGE_RESOURCE_DATA_ENTRY。用兩個(gè)最高位作為指針類型標(biāo)識(shí)這種技巧在二進(jìn)制格式里很常見本質(zhì)上就是用一個(gè)標(biāo)志位把這是分支和這是葉子區(qū)分開。我當(dāng)年第一次看到這個(gè)結(jié)構(gòu)時(shí)被兩個(gè)union繞暈了后來(lái)自己用十六進(jìn)制編輯器dumping了幾個(gè)文件一眼就明白了其實(shí)就是一個(gè)32位值最高位一路數(shù)過(guò)去全是1下面低31位就是偏移簡(jiǎn)單直接。2.3 IMAGE_RESOURCE_DATA_ENTRY資源數(shù)據(jù)的真實(shí)入口走到第三級(jí)的目錄項(xiàng)它的位置信息指向的就是數(shù)據(jù)條目了typedef struct _IMAGE_RESOURCE_DATA_ENTRY { DWORD OffsetToData; // 資源數(shù)據(jù)的RVA DWORD Size; // 資源數(shù)據(jù)大小單位字節(jié) DWORD CodePage; // 代碼頁(yè)通常為0 DWORD Reserved; // 保留字段 } IMAGE_RESOURCE_DATA_ENTRY;這個(gè)結(jié)構(gòu)16字節(jié)核心就兩個(gè)字段OffsetToData和Size。注意OffsetToData是RVA不是文件偏移。也就是說(shuō)它描述的是當(dāng)程序被加載進(jìn)內(nèi)存后這個(gè)資源位于虛擬地址空間的哪里而不是它在磁盤文件的哪個(gè)位置。想在磁盤上定位資源必須先把RVA轉(zhuǎn)換成文件偏移轉(zhuǎn)換規(guī)則跟轉(zhuǎn)換導(dǎo)入表、導(dǎo)出表一樣找到包含這個(gè)RVA的節(jié)section然后按文件偏移 節(jié)的PointerToRawData (RVA - 節(jié)的VirtualAddress)來(lái)計(jì)算。CodePage和Reserved兩個(gè)字段大部分情況下都是0。尤其CodePagePE規(guī)范把它描述為資源的代碼頁(yè)但實(shí)際幾乎沒有人往這里填東西解析時(shí)基本可以忽略。到這一步一條完整的資源解析路徑就通了從資源表起始地址出發(fā)第一級(jí)目錄項(xiàng)按類型找第二級(jí)按名稱找第三級(jí)按語(yǔ)言找第三級(jí)目錄項(xiàng)指向資源數(shù)據(jù)條目數(shù)據(jù)條目給出RVA和大小再經(jīng)過(guò)RVA轉(zhuǎn)換最終在磁盤文件里拿到資源的那一坨原始字節(jié)。2.4 字符串名稱與數(shù)字ID最高位的妙用資源名稱有兩種表達(dá)形式數(shù)字ID和Unicode字符串。數(shù)字ID直接存16位范圍從0到65535字符串名稱則通過(guò)另一個(gè)結(jié)構(gòu)來(lái)引用typedef struct _IMAGE_RESOURCE_DIRECTORY_STRING { WORD Length; // 字符串長(zhǎng)度單位是字符數(shù)不是字節(jié)數(shù) CHAR NameString[1]; // Unicode字符串內(nèi)容 } IMAGE_RESOURCE_DIRECTORY_STRING;這個(gè)結(jié)構(gòu)同樣簡(jiǎn)單難點(diǎn)在偏移的計(jì)算方式上。目錄項(xiàng)里的NameOffset或OffsetToData、OffsetToDirectory統(tǒng)統(tǒng)是相對(duì)于資源表起始地址的偏移而不是相對(duì)于當(dāng)前目錄也不是相對(duì)于某個(gè)節(jié)的偏移。這一點(diǎn)至關(guān)重要。我見過(guò)太多人栽在這里拿著目錄項(xiàng)里那個(gè)偏移直接當(dāng)文件偏移去讀結(jié)果讀出來(lái)一堆亂碼。正確做法是先取資源表在文件中的地址即數(shù)據(jù)目錄給出的RVA轉(zhuǎn)換后得到的文件偏移再加上目錄項(xiàng)里的偏移值得到的才是字符串或子目錄在文件里的真實(shí)位置。為什么設(shè)計(jì)成這種相對(duì)基址的方式因?yàn)镻E文件在磁盤上和內(nèi)存里的加載基址不同如果存絕對(duì)地址程序在不同基址下加載時(shí)這些指針就全失效了。資源表本身的位置由數(shù)據(jù)目錄指定所有內(nèi)部指針都相對(duì)于資源表基址這樣文件無(wú)論加載到哪里只要資源表整體被映射過(guò)來(lái)這些相對(duì)偏移就永遠(yuǎn)有效。這種設(shè)計(jì)思想跟節(jié)表里用VirtualAddress而不是絕對(duì)地址是同一個(gè)道理。再說(shuō)二分查找。IMAGE_RESOURCE_DIRECTORY頭里的兩個(gè)數(shù)量字段讓解析器可以知道同一級(jí)目錄下最多有多少個(gè)條目。因?yàn)槟夸涰?xiàng)數(shù)組是有序的ID按升序字符串按Unicode碼點(diǎn)升序Windows加載器定位某個(gè)資源時(shí)可以直接二分查找不必線性掃描全部條目這在資源數(shù)量非常龐大的程序里能省不少時(shí)間。3. 手把手解析一個(gè)真實(shí)的資源表3.1 環(huán)境準(zhǔn)備與工具選型紙上談兵沒意思直接拿一個(gè)真實(shí)的exe來(lái)解析。建議動(dòng)手前準(zhǔn)備好三樣?xùn)|西一個(gè)精簡(jiǎn)的PE文件最好帶圖標(biāo)、版本信息、manifest的小工具文件越大越難debug。一個(gè)十六進(jìn)制編輯器我用的是HxD和010 Editor。HxD免費(fèi)夠用010 Editor自帶PE模板能自動(dòng)標(biāo)出各個(gè)結(jié)構(gòu)的位置新手強(qiáng)烈推薦。Resource Hacker或CFF Explorer作為對(duì)照工具驗(yàn)證自己解析出來(lái)的結(jié)果對(duì)不對(duì)。我這里用一個(gè)自己寫的測(cè)試程序文件不大資源包括一個(gè)圖標(biāo)組、一個(gè)版本塊和一個(gè)manifest清單。整個(gè)解析流程分為三步定位資源表遞歸遍歷資源樹最后把拿到的資源數(shù)據(jù)RVA轉(zhuǎn)成文件偏移并讀取。3.2 用Python編寫資源表解析器手工一個(gè)個(gè)字節(jié)讀太慢了我用Python寫了段腳本把解析流程自動(dòng)化。先讀PE頭定位數(shù)據(jù)目錄再找到資源表RVA轉(zhuǎn)換成文件偏移然后遞歸遍歷目錄樹import struct with open(test.exe, rb) as f: data f.read() # 解析DOS頭定位PE頭 e_lfanew struct.unpack(I, data[0x3C:0x40])[0] assert data[e_lfanew:e_lfanew 4] bPE\0\0 # 解析COFF頭IMAGE_FILE_HEADER coff_offset e_lfanew 4 machine, number_of_sections, timestamp struct.unpack(HHI, data[coff_offset:coff_offset 8]) size_of_optional_header struct.unpack(H, data[coff_offset 16:coff_offset 18])[0] optional_offset coff_offset 20 # 數(shù)據(jù)目錄在可選頭偏移0x60處資源表是第2個(gè)條目index為2 data_dir_offset optional_offset 0x60 resource_rva, resource_size struct.unpack(II, data[data_dir_offset 16:data_dir_offset 24]) print(f[] 資源表RVA: 0x{resource_rva:X}, 大小: 0x{resource_size:X}) # 解析節(jié)表 sections_offset optional_offset size_of_optional_header sections [] for i in range(number_of_sections): sec data[sections_offset i * 40: sections_offset (i 1) * 40] name sec[:8].rstrip(b\0).decode(ascii, errorsignore) virtual_size, virtual_addr, raw_size, raw_ptr struct.unpack(IIII, sec[8:24]) sections.append({ name: name, VirtualAddress: virtual_addr, VirtualSize: virtual_size, PointerToRawData: raw_ptr, RawSize: raw_size }) print(f 節(jié) {name}: VA0x{virtual_addr:X}, VS0x{virtual_size:X}, fRoff0x{raw_ptr:X}, RS0x{raw_size:X}) def rva_to_offset(rva): for s in sections: start s[VirtualAddress] end s[VirtualAddress] s[VirtualSize] if start rva end: return s[PointerToRawData] (rva - start) return None resource_off rva_to_offset(resource_rva) print(f[] 資源表文件偏移: 0x{resource_off:X})這段代碼做了三件事解析PE頭、解析節(jié)表、實(shí)現(xiàn)RVA轉(zhuǎn)文件偏移。接下來(lái)是核心的遞歸解析邏輯def parse_resource_directory(offset, base_offset, depth0): # 讀取16字節(jié)目錄頭 characteristics, timestamp, major, minor, named_count, id_count \ struct.unpack(IIHHHH, data[offset:offset 16]) total_entries named_count id_count print( * depth f[目錄] 項(xiàng)數(shù)量{total_entries} (命名{named_count}, ID{id_count})) entry_offset offset 16 for i in range(total_entries): name_raw, offset_raw struct.unpack(II, data[entry_offset:entry_offset 8]) entry_offset 8 # 解析名稱最高位為1是字符串否則是數(shù)字ID if name_raw 0x80000000: str_off base_offset (name_raw 0x7FFFFFFF) length struct.unpack(H, data[str_off:str_off 2])[0] name data[str_off 2:str_off 2 length * 2].decode(utf-16le, errorsignore) name_str f字符串名稱 {name} else: name_id name_raw 0xFFFF name_str fID0x{name_id:X}({name_id}) # 解析位置最高位為1是子目錄否則是數(shù)據(jù)條目 if offset_raw 0x80000000: sub_off base_offset (offset_raw 0x7FFFFFFF) print( * depth f[條目] {name_str} - 子目錄) parse_resource_directory(sub_off, base_offset, depth 1) else: data_entry_off base_offset offset_raw data_rva, data_size, code_page, reserved \ struct.unpack(IIII, data[data_entry_off:data_entry_off 16]) file_off rva_to_offset(data_rva) print( * depth f[條目] {name_str} - RVA0x{data_rva:X}, fSize0x{data_size:X}, 文件偏移0x{file_off:X}) parse_resource_directory(resource_off, resource_off)跑完腳本后輸出是一棵完整的資源樹。拿這份輸出跟Resource Hacker里看到的資源樹對(duì)比一下類型、名稱、語(yǔ)言、大小全都對(duì)得上說(shuō)明解析成功。我第一次跑通這個(gè)腳本時(shí)盯著屏幕上的樹形輸出成就感是實(shí)打?qū)嵉摹獜倪@一刻起任何PE文件的資源表對(duì)我來(lái)說(shuō)都不再是黑盒了。3.3 用Resource Hacker對(duì)照驗(yàn)證腳本跑完我通常還會(huì)用Resource Hacker打開同一個(gè)文件目測(cè)一下資源樹層級(jí)確認(rèn)解析結(jié)果一致。Resource Hacker會(huì)把資源樹顯示為類型→名稱→語(yǔ)言三欄結(jié)構(gòu)類型那一欄的名字都是處理過(guò)的文本比如Version Info對(duì)應(yīng)的其實(shí)是RT_VERSION即類型ID16Manifest對(duì)應(yīng)的就是類型ID24?？吹竭@些熟悉編號(hào)以人類可讀的方式呈現(xiàn)正好反推出了資源表內(nèi)部的編號(hào)規(guī)則。對(duì)照驗(yàn)證特別適合排查那種明明感覺解析對(duì)了但數(shù)據(jù)內(nèi)容就是不對(duì)的奇怪問(wèn)題。比如Resource Hacker顯示的版本信息是正常的而我腳本dump出來(lái)的版本塊卻亂碼那十有八九是CodePage沒處理對(duì)或者資源數(shù)據(jù)RVA轉(zhuǎn)文件偏移時(shí)節(jié)的VirtualSize比RawSize大導(dǎo)致落在了未映射的Padding區(qū)域里。這些問(wèn)題等到了踩坑那節(jié)我再展開說(shuō)。4. 資源表的四大實(shí)戰(zhàn)場(chǎng)景4.1 漢化與資源編輯資源表最古老、也最經(jīng)典的應(yīng)用就是漢化。早期很多國(guó)外軟件沒有國(guó)際化設(shè)計(jì)字符串硬編碼在資源里要改成中文就得動(dòng)資源表。通過(guò)修改資源表里對(duì)應(yīng)語(yǔ)言版本的字符串資源或者把整個(gè)資源目錄里某種語(yǔ)言的資源替換成翻譯后的版本就能實(shí)現(xiàn)界面漢化而不碰任何代碼。具體操作上成熟的漢化工具比如Radialix、Passolo做得比較完善但它們的原理用一句話概括把資源解析出來(lái)后替換掉RT_STRING和RT_DIALOG里的文本再重新計(jì)算資源表相關(guān)偏移并回寫文件。這里面最麻煩的是體積變化。如果修改后的資源比原來(lái)大原來(lái)的目錄樹和數(shù)據(jù)區(qū)空間不夠放就得重新調(diào)整整個(gè)資源表的布局牽一發(fā)動(dòng)全身。這也是為什么我建議初學(xué)者先學(xué)習(xí)解析而不是直接上手修改能讀是能寫的基礎(chǔ)。4.2 圖標(biāo)與素材提取游戲和軟件的圖標(biāo)、圖片素材很多都以資源形式打包在exe/dll里。用資源表解析器把RT_ICON、RT_BITMAP、RT_RCDATA這些類型的數(shù)據(jù)dump出來(lái)再按對(duì)應(yīng)格式保存就能把原始素材提取出來(lái)。這里有個(gè)細(xì)節(jié)圖標(biāo)通常不是一塊獨(dú)立資源而是拆成RT_GROUP_ICON和若干個(gè)RT_ICON。RT_GROUP_ICON是一個(gè)小組目錄里面記錄了一組圖標(biāo)各自的大小、色彩位數(shù)和對(duì)應(yīng)的RT_ICON資源ID真正存像素?cái)?shù)據(jù)的是那些RT_ICON資源。如果只dump RT_ICON得到的是一塊沒法直接看的圖像數(shù)據(jù)必須結(jié)合RT_GROUP_ICON里的結(jié)構(gòu)信息才能拼出一個(gè)可用的.ico文件。感性的朋友可以這么理解RT_GROUP_ICON是圖像索引文件RT_ICON是圖像數(shù)據(jù)分片兩者結(jié)合起來(lái)才是一張完整的圖。4.3 資源完整性校驗(yàn)在一些安全審計(jì)場(chǎng)景里資源表常被拿來(lái)當(dāng)完整性指紋。比如一個(gè)程序明明自稱是官方版但它的資源跟官方版對(duì)不上——圖標(biāo)被換過(guò)、版本號(hào)被改過(guò)、多了一個(gè)奇怪的自定義類型資源。把資源表里所有資源條目拎出來(lái)計(jì)算每個(gè)數(shù)據(jù)塊的哈希再跟官方安裝包比對(duì)就能快速定位差異點(diǎn)。這種校驗(yàn)不需要理解資源內(nèi)容本身是干嘛的只要完整解析出哪些資源存在、每個(gè)多大、內(nèi)容哈希是什么就已經(jīng)很有價(jià)值了。我做樣本分析時(shí)經(jīng)常先把資源表哈希跑一遍再看結(jié)果——光憑一個(gè)異常的資源類型編號(hào)就能篩掉一大批改了資源就敢自稱破解版的東西。4.4 資源注入的邊界與思考既然能讀自然也能寫。向資源表里添加一個(gè)新條目或者往某個(gè)自定義類型里塞一段自定義數(shù)據(jù)本身是一項(xiàng)中性技術(shù)廣泛應(yīng)用于插件系統(tǒng)、補(bǔ)丁分發(fā)、軟件授權(quán)信息存儲(chǔ)等場(chǎng)景。很多軟件的許可證信息就存在RT_RCDATA類型里程序啟動(dòng)時(shí)自己解析。但任何技術(shù)工具都有邊界。資源表是PE文件里公開可見的部分CFF Explorer、Resource Hacker這類工具都能一覽無(wú)余所以把敏感內(nèi)容藏到資源表里從來(lái)不是一個(gè)隱蔽的選擇。反過(guò)來(lái)正常做軟件定制時(shí)也別指望資源表能擋住任何有基本逆向能力的人。理解資源的存儲(chǔ)與讀取是為了更好地保護(hù)自己的軟件形態(tài)、理解程序的組成而不是去給惡意行為找掩護(hù)。對(duì)學(xué)習(xí)資源表的人來(lái)說(shuō)把重心放在讀懂結(jié)構(gòu)、正確解析這件事本身上就足夠有價(jià)值了。5. 最容易踩的五個(gè)坑5.1 RVA與文件偏移的混淆這是資源表解析里第一大坑。資源樹內(nèi)部存的全是相對(duì)資源表基址的偏移資源數(shù)據(jù)條目里存的是RVA而你在文件里實(shí)際讀取時(shí)用的是文件偏移。三者之間任何一個(gè)環(huán)節(jié)沒轉(zhuǎn)對(duì)結(jié)果都是定位錯(cuò)誤。舉個(gè)真實(shí)例子我調(diào)試某個(gè)程序時(shí)解析出來(lái)版本資源的大小是0x234但dump出來(lái)的數(shù)據(jù)開頭完全沒有版本塊的固定簽名反而是一堆看起來(lái)像代碼的字節(jié)。排查了半天發(fā)現(xiàn)是資源數(shù)據(jù)RVA落在了某個(gè)節(jié)的VirtualSize和RawSize不一致的區(qū)域。節(jié)表里VirtualAddress到VirtualAddressVirtualSize這段空間在文件里可能沒有對(duì)應(yīng)的原始數(shù)據(jù)因?yàn)榇疟P上不需要映射到那么大按公式映射到文件卻計(jì)算出了一個(gè)落在節(jié)尾Padding的偏移自然就讀錯(cuò)了。正確的排查方式是先確認(rèn)RVA落在哪個(gè)節(jié)再看這個(gè)節(jié)的RawSize是否覆蓋了目標(biāo)偏移最后才動(dòng)手讀數(shù)據(jù)。如果RVA落在VirtualSize內(nèi)但超出了RawSize范圍那這個(gè)資源在磁盤文件里本來(lái)就沒有對(duì)應(yīng)的原始字節(jié)必須放棄物理讀取或者按程序加載進(jìn)內(nèi)存后的狀態(tài)來(lái)分析。5.2 偏移基準(zhǔn)搞錯(cuò)從第二級(jí)目錄開始的陷阱資源目錄項(xiàng)的NameOffset、OffsetToData、OffsetToDirectory這三個(gè)偏移都以資源表基址為基準(zhǔn)而不是以當(dāng)前目錄為基準(zhǔn)。這個(gè)基準(zhǔn)問(wèn)題特別隱蔽因?yàn)榈谝患?jí)目錄的基址和資源表基址是同一個(gè)你按資源表基址偏移算出來(lái)的結(jié)果跟按當(dāng)前目錄基址偏移算出來(lái)的一樣于是你以為自己搞對(duì)了。到了第二級(jí)、第三級(jí)目錄不再是資源表基址了但那些偏移還是相對(duì)資源表基址的如果你還按當(dāng)前目錄去算就全亂了。我在文章前面反復(fù)強(qiáng)調(diào)這一點(diǎn)是因?yàn)樗褪切率肿钊菀族e(cuò)、又最難自查的地方。強(qiáng)烈建議你把每一級(jí)目錄的基址打印出來(lái)逐級(jí)手動(dòng)驗(yàn)證偏移務(wù)必確保每個(gè)子目錄和數(shù)據(jù)條目都是用同一個(gè)基準(zhǔn)算出來(lái)的。寫遞歸解析器時(shí)把base_offset作為參數(shù)一路傳下去不要在遞歸過(guò)程中隨意改基準(zhǔn)。5.3 對(duì)齊與Padding問(wèn)題資源數(shù)據(jù)存放在節(jié)內(nèi)部時(shí)一切都要遵守節(jié)的對(duì)齊規(guī)則。比如一個(gè)節(jié)的文件對(duì)齊是0x200資源數(shù)據(jù)從0x2C0開始那么下一個(gè)資源的文件偏移最也要對(duì)齊到0x400。在解析時(shí)DataEntry給出的Size是精確數(shù)據(jù)大小不包含Padding要讀取的就應(yīng)該是Size這么多字節(jié)而不是把節(jié)里后續(xù)的所有內(nèi)容都當(dāng)作資源的一部分。這個(gè)問(wèn)題在人工翻十六進(jìn)制時(shí)特別容易看走眼。資源數(shù)據(jù)后面經(jīng)常跟著一堆00那不是資源內(nèi)容是對(duì)齊Padding。有些資源本身以00結(jié)尾更難分辨Padding從哪開始。穩(wěn)妥的做法是嚴(yán)格按DataEntry里的Size字段截?cái)鄤e多讀。尤其在做哈希校驗(yàn)時(shí)多讀了Padding會(huì)導(dǎo)致哈希永遠(yuǎn)對(duì)不上白白浪費(fèi)時(shí)間排查。5.4 遞歸遍歷的終止條件資源樹的層級(jí)從設(shè)計(jì)上說(shuō)是類型、名稱、語(yǔ)言三層最多只能嵌套三層。但寫遞歸解析器時(shí)理想做法不是限制深度等于3而是根據(jù)目錄項(xiàng)的DataIsDirectory標(biāo)志來(lái)判斷——是子目錄就繼續(xù)遞歸是數(shù)據(jù)條目就讀取數(shù)據(jù)。這么寫的好處是能兼容那些不合規(guī)但實(shí)際存在的PE文件有些壓縮殼、混淆器會(huì)生成四層甚至五層嵌套的資源樹加載器照樣讀得動(dòng)限制死深度反而容易漏解析。同時(shí)要注意遞歸別寫成死循環(huán)。正常情況下子目錄偏移不會(huì)指向自己的祖先目錄但畸形文件里可能存在循環(huán)引用。穩(wěn)妥的解析器會(huì)維護(hù)一個(gè)訪問(wèn)過(guò)的目錄偏移集合發(fā)現(xiàn)重復(fù)就停下并報(bào)警。這既是工程健壯性也是安全考慮——一個(gè)惡意構(gòu)造的PE文件讓解析器陷入死循環(huán)是再簡(jiǎn)單不過(guò)的目的了。5.5 工具使用與人工驗(yàn)證的思路最后聊一點(diǎn)工具心得。CFF Explorer和010 Editor是我做PE解析時(shí)用得最多的工具一個(gè)負(fù)責(zé)快速看全貌一個(gè)負(fù)責(zé)深入摳字節(jié)。資源表解析這種活兒只用腳本不用工具驗(yàn)證跟只用工具不寫腳本都是走不遠(yuǎn)的。我的習(xí)慣流程是先讓腳本輸出資源樹和資源數(shù)據(jù)哈希再用CFF Explorer打開同一文件人工比對(duì)每一級(jí)條目的名稱和ID最后用Resource Hacker驗(yàn)證資源內(nèi)容是否正確。三次驗(yàn)證全都通過(guò)才敢確認(rèn)這個(gè)文件解析真沒問(wèn)題。這個(gè)流程看著繁瑣但對(duì)培養(yǎng)結(jié)構(gòu)直覺特別有用練多了之后你看一個(gè)十六進(jìn)制dump就能大概猜出資源表在哪一層、偏移基準(zhǔn)對(duì)不對(duì)。結(jié)尾一個(gè)持續(xù)有用的習(xí)慣資源表只是PE格式眾多結(jié)構(gòu)中的一塊拼圖但它的樹形設(shè)計(jì)、相對(duì)偏移機(jī)制、RVA轉(zhuǎn)換邏輯幾乎涵蓋了理解PE所需的全部核心思想。我自己當(dāng)年把資源表徹底吃透之后再回頭去看導(dǎo)入導(dǎo)出表、延遲加載、異常表這些結(jié)構(gòu)感覺都順了不少——因?yàn)樗鼈兊脑碓谫Y源表里都已經(jīng)出現(xiàn)過(guò)一遍了。最后分享一個(gè)我實(shí)際踩過(guò)的小技巧做解析實(shí)驗(yàn)時(shí)別只拿一個(gè)小工具測(cè)試經(jīng)常換不同的正常軟件去跑你會(huì)發(fā)現(xiàn)資源表的生活習(xí)慣千奇百怪。有的軟件資源樹里塞著幾百個(gè)名字全部是數(shù)字ID的條目有的軟件把自定義數(shù)據(jù)裸放在RT_RCDATA里不帶任何封裝有的軟件一個(gè)資源數(shù)據(jù)塊跨越了節(jié)區(qū)的邊界——這些都只有拿真實(shí)世界的文件去碰才能提前預(yù)習(xí)到。等你哪天閉著眼睛能把資源表的結(jié)構(gòu)畫出來(lái)、隨手寫出遞歸解析代碼那種感覺看十篇文章都換不來(lái)。 PE文件資源表完全解析：從三級(jí)樹形結(jié)構(gòu)到遞歸解析實(shí)戰(zhàn)
每個(gè)接觸過(guò)PE文件的人心里大概都有一道坎數(shù)據(jù)目錄、導(dǎo)入表、導(dǎo)出表這些還好說(shuō)到了資源表就有點(diǎn)繞了。我做逆向分析和去殼工作也算有些年頭了最開始卡住我的就是這個(gè)資源表。圖標(biāo)是它管的版本信息是它管的菜單對(duì)話框是它管的就連不少軟件藏著的自定義數(shù)據(jù)也經(jīng)常作為一個(gè)特殊類型資源掛靠在資源表里。所以無(wú)論是做漢化、改圖標(biāo)、提取素材還是做樣本分析過(guò)不了資源表這一關(guān)后面的活兒基本都干不下去。這篇文章我就把資源表的原理、結(jié)構(gòu)和實(shí)操解析完整地講一遍適合剛學(xué)完P(guān)E頭格式、正準(zhǔn)備啃資源表的新手也適合那些一直在用工具改資源卻從沒搞清楚它內(nèi)部長(zhǎng)什么樣的朋友。1. 資源表到底是什么一個(gè)藏在PE里的文件系統(tǒng)1.1 資源表解決了什么問(wèn)題一個(gè)Windows可執(zhí)行程序除了代碼和數(shù)據(jù)還帶著一大堆附屬品窗口左上角的圖標(biāo)、程序名底下的版本號(hào)、右鍵菜單里的文字、開屏彈出來(lái)的對(duì)話框、UAC需要的manifest清單。這些東西形式各異、長(zhǎng)度不一散落在文件里東一塊西一塊顯然不行所以PE格式專門設(shè)計(jì)了一張資源表把這些資源統(tǒng)一管起來(lái)。你可以把資源表想象成一個(gè)圖書館的目錄系統(tǒng)。圖書館要把書分類擺放必須有一套編號(hào)規(guī)則先按圖書分類文學(xué)、歷史、計(jì)算機(jī)再按書名或者作者最后可能還要細(xì)分到具體版本。資源表的組織方式幾乎一模一樣它用三級(jí)樹形結(jié)構(gòu)來(lái)定位任何一個(gè)資源第一級(jí)是資源類型第二級(jí)是資源名稱第三級(jí)是資源語(yǔ)言。你最終想拿到的圖標(biāo)、字符串、版本塊就掛在第三級(jí)目錄下面的葉子節(jié)點(diǎn)上。這個(gè)設(shè)計(jì)最巧妙的地方在于它把資源尋址和資源存儲(chǔ)分開了。資源目錄樹負(fù)責(zé)告訴解析器你要找的東西屬于什么類型、叫什么名字、哪個(gè)語(yǔ)言版本而真正的數(shù)據(jù)塊則散落在文件的任意位置只要記錄下它的RVA相對(duì)虛擬地址和大小就夠了。所以資源表本質(zhì)上是一套索引而不是一個(gè)連續(xù)存放所有資源的大文件。理解了這個(gè)后面看數(shù)據(jù)結(jié)構(gòu)就不會(huì)懵。1.2 三級(jí)樹形結(jié)構(gòu)類型、名稱、語(yǔ)言先看第一級(jí)也就是資源類型。PE規(guī)范里預(yù)定義了一批數(shù)字編號(hào)常見的包括類型號(hào)宏定義含義3RT_ICON圖標(biāo)6RT_STRING字符串表10RT_RCDATA原始數(shù)據(jù)塊14RT_GROUP_ICON圖標(biāo)組16RT_VERSION版本信息24RT_MANIFEST程序清單每個(gè)類型下面又會(huì)掛若干名稱項(xiàng)比如一個(gè)程序可能有三個(gè)不同尺寸的圖標(biāo)它們各自有一個(gè)ID再往下每個(gè)名稱下面還有多個(gè)語(yǔ)言版本比如中文版和英文版的字符串表雖然ID相同但語(yǔ)言不同所以也被區(qū)分為兩個(gè)獨(dú)立資源。在數(shù)據(jù)結(jié)構(gòu)上每一級(jí)都是一個(gè)目錄表IMAGE_RESOURCE_DIRECTORY里面放著一組目錄項(xiàng)IMAGE_RESOURCE_DIRECTORY_ENTRY。第一級(jí)目錄項(xiàng)指向第二級(jí)目錄第二級(jí)指向第三級(jí)第三級(jí)的目錄項(xiàng)再指向真正的資源數(shù)據(jù)條目IMAGE_RESOURCE_DATA_ENTRY。一級(jí)一層逐級(jí)向下最終在第三級(jí)拿到數(shù)據(jù)區(qū)的RVA和大小。微軟為何設(shè)計(jì)成這種固定三層結(jié)構(gòu)而不是簡(jiǎn)單一張大表因?yàn)橘Y源多的時(shí)候樹形結(jié)構(gòu)可以用ID做二分查找效率高得多而且類型、名稱、語(yǔ)言三個(gè)維度的組合本身就很自然地對(duì)應(yīng)了樹的分層。還有個(gè)更實(shí)際的原因多語(yǔ)言軟件很常見如果用扁平結(jié)構(gòu)每種語(yǔ)言的每個(gè)資源都要獨(dú)立一行表會(huì)膨脹得很難看用三級(jí)樹每種資源先按類型歸類再按名稱歸類最后語(yǔ)言作為葉子分叉管理起來(lái)清爽得多。2. 核心數(shù)據(jù)結(jié)構(gòu)逐字節(jié)拆解2.1 IMAGE_RESOURCE_DIRECTORY目錄頭節(jié)點(diǎn)任何一級(jí)資源目錄的起點(diǎn)都是一個(gè)16字節(jié)的結(jié)構(gòu)typedef struct _IMAGE_RESOURCE_DIRECTORY { DWORD Characteristics; // 資源屬性通常為0 DWORD TimeDateStamp; // 資源編譯時(shí)間戳 WORD MajorVersion; // 主版本號(hào) WORD MinorVersion; // 次版本號(hào) WORD NumberOfNamedEntries; // 名稱項(xiàng)數(shù)量 WORD NumberOfIdEntries; // ID項(xiàng)數(shù)量 } IMAGE_RESOURCE_DIRECTORY;這個(gè)結(jié)構(gòu)本身不復(fù)雜真正重要的是最后兩個(gè)字段NumberOfNamedEntries和NumberOfIdEntries。這兩個(gè)值加起來(lái)就是緊跟在目錄頭后面的目錄項(xiàng)IMAGE_RESOURCE_DIRECTORY_ENTRY的總數(shù)。其中前NumberOfNamedEntries個(gè)目錄項(xiàng)使用字符串名稱后NumberOfIdEntries個(gè)使用數(shù)字ID。解析器讀到這個(gè)頭之后立刻就能算出接下來(lái)要連續(xù)讀取多少個(gè)8字節(jié)的目錄項(xiàng)再逐個(gè)處理。初次接觸的人很容易把這個(gè)目錄想成一種容器結(jié)構(gòu)覺得目錄里直接裝數(shù)據(jù)。實(shí)際上IMAGE_RESOURCE_DIRECTORY只是描述節(jié)點(diǎn)狀態(tài)的一個(gè)頭節(jié)點(diǎn)下面真正起作用的是數(shù)組形式的目錄項(xiàng)列表。換句話說(shuō)這個(gè)頭是節(jié)點(diǎn)信息卡數(shù)組才是通向下一層的路標(biāo)。很多工具在顯示資源樹時(shí)展開每一層看到的那些條目就是從這里按順序輸出的。2.2 IMAGE_RESOURCE_DIRECTORY_ENTRY通往下一層的路標(biāo)每個(gè)目錄項(xiàng)固定8字節(jié)結(jié)構(gòu)如下typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY { union { struct { DWORD NameOffset : 31; // 名稱字符串的偏移 DWORD NameIsString : 1; // 最高位1表示名稱是字符串0表示是數(shù)字ID } DUMMYSTRUCTNAME; DWORD Name; WORD Id; } DUMMYUNIONNAME; union { DWORD OffsetToData; // 數(shù)據(jù)條目偏移 struct { DWORD OffsetToDirectory : 31; // 子目錄偏移 DWORD DataIsDirectory : 1; // 最高位1表示指向子目錄0表示指向數(shù)據(jù)條目 } DUMMYSTRUCTNAME2; } DUMMYUNIONNAME2; } IMAGE_RESOURCE_DIRECTORY_ENTRY;這個(gè)結(jié)構(gòu)看著有點(diǎn)嚇人兩個(gè)union字段還帶位域。拆開看其實(shí)清楚得很第一個(gè)4字節(jié)是身份信息告訴解析器這個(gè)資源項(xiàng)叫什么名字。如果最高位是0低16位就是一個(gè)數(shù)字ID比如類型號(hào)為3的表示圖標(biāo)如果最高位是1說(shuō)明名字不是數(shù)字而是一個(gè)字符串低31位就是該字符串的偏移地址。第二個(gè)4字節(jié)是位置信息告訴解析器這個(gè)資源項(xiàng)的下一層在哪。如果最高位是1說(shuō)明這一層下面還有子目錄比如類型后面還有名稱OffsetToDirectory就是子目錄的偏移如果最高位是0說(shuō)明這一層已經(jīng)到了葉子OffsetToData指向真正的IMAGE_RESOURCE_DATA_ENTRY。用兩個(gè)最高位作為指針類型標(biāo)識(shí)這種技巧在二進(jìn)制格式里很常見本質(zhì)上就是用一個(gè)標(biāo)志位把這是分支和這是葉子區(qū)分開。我當(dāng)年第一次看到這個(gè)結(jié)構(gòu)時(shí)被兩個(gè)union繞暈了后來(lái)自己用十六進(jìn)制編輯器dumping了幾個(gè)文件一眼就明白了其實(shí)就是一個(gè)32位值最高位一路數(shù)過(guò)去全是1下面低31位就是偏移簡(jiǎn)單直接。2.3 IMAGE_RESOURCE_DATA_ENTRY資源數(shù)據(jù)的真實(shí)入口走到第三級(jí)的目錄項(xiàng)它的位置信息指向的就是數(shù)據(jù)條目了typedef struct _IMAGE_RESOURCE_DATA_ENTRY { DWORD OffsetToData; // 資源數(shù)據(jù)的RVA DWORD Size; // 資源數(shù)據(jù)大小單位字節(jié) DWORD CodePage; // 代碼頁(yè)通常為0 DWORD Reserved; // 保留字段 } IMAGE_RESOURCE_DATA_ENTRY;這個(gè)結(jié)構(gòu)16字節(jié)核心就兩個(gè)字段OffsetToData和Size。注意OffsetToData是RVA不是文件偏移。也就是說(shuō)它描述的是當(dāng)程序被加載進(jìn)內(nèi)存后這個(gè)資源位于虛擬地址空間的哪里而不是它在磁盤文件的哪個(gè)位置。想在磁盤上定位資源必須先把RVA轉(zhuǎn)換成文件偏移轉(zhuǎn)換規(guī)則跟轉(zhuǎn)換導(dǎo)入表、導(dǎo)出表一樣找到包含這個(gè)RVA的節(jié)section然后按文件偏移 節(jié)的PointerToRawData (RVA - 節(jié)的VirtualAddress)來(lái)計(jì)算。CodePage和Reserved兩個(gè)字段大部分情況下都是0。尤其CodePagePE規(guī)范把它描述為資源的代碼頁(yè)但實(shí)際幾乎沒有人往這里填東西解析時(shí)基本可以忽略。到這一步一條完整的資源解析路徑就通了從資源表起始地址出發(fā)第一級(jí)目錄項(xiàng)按類型找第二級(jí)按名稱找第三級(jí)按語(yǔ)言找第三級(jí)目錄項(xiàng)指向資源數(shù)據(jù)條目數(shù)據(jù)條目給出RVA和大小再經(jīng)過(guò)RVA轉(zhuǎn)換最終在磁盤文件里拿到資源的那一坨原始字節(jié)。2.4 字符串名稱與數(shù)字ID最高位的妙用資源名稱有兩種表達(dá)形式數(shù)字ID和Unicode字符串。數(shù)字ID直接存16位范圍從0到65535字符串名稱則通過(guò)另一個(gè)結(jié)構(gòu)來(lái)引用typedef struct _IMAGE_RESOURCE_DIRECTORY_STRING { WORD Length; // 字符串長(zhǎng)度單位是字符數(shù)不是字節(jié)數(shù) CHAR NameString[1]; // Unicode字符串內(nèi)容 } IMAGE_RESOURCE_DIRECTORY_STRING;這個(gè)結(jié)構(gòu)同樣簡(jiǎn)單難點(diǎn)在偏移的計(jì)算方式上。目錄項(xiàng)里的NameOffset或OffsetToData、OffsetToDirectory統(tǒng)統(tǒng)是相對(duì)于資源表起始地址的偏移而不是相對(duì)于當(dāng)前目錄也不是相對(duì)于某個(gè)節(jié)的偏移。這一點(diǎn)至關(guān)重要。我見過(guò)太多人栽在這里拿著目錄項(xiàng)里那個(gè)偏移直接當(dāng)文件偏移去讀結(jié)果讀出來(lái)一堆亂碼。正確做法是先取資源表在文件中的地址即數(shù)據(jù)目錄給出的RVA轉(zhuǎn)換后得到的文件偏移再加上目錄項(xiàng)里的偏移值得到的才是字符串或子目錄在文件里的真實(shí)位置。為什么設(shè)計(jì)成這種相對(duì)基址的方式因?yàn)镻E文件在磁盤上和內(nèi)存里的加載基址不同如果存絕對(duì)地址程序在不同基址下加載時(shí)這些指針就全失效了。資源表本身的位置由數(shù)據(jù)目錄指定所有內(nèi)部指針都相對(duì)于資源表基址這樣文件無(wú)論加載到哪里只要資源表整體被映射過(guò)來(lái)這些相對(duì)偏移就永遠(yuǎn)有效。這種設(shè)計(jì)思想跟節(jié)表里用VirtualAddress而不是絕對(duì)地址是同一個(gè)道理。再說(shuō)二分查找。IMAGE_RESOURCE_DIRECTORY頭里的兩個(gè)數(shù)量字段讓解析器可以知道同一級(jí)目錄下最多有多少個(gè)條目。因?yàn)槟夸涰?xiàng)數(shù)組是有序的ID按升序字符串按Unicode碼點(diǎn)升序Windows加載器定位某個(gè)資源時(shí)可以直接二分查找不必線性掃描全部條目這在資源數(shù)量非常龐大的程序里能省不少時(shí)間。3. 手把手解析一個(gè)真實(shí)的資源表3.1 環(huán)境準(zhǔn)備與工具選型紙上談兵沒意思直接拿一個(gè)真實(shí)的exe來(lái)解析。建議動(dòng)手前準(zhǔn)備好三樣?xùn)|西一個(gè)精簡(jiǎn)的PE文件最好帶圖標(biāo)、版本信息、manifest的小工具文件越大越難debug。一個(gè)十六進(jìn)制編輯器我用的是HxD和010 Editor。HxD免費(fèi)夠用010 Editor自帶PE模板能自動(dòng)標(biāo)出各個(gè)結(jié)構(gòu)的位置新手強(qiáng)烈推薦。Resource Hacker或CFF Explorer作為對(duì)照工具驗(yàn)證自己解析出來(lái)的結(jié)果對(duì)不對(duì)。我這里用一個(gè)自己寫的測(cè)試程序文件不大資源包括一個(gè)圖標(biāo)組、一個(gè)版本塊和一個(gè)manifest清單。整個(gè)解析流程分為三步定位資源表遞歸遍歷資源樹最后把拿到的資源數(shù)據(jù)RVA轉(zhuǎn)成文件偏移并讀取。3.2 用Python編寫資源表解析器手工一個(gè)個(gè)字節(jié)讀太慢了我用Python寫了段腳本把解析流程自動(dòng)化。先讀PE頭定位數(shù)據(jù)目錄再找到資源表RVA轉(zhuǎn)換成文件偏移然后遞歸遍歷目錄樹import struct with open(test.exe, rb) as f: data f.read() # 解析DOS頭定位PE頭 e_lfanew struct.unpack(I, data[0x3C:0x40])[0] assert data[e_lfanew:e_lfanew 4] bPE\0\0 # 解析COFF頭IMAGE_FILE_HEADER coff_offset e_lfanew 4 machine, number_of_sections, timestamp struct.unpack(HHI, data[coff_offset:coff_offset 8]) size_of_optional_header struct.unpack(H, data[coff_offset 16:coff_offset 18])[0] optional_offset coff_offset 20 # 數(shù)據(jù)目錄在可選頭偏移0x60處資源表是第2個(gè)條目index為2 data_dir_offset optional_offset 0x60 resource_rva, resource_size struct.unpack(II, data[data_dir_offset 16:data_dir_offset 24]) print(f[] 資源表RVA: 0x{resource_rva:X}, 大小: 0x{resource_size:X}) # 解析節(jié)表 sections_offset optional_offset size_of_optional_header sections [] for i in range(number_of_sections): sec data[sections_offset i * 40: sections_offset (i 1) * 40] name sec[:8].rstrip(b\0).decode(ascii, errorsignore) virtual_size, virtual_addr, raw_size, raw_ptr struct.unpack(IIII, sec[8:24]) sections.append({ name: name, VirtualAddress: virtual_addr, VirtualSize: virtual_size, PointerToRawData: raw_ptr, RawSize: raw_size }) print(f 節(jié) {name}: VA0x{virtual_addr:X}, VS0x{virtual_size:X}, fRoff0x{raw_ptr:X}, RS0x{raw_size:X}) def rva_to_offset(rva): for s in sections: start s[VirtualAddress] end s[VirtualAddress] s[VirtualSize] if start rva end: return s[PointerToRawData] (rva - start) return None resource_off rva_to_offset(resource_rva) print(f[] 資源表文件偏移: 0x{resource_off:X})這段代碼做了三件事解析PE頭、解析節(jié)表、實(shí)現(xiàn)RVA轉(zhuǎn)文件偏移。接下來(lái)是核心的遞歸解析邏輯def parse_resource_directory(offset, base_offset, depth0): # 讀取16字節(jié)目錄頭 characteristics, timestamp, major, minor, named_count, id_count \ struct.unpack(IIHHHH, data[offset:offset 16]) total_entries named_count id_count print( * depth f[目錄] 項(xiàng)數(shù)量{total_entries} (命名{named_count}, ID{id_count})) entry_offset offset 16 for i in range(total_entries): name_raw, offset_raw struct.unpack(II, data[entry_offset:entry_offset 8]) entry_offset 8 # 解析名稱最高位為1是字符串否則是數(shù)字ID if name_raw 0x80000000: str_off base_offset (name_raw 0x7FFFFFFF) length struct.unpack(H, data[str_off:str_off 2])[0] name data[str_off 2:str_off 2 length * 2].decode(utf-16le, errorsignore) name_str f字符串名稱 {name} else: name_id name_raw 0xFFFF name_str fID0x{name_id:X}({name_id}) # 解析位置最高位為1是子目錄否則是數(shù)據(jù)條目 if offset_raw 0x80000000: sub_off base_offset (offset_raw 0x7FFFFFFF) print( * depth f[條目] {name_str} - 子目錄) parse_resource_directory(sub_off, base_offset, depth 1) else: data_entry_off base_offset offset_raw data_rva, data_size, code_page, reserved \ struct.unpack(IIII, data[data_entry_off:data_entry_off 16]) file_off rva_to_offset(data_rva) print( * depth f[條目] {name_str} - RVA0x{data_rva:X}, fSize0x{data_size:X}, 文件偏移0x{file_off:X}) parse_resource_directory(resource_off, resource_off)跑完腳本后輸出是一棵完整的資源樹。拿這份輸出跟Resource Hacker里看到的資源樹對(duì)比一下類型、名稱、語(yǔ)言、大小全都對(duì)得上說(shuō)明解析成功。我第一次跑通這個(gè)腳本時(shí)盯著屏幕上的樹形輸出成就感是實(shí)打?qū)嵉摹獜倪@一刻起任何PE文件的資源表對(duì)我來(lái)說(shuō)都不再是黑盒了。3.3 用Resource Hacker對(duì)照驗(yàn)證腳本跑完我通常還會(huì)用Resource Hacker打開同一個(gè)文件目測(cè)一下資源樹層級(jí)確認(rèn)解析結(jié)果一致。Resource Hacker會(huì)把資源樹顯示為類型→名稱→語(yǔ)言三欄結(jié)構(gòu)類型那一欄的名字都是處理過(guò)的文本比如Version Info對(duì)應(yīng)的其實(shí)是RT_VERSION即類型ID16Manifest對(duì)應(yīng)的就是類型ID24?？吹竭@些熟悉編號(hào)以人類可讀的方式呈現(xiàn)正好反推出了資源表內(nèi)部的編號(hào)規(guī)則。對(duì)照驗(yàn)證特別適合排查那種明明感覺解析對(duì)了但數(shù)據(jù)內(nèi)容就是不對(duì)的奇怪問(wèn)題。比如Resource Hacker顯示的版本信息是正常的而我腳本dump出來(lái)的版本塊卻亂碼那十有八九是CodePage沒處理對(duì)或者資源數(shù)據(jù)RVA轉(zhuǎn)文件偏移時(shí)節(jié)的VirtualSize比RawSize大導(dǎo)致落在了未映射的Padding區(qū)域里。這些問(wèn)題等到了踩坑那節(jié)我再展開說(shuō)。4. 資源表的四大實(shí)戰(zhàn)場(chǎng)景4.1 漢化與資源編輯資源表最古老、也最經(jīng)典的應(yīng)用就是漢化。早期很多國(guó)外軟件沒有國(guó)際化設(shè)計(jì)字符串硬編碼在資源里要改成中文就得動(dòng)資源表。通過(guò)修改資源表里對(duì)應(yīng)語(yǔ)言版本的字符串資源或者把整個(gè)資源目錄里某種語(yǔ)言的資源替換成翻譯后的版本就能實(shí)現(xiàn)界面漢化而不碰任何代碼。具體操作上成熟的漢化工具比如Radialix、Passolo做得比較完善但它們的原理用一句話概括把資源解析出來(lái)后替換掉RT_STRING和RT_DIALOG里的文本再重新計(jì)算資源表相關(guān)偏移并回寫文件。這里面最麻煩的是體積變化。如果修改后的資源比原來(lái)大原來(lái)的目錄樹和數(shù)據(jù)區(qū)空間不夠放就得重新調(diào)整整個(gè)資源表的布局牽一發(fā)動(dòng)全身。這也是為什么我建議初學(xué)者先學(xué)習(xí)解析而不是直接上手修改能讀是能寫的基礎(chǔ)。4.2 圖標(biāo)與素材提取游戲和軟件的圖標(biāo)、圖片素材很多都以資源形式打包在exe/dll里。用資源表解析器把RT_ICON、RT_BITMAP、RT_RCDATA這些類型的數(shù)據(jù)dump出來(lái)再按對(duì)應(yīng)格式保存就能把原始素材提取出來(lái)。這里有個(gè)細(xì)節(jié)圖標(biāo)通常不是一塊獨(dú)立資源而是拆成RT_GROUP_ICON和若干個(gè)RT_ICON。RT_GROUP_ICON是一個(gè)小組目錄里面記錄了一組圖標(biāo)各自的大小、色彩位數(shù)和對(duì)應(yīng)的RT_ICON資源ID真正存像素?cái)?shù)據(jù)的是那些RT_ICON資源。如果只dump RT_ICON得到的是一塊沒法直接看的圖像數(shù)據(jù)必須結(jié)合RT_GROUP_ICON里的結(jié)構(gòu)信息才能拼出一個(gè)可用的.ico文件。感性的朋友可以這么理解RT_GROUP_ICON是圖像索引文件RT_ICON是圖像數(shù)據(jù)分片兩者結(jié)合起來(lái)才是一張完整的圖。4.3 資源完整性校驗(yàn)在一些安全審計(jì)場(chǎng)景里資源表常被拿來(lái)當(dāng)完整性指紋。比如一個(gè)程序明明自稱是官方版但它的資源跟官方版對(duì)不上——圖標(biāo)被換過(guò)、版本號(hào)被改過(guò)、多了一個(gè)奇怪的自定義類型資源。把資源表里所有資源條目拎出來(lái)計(jì)算每個(gè)數(shù)據(jù)塊的哈希再跟官方安裝包比對(duì)就能快速定位差異點(diǎn)。這種校驗(yàn)不需要理解資源內(nèi)容本身是干嘛的只要完整解析出哪些資源存在、每個(gè)多大、內(nèi)容哈希是什么就已經(jīng)很有價(jià)值了。我做樣本分析時(shí)經(jīng)常先把資源表哈希跑一遍再看結(jié)果——光憑一個(gè)異常的資源類型編號(hào)就能篩掉一大批改了資源就敢自稱破解版的東西。4.4 資源注入的邊界與思考既然能讀自然也能寫。向資源表里添加一個(gè)新條目或者往某個(gè)自定義類型里塞一段自定義數(shù)據(jù)本身是一項(xiàng)中性技術(shù)廣泛應(yīng)用于插件系統(tǒng)、補(bǔ)丁分發(fā)、軟件授權(quán)信息存儲(chǔ)等場(chǎng)景。很多軟件的許可證信息就存在RT_RCDATA類型里程序啟動(dòng)時(shí)自己解析。但任何技術(shù)工具都有邊界。資源表是PE文件里公開可見的部分CFF Explorer、Resource Hacker這類工具都能一覽無(wú)余所以把敏感內(nèi)容藏到資源表里從來(lái)不是一個(gè)隱蔽的選擇。反過(guò)來(lái)正常做軟件定制時(shí)也別指望資源表能擋住任何有基本逆向能力的人。理解資源的存儲(chǔ)與讀取是為了更好地保護(hù)自己的軟件形態(tài)、理解程序的組成而不是去給惡意行為找掩護(hù)。對(duì)學(xué)習(xí)資源表的人來(lái)說(shuō)把重心放在讀懂結(jié)構(gòu)、正確解析這件事本身上就足夠有價(jià)值了。5. 最容易踩的五個(gè)坑5.1 RVA與文件偏移的混淆這是資源表解析里第一大坑。資源樹內(nèi)部存的全是相對(duì)資源表基址的偏移資源數(shù)據(jù)條目里存的是RVA而你在文件里實(shí)際讀取時(shí)用的是文件偏移。三者之間任何一個(gè)環(huán)節(jié)沒轉(zhuǎn)對(duì)結(jié)果都是定位錯(cuò)誤。舉個(gè)真實(shí)例子我調(diào)試某個(gè)程序時(shí)解析出來(lái)版本資源的大小是0x234但dump出來(lái)的數(shù)據(jù)開頭完全沒有版本塊的固定簽名反而是一堆看起來(lái)像代碼的字節(jié)。排查了半天發(fā)現(xiàn)是資源數(shù)據(jù)RVA落在了某個(gè)節(jié)的VirtualSize和RawSize不一致的區(qū)域。節(jié)表里VirtualAddress到VirtualAddressVirtualSize這段空間在文件里可能沒有對(duì)應(yīng)的原始數(shù)據(jù)因?yàn)榇疟P上不需要映射到那么大按公式映射到文件卻計(jì)算出了一個(gè)落在節(jié)尾Padding的偏移自然就讀錯(cuò)了。正確的排查方式是先確認(rèn)RVA落在哪個(gè)節(jié)再看這個(gè)節(jié)的RawSize是否覆蓋了目標(biāo)偏移最后才動(dòng)手讀數(shù)據(jù)。如果RVA落在VirtualSize內(nèi)但超出了RawSize范圍那這個(gè)資源在磁盤文件里本來(lái)就沒有對(duì)應(yīng)的原始字節(jié)必須放棄物理讀取或者按程序加載進(jìn)內(nèi)存后的狀態(tài)來(lái)分析。5.2 偏移基準(zhǔn)搞錯(cuò)從第二級(jí)目錄開始的陷阱資源目錄項(xiàng)的NameOffset、OffsetToData、OffsetToDirectory這三個(gè)偏移都以資源表基址為基準(zhǔn)而不是以當(dāng)前目錄為基準(zhǔn)。這個(gè)基準(zhǔn)問(wèn)題特別隱蔽因?yàn)榈谝患?jí)目錄的基址和資源表基址是同一個(gè)你按資源表基址偏移算出來(lái)的結(jié)果跟按當(dāng)前目錄基址偏移算出來(lái)的一樣于是你以為自己搞對(duì)了。到了第二級(jí)、第三級(jí)目錄不再是資源表基址了但那些偏移還是相對(duì)資源表基址的如果你還按當(dāng)前目錄去算就全亂了。我在文章前面反復(fù)強(qiáng)調(diào)這一點(diǎn)是因?yàn)樗褪切率肿钊菀族e(cuò)、又最難自查的地方。強(qiáng)烈建議你把每一級(jí)目錄的基址打印出來(lái)逐級(jí)手動(dòng)驗(yàn)證偏移務(wù)必確保每個(gè)子目錄和數(shù)據(jù)條目都是用同一個(gè)基準(zhǔn)算出來(lái)的。寫遞歸解析器時(shí)把base_offset作為參數(shù)一路傳下去不要在遞歸過(guò)程中隨意改基準(zhǔn)。5.3 對(duì)齊與Padding問(wèn)題資源數(shù)據(jù)存放在節(jié)內(nèi)部時(shí)一切都要遵守節(jié)的對(duì)齊規(guī)則。比如一個(gè)節(jié)的文件對(duì)齊是0x200資源數(shù)據(jù)從0x2C0開始那么下一個(gè)資源的文件偏移最也要對(duì)齊到0x400。在解析時(shí)DataEntry給出的Size是精確數(shù)據(jù)大小不包含Padding要讀取的就應(yīng)該是Size這么多字節(jié)而不是把節(jié)里后續(xù)的所有內(nèi)容都當(dāng)作資源的一部分。這個(gè)問(wèn)題在人工翻十六進(jìn)制時(shí)特別容易看走眼。資源數(shù)據(jù)后面經(jīng)常跟著一堆00那不是資源內(nèi)容是對(duì)齊Padding。有些資源本身以00結(jié)尾更難分辨Padding從哪開始。穩(wěn)妥的做法是嚴(yán)格按DataEntry里的Size字段截?cái)鄤e多讀。尤其在做哈希校驗(yàn)時(shí)多讀了Padding會(huì)導(dǎo)致哈希永遠(yuǎn)對(duì)不上白白浪費(fèi)時(shí)間排查。5.4 遞歸遍歷的終止條件資源樹的層級(jí)從設(shè)計(jì)上說(shuō)是類型、名稱、語(yǔ)言三層最多只能嵌套三層。但寫遞歸解析器時(shí)理想做法不是限制深度等于3而是根據(jù)目錄項(xiàng)的DataIsDirectory標(biāo)志來(lái)判斷——是子目錄就繼續(xù)遞歸是數(shù)據(jù)條目就讀取數(shù)據(jù)。這么寫的好處是能兼容那些不合規(guī)但實(shí)際存在的PE文件有些壓縮殼、混淆器會(huì)生成四層甚至五層嵌套的資源樹加載器照樣讀得動(dòng)限制死深度反而容易漏解析。同時(shí)要注意遞歸別寫成死循環(huán)。正常情況下子目錄偏移不會(huì)指向自己的祖先目錄但畸形文件里可能存在循環(huán)引用。穩(wěn)妥的解析器會(huì)維護(hù)一個(gè)訪問(wèn)過(guò)的目錄偏移集合發(fā)現(xiàn)重復(fù)就停下并報(bào)警。這既是工程健壯性也是安全考慮——一個(gè)惡意構(gòu)造的PE文件讓解析器陷入死循環(huán)是再簡(jiǎn)單不過(guò)的目的了。5.5 工具使用與人工驗(yàn)證的思路最后聊一點(diǎn)工具心得。CFF Explorer和010 Editor是我做PE解析時(shí)用得最多的工具一個(gè)負(fù)責(zé)快速看全貌一個(gè)負(fù)責(zé)深入摳字節(jié)。資源表解析這種活兒只用腳本不用工具驗(yàn)證跟只用工具不寫腳本都是走不遠(yuǎn)的。我的習(xí)慣流程是先讓腳本輸出資源樹和資源數(shù)據(jù)哈希再用CFF Explorer打開同一文件人工比對(duì)每一級(jí)條目的名稱和ID最后用Resource Hacker驗(yàn)證資源內(nèi)容是否正確。三次驗(yàn)證全都通過(guò)才敢確認(rèn)這個(gè)文件解析真沒問(wèn)題。這個(gè)流程看著繁瑣但對(duì)培養(yǎng)結(jié)構(gòu)直覺特別有用練多了之后你看一個(gè)十六進(jìn)制dump就能大概猜出資源表在哪一層、偏移基準(zhǔn)對(duì)不對(duì)。結(jié)尾一個(gè)持續(xù)有用的習(xí)慣資源表只是PE格式眾多結(jié)構(gòu)中的一塊拼圖但它的樹形設(shè)計(jì)、相對(duì)偏移機(jī)制、RVA轉(zhuǎn)換邏輯幾乎涵蓋了理解PE所需的全部核心思想。我自己當(dāng)年把資源表徹底吃透之后再回頭去看導(dǎo)入導(dǎo)出表、延遲加載、異常表這些結(jié)構(gòu)感覺都順了不少——因?yàn)樗鼈兊脑碓谫Y源表里都已經(jīng)出現(xiàn)過(guò)一遍了。最后分享一個(gè)我實(shí)際踩過(guò)的小技巧做解析實(shí)驗(yàn)時(shí)別只拿一個(gè)小工具測(cè)試經(jīng)常換不同的正常軟件去跑你會(huì)發(fā)現(xiàn)資源表的生活習(xí)慣千奇百怪。有的軟件資源樹里塞著幾百個(gè)名字全部是數(shù)字ID的條目有的軟件把自定義數(shù)據(jù)裸放在RT_RCDATA里不帶任何封裝有的軟件一個(gè)資源數(shù)據(jù)塊跨越了節(jié)區(qū)的邊界——這些都只有拿真實(shí)世界的文件去碰才能提前預(yù)習(xí)到。等你哪天閉著眼睛能把資源表的結(jié)構(gòu)畫出來(lái)、隨手寫出遞歸解析代碼那種感覺看十篇文章都換不來(lái)。