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