簡介一份從內(nèi)存直接加載并調(diào)用DLL導(dǎo)出函數(shù)的完整示例主要面向需要實(shí)現(xiàn)免落地加載、提升程序隱蔽性或希望在插件系統(tǒng)中動(dòng)態(tài)裝載模塊的Windows開發(fā)者。資源采用Visual C 6.0工程組織核心是MemoryModule實(shí)現(xiàn)封裝了MemoryLoadLibrary、MemoryGetProcAddress、MemoryFreeLibrary三個(gè)關(guān)鍵接口配套兩個(gè)工程xDll是僅用于測(cè)試的DLL導(dǎo)出若干函數(shù)供調(diào)用驗(yàn)證testLoadDll則演示如何將DLL作為資源嵌入自身在運(yùn)行時(shí)從內(nèi)存解析并調(diào)用導(dǎo)出函數(shù)。包內(nèi)共22個(gè)文件文件類型覆蓋C/C頭文件與源碼、編譯生成的DLL與LIB、VC工程文件以及文本說明整體僅87KB結(jié)構(gòu)緊湊便于對(duì)照學(xué)習(xí)。已有1500余人學(xué)習(xí)下載。仔細(xì)閱讀代碼可以梳理出內(nèi)存PE映像的映射步驟、導(dǎo)入表處理思路、函數(shù)地址查找機(jī)制和資源釋放順序適合具備一定PE結(jié)構(gòu)基礎(chǔ)、想深入理解DLL加載原理的讀者作為參考實(shí)現(xiàn)。1. 從內(nèi)存加載DLL是什么解決什么問題做 Windows 開發(fā)的兄弟多少都遇到過 DLL 加載失敗的問題?！癴ailed to load python dll”“找不到指定的模塊”“dll沖突”這些報(bào)錯(cuò)本質(zhì)都是系統(tǒng)加載器在文件系統(tǒng)里找不到依賴或者版本不匹配。而今天要聊的從內(nèi)存加載 DLL走的是和系統(tǒng)加載器完全不同的一條路——全程不把 DLL 寫到磁盤直接在進(jìn)程內(nèi)存里把 PE 結(jié)構(gòu)解析出來、映射好、修復(fù)好導(dǎo)入表和重定位然后像正常 LoadLibrary 一樣拿到 HMODULE 和函數(shù)地址。這種技術(shù)最常見的落地場景是插件系統(tǒng)、軟件熱更新和工具加載器。比如你寫了一個(gè)核心程序插件不落地釋放而是從加密包或網(wǎng)絡(luò)流里讀出來直接加載又或者是想在同一進(jìn)程里加載兩個(gè)同名但不同版本的 DLL系統(tǒng) LoadLibrary 會(huì)因?yàn)槲募麤_突直接翻車內(nèi)存加載則沒有這個(gè)限制。適合誰適合已經(jīng)理解了 PE 格式基礎(chǔ)想自己掌控 DLL 加載過程的開發(fā)者。它不挑語言但核心代碼必然要用 C/C 寫因?yàn)橐僮鞯氖?Windows 的進(jìn)程地址空間。2. 內(nèi)存加載 DLL 的原理PE 結(jié)構(gòu)與手動(dòng)映射2.1 為什么系統(tǒng) LoadLibrary 能加載內(nèi)存加載不行系統(tǒng)加載 DLL 時(shí)Windows 內(nèi)核的加載器會(huì)做一系列操作讀取文件頭、分配內(nèi)存、把各個(gè)節(jié)區(qū)從磁盤偏移拷貝到虛擬地址、處理重定位、解析導(dǎo)入表、執(zhí)行 TLS 回調(diào)最后調(diào)用 DllMain。這個(gè)過程對(duì)開發(fā)者是黑匣子LoadLibrary 一句就完事。但內(nèi)存加載沒有這個(gè)黑匣子可用因?yàn)榧虞d器的輸入是文件路徑它只認(rèn)文件系統(tǒng)。如果你手里只有一個(gè)內(nèi)存緩沖區(qū)想讓系統(tǒng)加載器去讀是不可能的。所以我們要自己按照 PE 規(guī)范把整個(gè)流程重寫一遍從緩沖區(qū)里解析出 DOS 頭、NT 頭、節(jié)區(qū)表然后分配一塊內(nèi)存把 DLL 的鏡像按節(jié)區(qū)擺放好再手動(dòng)修復(fù)重定位和導(dǎo)入表。聽起來不難但細(xì)節(jié)非常多。PE 格式在磁盤上的布局和加載到內(nèi)存后的布局不一樣。磁盤上節(jié)區(qū)是按文件偏移對(duì)齊的內(nèi)存里是按頁對(duì)齊的。比如 .text 節(jié)在磁盤上的偏移可能是 0x200但在內(nèi)存里的虛擬地址是 0x1000。手動(dòng)映射的時(shí)候不能整個(gè)文件 memcpy必須一個(gè)節(jié)一個(gè)節(jié)按 VirtualAddress 拷貝。2.2 手動(dòng)映射的 6 個(gè)關(guān)鍵步驟內(nèi)存加載 DLL 的流程可以拆成六步每一部都不能跳步驟動(dòng)作說明1校驗(yàn) DOS 頭與 NT 頭確認(rèn)緩沖區(qū)里真的是一個(gè)合法的 PE 文件2分配鏡像內(nèi)存用 VirtualAlloc 分配 SizeOfImage 大小的空間權(quán)限先給讀寫3按節(jié)區(qū)拷貝數(shù)據(jù)把每個(gè)節(jié)從磁盤偏移拷貝到 image VirtualAddress4修復(fù)重定位表加載地址和首選基址不一致時(shí)把所有絕對(duì)地址加上 Delta5修復(fù)導(dǎo)入表遍歷導(dǎo)入描述符用 LoadLibrary 加載依賴 DLL用 GetProcAddress 填 IAT6執(zhí)行入口函數(shù)先執(zhí)行 TLS 回調(diào)再調(diào)用 DllMain 的 DLL_PROCESS_ATTACH這六步里最容易做錯(cuò)的是第 4 步和第 5 步的邊界處理。后面我會(huì)用完整代碼說明先牢記一個(gè)原則每個(gè)步驟的輸入輸出都要基于“內(nèi)存鏡像地址”而不是原始文件地址。2.3 內(nèi)存分配為什么不直接用 malloc很多人第一次寫內(nèi)存加載器會(huì)直接用 malloc 分配一塊內(nèi)存來裝 DLL。結(jié)果調(diào)用導(dǎo)出函數(shù)時(shí)直接 Access Violation。原因很簡單malloc 分配的內(nèi)存默認(rèn)是不可執(zhí)行的而且沒有按頁對(duì)齊到適合 PE 加載的邊界。正確做法是使用 VirtualAlloc并指定 MEM_COMMIT | MEM_RESERVE。這樣分配的地址空間由你自己控制頁權(quán)限。開始先給 PAGE_READWRITE因?yàn)楹竺嫘迯?fù)導(dǎo)入表和重定位要寫內(nèi)存等全部修復(fù)完之后再通過 VirtualProtect 把 .text 節(jié)改成 PAGE_EXECUTE_READ把 .data 節(jié)改成 PAGE_READWRITE。這一步常被省略省略的后果就是 DLL 里的靜態(tài)變量一旦寫入就報(bào)錯(cuò)。這里還有一個(gè)選型細(xì)節(jié)分配鏡像內(nèi)存時(shí)常見做法是用 VirtualAlloc(NULL, SizeOfImage, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)。不要用 MAPV11 這類 API也不要自己指定固定地址因?yàn)檫M(jìn)程地址空間碎片化后固定地址可能分配失敗。3. 完整代碼實(shí)現(xiàn)從內(nèi)存加載 DLL 的 Loader3.1 數(shù)據(jù)結(jié)構(gòu)與輔助函數(shù)先定義一個(gè)上下文結(jié)構(gòu)用來跟蹤加載狀態(tài)比如是否已經(jīng)調(diào)用過 DllMain這樣卸載時(shí)能避免重復(fù)通知。#include windows.h #include winnt.h #include stdio.h typedef struct _MEMORY_DLL { BYTE* pImageBase; // 內(nèi)存鏡像基址 BOOL bDllMainCalled; // 是否已調(diào)用過 DllMain } MEMORY_DLL; // 計(jì)算兩個(gè)值的較小者 #ifndef MIN #define MIN(a, b) (((a) (b)) ? (a) : (b)) #endif輔助函數(shù)IsValidPeFile用來校驗(yàn)緩沖區(qū)里的 PE 文件是否合法。注意計(jì)算e_lfanew后要檢查是否超出緩沖區(qū)長度防止越界讀取。BOOL IsValidPeFile(const BYTE* pData, SIZE_T nSize) { if (pData NULL || nSize sizeof(IMAGE_DOS_HEADER)) return FALSE; IMAGE_DOS_HEADER* pDos (IMAGE_DOS_HEADER*)pData; if (pDos-e_magic ! IMAGE_DOS_SIGNATURE) return FALSE; if (pDos-e_lfanew 0 || pDos-e_lfanew sizeof(IMAGE_NT_HEADERS) nSize) return FALSE; IMAGE_NT_HEADERS* pNt (IMAGE_NT_HEADERS*)(pData pDos-e_lfanew); if (pNt-Signature ! IMAGE_NT_SIGNATURE) return FALSE; return TRUE; }這里的參數(shù)說明pData是 DLL 文件的字節(jié)數(shù)組nSize是數(shù)組長度。很多內(nèi)存加載失敗都是因?yàn)橹粋髁酥羔槢]傳長度導(dǎo)致后面訪問節(jié)區(qū)表時(shí)越界。所以函數(shù)簽名一定要帶 size。3.2 核心函數(shù) MemoryLoadLibrary下面是完整的內(nèi)存加載函數(shù)。這個(gè)版本以 32 位 DLL 為例64 位 DLL 需要把IMAGE_NT_HEADERS換成IMAGE_NT_HEADERS64重定位項(xiàng)類型也要改成ULONGLONG。HMODULE MemoryLoadLibrary(const BYTE* pData, SIZE_T nSize) { if (!IsValidPeFile(pData, nSize)) return NULL; IMAGE_DOS_HEADER* pDos (IMAGE_DOS_HEADER*)pData; IMAGE_NT_HEADERS* pNt (IMAGE_NT_HEADERS*)(pData pDos-e_lfanew); // 1. 分配鏡像內(nèi)存先用讀寫權(quán)限后面修復(fù)完再改 BYTE* pImageBase (BYTE*)VirtualAlloc(NULL, pNt-OptionalHeader.SizeOfImage, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); if (pImageBase NULL) return NULL; // 2. 拷貝文件頭包括DOS頭、NT頭、節(jié)區(qū)表 memcpy(pImageBase, pData, pNt-OptionalHeader.SizeOfHeaders); // 3. 按節(jié)區(qū)表逐個(gè)拷貝節(jié)數(shù)據(jù) IMAGE_SECTION_HEADER* pSec (IMAGE_SECTION_HEADER*)( (BYTE*)pNt sizeof(IMAGE_NT_HEADERS)); for (DWORD i 0; i pNt-FileHeader.NumberOfSections; i, pSec) { if (pSec-SizeOfRawData 0) { memcpy(pImageBase pSec-VirtualAddress, pData pSec-PointerToRawData, MIN(pSec-SizeOfRawData, pSec-Misc.VirtualSize)); } } // 4. 計(jì)算重定位Delta ULONG_PTR delta (ULONG_PTR)pImageBase - pNt-OptionalHeader.ImageBase; // 5. 修復(fù)導(dǎo)入表 if (pNt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress ! 0) { PIMAGE_IMPORT_DESCRIPTOR pImp (PIMAGE_IMPORT_DESCRIPTOR)( pImageBase pNt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress); for (; pImp-Name ! 0; pImp) { char* pDllName (char*)(pImageBase pImp-Name); HMODULE hDep LoadLibraryA(pDllName); if (hDep NULL) { // 依賴DLL加載失敗這里可以記錄日志但不中斷 continue; } PIMAGE_THUNK_DATA pOrigThunk (PIMAGE_THUNK_DATA)( pImageBase pImp-OriginalFirstThunk); PIMAGE_THUNK_DATA pThunk (PIMAGE_THUNK_DATA)( pImageBase pImp-FirstThunk); // 某些鏈接器不生成OriginalFirstThunk此時(shí)直接用FirstThunk if (pOrigThunk NULL) pOrigThunk pThunk; for (; pOrigThunk-u1.AddressOfData ! 0; pOrigThunk, pThunk) { if (IMAGE_SNAP_BY_ORDINAL(pOrigThunk-u1.Ordinal)) { pThunk-u1.Function (ULONG_PTR)GetProcAddress(hDep, (LPCSTR)IMAGE_ORDINAL(pOrigThunk-u1.Ordinal)); } else { PIMAGE_IMPORT_BY_NAME pName (PIMAGE_IMPORT_BY_NAME)( pImageBase pOrigThunk-u1.AddressOfData); pThunk-u1.Function (ULONG_PTR)GetProcAddress(hDep, pName-Name); } } } } // 6. 修復(fù)重定位表僅當(dāng)delta非0 if (delta ! 0) { if (pNt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress ! 0) { PIMAGE_BASE_RELOCATION pReloc (PIMAGE_BASE_RELOCATION)( pImageBase pNt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress); while (pReloc-VirtualAddress ! 0) { DWORD count (pReloc-SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD); WORD* pItems (WORD*)((BYTE*)pReloc sizeof(IMAGE_BASE_RELOCATION)); for (DWORD j 0; j count; j) { if ((pItems[j] 0x3000) 0x3000) { // IMAGE_REL_BASED_HIGHLOW ULONG_PTR* pAddr (ULONG_PTR*)( pImageBase pReloc-VirtualAddress (pItems[j] 0x0FFF)); *pAddr delta; } } pReloc (PIMAGE_BASE_RELOCATION)((BYTE*)pReloc pReloc-SizeOfBlock); } } } // 7. 設(shè)置節(jié)區(qū)內(nèi)存權(quán)限 pSec (IMAGE_SECTION_HEADER*)((BYTE*)pNt sizeof(IMAGE_NT_HEADERS)); for (DWORD i 0; i pNt-FileHeader.NumberOfSections; i, pSec) { DWORD protect PAGE_READONLY; if (pSec-Characteristics IMAGE_SCN_MEM_WRITE) protect PAGE_READWRITE; if (pSec-Characteristics IMAGE_SCN_MEM_EXECUTE) protect PAGE_EXECUTE_READ; DWORD oldProtect 0; VirtualProtect(pImageBase pSec-VirtualAddress, pSec-Misc.VirtualSize, protect, oldProtect); } // 8. 調(diào)用DllMain(DLL_PROCESS_ATTACH) MEMORY_DLL* pCtx (MEMORY_DLL*)malloc(sizeof(MEMORY_DLL)); pCtx-pImageBase pImageBase; pCtx-bDllMainCalled FALSE; if (pNt-OptionalHeader.AddressOfEntryPoint ! 0) { typedef BOOL (WINAPI *DllMainProc)(HMODULE, DWORD, LPVOID); DllMainProc pDllMain (DllMainProc)( pImageBase pNt-OptionalHeader.AddressOfEntryPoint); BOOL ret pDllMain((HMODULE)pImageBase, DLL_PROCESS_ATTACH, NULL); if (!ret) { VirtualFree(pImageBase, 0, MEM_RELEASE); free(pCtx); return NULL; } pCtx-bDllMainCalled TRUE; } // 這里返回HMODULE但實(shí)際上要把pCtx保存下來才能正確釋放 // 常見的做法是用靜態(tài)表保存指針 return (HMODULE)pImageBase; }代碼邏輯說明第 1 步分配的內(nèi)存是整塊連續(xù)的大小等于SizeOfImage。這個(gè)值在 PE 文件里已經(jīng)算好了包含了所有節(jié)的虛擬大小對(duì)齊后的總和。第 3 步拷貝節(jié)區(qū)時(shí)VirtualAddress是這個(gè)節(jié)在內(nèi)存中的偏移PointerToRawData是文件中的偏移。注意拷貝長度用MIN(SizeOfRawData, VirtualSize)因?yàn)樽詈笠粋€(gè)節(jié)的文件數(shù)據(jù)可能比虛擬大小小多出的部分應(yīng)該零填充這里簡單的 memcpy 沒有清零如果你需要嚴(yán)謹(jǐn)應(yīng)該對(duì)不足部分用memset補(bǔ)零。導(dǎo)入表修復(fù)時(shí)OriginalFirstThunk是導(dǎo)入名稱表INTFirstThunk是導(dǎo)入地址表IAT。有些鏈接器會(huì)把兩個(gè)字段設(shè)為相同所以必須處理pOrigThunk NULL的情況。這里的邏輯和系統(tǒng) LoadLibrary 加載時(shí)的做法一致只是我們把 LoadLibrary 換成自己調(diào)用。重定位修復(fù)只處理了 32 位的 HIGHLOW 類型。64 位 DLL 還需要處理IMAGE_REL_BASED_DIR64類型判斷條件變成pItems[j] 0xF000 0xA000。如果你要支持 64 位把重定位分支補(bǔ)充一下。3.3 調(diào)用示例與釋放函數(shù)從磁盤讀文件到內(nèi)存然后調(diào)用MemoryLoadLibrary的示例BOOL LoadDllFromFile(const char* path) { HANDLE hFile CreateFileA(path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (hFile INVALID_HANDLE_VALUE) return FALSE; DWORD fileSize GetFileSize(hFile, NULL); BYTE* pBuffer (BYTE*)malloc(fileSize); DWORD bytesRead 0; ReadFile(hFile, pBuffer, fileSize, bytesRead, NULL); CloseHandle(hFile); HMODULE hMem MemoryLoadLibrary(pBuffer, fileSize); free(pBuffer); return hMem ! NULL; }對(duì)應(yīng)釋放函數(shù)MemoryFreeLibraryvoid MemoryFreeLibrary(HMODULE hModule, MEMORY_DLL* pCtx) { if (hModule NULL) return; if (pCtx pCtx-bDllMainCalled) { typedef BOOL (WINAPI *DllMainProc)(HMODULE, DWORD, LPVOID); DllMainProc pDllMain (DllMainProc)( (BYTE*)hModule pCtx-pImageBase); // 這里要有入口偏移實(shí)際應(yīng)從PE頭讀取 pDllMain(hModule, DLL_PROCESS_DETACH, NULL); pCtx-bDllMainCalled FALSE; } VirtualFree(hModule, 0, MEM_RELEASE); free(pCtx); }需要注意的是上面MemoryLoadLibrary返回的只是基址釋放時(shí)需要拿到入口點(diǎn)地址。常見做法是把MEMORY_DLL上下文放到一個(gè)全局鏈表中用基址做 key。為了簡潔示例里直接用靜態(tài)變量保存入口偏移。真正工程化時(shí)建議寫一個(gè)AddToGlobalList和FindFromGlobalList管理多個(gè)內(nèi)存 DLL。4. 依賴處理導(dǎo)入表、重定位與 TLS 回調(diào)4.1 導(dǎo)入表修復(fù)LoadLibrary 加 GetProcAddress 的配合導(dǎo)入表是內(nèi)存加載 DLL 的重災(zāi)區(qū)。很多朋友在執(zhí)行導(dǎo)出函數(shù)時(shí)崩潰用調(diào)試器一看停在call dword ptr [xxx]上這個(gè)地址指向的是一塊無效內(nèi)存。原因就是導(dǎo)入表沒有被正確填充。修復(fù)流程說簡單也簡單對(duì)于每個(gè)導(dǎo)入描述符先用LoadLibraryA把依賴的 DLL 加載到進(jìn)程里然后遍歷該描述符對(duì)應(yīng)的函數(shù)名稱列表用GetProcAddress找到函數(shù)地址寫回到 IAT 中。但有幾個(gè)坑第一依賴 DLL 自身的依賴也要被遞歸加載不過LoadLibraryA會(huì)自己處理不用你操心第二如果依賴 DLL 找不到別急著返回 NULL先記錄錯(cuò)誤然后嘗試?yán)^續(xù)修復(fù)其他依賴最后通過一個(gè)總開關(guān)判斷是否成功第三有些 DLL 使用延遲加載也就是函數(shù)第一次調(diào)用時(shí)才加載這種在導(dǎo)入表里沒有記錄需要額外處理延遲加載描述符。// 修復(fù)延遲導(dǎo)入表的簡化邏輯 // 需要遍歷 DirectoryEntryDelayImport延遲導(dǎo)入的修復(fù)方式和普通導(dǎo)入類似但函數(shù)地址要寫成ImgpDelayLoad的 thunk。做法是在每個(gè)延遲導(dǎo)入項(xiàng)的函數(shù)地址上放一個(gè)跳板。因?yàn)檫壿嫳容^復(fù)雜一般工具庫都選擇不支持延遲加載遇到就報(bào)錯(cuò)。我的建議是如果你的業(yè)務(wù) DLL 用了/DELAYLOAD在打包階段把延遲加載關(guān)掉改用普通靜態(tài)導(dǎo)入。4.2 重定位表修復(fù)的原理與邊界重定位的作用是修正代碼里的絕對(duì)地址。DLL 編譯時(shí)默認(rèn)的ImageBase通常是0x10000000但加載到進(jìn)程后沒人保證這個(gè)地址空閑。系統(tǒng)加載器選擇占用其他地址時(shí)就必須把代碼里所有寫死的絕對(duì)地址都加上一個(gè)差值 delta。重定位表的結(jié)構(gòu)是以IMAGE_BASE_RELOCATION為頭每個(gè)塊描述一個(gè) 4KB 頁內(nèi)的偏移項(xiàng)。VirtualAddress是頁起始地址SizeOfBlock是整個(gè)塊的大小。項(xiàng)數(shù)據(jù)是 16 位的高 4 位是類型低 12 位是頁內(nèi)偏移。32 位 DLL 最常見的類型是IMAGE_REL_BASED_HIGHLOW0x3需要把偏移處的 32 位值加上 delta。邊界坑有兩個(gè)。第一個(gè)是重定位塊的長度可能覆蓋到下一頁所以遍歷時(shí)必須用SizeOfBlock移動(dòng)指針不能用自增。第二個(gè)是有些 DLL 編譯時(shí)不生成重定位表VirtualAddress為 0此時(shí)如果 delta 不為 0直接跳過即可不能因此認(rèn)定加載失敗。實(shí)際上不生成重定位表的 DLL 只能在首選基址上運(yùn)行這種 DLL 不適合內(nèi)存加載。// 處理64位重定位 if ((pItems[j] 0xF000) IMAGE_REL_BASED_DIR64) { ULONGLONG* pAddr (ULONGLONG*)(pImageBase pReloc-VirtualAddress (pItems[j] 0x0FFF)); *pAddr (LONGLONG)delta; }4.3 TLS 回調(diào)和 DLL_PROCESS_ATTACH 的執(zhí)行順序TLS線程局部存儲(chǔ)回調(diào)在 DllMain 之前執(zhí)行用于初始化每個(gè)線程的 TLS 槽。內(nèi)存加載時(shí)必須手動(dòng)找到 TLS 目錄然后依次調(diào)用回調(diào)函數(shù)。順序不對(duì)會(huì)導(dǎo)致在線程里訪問 TLS 變量時(shí)拿到垃圾值。PIMAGE_TLS_DIRECTORY pTls (PIMAGE_TLS_DIRECTORY)( pImageBase pNt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS].VirtualAddress); if (pTls ! NULL pTls-AddressOfCallBacks ! 0) { PIMAGE_TLS_CALLBACK* pCallback (PIMAGE_TLS_CALLBACK*)( pImageBase (ULONG_PTR)pTls-AddressOfCallBacks); while (*pCallback ! NULL) { (*pCallback)((HMODULE)pImageBase, DLL_PROCESS_ATTACH, NULL); pCallback; } }注意TLS 目錄中的AddressOfCallBacks是一個(gè) RVA但由于 TLS 回調(diào)指針本身可能是絕對(duì)地址這里需要根據(jù)指針大小做轉(zhuǎn)換。上面的代碼在 32 位下通常沒問題但嚴(yán)謹(jǐn)做法是用(ULONG_PTR)pTls-AddressOfCallBacks作為 RVA再轉(zhuǎn)換成 VA。這個(gè)細(xì)節(jié)很多開源實(shí)現(xiàn)都會(huì)踩。DLL_PROCESS_ATTACH 的調(diào)用時(shí)機(jī)和系統(tǒng) LoadLibrary 不同系統(tǒng)加載器先設(shè)置好所有節(jié)區(qū)權(quán)限再執(zhí)行回調(diào)我們也應(yīng)該先做 VirtualProtect再執(zhí)行 TLS 回調(diào)最后調(diào)用 DllMain。反過來會(huì)出現(xiàn)什么如果 DllMain 里寫了全局變量而 .data 節(jié)還沒拿到寫權(quán)限直接崩潰。5. 踩坑指南常見崩潰場景與排查方法5.1 一調(diào)導(dǎo)出函數(shù)就崩潰原因是導(dǎo)入表沒修現(xiàn)象加載成功后動(dòng)態(tài)獲取導(dǎo)出函數(shù)地址調(diào)用時(shí)進(jìn)程直接報(bào)錯(cuò)“訪問沖突”。原因最常見的是內(nèi)存加載時(shí)跳過了導(dǎo)入表修復(fù)的OriginalFirstThunk為 0 的情況。某些編譯選項(xiàng)下PE 文件里沒有 INT 字段只有 IAT。網(wǎng)上很多示例代碼只處理OriginalFirstThunk遇到這種情況直接忽略了整個(gè)導(dǎo)入表導(dǎo)致 IAT 一直是 0。調(diào)用導(dǎo)出函數(shù)時(shí)指令跳到一個(gè)空指針上。解決參照前面代碼當(dāng)pOrigThunk NULL時(shí)把pThunk當(dāng)作名稱列表使用。同時(shí)建議你在加載后、調(diào)用導(dǎo)出函數(shù)前寫一個(gè)自檢函數(shù)遍歷導(dǎo)出表把每個(gè)導(dǎo)出函數(shù)的 IAT 項(xiàng)都打印出來看哪些是 0。// 自檢遍歷導(dǎo)出表并測(cè)試調(diào)用 void DebugDumpExports(HMODULE hMod) { PIMAGE_DOS_HEADER pDos (PIMAGE_DOS_HEADER)hMod; PIMAGE_NT_HEADERS pNt (PIMAGE_NT_HEADERS)((BYTE*)hMod pDos-e_lfanew); PIMAGE_EXPORT_DIRECTORY pExp (PIMAGE_EXPORT_DIRECTORY)( (BYTE*)hMod pNt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress); DWORD* pFuncs (DWORD*)((BYTE*)hMod pExp-AddressOfFunctions); for (DWORD i 0; i pExp-NumberOfFunctions; i) { if (pFuncs[i] 0) continue; char* pName NULL; // 按序號(hào)或名稱取函數(shù)名 printf(Export %d at %p\n, i, (BYTE*)hMod pFuncs[i]); } }5.2 全局變量值不對(duì)是重定位沒修現(xiàn)象DLL 里的靜態(tài)計(jì)數(shù)器每次調(diào)用都復(fù)位或者某個(gè)全局配置讀出來是亂碼。原因DLL 編譯時(shí)所有的全局變量地址都基于ImageBase。你沒做重定位修復(fù)代碼里引用全局變量的指令還在用老地址訪問的只是進(jìn)程地址空間里的垃圾數(shù)據(jù)。這種情況在 Visual Studio 調(diào)試配置下偶爾看不出來因?yàn)檎{(diào)試器會(huì)把 DLL 加載到首選基址附近但 Release 下隨機(jī)地址一分配必現(xiàn)。解決在調(diào)用 DllMain 前先驗(yàn)證 delta 和重定位表的存在。最直接的辦法是寫一個(gè)調(diào)試輸出打印delta的值如果非 0 且重定位表中沒有對(duì)應(yīng)條目就要懷疑 DLL 編譯時(shí)關(guān)閉了重定位生成選項(xiàng)。// 檢查重定位表是否為空 BOOL HasBaseReloc(IMAGE_NT_HEADERS* pNt) { DWORD va pNt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress; return va ! 0; }5.3 節(jié)區(qū)權(quán)限沒設(shè)置導(dǎo)致寫入全局變量時(shí)崩潰現(xiàn)象導(dǎo)出的函數(shù)第一次調(diào)用能過第二次執(zhí)行到某個(gè)靜態(tài)變量寫入就“未處理的異?！?。原因內(nèi)存加載初期整個(gè)鏡像被設(shè)置為 PAGE_READWRITE。如果你在修復(fù)完導(dǎo)入和重定位后忘了調(diào)用 VirtualProtect 修改 .text 節(jié)為可執(zhí)行那么代碼讀取沒問題一旦代碼嘗試寫 .data 節(jié)而 .data 節(jié)依然是只讀權(quán)限就會(huì)觸發(fā)異常。反之如果整塊內(nèi)存一直保持 PAGE_READWRITE那么符合“可寫可讀不可執(zhí)行”的安全策略但很多 CPU 下 Page 被標(biāo)記為 NX代碼一運(yùn)行就崩。解決嚴(yán)格按每個(gè)節(jié)區(qū)的Characteristics設(shè)置權(quán)限。項(xiàng)目發(fā)布前做一遍全函數(shù)回歸尤其是帶字符串字面量、全局開關(guān)的函數(shù)。有一個(gè)玄學(xué)現(xiàn)象有些機(jī)器上 PAGE_READWRITE 也能執(zhí)行是因?yàn)殚_了兼容模式。別依賴這個(gè)該設(shè)就設(shè)。5.4 依賴 DLL 搜索路徑不一致提示找不到模塊現(xiàn)象內(nèi)存加載時(shí)調(diào)用LoadLibraryA(dep.dll)失敗然后在系統(tǒng)里看到了“failed to load python dll”這樣的報(bào)錯(cuò)。原因系統(tǒng) LoadLibrary 搜索路徑包括應(yīng)用程序目錄、系統(tǒng)目錄、PATH 環(huán)境變量等但你的程序可能設(shè)置了 CWD當(dāng)前工作目錄或者 DLL 自帶 QIP 資源里指定了某個(gè)路徑。內(nèi)存加載器把解析依賴 DLL 的任務(wù)交給了 LoadLibrary而 LoadLibrary 自己也有搜索順序兩者如果不一致就會(huì)找不到。解決在加載前調(diào)用SetDllDirectory或AddDllDirectory把依賴 DLL 所在的目錄手動(dòng)加進(jìn)去。更穩(wěn)妥的做法是自己在內(nèi)存加載器里維護(hù)一張依賴映射表先嘗試從內(nèi)存緩存加載已經(jīng)讀進(jìn)來過的 DLL再 fallback 到 LoadLibrary。這種方式能解決同名不同版本的 dll 沖突問題也是內(nèi)存加載相對(duì)系統(tǒng)加載器的一大優(yōu)勢(shì)。// 常見做法加載前把依賴目錄加入搜索鏈 SetDllDirectoryA(C:\\libs\\my_deps);5.5 卸載時(shí)反復(fù)崩潰是 DllMain 通知次數(shù)沒管理好現(xiàn)象調(diào)用了VirtualFree釋放鏡像內(nèi)存但后續(xù)其他模塊再申請(qǐng)內(nèi)存時(shí)地址沖突或者程序退出時(shí)崩潰在某個(gè) DllMain 回調(diào)里。原因我們手動(dòng)調(diào)用了 DLL_PROCESS_DETACH但 DllMain 內(nèi)部可能注冊(cè)了線程鉤子或者鎖DllMain 執(zhí)行后有些線程還在用這個(gè) DLL 的代碼。另外如果重復(fù)調(diào)用 MemoryFreeLibrary 兩次DllMain 被執(zhí)行兩次第二次參考到的內(nèi)存已經(jīng)被釋放直接崩潰。解決用MEMORY_DLL上下文里的bDllMainCalled標(biāo)志位保證每次加載只調(diào)用一次 ATTACH 和一次 DETACH。釋放后把基址指針置空避免懸空引用。還有一個(gè)血淚經(jīng)驗(yàn)不要在 DllMain 里直接調(diào)用FreeLibrary自己否則死鎖同理內(nèi)存加載器在釋放 DLL 時(shí)也盡量不要持有它的線程鎖等待。6. 驗(yàn)證技巧確認(rèn)內(nèi)存 DLL 加載成功最終交付前我習(xí)慣做一個(gè)自帶驗(yàn)證樣本。寫一個(gè)很簡單的 DLL導(dǎo)出兩個(gè)函數(shù)一個(gè)做整數(shù)加法一個(gè)返回版本號(hào)。然后內(nèi)存加載它分別調(diào)用這兩個(gè)函數(shù)再執(zhí)行一個(gè)稍復(fù)雜的場景——在 DLL 內(nèi)部申請(qǐng)堆內(nèi)存、寫入數(shù)據(jù)、讀取校驗(yàn)。// 驗(yàn)證用DLL的部分代碼 extern C __declspec(dllexport) int AddTwo(int a, int b) { static int calls 0; // 故意用靜態(tài)變量驗(yàn)證重定位 calls; return a b calls; } extern C __declspec(dllexport) const char* Version() { return memdll-v1.0; }加載驗(yàn)證代碼HMODULE hMod MemoryLoadLibrary(pBuffer, fileSize); if (hMod NULL) { printf(load failed\n); return; } typedef int (*AddTwo_t)(int, int); typedef const char* (*Version_t)(); AddTwo_t addFn (AddTwo_t)GetProcAddress(hMod, AddTwo); Version_t verFn (Version_t)GetProcAddress(hMod, Version); if (addFn verFn) { printf(version: %s\n, verFn()); int sum addFn(3, 4); if (sum ! 10) // 34calls(1)calls初始值? 注意靜態(tài)變量 printf(unexpected result: %d\n, sum); else printf(basic call ok\n); }注意上面的加法結(jié)果因?yàn)殪o態(tài)變量calls每次調(diào)用都會(huì)加 1所以第一次返回可能不是 7。如果它返回一個(gè)負(fù)數(shù)或者巨大值說明重定位確實(shí)壞了。這種小技巧比任何調(diào)試手段都直觀。我通常還會(huì)做一個(gè)邊界測(cè)試把 DLL 文件內(nèi)容隨機(jī)改一個(gè)字節(jié)再加載確認(rèn)加載器能在校驗(yàn)段直接拒絕。這能防止線上加載到損壞數(shù)據(jù)時(shí)靜默出錯(cuò)。把這一套寫進(jìn)自動(dòng)化腳本每次改 PE 解析代碼就回歸一遍。最后要說的是內(nèi)存加載 DLL 雖然繞過了一些系統(tǒng)機(jī)制但也扛下了更多責(zé)任尤其是內(nèi)存權(quán)限、導(dǎo)入依賴和生命周期的管理。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取