1. 為什么會(huì)想到用兩套工具鏈編譯同一個(gè)庫事情得從一次程序一致性分析說起。我手頭有一批從不同途徑收集到的Windows可執(zhí)行文件需要批量確認(rèn)它們之間的構(gòu)建來源差異找出哪些文件是同一套源碼編出來的哪些被改動(dòng)過。常規(guī)做法無非是比對(duì)文件哈希、檢查PE頭、看導(dǎo)入表和字符串但這類淺層特征很容易被有意或無意地混淆說服力有限。往深了走就得看調(diào)試信息——編譯器會(huì)把源文件路徑、編譯器版本、優(yōu)化級(jí)別、函數(shù)邊界甚至局部變量信息寫進(jìn)產(chǎn)物里這些細(xì)節(jié)很難偽造也最能反映一個(gè)二進(jìn)制從哪來、怎么編出來的。當(dāng)時(shí)我選擇的分析管線需要解析DWARF調(diào)試信息而手頭最順手的方案是編譯一個(gè)libdwarf庫嵌進(jìn)去。真正動(dòng)手之后才發(fā)現(xiàn)在Windows上編譯libdwarf并不是跑一遍CMake那么簡(jiǎn)單。我先后用MSYS2的MinGW-w64工具鏈和Visual Studio的原生工具鏈各自編了一遍結(jié)果兩個(gè)庫的行為表現(xiàn)出不少差異。跟蹤排查之后發(fā)現(xiàn)這些差異恰恰就是“程序一致性分析”最關(guān)心的那一類信息——不同工具鏈、不同運(yùn)行時(shí)、不同調(diào)試格式到底對(duì)最終二進(jìn)制產(chǎn)生了什么影響。這篇文章就把我踩過的坑和總結(jié)出的流程完整寫出來覆蓋兩套工具鏈的編譯細(xì)節(jié)、產(chǎn)物對(duì)比方法和容易翻車的坑。如果你也需要在Windows下做DWARF相關(guān)的工作或者想驗(yàn)證某個(gè)庫能否在多種工具鏈下保持行為一致這篇應(yīng)該能幫你省下不少折騰時(shí)間。1.1 程序一致性分析要解決的實(shí)際問題所謂程序一致性分析往大了說包括源碼級(jí)一致性、二進(jìn)制級(jí)一致性和運(yùn)行行為一致性三個(gè)層面。做審計(jì)和取證時(shí)最常見的問題是兩個(gè)名字不同、大小也不同的EXE底層是不是同一個(gè)程序某個(gè)二進(jìn)制是否由某一份泄露的源碼編譯而來發(fā)布版和測(cè)試版之間除了版本號(hào)還改了什么這些問題的回答路徑通常是分層的。第一層是計(jì)算文件哈希、比較PE節(jié)區(qū)特征第二層是解析導(dǎo)入導(dǎo)出表看外部依賴是否吻合第三層才輪到調(diào)試信息。前兩層只能回答“相似不相似”第三層才有機(jī)會(huì)回答“同源不同源”。因?yàn)榫幾g調(diào)試信息里保存的內(nèi)容比如源文件絕對(duì)路徑、具體到行號(hào)的行號(hào)表、每個(gè)編譯單元里的類型信息跟源碼和構(gòu)建環(huán)境幾乎是綁定的。只要構(gòu)建機(jī)器、源碼目錄、編譯器版本有一處不同得到的調(diào)試信息就會(huì)留下痕跡。libdwarf在這里扮演的角色就是把這些調(diào)試信息從二進(jìn)制里抽取出來組織成可以編程訪問的結(jié)構(gòu)。分析程序拿到這些結(jié)構(gòu)之后再和reference對(duì)象逐一比對(duì)。我的場(chǎng)景里需要一個(gè)能嵌入到自研工具中的解析庫不能每次都調(diào)外部命令行工具所以庫本身必須可控、可編譯、可裁剪。1.2 為什么選libdwarf做解析庫同類型庫里有幾個(gè)選擇要么直接調(diào)用系統(tǒng)的dwarfdump命令要么用libdw家族的實(shí)現(xiàn)要么用llvm的DWARF解析組件再要么就是libdwarf。我當(dāng)時(shí)做取舍的標(biāo)準(zhǔn)很實(shí)際體積小、依賴少、API穩(wěn)定、可嵌入。libdwarf基本符合全部條件源碼是純CGit倉庫里沒有一堆外部依賴CMake配置也比較簡(jiǎn)潔編譯出來之后無論是靜態(tài)庫還是動(dòng)態(tài)庫都方便集成。另外libdwarf的許可比較寬松適合放進(jìn)需要分發(fā)給別人的工具鏈里不用逼著使用者去處理傳染性授權(quán)問題。它雖然不像llvm系列那樣功能全面但對(duì)我的使用場(chǎng)景來說足夠了——解析編譯單元、讀取DIE樹、遍歷行號(hào)表、訪問字符串表這些核心能力都覆蓋到了。1.3 MSYS2和Visual Studio的定位差異MSYS2本質(zhì)上是一個(gè)在Windows上模擬Unix風(fēng)格環(huán)境的工具集它提供三套終端環(huán)境常用的是MSYS和MINGW64。在MINGW64環(huán)境里工具鏈?zhǔn)荕inGW-w64的GCC編譯器生成的是Windows原生PE格式的可執(zhí)行文件但它保留了Unix習(xí)慣的路徑風(fēng)格和shell命令。Visual Studio則完全不同它用MSVC編譯器生成COFF格式的目標(biāo)文件調(diào)試信息默認(rèn)走PDB和CodeView路徑。重點(diǎn)在于這兩套工具鏈編出來的同一個(gè)庫二進(jìn)制層面一定會(huì)不同這是預(yù)期內(nèi)的“程序不一致”。但我們希望解析行為一致、API兼容、語義一致。如果做到這一點(diǎn)就說明庫的跨工具鏈移植做得夠好反過來這樣的驗(yàn)證過程也無異于對(duì)庫本身的體檢。后面第五部分我會(huì)專門講怎么對(duì)比兩套產(chǎn)物的差異而不是直接看二進(jìn)制不一樣就下結(jié)論。2. libdwarf能做什么DWARF調(diào)試信息解析的底層邏輯在進(jìn)入編譯步驟之前我建議你先花十分鐘搞清楚DWARF信息到底躺在二進(jìn)制的哪里、怎么被解析出來。磨刀不誤砍柴工尤其是后面做一致性分析時(shí)如果你不理解“編譯單元”“DIE”這些概念對(duì)比結(jié)果對(duì)你來說就是一堆無意義的數(shù)字。2.1 DWARF和PE/ELF的關(guān)系DWARF最初是為ELF平臺(tái)設(shè)計(jì)的調(diào)試信息格式GCC和Clang在Linux上編譯時(shí)默認(rèn)會(huì)把調(diào)試信息寫進(jìn)目標(biāo)文件里專門以.debug開頭的節(jié)區(qū)比如.debug_info、.debug_line、.debug_abbrev、.debug_str等等。Windows上的PE文件沒有這些固定節(jié)區(qū)但MinGW-w64的GCC編譯器在生成Windows目標(biāo)文件的時(shí)候仍然會(huì)把調(diào)試信息以DWARF格式寫入PE文件的附加節(jié)區(qū)中。也就是說MSYS2里編出來的二進(jìn)制雖然文件容器是PE但內(nèi)部調(diào)試信息用的還是DWARF。Visual Studio的MSVC編譯器則不一樣它默認(rèn)的調(diào)試信息格式是CodeView存放位置在PDB文件里不直接嵌在PE的節(jié)區(qū)中。這一點(diǎn)必須一開始就記清楚用MSYS2編出來的libdwarf可以解析別的MSYS2程序里的DWARF節(jié)區(qū)但你要去解析一個(gè)用Visual Studio默認(rèn)配置編出來的EXE最大概率是什么都解析不到因?yàn)樗锩娓緵]有DWARF。做一致性分析時(shí)不能盲目套用解析器先看目標(biāo)二進(jìn)制到底帶沒帶目標(biāo)格式的調(diào)試信息。2.2 解析鏈路的四個(gè)階段初始化、編譯單元、DIE、屬性libdwarf的API設(shè)計(jì)是圍繞DWARF標(biāo)準(zhǔn)的數(shù)據(jù)結(jié)構(gòu)展開的。整個(gè)解析過程可以簡(jiǎn)化成四個(gè)階段。第一階段是初始化調(diào)用dwarf_init或dwarf_elf_init傳入文件描述符和DWARF處理選項(xiàng)得到Dwarf_Debug句柄。第二階段是遍歷編譯單元調(diào)用dwarf_next_cu_header遍歷到每個(gè)Compile Unit的開頭再調(diào)用dwarf_siblingof等函數(shù)在CU內(nèi)部游走。第三階段是讀取DIE每個(gè)編譯單元下面掛著一棵DIE樹函數(shù)、變量、類型、命名空間都以DIE節(jié)點(diǎn)存在。第四階段是解析屬性比如每個(gè)函數(shù)DIE可能帶低地址、高地址、名稱、源文件編號(hào)、行號(hào)等屬性。下面這段是我在實(shí)際分析工具里用的一個(gè)最小化解析片段作用就是遍歷所有編譯單元并統(tǒng)計(jì)DIE數(shù)量#include stdio.h #include libdwarf/dwarf.h #include libdwarf/libdwarf.h static void count_cu_dies(Dwarf_Debug dbg) { Dwarf_Unsigned cu_header_length; Dwarf_Half version_stamp; Dwarf_Unsigned abbrev_offset; Dwarf_Half address_size; Dwarf_Unsigned next_cu_header; Dwarf_Error err 0; int cu_count 0; int total_dies 0; while (dwarf_next_cu_header(dbg, cu_header_length, version_stamp, abbrev_offset, address_size, next_cu_header, err) DW_DLV_OK) { Dwarf_Die cu_die 0; int res dwarf_siblingof(dbg, NULL, cu_die, err); if (res ! DW_DLV_OK) { break; } cu_count; Dwarf_Die current cu_die; while (current ! 0) { total_dies; Dwarf_Die sibling 0; int const sres dwarf_siblingof(dbg, current, sibling, err); dwarf_dealloc(dbg, current, DW_DLA_DIE); current sibling; if (sres ! DW_DLV_OK) { break; } } cu_count; } printf(CU count: %d, DIE count: %d\n, cu_count, total_dies); }這段代碼省略了錯(cuò)誤處理細(xì)節(jié)但足以說明解析結(jié)構(gòu)并不復(fù)雜。一致性分析時(shí)我會(huì)記錄每個(gè)CUs的version_stamp、address_size、DIE總數(shù)和屬性分布這些數(shù)值直接進(jìn)對(duì)比報(bào)告。2.3 為什么跨工具鏈能檢驗(yàn)實(shí)現(xiàn)一致性DWARF標(biāo)準(zhǔn)雖然規(guī)定了數(shù)據(jù)格式但不同編譯器產(chǎn)出的DWARF信息會(huì)有“方言”差異。比如某些編譯器會(huì)為同一個(gè)類型生成多個(gè)重復(fù)的DIE某些編譯器對(duì)行號(hào)表的壓縮策略不一樣某些編譯器的路徑分隔符用的是反斜杠在Unix環(huán)境里則是斜杠。同一個(gè)解析庫如果面對(duì)GCC系的DWARF和MSVC系的調(diào)試信息都能正確工作說明它對(duì)標(biāo)準(zhǔn)之外的各種實(shí)現(xiàn)偏差處理得足夠健壯。反過來兩套工具鏈編出來的庫解析同一個(gè)GCC編譯出來的DWARF數(shù)據(jù)結(jié)果也應(yīng)該完全一致。如果結(jié)果不一致那就有意思了——這往往意味著其中一個(gè)庫的編譯配置有問題比如編譯時(shí)宏定義不同導(dǎo)致API行為分支被開啟。我在實(shí)際驗(yàn)證中就遇到過MSYS2環(huán)境下CMake默認(rèn)定義了LIBDWARF_STATIC宏VS環(huán)境里沒定義結(jié)果鏈接出來的庫一個(gè)走靜態(tài)符號(hào)一個(gè)是動(dòng)態(tài)導(dǎo)出符號(hào)解析外部輸入的DWARF文件時(shí)行為相似但用到回調(diào)函數(shù)時(shí)出現(xiàn)了偏差。這類問題不用兩套工具鏈交叉驗(yàn)證是根本測(cè)不出來的。3. MSYS2編譯libdwarf環(huán)境準(zhǔn)備與完整步驟我在MSYS2環(huán)境下的編譯流程相對(duì)順利但有幾個(gè)細(xì)節(jié)很值得注意如果你按網(wǎng)上的舊教程操作特別容易卡住。3.1 環(huán)境初始化選對(duì)終端是關(guān)鍵MSYS2安裝完成后開始菜單里會(huì)多出好幾個(gè)終端最常見的是“MSYS2 MSYS”和“MSYS2 MINGW64”兩個(gè)入口。很多人第一次用的時(shí)候順手點(diǎn)開MSYS終端安裝了一堆mingw-w64包結(jié)果編譯時(shí)怎么都不對(duì)。問題在于MSYS環(huán)境是模擬Unix的一層殼它跑的是POSIX工具鏈生成的程序依賴msys-2.0.dll之類的運(yùn)行時(shí)不適合作為Windows原生工具鏈。正確做法是安裝完MSYS2之后用“MSYS2 MINGW64”終端執(zhí)行pacman更新再安裝mingw-w64-x86_64工具鏈。執(zhí)行下面這幾條命令pacman -Syu pacman -S --needed base-devel mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake mingw-w64-x86_64-ninja這里有幾個(gè)包名非常容易拼錯(cuò)比如mingw-w64-x86_64-cmake和mingw-w64-x86_64-ninja不能漏掉前綴mingw-w64-x86_64。如果用系統(tǒng)自帶的分發(fā)包名安裝出來的很可能是MSYS環(huán)境下的工具不是Windows原生的。3.2 CMake配置階段最容易忽略的兩件事我第一次配置libdwarf時(shí)直接執(zhí)行了cmake ..結(jié)果CMake自動(dòng)選擇了Visual Studio生成器生成了一堆.sln文件然后在MINGW64的shell里根本沒法用ninja或make去編譯。原因在于MSYS2環(huán)境里同時(shí)能看到Windows系統(tǒng)上安裝的Visual Studio生成器CMake的生成器探測(cè)順序并不總是偏向MinGW。我建議明確指定生成器同時(shí)把構(gòu)建類型、安裝路徑都一次性配好。完整的配置命令如下cmake -G Ninja -DCMAKE_BUILD_TYPERelease -DCMAKE_INSTALL_PREFIX/opt/libdwarf-mingw -DBUILD_SHARED_LIBSON -DCMAKE_C_STANDARD99 ..這里我的考慮是-DBUILD_SHARED_LIBSON讓產(chǎn)物帶動(dòng)態(tài)庫方便后續(xù)做DLL導(dǎo)出現(xiàn)象對(duì)比如果不想要?jiǎng)討B(tài)庫改成OFF即可。CMAKE_C_STANDARD99是顯式告訴CMake使用C99標(biāo)準(zhǔn)避免某些編譯器和默認(rèn)標(biāo)準(zhǔn)不匹配導(dǎo)致源碼里的聲明被拒絕。還需要注意zlib依賴問題。libdwarf支持解析帶壓縮的調(diào)試信息比如.debug_compressed或者.zdebug節(jié)但需要zlib庫。MSYS2環(huán)境中直接安裝即可pacman -S mingw-w64-x86_64-zlib然后在CMake配置時(shí)加上-DDWARF_WITH_ZLIBON。如果跳過這一步后面遇到帶壓縮節(jié)的樣本文件時(shí)會(huì)直接報(bào)錯(cuò)。3.3 編譯與安裝驗(yàn)證配置完成之后執(zhí)行編譯安裝ninja ninja install產(chǎn)物會(huì)出現(xiàn)在/opt/libdwarf-mingw下。常規(guī)驗(yàn)證方式是編譯一個(gè)輔助程序或直接用附帶的dwarfdump工具讀一下某測(cè)試文件的調(diào)試信息確認(rèn)沒有加載和解析錯(cuò)誤。我一般還會(huì)額外寫一個(gè)小程序做冒煙測(cè)試邏輯比剛才的示例代碼更簡(jiǎn)單打開一個(gè)已知的帶調(diào)試信息的PE文件初始化庫循環(huán)讀取編譯單元打印每個(gè)CU的版本號(hào)和地址長(zhǎng)度。只要這段程序在MSYS2環(huán)境下能正確跑通庫的編譯就是基本合格的。額外提一句不要在MINGW64終端里直接跑到Windows原生cmd窗口里執(zhí)行ninja compile。雖然二進(jìn)制是一樣的但路徑風(fēng)格和動(dòng)態(tài)庫搜索方式會(huì)導(dǎo)致莫名其妙的加載失敗明明編出來了的DLL聲稱找不到。4. Visual Studio編譯libdwarf完全不同的坑Visual Studio環(huán)境下編譯坑比MSYS2多好幾個(gè)量級(jí)。不是MSVC編譯器不行而是這個(gè)庫的源碼從一開始就帶著濃郁的Unix/ELF基因到了MSVC的規(guī)則里處處需要將就。4.1 生成器選擇用CMake還是直接開VS工程VS環(huán)境下我推薦用CMake的Visual Studio生成器。如果你在VS的“開發(fā)者命令提示符”里配置CMake會(huì)自動(dòng)發(fā)現(xiàn)自己生成.sln文件然后用MSBuild編譯不用開IDE界面。具體步驟是以管理員身份打開“x64 Native Tools Command Prompt for VS”進(jìn)到源碼目錄執(zhí)行cmake -G Visual Studio 17 2022 -A x64 -DCMAKE_INSTALL_PREFIXC:\libdwarf-msvc -DBUILD_SHARED_LIBSON -DCMAKE_C_STANDARD99 .. cmake --build . --config Release cmake --install .這組命令的關(guān)鍵是-A x64強(qiáng)制目標(biāo)平臺(tái)為x64。如果不加CMake默認(rèn)按Win32來處理生成32位版本后面和MSYS2編的64位庫做對(duì)比時(shí)基礎(chǔ)都不一樣整篇分析就廢了。如果電腦上只用Build Tools沒有完整版VS生成器要改寫成“Visual Studio 17 2022”即使沒有安裝IDE也能用MSBuild編譯。4.2 隱藏的編譯開關(guān)幾個(gè)宏直接影響行為libdwarf在Windows下有幾個(gè)條件編譯開關(guān)最關(guān)鍵的坑出現(xiàn)在是否定義DWARF_DLL這個(gè)宏上。這個(gè)宏決定符號(hào)的導(dǎo)入導(dǎo)出方式如果打算編DLL需要在編譯libdwarf工程時(shí)讓它導(dǎo)出符號(hào)如果只是靜態(tài)庫就不要定義這個(gè)宏。問題來了——CMake在配置階段會(huì)根據(jù)BUILD_SHARED_LIBS自動(dòng)處理不同平臺(tái)的符號(hào)宏但MSVC平臺(tái)分支的處理和MinGW不完全一樣。我第一次直接用BUILD_SHARED_LIBSON配置結(jié)果編譯出來的DLL導(dǎo)出表竟然是空的導(dǎo)致應(yīng)用鏈接時(shí)一堆LNK2019。排查過程我放后面單獨(dú)說這里先給結(jié)論MSVC下務(wù)必確認(rèn)宏DLL_EXPORT和LIBDWARF_STATIC的組合狀態(tài)。我的建議是在CMake配置時(shí)打開CMAKE_VERBOSE_MAKEFILE并查看實(shí)際編譯命令確認(rèn)命令行里有沒有-DDLL_EXPORT。如果編出來DLL沒有導(dǎo)出表或者靜態(tài)庫里有明顯的導(dǎo)入導(dǎo)出修飾符沖突多半就是宏組合錯(cuò)了。4.3 MSVC下LNK2019/LNK2005的完整排查鏈路這是我在VS環(huán)境編譯時(shí)花費(fèi)時(shí)間最長(zhǎng)的一個(gè)坑。當(dāng)時(shí)現(xiàn)象編dwarfdump工具時(shí)鏈接器拋出一堆LNK2019說解析不到dwarf_init、dwarf_next_cu_header這些函數(shù)。第一次反應(yīng)是檢查是不是libdwarf.lib沒有正確鏈接。把lib路徑、附加依賴項(xiàng)都檢查了一遍幾個(gè)明顯問題不存在。于是加開了CMAKE_VERBOSE_MAKEFILE把鏈接具體命令打出來發(fā)現(xiàn)鏈接的是libdwarf.lib沒錯(cuò)但里面符號(hào)根本沒有導(dǎo)出。再用dumpbin去看庫的導(dǎo)出表發(fā)現(xiàn)壓根是空的。這就把猜測(cè)鎖定到了符號(hào)導(dǎo)出宏上?；氐皆创a搜索DLL_EXPORT的引用看到頭文件里的聲明邏輯大致是如果定義了DLL_EXPORT則聲明為__declspec(dllexport)如果定義了LIBDWARF_STATIC則不修飾否則聲明為__declspec(dllimport)。繼續(xù)追下去發(fā)現(xiàn)問題出在CMakeLists里對(duì)MSVC平臺(tái)下的-DLL_EXPORT定義依賴了一個(gè)變量而這個(gè)變量只在構(gòu)建目標(biāo)名匹配的時(shí)候才生效。我在生成解決方案時(shí)改了輸出名稱結(jié)果宏的定義條件沒被觸發(fā)。原因就是這么簡(jiǎn)單。最終解決方式是不依賴CMake的自動(dòng)推導(dǎo)直接顯式加上編譯選項(xiàng)cmake -G Visual Studio 17 2022 -A x64 -DCMAKE_INSTALL_PREFIXC:\libdwarf-msvc -DBUILD_SHARED_LIBSON -DCMAKE_C_FLAGS_RELEASE/DDLL_EXPORT ..重新生成工程后導(dǎo)出表正常了鏈接也過了。這個(gè)坑的核心經(jīng)驗(yàn)是Windows下DLL是否導(dǎo)出取決于編譯器命令行里有沒有定義導(dǎo)出宏這跟Linux下隱藏符號(hào)的默認(rèn)行為完全不同。4.4 VS下的調(diào)試信息選項(xiàng)順帶提一下VS環(huán)境下編譯出的libdwarf庫本身也會(huì)帶調(diào)試信息但默認(rèn)格式是PDB不是DWARF。因此后面做“兩套庫解析同一份dwarf文件”的對(duì)比雙方的差異不會(huì)體現(xiàn)在被解析的數(shù)據(jù)上而是體現(xiàn)在庫自身二進(jìn)制的調(diào)試信息格式上。如果你希望VS編出來的庫也帶DWARF格式調(diào)試信息可以嘗試Clang-cl工具鏈它不是MSVC但能插入VS環(huán)境。我試過用VS 2022附帶Clang的-compiler把生成器換成“Visual Studio 17 2022”并加上-DCMAKE_C_COMPILERclang-cl能編出帶DWARF節(jié)區(qū)的Windows二進(jìn)制。在一些更細(xì)粒度的一致性對(duì)比中這一步非常有用。5. 兩套產(chǎn)物的對(duì)比思路從二進(jìn)制到DWARF逐層拆解兩套工具鏈都編譯成功之后真正有意思的部分才剛開始。把兩套產(chǎn)物拿來做一致性對(duì)比不能只看文件是否一樣因?yàn)椴还茉趺凑{(diào)整編譯選項(xiàng)它們都不可能逐字節(jié)相同。站在程序一致性分析的角度我們想要的是“分層解釋差異”。5.1 文件層面對(duì)比差異是必然的關(guān)鍵是差異可否解釋我習(xí)慣先把兩套產(chǎn)物做一份客觀記錄包括文件大小、文件哈希、PE頭里時(shí)間戳、節(jié)區(qū)數(shù)量和節(jié)區(qū)名稱。拿到一組樣例數(shù)據(jù)時(shí)差異會(huì)非常明顯。對(duì)比項(xiàng)MSYS2 (MINGW64 GCC)Visual Studio (MSVC)文件大小約420KB約610KBSHA256不同不同PE節(jié)區(qū)數(shù)量4個(gè)常見節(jié)區(qū)5個(gè)以上常見節(jié)區(qū)節(jié)區(qū)名稱.text/.data/.rdata/.bss.text/.rdata/.data/.pdata/.gfids調(diào)試信息位置內(nèi)嵌DWARF節(jié)區(qū)獨(dú)立PDB文件鏈接器GNU ldMSVC link運(yùn)行時(shí)依賴msvcrt或ucrtbaseVCRUNTIME等看到這些差異不要慌。只要差異能對(duì)應(yīng)到工具鏈特征一致性分析就可以繼續(xù)往下推進(jìn)。比如節(jié)區(qū)名稱和數(shù)量變化是MSVC鏈接器添加了GFIDS和PDATA節(jié)區(qū)的結(jié)果調(diào)試信息位置不同是默認(rèn)調(diào)試格式差異的結(jié)果。這些都是可解釋差異說明兩個(gè)二進(jìn)制由不同工具鏈構(gòu)建但來源源碼可能是同一份。5.2 DWARF信息對(duì)比關(guān)注解析結(jié)果而非文件本身既然兩套庫都是用來解析DWARF的最核心的驗(yàn)證方式是讓它們?nèi)ソ馕鐾粋€(gè)測(cè)試PE文件再比較解析結(jié)果。這個(gè)測(cè)試PE文件需要同時(shí)具備內(nèi)嵌DWARF節(jié)區(qū)所以我用MSYS2的GCC編了一個(gè)帶-g選項(xiàng)的測(cè)試程序。解析結(jié)果對(duì)比我會(huì)記錄這些指標(biāo)編譯單元數(shù)量、DIE總數(shù)量、行號(hào)表?xiàng)l目數(shù)、每種屬性名稱的出現(xiàn)頻次、字符串表里的源文件路徑條目數(shù)。理論上兩套庫解析這些數(shù)據(jù)得到的結(jié)果應(yīng)該完全一致因?yàn)檩斎胂嗤WARF標(biāo)準(zhǔn)相同、解析邏輯也來自同一份源碼。我在實(shí)際測(cè)試中遇到過一個(gè)差異點(diǎn)MSYS2版庫解析出的某個(gè)函數(shù)DIE的訪問標(biāo)志屬性和VS版庫不同。排查后發(fā)現(xiàn)這不是庫的解析結(jié)果不同而是被解析的測(cè)試文件在編譯時(shí)出現(xiàn)了非確定性GCC在MSYS2環(huán)境里默認(rèn)對(duì)部分路徑做了大小寫折疊導(dǎo)致DWARF里記錄的路徑大小寫和另外一份樣本不同。由此可見一致性分析的對(duì)象數(shù)據(jù)質(zhì)量直接影響最后結(jié)論的可靠性。5.3 程序語義層面的判定思路二進(jìn)制對(duì)比和DWARF信息對(duì)比都只能說明“構(gòu)建特征”判斷“程序是不是同一個(gè)程序”還要考慮語義。一致性分析里最立得住的做法是把兩個(gè)二進(jìn)制分別做反匯編提取出函數(shù)級(jí)的控制流圖再比較控制流圖的結(jié)構(gòu)是否同構(gòu)。這一步可以用現(xiàn)成的反匯編庫或者直接導(dǎo)出為中間表示再做圖匹配。因?yàn)椴煌幾g器的指令調(diào)度差別很大直接用指令字節(jié)匹配幾乎不可行但控制流圖的結(jié)構(gòu)和基本塊的邏輯順序通常能保留到較高比例。如果在控制流圖層面都能匹配上再結(jié)合DWARF里源文件路徑的一致性基本可以認(rèn)定是同一份源碼在近似環(huán)境下編譯出來的。反之控制流圖差異很大但DWARF路徑一致就要考慮源碼中是否存在條件編譯分支或者編譯器優(yōu)化級(jí)別不同導(dǎo)致的結(jié)構(gòu)性改動(dòng)。6. 實(shí)操中容易翻車的幾個(gè)細(xì)節(jié)總結(jié)最后把幾個(gè)常規(guī)文檔里幾乎不會(huì)寫的坑集中整理一下做一次完整復(fù)盤。6.1 路徑風(fēng)格和編碼問題會(huì)污染對(duì)比結(jié)果MSYS2的GCC默認(rèn)編譯時(shí)會(huì)記錄Unix風(fēng)格路徑比如/usr/include/stdio.h。Visual Studio的MSVC記錄的是Windows風(fēng)格路徑比如C:\Program Files\Microsoft Visual Studio\2022...\include\stdio.h。當(dāng)你把兩套工具鏈編出的庫用于解析同一個(gè)測(cè)試文件時(shí)測(cè)試文件里記錄的源文件路徑來自編譯它的那個(gè)環(huán)境跟當(dāng)前解析庫的環(huán)境無關(guān)。但如果你拿兩套庫分別解析“它們各自編譯出來的測(cè)試程序”那結(jié)果里天然混入了路徑風(fēng)格的差異對(duì)比報(bào)告會(huì)被污染。我建議做對(duì)比解析實(shí)驗(yàn)時(shí)只讓兩套庫解析同一個(gè)第三方PE文件而不是各自編一個(gè)再互相解析。這樣能得到干凈的同輸入異解析器對(duì)照數(shù)據(jù)。6.2 分清DWARF、CodeView和PDB之間的邊界再做一次強(qiáng)調(diào)MSVC默認(rèn)的調(diào)試信息格式不是DWARF而是CodeView并把內(nèi)容輸出到PDB文件。只有當(dāng)MSVC配置了/Z7選項(xiàng)時(shí)才會(huì)把CodeView調(diào)試信息嵌進(jìn)目標(biāo)文件即使如此也不是DWARF。所以在Windows上做程序一致性分析必須事先定義好詞匯表用MSYS2工具鏈編的程序可以被libdwarf直接解析DWARF節(jié)區(qū)用VS工具鏈編的程序要分析調(diào)試信息多半得走PDB解析路線。這直接影響到分析工具的設(shè)計(jì)。我在自研工具里做了兩層調(diào)試信息提取先嘗試DWARF解析拿不到結(jié)果就轉(zhuǎn)PDB解析器。libdwarf只覆蓋了一半場(chǎng)景另一半需要額外的PDB解析邏輯。6.3 一組實(shí)測(cè)數(shù)據(jù)示例下面這組數(shù)據(jù)來自我本地用同一個(gè)小型測(cè)試程序分別在MSYS2和VS環(huán)境下編譯再用同一套內(nèi)嵌了libdwarf的分析器去解析的對(duì)比記錄。指標(biāo)MSYS2編譯的測(cè)試程序VS編譯的測(cè)試程序原始文件大小1.8MB2.6MB內(nèi)嵌DWARF節(jié)區(qū)有.debug_info等無PDB文件無有l(wèi)ibdwarf可解析CU數(shù)70解析耗時(shí)約30ms不可用反匯編函數(shù)數(shù)96118數(shù)字差異很大但每一條都能對(duì)應(yīng)到工具鏈的構(gòu)建策略差異。比如VS編譯的程序函數(shù)數(shù)更多是因?yàn)檎{(diào)試版里包含更多安全檢查和輔助樁函數(shù)這些函數(shù)在GCC的普通Release配置里會(huì)被優(yōu)化合并。這類數(shù)字的意義不在大小本身而是當(dāng)你面對(duì)一份陌生二進(jìn)制時(shí)這些特征能幫你反推它的構(gòu)建工具鏈和大致配置。這正是程序一致性分析在日常取證中最樸素也最實(shí)用的輸出。6.4 一個(gè)小技巧用CMake Preset統(tǒng)一管理雙工具鏈配置兩套工具鏈的配置命令冗長(zhǎng)我后來直接把它們固化進(jìn)CMakeUserPresets.json一鍵切換。感興趣的可以按下面結(jié)構(gòu)配置把源碼目錄下的工具鏈切換從五分鐘的手動(dòng)操作縮短到一條命令{ version: 3, configurePresets: [ { name: mingw, displayName: MSYS2 MINGW64, generator: Ninja, binaryDir: ${sourceDir}/build-mingw, cacheVariables: { CMAKE_BUILD_TYPE: Release, BUILD_SHARED_LIBS: ON, CMAKE_C_STANDARD: 99, DWARF_WITH_ZLIB: ON } }, { name: msvc, displayName: Visual Studio 17 2022, generator: Visual Studio 17 2022, binaryDir: ${sourceDir}/build-msvc, cacheVariables: { CMAKE_BUILD_TYPE: Release, BUILD_SHARED_LIBS: ON, CMAKE_C_STANDARD: 99, CMAKE_C_FLAGS_RELEASE: /DDLL_EXPORT } } ] }使用時(shí)分別執(zhí)行cmake --presetmingw和cmake --presetmsvc即可生成兩套工程互不干擾。這個(gè)做法我后來也用到了別的庫上對(duì)于任何需要在Windows下做跨工具鏈驗(yàn)證的項(xiàng)目都適用。最后再分享一點(diǎn)個(gè)人的體會(huì)編譯一個(gè)庫本身不算難難的是圍繞編譯配置建立一套可解釋的對(duì)比流程。MSYS2和VS的差異不是錯(cuò)誤它們只是從不同角度描述了同一個(gè)程序的構(gòu)建歷史。把這些差異一層層拆開并給出解釋程序一致性分析的價(jià)值才能真正落地。