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