簡介一套圍繞內(nèi)存DLL與內(nèi)存加載EXE的完整源碼包面向熟悉Windows編程、希望深入進程注入與PE加載原理的開發(fā)者可用于學習如何擺脫傳統(tǒng)磁盤路徑直接在內(nèi)存中加載并執(zhí)行EXE同時以DLL接口形式對外提供調(diào)用。包內(nèi)共17個文件主要包含cpp、h源碼和rc資源腳本另有dsp、dsw工程文件、def導出定義、lib/exp鏈接文件及一個可運行的樣例DLL/EXE整體約942KB。已有192人學習過。源碼展示了從內(nèi)存中解析PE結(jié)構(gòu)、處理重定位、申請內(nèi)存并創(chuàng)建線程執(zhí)行入口點的關(guān)鍵步驟也給出了封裝接口函數(shù)的具體實現(xiàn)參考價值較高。通過閱讀工程代碼讀者可掌握CreateRemoteThread、VirtualAllocEx等API的典型用法并為自行開發(fā)內(nèi)存加載或安全分析工具打下基礎(chǔ)。1. 從磁盤啟動到內(nèi)存執(zhí)行這份DLL源碼到底在解決什么問題有一次我在排查一個進程頻繁閃退的問題查了半天發(fā)現(xiàn)根本不是程序自身的問題——是有人把另一個EXE當成DLL直接塞進了這個進程的地址空間里執(zhí)行。當時我就意識到內(nèi)存DLL、內(nèi)存加載EXE這套玩法在實際項目中遠比教科書寫得要復雜得多。這份“DLL源碼啟動”壓縮包就是這么一套完整的工程調(diào)用方宿主、被加載的EXE、簽名庫全配齊適合想做PE加載器、調(diào)試注入邏輯、研究手動映射技術(shù)的人。它的核心價值在于讓你不再依賴 CreateProcess 去拉起一個新進程而是把 EXE 當作一組二進制數(shù)據(jù)在當前進程里完成裝載、修復、執(zhí)行。這套技能在接口封裝、功能改造、逆向調(diào)試和特殊場景部署里都繞不開。2. 為什么不用 LoadLibrary手動映射的原理與選型2.1 LoadLibrary 的硬限制路徑、落盤和加載回調(diào)傳統(tǒng)的 LoadLibrary / LoadLibraryEx必須給一個磁盤路徑。Windows 會沿著這個路徑找到文件讀入系統(tǒng)緩存再交給裝載器做映射。在這個過程中文件路徑會出現(xiàn)在進程模塊列表里DLL 的加載事件會被 ETW 記錄而且 DLL 里的 DllMain 會因為進程線程狀態(tài)的變化被多次調(diào)用參數(shù)從 DLL_PROCESS_ATTACH 到 DLL_THREAD_ATTACH 輪番上陣。如果你只是想“在當前進程里跑一段現(xiàn)成的 EXE 邏輯”LoadLibrary 這條路根本行不通——它只能加載 DLL加載不了 EXE。就算你把 EXE 強行改名成 DLL裝載器會因為校驗 PE 頭、檢查 Subsystem 字段等原因拒絕加載。就算你用 LoadLibraryEx 加 LOAD_LIBRARY_AS_DATAFILE 把它當數(shù)據(jù)文件讀入那也只是把二進制讀進內(nèi)存并不能執(zhí)行。這就要一個更底層的方案手動映射也就是業(yè)內(nèi)常說的 Manual Map。手動映射的本質(zhì)是繞開系統(tǒng)的加載流程自己把 PE 文件的每個節(jié)區(qū)復制到內(nèi)存里修復重定位表和導入表然后直接跳到入口點。整個過程里磁盤上可以沒有這個 EXE。2.2 手動映射的六個標準步驟第一步讀取文件內(nèi)容。直接用 CreateFile ReadFile 把 EXE 的二進制讀進一塊緩沖區(qū)這塊緩沖區(qū)只是原始數(shù)據(jù)不參與執(zhí)行。第二步解析 DOS 頭和 PE 頭。校驗 e_magic 是否為 MZ、Signature 是否為 PE\0\0從這里拿到節(jié)區(qū)表、可選頭的入口點地址、鏡像基址、數(shù)據(jù)目錄。第三步按 SizeOfImage 分配一塊可讀可寫可執(zhí)行的內(nèi)存。這里有個容易踩的坑分配粒度要按 SectionAlignment 對齊不能直接拿文件大小來分配。第四步按節(jié)區(qū)表的 VirtualAddress 和 PointerToRawData把每個節(jié)區(qū)從文件偏移復制到內(nèi)存偏移同時把文件頭復制到鏡像起始位置。第五步判斷模塊被加載到的新地址是否和 ImageBase 一致。不一致就遍歷重定位表把所有絕對地址加上一個 Delta 值。第六步遍歷導入表逐個 LoadLibrary 和 GetProcAddress把導入地址表 IAT 替換成真實函數(shù)地址。最后跳到 AddressOfEntryPoint 執(zhí)行。整個流程看起來不復雜但每一步都有很多細節(jié)。一旦某一步寫錯程序不會給你報錯只會靜默崩潰。而且崩潰點往往不在出錯的那一步而是拖到執(zhí)行入口點之后才爆發(fā)排查起來非常難受。我做這個功能時習慣在每個步驟后加一個狀態(tài)輸出把 Section 數(shù)量、ImageBase、入口點地址、重定位表大小這些關(guān)鍵參數(shù)先打出來確認每一步都有據(jù)可查。2.3 三個關(guān)鍵選型點入口點、重定位、導入表入口點要不要作為線程啟動常見做法是 CreateThread傳入入口地址作為起始地址。好處是加載器線程可以立即返回不會阻塞調(diào)用方壞處是如果 EXE 的 WinMain 里做了大量初始化線程生命周期就脫離了加載器的控制。我一般傾向用 CreateThread 啟動然后 WaitForSingleObject 等待入口點函數(shù)返回這樣不會出現(xiàn)加載器線程已經(jīng)退出、入口點還在另一個線程里跑的情況。但要注意如果目標 EXE 內(nèi)部調(diào)用了 ExitProcess那整個進程還是會結(jié)束這一點沒得商量。重定位是否必須做如果 EXE 的 ImageBase 和 VirtualAlloc 分配到的地址恰好一致重定位理論上可以跳過。但這么想的基本都會翻車——VirtualAlloc 能分到的地址由系統(tǒng)決定不能保證一致。尤其是開啟了 ASLR 的系統(tǒng)EXE 頭里聲明的 ImageBase 基本不可能被滿足。所以重定位處理是所有內(nèi)存加載器里最不能省的邏輯。導入表修復則是另一個生死線它決定了 EXE 里能不能調(diào)用系統(tǒng) API。如果導入表不修復加載出來的 EXE 只要碰到一個外部函數(shù)調(diào)用就會瞬間崩掉而且崩在 ntdll 里看起來像是系統(tǒng)問題。2.4 手動映射和進程注入的區(qū)別很多人把手動映射和進程注入混為一談。實際上進程注入強調(diào)的是“把代碼放進別人的進程空間”手法可以是 CreateRemoteThread、SetWindowsHookEx、APC 注入而手動映射強調(diào)的是“不通過系統(tǒng)加載器來裝載 PE”兩者可以結(jié)合使用。比如把手動映射出來的 DLL 通過遠程線程注入到目標進程那就是一套完整的注入方案。但如果只是在自己進程里加載一個 EXE那只需要手動映射不需要遠程線程。這份資源里的做法更接近后者宿主和加載目標都在同一進程里。3. 壓縮包內(nèi)的文件布局PotPlayer 工程、HWSignature 與 SGDownload 的分工打開這個壓縮包第一眼看上去文件很多其實大部分是編譯生成物。怎么把它們分層、找出來源是能不能看懂這份源碼的關(guān)鍵。3.1 文件清單與角色判斷從文件后綴和命名看這是基于 Visual C 6.0 工程.dsp / .dsw的一套方案。我把文件分成幾類分類文件角色宿主源碼PotPlayer.dsp / PotPlayer.dsw / PotPlayer.cpp / StdAfx.cpp / StdAfx.h調(diào)用方工程主體資源與定義Potplayer.rc / resource.h / Potplayer.def界面資源與導出符號定義編譯生成物Release\HWSignature.exp / HWSignature.lib / HWSignature.dll簽名庫的導入庫和 DLL目標與臨時Bin\HWSignature.dll / Bin\temp / Release\SGDownload.exe運行時依賴與目標加載對象清理腳本刪除臨時文件.bat清理運行后殘留PotPlayer 是這個工程的宿主名字。為什么叫 PotPlayer一種可能是它借了播放器的外殼實際干的卻是加載器的活。PotPlayer.cpp 是主入口里面應該封裝了內(nèi)存加載邏輯和接口調(diào)用。注意 Potplayer.def 這個文件它在 DLL 工程里用來聲明哪些函數(shù)可以被外部程序調(diào)用如果一個 EXE 工程里出現(xiàn)了 .def很可能是想讓 EXE 也導出函數(shù)給別的模塊使用或者用它來重定向入口點。HWSignature.dll 從名字看是“硬件簽名”相關(guān)模塊可能的作用是校驗被加載的 EXE 是否合法或者在加載完成后做簽名檢查。這一塊在調(diào)試時可以直接忽略但務必保證它存在因為宿主程序加載時很可能通過 LoadLibrary 依賴了它。SGDownload.exe 是典型的目標程序——被加載者。從命名看它可能是一個下載器程序這里被當成內(nèi)存加載的對象。在真實使用場景里這個文件不應該常駐磁盤而是由宿主程序在內(nèi)存中直接執(zhí)行。3.2 調(diào)用方與被加載方的連接方式內(nèi)存加載和普通 DLL 調(diào)用最大的不同在于DLL 可以通過 GetProcAddress 找導出函數(shù)而內(nèi)存加載的 EXE 沒有標準的導出機制。那么調(diào)用方怎么和 SGDownload.exe 溝通常見做法是在調(diào)用方里定義接口結(jié)構(gòu)體。比如定義一個結(jié)構(gòu)體 SGDOWNLOAD_INTERFACE里面放函數(shù)指針。然后調(diào)用方在內(nèi)存加載完成后找到 EXE 的入口點給它傳一個結(jié)構(gòu)體地址讓它把自身的函數(shù)指針填入這個結(jié)構(gòu)體。這樣調(diào)用方就能像調(diào)用本地函數(shù)一樣調(diào)用加載到內(nèi)存中的 EXE 功能。這個思路在工程里可能以 PotPlayer.cpp 里的一段全局結(jié)構(gòu)體形式存在// InterfaceDef.h typedef struct _SGDOWNLOAD_INTERFACE { int nStructSize; // 結(jié)構(gòu)體大小用于版本協(xié)商 DWORD dwFunctionFlags; // 支持的功能位掩碼 BOOL (*SetSourceURL)(const char* lpszUrl); // 設置下載地址 BOOL (*StartDownload)(const char* lpszSavePath, DWORD dwTimeout); BOOL (*StopDownload)(void); DWORD (*GetProgress)(void); // 返回下載進度百分比 void (*Release)(void); // 釋放內(nèi)部資源 } SGDOWNLOAD_INTERFACE;這段代碼定義了調(diào)用方和內(nèi)存中 EXE 之間的接口契約。nStructSize 用于版本協(xié)商避免兩邊結(jié)構(gòu)體對齊方式不一致導致字段錯位dwFunctionFlags 讓調(diào)用方在調(diào)用前先確認目標支持哪些功能。SetSourceURL 和 StartDownload 是業(yè)務函數(shù)。通過這種結(jié)構(gòu)體傳參方式內(nèi)存加載的 EXE 也能像 DLL 一樣提供清晰的函數(shù)入口。參數(shù)里我沒有寫路徑和文件句柄因為內(nèi)存模式下不依賴落盤所有地址都是函數(shù)指針。3.3 哪些文件是源碼、哪些是生成物去掉 Release、Debug、Bin 這些目錄后純凈的源碼其實只有十來個文件。當你拿到這樣的壓縮包時第一件事是重建工程結(jié)構(gòu)新建一個目錄從 dsp / dsw 恢復 VC6 工程把 cpp / h / rc / def 放進去再編譯。編譯時注意 HWSignature.lib 要能鏈接上否則會報“無法解析的外部符號”。Release 目錄下那幾個 .exp / .lib 是為了和 HWSignature.dll 一起鏈接用的如果只是看加載器的邏輯不需要深究它的簽名算法。還要留意 PotPlayer.plg 這個文件它是 VC6 的編譯日志記錄的是某一次編譯的輸出信息。這個文件基本沒有保留價值但有時能從里面看到工程文件的編譯順序和依賴關(guān)系比如要不要先編譯 HWSignature 再編譯 PotPlayer。刪除臨時文件.bat 這個文件值得多說一句。它清理的是 Bin\temp 目錄下的臨時文件。內(nèi)存加載雖然不需要目標 EXE 常駐磁盤但在某些方案里為了配合下載流程會先把 EXE 寫到臨時目錄再立即用內(nèi)存方式讀入并刪除。這個批處理就是把沒刪干凈的殘骸清理掉。4. 手寫一版內(nèi)存加載器從 PE 解析到入口點執(zhí)行這一章是落地章節(jié)用 C 把整個手動映射流程拆開寫一遍。代碼以 Windows API 為主編譯環(huán)境可以是 VS2022也可以退回 VC6核心邏輯不變。4.1 把 EXE 讀進內(nèi)存并校驗 PE 頭// LoadFile.cpp HANDLE hFile CreateFileA(SGDownload.exe, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); if (hFile INVALID_HANDLE_VALUE) { return FALSE; // 文件不存在或沒有權(quán)限 } DWORD fileSize GetFileSize(hFile, NULL); BYTE* pBuffer new BYTE[fileSize]; DWORD bytesRead 0; ReadFile(hFile, pBuffer, fileSize, bytesRead, NULL); CloseHandle(hFile); // 校驗 DOS 頭和 PE 頭 IMAGE_DOS_HEADER* pDos (IMAGE_DOS_HEADER*)pBuffer; if (pDos-e_magic ! IMAGE_DOS_SIGNATURE) { // MZ delete[] pBuffer; return FALSE; } IMAGE_NT_HEADERS* pNt (IMAGE_NT_HEADERS*)(pBuffer pDos-e_lfanew); if (pNt-Signature ! IMAGE_NT_SIGNATURE) { // PE\0\0 delete[] pBuffer; return FALSE; }這里把 EXE 整體讀成一塊緩沖區(qū)然后強轉(zhuǎn)成 IMAGE_DOS_HEADER 并校驗 e_magic再通過 e_lfanew 跳轉(zhuǎn)到 NT 頭校驗 Signature。注意 e_lfanew 這個字段是 DOS 頭里指向 PE 頭的文件偏移不能直接假設它固定是 0x80。用 ImageNtHeaders 宏也能做轉(zhuǎn)換但這里手動寫更直觀也方便打印中間變量。讀文件時我用了 FILE_SHARE_READ這樣即使目標 EXE 被其他進程打開了也不會因為共享沖突讀失敗。4.2 按節(jié)區(qū)分配內(nèi)存并復制數(shù)據(jù)// AllocImage.cpp IMAGE_OPTIONAL_HEADER32* pOpt pNt-OptionalHeader; BYTE* pImageBase (BYTE*)VirtualAlloc(NULL, pOpt-SizeOfImage, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); if (pImageBase NULL) { delete[] pBuffer; return FALSE; } // 復制文件頭部分 memcpy(pImageBase, pBuffer, pOpt-SizeOfHeaders); // 遍歷節(jié)區(qū)表并按節(jié)區(qū)實際數(shù)據(jù)大小復制 IMAGE_SECTION_HEADER* pSec IMAGE_FIRST_SECTION(pNt); for (int i 0; i pNt-FileHeader.NumberOfSections; i) { memcpy(pImageBase pSec[i].VirtualAddress, pBuffer pSec[i].PointerToRawData, pSec[i].SizeOfRawData); }分配內(nèi)存用的是 VirtualAlloc分配大小是 SizeOfImage 而不是文件大小。SizeOfImage 是加載到內(nèi)存后整個鏡像的虛擬大小包含節(jié)區(qū)對齊后的空隙和頭部對齊所以它一般會比文件大小大。如果只分配文件大小PE 頭里所有基于 VirtualAddress 的地址都會越界等執(zhí)行到入口點附近就會觸發(fā)訪問沖突。節(jié)區(qū)復制時用 PointerToRawData 去文件里取數(shù)據(jù)寫入 VirtualAddress 對應的位置。這里特意用了 PAGE_EXECUTE_READWRITE是為了避免節(jié)區(qū)權(quán)限不同導致后續(xù)寫入時崩潰正常做法是后面按節(jié)區(qū)屬性重新設置保護屬性。4.3 修復重定位表// FixReloc.cpp DWORD delta (DWORD)((BYTE*)pImageBase - pOpt-ImageBase); if (delta ! 0) { DWORD relocRVA pOpt-DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress; DWORD relocSize pOpt-DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].Size; if (relocRVA ! 0) { DWORD offset 0; while (offset relocSize) { IMAGE_BASE_RELOCATION* pReloc (IMAGE_BASE_RELOCATION*)(pImageBase relocRVA offset); DWORD count (pReloc-SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD); WORD* entries (WORD*)((BYTE*)pReloc sizeof(IMAGE_BASE_RELOCATION)); for (DWORD j 0; j count; j) { if ((entries[j] 0x3000) IMAGE_REL_BASED_HIGHLOW) { DWORD* pAddr (DWORD*)(pImageBase pReloc-VirtualAddress (entries[j] 0x0FFF)); *pAddr delta; } } offset pReloc-SizeOfBlock; } } }delta 是實際加載地址和 PE 頭里聲明的首選基址之間的差。重定位表里的每一項都是一個塊結(jié)構(gòu)VirtualAddress 指明這個塊作用于哪個頁面SizeOfBlock 是這個塊的總字節(jié)數(shù)后面的 WORD 數(shù)組每一項的高 4 位表示重定位類型低 12 位是頁面內(nèi)的偏移。HIGHLOW 類型表示這是一個 32 位地址需要加上 delta。如果 EXE 沒有重定位表也就是 Base Relocation Directory 的 Size 為 0那這個 EXE 就只能加載到它的 ImageBase 上否則一定會崩。這種情況在 VC6 編譯的 Release EXE 里比較常見遇到時不要硬加載要么用 LoadLibrary 走正常路要么給工程加上 /DYNAMICBASE 重新編譯。4.4 修復導入表// FixImport.cpp DWORD importRVA pOpt-DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress; if (importRVA ! 0) { IMAGE_IMPORT_DESCRIPTOR* pImp (IMAGE_IMPORT_DESCRIPTOR*)(pImageBase importRVA); for (; pImp-Name ! 0; pImp) { char* dllName (char*)(pImageBase pImp-Name); HMODULE hDll LoadLibraryA(dllName); if (hDll NULL) { continue; // 依賴的 DLL 不在系統(tǒng)路徑或當前目錄 } IMAGE_THUNK_DATA* pThunk (IMAGE_THUNK_DATA*)(pImageBase pImp-FirstThunk); IMAGE_THUNK_DATA* pOrig (IMAGE_THUNK_DATA*)(pImageBase pImp-OriginalFirstThunk); for (; pThunk-u1.AddressOfData ! 0; pThunk, pOrig) { if (pOrig-u1.AddressOfData 0x80000000) { // 按序號導入的函數(shù) DWORD ordinal pOrig-u1.AddressOfData 0x7FFFFFFF; pThunk-u1.Function (DWORD)GetProcAddress(hDll, (char*)ordinal); } else { // 按名稱導入的函數(shù) IMAGE_IMPORT_BY_NAME* pName (IMAGE_IMPORT_BY_NAME*)(pImageBase pOrig-u1.AddressOfData); pThunk-u1.Function (DWORD)GetProcAddress(hDll, pName-Name); } } } }導入表修復的邏輯是把 EXE 里聲明的導入函數(shù)從“函數(shù)名稱”替換為實際加載到進程空間的函數(shù)地址。OriginalFirstThunk 指向原始導入名稱表FirstThunk 是 IAT兩者在編譯時可能指向同一塊數(shù)據(jù)但修復時只能改 IAT不能動 OriginalFirstThunk 指向的內(nèi)容。按序號導入時AddressOfData 的最高位為 1低位就是函數(shù)序號GetProcAddress 可以直接用序號查找。按名稱導入則要解析 IMAGE_IMPORT_BY_NAME里面是 Hint 加函數(shù)名字符串。如果 LoadLibrary 返回 NULL說明目標 EXE 依賴的這個 DLL 不在系統(tǒng)的搜索路徑里這時候要自己先 LoadLibrary 一個絕對路徑或者把 DLL 目錄加到當前進程的搜索路徑中。4.5 執(zhí)行入口點并管理線程生命周期// RunEntry.cpp BYTE* entryPoint pImageBase pOpt-AddressOfEntryPoint; HANDLE hThread CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)entryPoint, (LPVOID)pInterface, // 傳給入口點的參數(shù) 0, NULL); if (hThread NULL) { VirtualFree(pImageBase, 0, MEM_RELEASE); delete[] pBuffer; return FALSE; } WaitForSingleObject(hThread, INFINITE); CloseHandle(hThread); // 線程結(jié)束后再釋放鏡像 VirtualFree(pImageBase, 0, MEM_RELEASE); delete[] pBuffer;入口點地址是 AddressOfEntryPoint 相對于鏡像基址的偏移。對于 EXE 來說這個入口點一般會經(jīng)過 C 運行時初始化最終調(diào)用 WinMain。用 CreateThread 而不是直接函數(shù)調(diào)用的好處是線程有自己的?？臻g入口點里即使對棧做了大量操作也不會污染加載器所在線程的棧。另一個好處是可以在外部等待線程結(jié)束便于管理生命周期。這里我傳入了 pInterface 結(jié)構(gòu)體指針也就是上一章定義的接口結(jié)構(gòu)目標 EXE 在入口點階段往里面填充函數(shù)指針。注意VirtualFree 釋放鏡像內(nèi)存必須在所有相關(guān)線程退出之后否則就是在代碼還沒有停止執(zhí)行的時候先把代碼卸載了。4.6 參數(shù)怎么傳、返回值怎么拿傳參數(shù)給內(nèi)存加載的 EXE 是一個容易忽略的問題。CreateProcess 可以通過命令行傳參數(shù)而內(nèi)存加載的入口點函數(shù)簽名理論上只有一個參數(shù)也就是我們常說的 lpParameter。這個自由度其實很大——你可以傳一個整數(shù)可以傳一個字符串指針也可以傳一個結(jié)構(gòu)體指針。我一般把所有參數(shù)包成一個結(jié)構(gòu)體里面放業(yè)務需要的 URL、保存路徑、超時時間、回調(diào)函數(shù)等。返回值通過結(jié)構(gòu)體里的指針帶回來比如結(jié)構(gòu)體里放一個 int* pResult目標程序執(zhí)行完把結(jié)果寫到這個地址。如果目標 EXE 的入口點是標準 WinMain那它的返回值要通過 ExitProcess 或者 return 返回。在線程場景下入口點 return 的值會變成線程退出碼可以通過 GetExitCodeThread 拿到。注意拿返回值要在 WaitForSingleObject 之后調(diào)用線程沒結(jié)束就拿退出碼結(jié)果是不確定的。5. 常見問題與排錯加載器翻車的五條血淚經(jīng)驗5.1 加載后進程活著但主窗口沒出現(xiàn)現(xiàn)象加載返回成功線程也創(chuàng)建了但目標 EXE 的主窗口沒彈出來進程卻在后臺跑著任務管理器里能看到進程存在。原因最常見的是入口點用的不是正常的 WinMain 入口流程。很多 EXE 在 WinMain 被調(diào)用前有一大段 CRT 初始化邏輯包括解析命令行、初始化全局變量、設置錯誤模式。如果直接跳到 AddressOfEntryPoint這些初始化步驟就被跳過了導致窗口創(chuàng)建失敗或者窗口類沒有注冊。解決確認目標 EXE 是否使用動態(tài)鏈接 CRT。如果是它的入口點通常是 mainCRTStartup 或 wWinMainCRTStartup這類入口點會調(diào)用 _cexit 清理邏輯。在調(diào)試器里設斷點看第一次異常發(fā)生在哪一步如果停在 CRT 源碼里就說明初始化路徑不對。另一個排查方向是檢查目標 EXE 是否依賴當前目錄下的 DLL如果 DLL 沒找到入口點可能在 LoadLibrary 階段就失敗返回了。5.2 一執(zhí)行就報 0xC0000005 崩潰定位到重定位段現(xiàn)象加載成功但入口點執(zhí)行不到三行就崩潰調(diào)試器停在一條 mov 指令上崩潰地址指向一個明顯不屬于任何模塊的地址。原因大概率是重定位被跳過了。如果 EXE 的 ImageBase 是 0x400000而 VirtualAlloc 返回的是 0x1A0000那么所有絕對地址都指向了錯誤的位置。還有一種情況是重定位表解析循環(huán)寫錯了比如 SizeOfBlock 計算錯誤導致跳過了某些塊修復了錯誤地址。解決打印 delta 值確認它不為 0。同時在重定位修復后把導入表地址隨機抽幾個打印出來和 GetProcAddress 的結(jié)果比對。如果發(fā)現(xiàn) AddressOfData 指向的地址不在 pImageBase 到 pImageBase SizeOfImage 的范圍內(nèi)基本就是重定位沒修對。還有一種玄學情況目標 EXE 是 x64 的你用了 32 位重定位邏輯去解析類型值根本匹配不上。遇到這種就先確認目標架構(gòu)和加載器架構(gòu)一致。5.3 頁面權(quán)限導致的訪問沖突RWX 段被 DEP 攔截現(xiàn)象重定位和導入表都修了運行時依然會偶發(fā)崩潰尤其是調(diào)用一些全局變量或者回調(diào)函數(shù)的時候。有時候加載器自己沒問題換了臺機器就崩。原因有的 EXE 代碼段和數(shù)據(jù)段對權(quán)限要求不同。全部用 PAGE_EXECUTE_READWRITE 雖然能跑但某些 API 比如 VirtualProtect 或 DEP 策略會對 RWX 段做特殊處理導致執(zhí)行到代碼段時被強制攔截。尤其是開啟了 CFG控制流保護的系統(tǒng)對間接調(diào)用目標有校驗RWX 內(nèi)存塊不在白名單里就會被拒絕。解決按節(jié)區(qū)屬性分別設置內(nèi)存權(quán)限。節(jié)區(qū)表里每個 Section 有 Characteristics 字段IMAGE_SCN_MEM_EXECUTE 表示可執(zhí)行IMAGE_SCN_MEM_READ 表示可讀IMAGE_SCN_MEM_WRITE 表示可寫。分配內(nèi)存時先用 MEM_RESERVE 保留整個 SizeOfImage 地址空間再按節(jié)區(qū)用 MEM_COMMIT 逐段提交然后根據(jù) Characteristics 用 VirtualProtect 設置對應權(quán)限。這樣代碼段是 PAGE_EXECUTE_READ數(shù)據(jù)段是 PAGE_READWRITE更接近系統(tǒng)正常加載的行為。5.4 殺毒軟件隔離 Bin 目錄下的 DLL 和 EXE現(xiàn)象編譯好的 Bin 目錄里HWSignature.dll 和 SGDownload.exe 偶爾會神秘消失或者被隔離到病毒隔離區(qū)。重新編譯后過一陣子又出現(xiàn)同樣情況。原因手動映射是一種高級監(jiān)控技術(shù)很多殺毒軟件會把“在內(nèi)存中分配 RWX 內(nèi)存 寫入代碼 跳轉(zhuǎn)到入口”識別為后門行為。工程里的 HWSignature.dll 如果做了簽名校驗邏輯也容易被靜態(tài)特征誤判。這不算加載器的邏輯錯誤但會直接影響復現(xiàn)。解決本地做加載器研發(fā)時把整個工程目錄加入殺毒軟件白名單或者干脆在虛擬機里做測試。不要在裝有重要資料的機器上反復編譯這類工程。如果你的目標是做正常的功能封裝建議優(yōu)先考慮標準 LoadLibrary GetProcAddress只有確實需要內(nèi)存加載時才動用這套方案。5.5 刪除臨時文件.bat 把正在運行的目標 EXE 刪了現(xiàn)象加載器運行過程中執(zhí)行一次批處理之后目標程序突然閃退或者下次運行提示找不到 SGDownload.exe。原因批處理清理的是 Bin\temp 目錄。如果加載器把 EXE 寫進 temp 后還沒來得及讀入批處理就先把它刪了加載自然就失敗。如果加載器運行完后批處理立刻清理又可能刪掉一個還在被映射到內(nèi)存的文件。更隱蔽的問題是第一次加載沒有釋放文件句柄批處理刪不掉文件但把它標記為“待刪除”進程退出后文件就消失了第二次運行就找不到。解決延遲清理時機。批處理里加一段 timeout 等待加載器完全退出或者讓加載器自己負責刪除臨時文件而不是依賴外部腳本。我現(xiàn)在的習慣是凡是需要落盤再讀入的場景文件刪除統(tǒng)一放在加載函數(shù)返回之后用 try-finally 的結(jié)構(gòu)保證任何分支退出時都會執(zhí)行清理同時清理前校驗句柄已關(guān)閉。6. 進階用法把加載器封裝成帶接口的 DLL到這一步手動加載已經(jīng)能跑通了。但實際項目里不會把加載邏輯寫死在 EXE 里而是封裝成 DLL對外暴露接口讓宿主程序通過普通 LoadLibrary 調(diào)用。這樣既方便復用也讓內(nèi)存加載的黑匣子只對調(diào)用方開一個小口。接口設計大概是這樣// MemLoader.h typedef struct _MEMLOADER_PARAMS { const char* lpFilePath; // 目標 EXE 路徑 void* lpReserved; // 保留參數(shù) HANDLE hThread; // 返回的主線程句柄 DWORD dwLoadFlags; // 0 表示只用內(nèi)存加載1 表示加載后落盤清理 } MEMLOADER_PARAMS; BOOL __stdcall MemLoadExe(MEMLOADER_PARAMS* pParams); BOOL __stdcall MemUnloadExe(HANDLE hThread);MemLoadExe 內(nèi)部完成整條加載鏈路成功返回 TRUE同時把主線程句柄存到參數(shù)里。MemUnloadExe 負責通知目標 EXE 退出并等待線程結(jié)束。如果需要更復雜的狀態(tài)反饋可以再加一個回調(diào)函數(shù)指針讓宿主主動感知加載進度。調(diào)用方只需要HMODULE hLoader LoadLibraryA(MemLoader.dll); typedef BOOL(__stdcall *PFN_Load)(MEMLOADER_PARAMS*); PFN_Load pfnLoad (PFN_Load)GetProcAddress(hLoader, MemLoadExe); MEMLOADER_PARAMS params {0}; params.lpFilePath SGDownload.exe; params.dwLoadFlags 0; BOOL bOK pfnLoad(params);封裝之后還有一個好處可以把接口結(jié)構(gòu)體版本化。如果目標 EXE 升級了函數(shù)指針數(shù)量變化了通過 nStructSize 判斷兩邊版本是否匹配不匹配直接返回錯誤而不是等到調(diào)用時崩潰。這些話聽起來簡單但真去封裝的時候你會發(fā)現(xiàn)內(nèi)存加載和 DLL 生命周期管理糾纏在一起。比如卸載時不能在目標 EXE 的線程內(nèi)部調(diào)用 VirtualFree 釋放鏡像否則會先把自己正在執(zhí)行的代碼釋放掉。正確做法是從外部線程釋放而且要先讓目標 EXE 的所有子線程退出。從那以后我每次封裝加載器都會強制走一遍“加載 → 運行 → 卸載 → 再次加載”的回歸測試特別是卸載后馬上再加載同一份鏡像的場景。這個流程能暴露絕大多數(shù)內(nèi)存管理問題希望幫到你。本文還有配套的精品資源點擊獲取