每個(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)備啃資源表的新手也適合那些一直在用工具改資源卻從沒(méi)搞清楚它內(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)覺(jué)得目錄里直接裝數(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í)際幾乎沒(méi)有人往這里填東西解析時(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)備與工具選型紙上談兵沒(méi)意思直接拿一個(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[目錄](méi) 項(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)證特別適合排查那種明明感覺(jué)解析對(duì)了但數(shù)據(jù)內(nèi)容就是不對(duì)的奇怪問(wèn)題。比如Resource Hacker顯示的版本信息是正常的而我腳本dump出來(lái)的版本塊卻亂碼那十有八九是CodePage沒(méi)處理對(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ó)外軟件沒(méi)有國(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得到的是一塊沒(méi)法直接看的圖像數(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é)沒(méi)轉(zhuǎn)對(duì)結(jié)果都是定位錯(cuò)誤。舉個(gè)真實(shí)例子我調(diào)試某個(gè)程序時(shí)解析出來(lái)版本資源的大小是0x234但dump出來(lái)的數(shù)據(jù)開頭完全沒(méi)有版本塊的固定簽名反而是一堆看起來(lái)像代碼的字節(jié)。排查了半天發(fā)現(xiàn)是資源數(shù)據(jù)RVA落在了某個(gè)節(jié)的VirtualSize和RawSize不一致的區(qū)域。節(jié)表里VirtualAddress到VirtualAddressVirtualSize這段空間在文件里可能沒(méi)有對(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)就沒(mé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è)文件解析真沒(méi)問(wèn)題。這個(gè)流程看著繁瑣但對(duì)培養(yǎng)結(jié)構(gòu)直覺(jué)特別有用練多了之后你看一個(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)感覺(jué)都順了不少——因?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)、隨手寫出遞歸解析代碼那種感覺(jué)看十篇文章都換不來(lái)。