網(wǎng)絡(luò)安全【免費(fèi)下載鏈接】BlackboneWindows memory hacking library項(xiàng)目地址https://gitcode.com/gh_mirrors/bl/Blackbone點(diǎn)擊查看免費(fèi)下載導(dǎo)讀WOW64Ext 是運(yùn)行在 x64 Windows 系統(tǒng) WOW64 兼容層之下的 x8632 位程序?qū)Ｓ幂o助庫它解決了 32 位進(jìn)程無法直接讀寫、枚舉原生 x64 進(jìn)程內(nèi)存的經(jīng)典難題并額外提供X64Call()這一核心機(jī)制使 x86 代碼可以間接調(diào)用 x64 版 NTDLL 中的任意函數(shù)。本篇文章以 WOW64Ext 官方文檔 為骨架結(jié)合 wow64ext.h 與 wow64ext.cpp 源碼及 示例程序完整講解每個(gè)導(dǎo)出 API 的簽名、參數(shù)語義與底層實(shí)現(xiàn)并展示該庫如何被本項(xiàng)目 Blackbone 的 WOW64 子系統(tǒng)直接吸收利用。讀完本文你將掌握從 32 位進(jìn)程訪問 64 位目標(biāo)進(jìn)程的內(nèi)存、模塊與線程上下文的完整方法以及 x86 模式切換至 x64 模式調(diào)用原生函數(shù)的底層原理。背景32 位進(jìn)程在 64 位系統(tǒng)上面臨的內(nèi)存訪問難題x64 版本 Windows 通過 WOW64Windows 32-bit on Windows 64-bit兼容層運(yùn)行 x86 程序。WOW64 環(huán)境中的 32 位進(jìn)程在功能上有很大限制標(biāo)準(zhǔn) Win32 APIReadProcessMemory、VirtualAllocEx、OpenProcess等的SIZE_T指針位寬被截?cái)酁?32 位無法表示 x64 目標(biāo)進(jìn)程中的高地址默認(rèn)情況下32 位進(jìn)程的地址空間被限制在 4GB 之內(nèi)無法直接尋址 64 位進(jìn)程位于 4GB 之上的內(nèi)存區(qū)域32 位代碼無法直接調(diào)用 64 位 NTDLL 中的系統(tǒng)服務(wù)封裝函數(shù)Nt*系列因?yàn)閮烧呤褂貌煌恼{(diào)用約定與代碼段。WOW64Ext 正是為了解決這些限制而設(shè)計(jì)的它在不依賴任何驅(qū)動(dòng)的情況下讓 x86 程序獲得對(duì)原生 x64 進(jìn)程內(nèi)存、模塊與線程的完整操作能力。該庫在 Blackbone 中承擔(dān)了關(guān)鍵角色——Blackbone 的NativeWow64子系統(tǒng)Wow64Subsystem.cpp直接編譯并使用了本庫的wow64ext.cpp見 CMakeLists.txt 與 BlackBone.vcxproj這正是 Blackbone 支持跨越 WOW64 屏障管理 x64 進(jìn)程功能的技術(shù)基礎(chǔ)。庫概覽與目錄結(jié)構(gòu)WOW64Ext 由作者 ReWolf 開發(fā)在倉庫中位于src/3rd_party/rewolf-wow64ext/核心文件如下文件作用src/wow64ext.h公共頭文件導(dǎo)出函數(shù)聲明、PEB/TEB/TIB/LDR 等結(jié)構(gòu)定義、_CONTEXT64_2定義src/wow64ext.cpp全部導(dǎo)出函數(shù)的實(shí)現(xiàn)內(nèi)含 x86 內(nèi)聯(lián)匯編src/internal.h內(nèi)部宏X64_Start()/X64_End()模式切換匯編字節(jié)碼、REX_W、reg64聯(lián)合體src/CMemPtr.h臨時(shí)內(nèi)存自動(dòng)釋放的 RAII 輔助WATCH宏sample/main.cpp示例程序x64 進(jìn)程內(nèi)存轉(zhuǎn)儲(chǔ)器 功能自測doc/wow64ext.txt完整 API 文檔src/wow64ext.vcxproj32 位動(dòng)態(tài)庫工程配置構(gòu)建工程只面向 Win32 平臺(tái)wow64ext.vcxproj 僅包含Debug|Win32與Release|Win32兩種配置這是因?yàn)樵搸斓脑O(shè)計(jì)目標(biāo)就是讓 x86 進(jìn)程跨越 WOW64 屏障64 位進(jìn)程直接使用標(biāo)準(zhǔn) API 即可無需此庫。編譯時(shí)定義WOW64EXT_EXPORTS會(huì)將導(dǎo)出函數(shù)標(biāo)記為dllexport否則標(biāo)記為dllimport見 wow64ext.h。核心機(jī)制X64Call() 與 x86/x64 模式切換函數(shù)簽名與參數(shù)約定DWORD64 __cdecl X64Call(DWORD64 func, int argC, ...);這是整個(gè)庫的引擎。官方文檔對(duì)其語義的定義如下func要調(diào)用的 x64 函數(shù)地址通常由GetProcAddress64()取得argC傳給func的參數(shù)個(gè)數(shù)...func的其余參數(shù)所有參數(shù)都必須顯式轉(zhuǎn)換為DWORD64。返回值是被調(diào)用 x64 函數(shù)在RAX中的返回值以DWORD64形式返回。底層原理x86 內(nèi)聯(lián)匯編 遠(yuǎn)程段切換從實(shí)現(xiàn)上看wow64ext.cppX64Call的代碼被編譯為 x86 內(nèi)聯(lián)匯編但在運(yùn)行時(shí)通過修改 CS代碼段寄存器以 x64 模式執(zhí)行這些字節(jié)碼。關(guān)鍵步驟包括切換 FS 段先將 FS 段保存隨后將 FS 寫入 x64 選擇子0x2B以正確處理 64 位環(huán)境的 FS 基址TEB64 定位依賴于此棧對(duì)齊將esp對(duì)齊到0x10邊界——源碼注釋明確指出未對(duì)齊的棧可能導(dǎo)致某些 syscall 返回錯(cuò)誤且 SSE 指令要求 16 字節(jié)對(duì)齊通過X64_Start()宏切換到 x64 代碼段宏展開后是一段精心構(gòu)造的字節(jié)碼push cs; call $5; add dword [esp], 5; retf通過retf遠(yuǎn)返回切換 CS 到 x64 選擇子0x33見 internal.h填充寄存器參數(shù)按 x64 調(diào)用約定把前 4 個(gè)參數(shù)放入rcx、rdx、r8、r9其余參數(shù)逆序壓棧注意其中REX_W前綴的作用——32 位匯編器會(huì)省略這些字節(jié)但 CPU 在 x64 模式下需要它們把指令解析為 64 位操作調(diào)用目標(biāo)函數(shù)并清理?xiàng)Ｕ{(diào)用完畢后按參數(shù)個(gè)數(shù)恢復(fù)棧retf返回 32 位模式X64_End()恢復(fù)ss、esp與 FS 段。為了在 32 位匯編中安全地操作 64 位值internal.h 定義了reg64聯(lián)合體用兩個(gè)DWORD模擬一個(gè)DWORD64注釋說明直接使用DWORD64會(huì)產(chǎn)生錯(cuò)誤的pop word ptr[]并破壞棧。配套輔助函數(shù)DWORD64 __cdecl getNTDLL64();返回 x64 版 ntdll.dll 的基址內(nèi)部緩存X64Call與內(nèi)存 API 的延遲解析都依賴它。GetModuleHandle64(Lntdll.dll)是它的實(shí)現(xiàn)基礎(chǔ)見 wow64ext.cpp。此外還有VOID __cdecl SetLastErrorFromX64Call(DWORD64 status);X64Call直接返回 NTSTATUS而內(nèi)存類 API 需要遵循 Win32 慣例設(shè)置GetLastError()。該函數(shù)通過 x86 版RtlNtStatusToDosError與RtlSetLastWin32Error把 NTSTATUS 轉(zhuǎn)成對(duì)應(yīng)的 Win32 錯(cuò)誤碼見 wow64ext.cpp。模塊枚舉與函數(shù)解析GetModuleHandle64 與 GetProcAddress64GetModuleHandle64DWORD64 __cdecl GetModuleHandle64(const wchar_t* lpModuleName);行為類似 x86 版GetModuleHandle但檢索的是已加載 x64 庫的模塊鏈表。官方文檔特別指出通常 WOW64 層下的 x86 進(jìn)程只加載 4 個(gè) x64 庫——ntdll.dll、wow64.dll、wow64cpu.dll、wow64win.dll。參數(shù)lpModuleName為寬字符串模塊名。其實(shí)現(xiàn)wow64ext.cpp展示了 WOW64Ext 結(jié)構(gòu)定義的典型用法通過getTEB64()拿到當(dāng)前線程的 TEB64——在 WOW64 進(jìn)程中R12寄存器恒指向 TEB64因此實(shí)現(xiàn)只是把R12壓棧再彈出從TEB64.ProcessEnvironmentBlock得到 PEB64從PEB64.Ldr得到PEB_LDR_DATA64沿InLoadOrderModuleList鏈表遍歷LDR_DATA_TABLE_ENTRY64逐個(gè)比較BaseDllName與目標(biāo)模塊名命中則返回DllBase。GetProcAddress64DWORD64 __cdecl GetProcAddress64(DWORD64 hModule, const char* funcName);行為類似 x86 版GetProcAddress內(nèi)部調(diào)用x64 版LdrGetProcedureAddress()。參數(shù)hModule為 x64 模塊基址funcName為函數(shù)名ANSI 字符串。解析LdrGetProcedureAddress地址的過程wow64ext.cpp體現(xiàn)了對(duì) x64 內(nèi)存的基礎(chǔ)讀寫能力定位 ntdll64 的 PE 頭 → 讀取導(dǎo)出目錄 → 用getMem64/cmpMem64將導(dǎo)出名稱表、序號(hào)表、函數(shù)地址表批量復(fù)制到本地內(nèi)存 → 線性匹配LdrGetProcedureAddress名稱 → 算出其 RVA 對(duì)應(yīng)的絕對(duì)地址。之后通過X64Call(_LdrGetProcedureAddress, 4, hModule, fName, 0, funcRet)完成真正的函數(shù)地址解析見 wow64ext.cpp。內(nèi)存操作 API在 x64 目標(biāo)進(jìn)程上執(zhí)行虛擬內(nèi)存管理以下 6 個(gè) API 的參數(shù)與行為都與 x86 對(duì)應(yīng)版 Win32 函數(shù)同名同義區(qū)別在于地址一律使用DWORD64寬指針且內(nèi)部通過X64Call調(diào)用 x64 NTDLL 中的Nt*系統(tǒng)服務(wù)。VirtualQueryEx64SIZE_T __cdecl VirtualQueryEx64(HANDLE hProcess, DWORD64 lpAddress, MEMORY_BASIC_INFORMATION64* lpBuffer, SIZE_T dwLength);hProcess進(jìn)程句柄由標(biāo)準(zhǔn) x86 版OpenProcess()獲取lpAddress待查詢區(qū)域的基址lpBuffer指向MEMORY_BASIC_INFORMATION64標(biāo)準(zhǔn) SDK 頭中已定義的緩沖區(qū)dwLength緩沖區(qū)大小。內(nèi)部經(jīng)X64Call(NtQueryVirtualMemory, 6, ...)調(diào)用 x64 版NtQueryVirtualMemory失敗時(shí)通過SetLastErrorFromX64Call設(shè)置 Win32 錯(cuò)誤碼成功則返回ReturnLength見 wow64ext.cpp。VirtualAllocEx64DWORD64 __cdecl VirtualAllocEx64(HANDLE hProcess, DWORD64 lpAddress, SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect);lpAddress期望的分配起始地址可傳 0 讓系統(tǒng)選擇dwSize區(qū)域大小flAllocationType分配類型MEM_COMMIT、MEM_RESERVE等flProtect內(nèi)存保護(hù)屬性PAGE_READWRITE等。底層調(diào)用NtAllocateVirtualMemory成功時(shí)返回實(shí)際分配的地址注意NtAllocateVirtualMemory會(huì)通過指針參數(shù)回寫實(shí)際地址因此傳入的是tmpAddr失敗返回FALSE并設(shè)置錯(cuò)誤碼見 wow64ext.cpp。VirtualFreeEx64BOOL __cdecl VirtualFreeEx64(HANDLE hProcess, DWORD64 lpAddress, SIZE_T dwSize, DWORD dwFreeType);dwFreeType釋放操作類型官方文檔明確給出可取MEM_RELEASE、MEM_DECOMMIT。底層調(diào)用NtFreeVirtualMemory見 wow64ext.cpp。VirtualProtectEx64BOOL __cdecl VirtualProtectEx64(HANDLE hProcess, DWORD64 lpAddress, SIZE_T dwSize, DWORD flNewProtect, DWORD* lpflOldProtect);flNewProtect新的內(nèi)存保護(hù)屬性lpflOldProtect接收舊保護(hù)值的指針。底層調(diào)用NtProtectVirtualMemory見 wow64ext.cpp。ReadProcessMemory64 與 WriteProcessMemory64BOOL __cdecl ReadProcessMemory64(HANDLE hProcess, DWORD64 lpBaseAddress, LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesRead); BOOL __cdecl WriteProcessMemory64(HANDLE hProcess, DWORD64 lpBaseAddress, LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesWritten);lpBaseAddress目標(biāo)內(nèi)存基址64 位寬lpBuffer讀/寫數(shù)據(jù)的本地緩沖區(qū)nSize讀/寫字節(jié)數(shù)lpNumberOfBytesRead/lpNumberOfBytesWritten實(shí)際讀/寫字節(jié)數(shù)輸出指針。兩者底層分別調(diào)用 x64 版NtReadVirtualMemory與NtWriteVirtualMemory見 wow64ext.cpp。線程上下文 APIGetThreadContext64 與 SetThreadContext64BOOL __cdecl GetThreadContext64(HANDLE hThread, _CONTEXT64_2* lpContext); BOOL __cdecl SetThreadContext64(HANDLE hThread, _CONTEXT64_2* lpContext);hThread目標(biāo)線程句柄文檔中寫作進(jìn)程句柄為筆誤實(shí)現(xiàn)與 Win32 語義均為線程句柄lpContext指向_CONTEXT64結(jié)構(gòu)的指針GetThreadContext64依據(jù)ContextFlags字段填充結(jié)構(gòu)SetThreadContext64僅寫入ContextFlags指定的字段。底層分別調(diào)用 x64 版NtGetContextThread/NtSetContextThread見 wow64ext.cpp。由于 32 位 SDK 不包含 x64 上下文結(jié)構(gòu)庫在 wow64ext.h 中自定義了完整的_CONTEXT64_2包含 6 個(gè)參數(shù) home 區(qū)、ContextFlags、各段寄存器、調(diào)試寄存器Dr0-Dr7、通用寄存器Rax-R15、Rip、_XSAVE_FORMAT64浮點(diǎn)保存區(qū)以及Xmm0-Xmm15、AVXVectorRegister[26]等。文件同時(shí)定義了一組與 WinNT.h 對(duì)應(yīng)的ContextFlags常量#define CONTEXT64_CONTROL (CONTEXT_AMD64 | 0x1L) #define CONTEXT64_INTEGER (CONTEXT_AMD64 | 0x2L) #define CONTEXT64_SEGMENTS (CONTEXT_AMD64 | 0x4L) #define CONTEXT64_FLOATING_POINT (CONTEXT_AMD64 | 0x8L) #define CONTEXT64_DEBUG_REGISTERS (CONTEXT_AMD64 | 0x10L) #define CONTEXT64_FULL (CONTEXT64_CONTROL | CONTEXT64_INTEGER | CONTEXT64_FLOATING_POINT) #define CONTEXT64_ALL (CONTEXT64_CONTROL | CONTEXT64_INTEGER | CONTEXT64_SEGMENTS | \ CONTEXT64_FLOATING_POINT | CONTEXT64_DEBUG_REGISTERS) #define CONTEXT64_XSTATE (CONTEXT_AMD64 | 0x20L)見 wow64ext.h。附贈(zèng)結(jié)構(gòu)定義模板化的 PEB / TEB / TIB / LDR 結(jié)構(gòu)官方文檔提到wow64ext.h還包含一批可能對(duì)訪問 PEB、TEB、TIB 等有用的結(jié)構(gòu)定義。它們?nèi)渴悄０寤摹灾羔樜粚扵為模板參數(shù)DWORD得到 32 位版、DWORD64得到 64 位版模板實(shí)例化別名說明_LIST_ENTRY_TT—雙向鏈表節(jié)點(diǎn)Flink/Blink_UNICODE_STRING_TT—寬字符串Length/MaximumLength/Buffer_NT_TIB_TT—線程信息塊 TIB 前 7 個(gè)字段_CLIENT_ID_TT—UniqueProcess/UniqueThread_TEB_T_TTEB32/TEB64線程環(huán)境塊注釋說明其余部分暫未定義因?yàn)闀翰恍枰猒LDR_DATA_TABLE_ENTRY_TTLDR_DATA_TABLE_ENTRY32/LDR_DATA_TABLE_ENTRY64加載器鏈表?xiàng)l目_PEB_LDR_DATA_TTPEB_LDR_DATA32/PEB_LDR_DATA64PEB 中的加載器數(shù)據(jù)_PEB_TT,NGF,APEB32/PEB64進(jìn)程環(huán)境塊含BeingDebugged、NtGlobalFlag、GdiHandleBuffer等常用字段定義位于 wow64ext.h注意文件頂部使用了#pragma pack(1)單字節(jié)對(duì)齊以保證與真實(shí)內(nèi)核結(jié)構(gòu)布局一致。PEB32/PEB64的模板參數(shù)A表示GdiHandleBuffer數(shù)組大小32 位為 34、64 位為 30NGF用于適配NtGlobalFlag字段類型差異。實(shí)戰(zhàn)示例官方內(nèi)存轉(zhuǎn)儲(chǔ)器解讀示例程序位于 sample/main.cpp它是 WOW64Ext 各 API 的綜合演示運(yùn)行方式為sample.exe hex_process_ID // 十六進(jìn)制格式的進(jìn)程 ID程序依次演示了以下能力解析 x64 模塊導(dǎo)出GetProcAddress64(GetModuleHandle64(Lwow64cpu.dll), TurboDispatchJumpAddressStart)直接取得 WOW64 CPU 調(diào)度函數(shù)的地址枚舉并轉(zhuǎn)儲(chǔ) x64 進(jìn)程內(nèi)存以VirtualQueryEx64從地址 0 開始逐區(qū)域掃描跳過PAGE_NOACCESS/PAGE_GUARD區(qū)域?qū)勺x區(qū)域用ReadProcessMemory64讀取并以進(jìn)程ID_基址_保護(hù)屬性.bin命名寫入文件——這正是官方文檔所說的簡單內(nèi)存轉(zhuǎn)儲(chǔ)器調(diào)用任意 x64 函數(shù)取得RtlComputeCrc32后執(zhí)行X64Call(rtlcrc32, 3, (DWORD64)0, (DWORD64)ReWolf, (DWORD64)6)計(jì)算字符串 CRC32注意所有參數(shù)顯式轉(zhuǎn)為DWORD64完整的內(nèi)存操作閉環(huán)AllocTest()展示了分配 → 查詢 → 改保護(hù) → 寫入 → 讀出比對(duì) → 釋放的完整流程其中VirtualAllocEx64(hProcess, 0x70000020000, 0x2000, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE)在 4GB 以上地址分配內(nèi)存之后WriteProcessMemory64/ReadProcessMemory64配合memcmp校驗(yàn)讀寫一致性最后VirtualFreeEx64(..., 0, MEM_RELEASE)釋放并再查詢確認(rèn)狀態(tài)該測試還對(duì)當(dāng)前進(jìn)程執(zhí)行了一次驗(yàn)證在 WOW64 內(nèi)部跨越 4GB 邊界分配內(nèi)存的能力讀寫線程上下文ctx.ContextFlags CONTEXT64_ALL; GetThreadContext64(GetCurrentThread(), ctx)后打印rsp、rip、r8、r9、r12。注釋中保留了被注釋掉的危險(xiǎn)代碼——把ctx.Rip 0后SetThreadContext64會(huì)直接崩潰進(jìn)程從反面印證了上下文寫入確實(shí)生效。在 Blackbone 中的集成NativeWow64 子系統(tǒng)Blackbone 將該庫作為 WOW64 子系統(tǒng)的底層實(shí)現(xiàn)直接編譯進(jìn)項(xiàng)目BlackBone.vcxproj 將wow64ext.cpp編入BlackBone.vcxproj.filters 將其歸入 Subsystem 分組CMake 構(gòu)建同樣包含該源文件見 CMakeLists.txt。集成點(diǎn)是 Wow64Subsystem.cpp其中NativeWow64類把 WOW64Ext 的底層原語封裝成 Blackbone 風(fēng)格的NTSTATUS接口VirtualAllocExT/VirtualFreeExT/VirtualQueryExT/VirtualProtectExT與 WOW64Ext 的內(nèi)存 API 一一對(duì)應(yīng)直接使用GetProcAddress64(getNTDLL64(), Nt*)配合X64Call實(shí)現(xiàn)見 Wow64Subsystem.cppReadProcessMemoryT/WriteProcessMemoryT對(duì) 4GB 以下的低地址走標(biāo)準(zhǔn)ReadProcessMemory/WriteProcessMemory快速路徑目標(biāo)本身也是 WOW64 進(jìn)程時(shí)高地址則通過 Blackbone 動(dòng)態(tài)導(dǎo)入的NtWow64ReadVirtualMemory64/NtWow64WriteVirtualMemory64處理見 Wow64Subsystem.cppGetThreadContextT/SetThreadContextT通過X64Call調(diào)用NtGetContextThread/NtSetContextThread讀寫 x64 上下文同時(shí)保留了對(duì)_CONTEXT32的重載見 Wow64Subsystem.cppgetPEB/getTEB借助NtWow64QueryInformationProcess64、NtWow64ReadVirtualMemory64讀取目標(biāo)的_PEB64/_TEB64其結(jié)構(gòu)直接取自 WOW64Ext 的模板化定義見 Wow64Subsystem.cppCreateRemoteThreadT、QueueApcT、SetProcessInfoT同樣通過X64Call調(diào)用NtCreateThreadEx、NtQueueApcThread、NtSetInformationProcess等 x64 函數(shù)見 Wow64Subsystem.cpp。由此可以推斷WOW64Ext 提供的X64CallGetProcAddress64 64 位結(jié)構(gòu)定義三件套是 Blackbone 實(shí)現(xiàn)Manage process through WOW64 barrier見 README.md這一核心特性的直接依賴。32 位 Blackbone 進(jìn)程正是憑借這套機(jī)制才能對(duì)原生 x64 目標(biāo)進(jìn)程完成注入、Hook、遠(yuǎn)程調(diào)用等整套操作。集成到自有項(xiàng)目時(shí)的注意事項(xiàng)使用前提本庫僅適用于 x86 程序且宿主系統(tǒng)必須是 x64 Windows。X64Call與GetModuleHandle64在非 WOW64 環(huán)境下直接返回 0見 wow64ext.cpp參數(shù)位寬所有傳給X64Call的參數(shù)必須以(DWORD64)顯式轉(zhuǎn)換指針參數(shù)傳遞(DWORD64)var這是最常見的誤用點(diǎn)棧對(duì)齊X64Call內(nèi)部已處理 16 字節(jié)對(duì)齊與棧平衡調(diào)用方無需干預(yù)但被調(diào)用的 x64 函數(shù)必須遵循標(biāo)準(zhǔn) x64 調(diào)用約定錯(cuò)誤處理內(nèi)存類 API 遵循 Win32 慣例——失敗返回 0/FALSE并設(shè)置線程本地錯(cuò)誤碼可用GetLastError()獲取結(jié)構(gòu)布局使用PEB64、TEB64、LDR_DATA_TABLE_ENTRY64等結(jié)構(gòu)時(shí)注意它們按#pragma pack(1)單字節(jié)對(duì)齊定義字段布局需與實(shí)際目標(biāo)系統(tǒng)版本核對(duì)授權(quán)該第三方庫以 LGPL-3.0 授權(quán)見 lgpl-3.0.txt作為 Blackbone 的 3rd_party 依賴隨項(xiàng)目分發(fā)。小結(jié)WOW64Ext 以極小的代碼規(guī)模解決了 32 位進(jìn)程與 64 位進(jìn)程之間的位寬鴻溝X64Call提供模式切換能力GetModuleHandle64/GetProcAddress64打通 x64 模塊與導(dǎo)出解析六個(gè)內(nèi)存 API 覆蓋查詢、分配、釋放、改保護(hù)、讀、寫全部虛擬內(nèi)存操作兩個(gè)上下文 API 實(shí)現(xiàn) x64 線程上下文的讀寫模板化結(jié)構(gòu)定義則讓 PEB/TEB 的訪問不再依賴 64 位 SDK。在本倉庫 Blackbone 中它已作為NativeWow64子系統(tǒng)的基石被實(shí)際編譯與使用是理解跨 WOW64 進(jìn)程操作技術(shù)的絕佳學(xué)習(xí)樣本也是一份可直接復(fù)用的 32 位/64 位混合內(nèi)存操作工具箱。贊分享網(wǎng)絡(luò)安全【免費(fèi)下載鏈接】BlackboneWindows memory hacking library項(xiàng)目地址https://gitcode.com/gh_mirrors/bl/Blackbone點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Blackbone WOW64子系統(tǒng)跨越32位與64位進(jìn)程屏障的終極指南Blackbone WOW64子系統(tǒng)跨越32位與64位進(jìn)程屏障的終極指南 Blackbone是一款強(qiáng)大的Windows內(nèi)存操作庫而其中的WOW64子系統(tǒng)更是網(wǎng)絡(luò)安全inih輕量級(jí) C 語言 INI 解析器詳解及其在 mGBA 中的集成實(shí)踐inih輕量級(jí) C 語言 INI 解析器詳解及其在 mGBA 中的集成實(shí)踐 導(dǎo)讀 inihINI Not Invented Here是一個(gè)用純 C 編寫的游戲開發(fā)深入解析 Go 版 XXH3 哈希庫zeebo/xxh3及其在 Cloudpods 中的 UUID 生成實(shí)踐深入解析 Go 版 XXH3 哈希庫zeebo/xxh3及其在 Cloudpods 中的 UUID 生成實(shí)踐 XXH3 是知名非加密哈希算法 xxHash后端云原生運(yùn)維虛擬化人工智能AI 應(yīng)用上一篇如何快速提取微信聊天記錄3步實(shí)現(xiàn)數(shù)據(jù)永久保存的完整指南下一篇伊斯蘭星形圖案二在 p5.js 中利用正弦定理精確計(jì)算 Hankin 長度的鋪貼算法優(yōu)化創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考