簡(jiǎn)介這份面向《魔力寶貝》玩家與C逆向編程學(xué)習(xí)者的輔助工具資料聚焦游戲內(nèi)角色血量查看需求提供可運(yùn)行程序及配套工程源碼。壓縮包共18個(gè)文件、約207KB以C源文件與頭文件為主體輔以VS工程配置、資源腳本、圖標(biāo)和可執(zhí)行文件便于在Visual Studio 2005環(huán)境中打開、編譯和繼續(xù)研究其中程序基于Win32/MFC界面與網(wǎng)絡(luò)數(shù)據(jù)解析實(shí)現(xiàn)血量顯示涉及數(shù)據(jù)包抓取、通信協(xié)議分析與內(nèi)存、指針操作等知識(shí)點(diǎn)。已有9126人瀏覽學(xué)習(xí)說明該案例在游戲輔助與逆向入門圈具有一定參考價(jià)值。讀者可從中了解一個(gè)完整小型輔助工具的項(xiàng)目組織方式、界面與邏輯分層、協(xié)議字段識(shí)別思路及調(diào)試排錯(cuò)過程也可把源碼當(dāng)作網(wǎng)絡(luò)編程和逆向工程的練習(xí)樣本需注意此類工具可能違反游戲用戶協(xié)議應(yīng)僅用于技術(shù)學(xué)習(xí)并尊重游戲公平性。1. 一個(gè)看血工具為什么值得拆從只讀內(nèi)存到懸浮窗的最小閉環(huán)朋友把這份「看血工具及其源碼」丟給我時(shí)我第一反應(yīng)是這不就是個(gè)讀內(nèi)存的小玩意嗎。真把壓縮包解開順著源碼讀下去才發(fā)現(xiàn)它是一個(gè)相當(dāng)完整的 Windows 桌面開發(fā)切片進(jìn)程枚舉、OpenProcess拿句柄、模塊基址加多級(jí)偏移解引用、內(nèi)存區(qū)域掃描定位數(shù)值最后用分層窗口把血條畫在游戲畫面角落。整條鏈路不長(zhǎng)但每一環(huán)都能單獨(dú)拎出來講也每一環(huán)都能翻車。它適合三類人想入門 Windows 內(nèi)存讀寫的 C 新手、想搞懂懸浮 HUD 怎么貼在別人窗口上的桌面開發(fā)者、手里有老工具要維護(hù)的同學(xué)。這份源碼最大的技術(shù)邊界是「只讀」——它不寫目標(biāo)進(jìn)程的內(nèi)存改數(shù)據(jù)這條路根本沒鋪所以整篇筆記也都圍著「讀」和「畫」展開。2. 工程結(jié)構(gòu)與編譯一個(gè) Win32 小工具的模塊切分2.1 目錄結(jié)構(gòu)與文件職責(zé)這類工具最怕寫成一個(gè)幾千行的main.cpp讀到一半就迷路。這份源碼的目錄大致按職責(zé)切成了七塊邊界比較清晰我按常見組織方式還原一下LookHp/ ├── src/ │ ├── main.cpp // 入口命令行參數(shù)、單實(shí)例互斥、啟動(dòng)采樣與 UI │ ├── process_reader.h/.cpp // 進(jìn)程附著、內(nèi)存讀取、模塊基址、指針鏈解析 │ ├── scanner.h/.cpp // 內(nèi)存區(qū)域遍歷與數(shù)值篩選用來定位血量地址 │ ├── sampler.h/.cpp // 采樣線程按固定節(jié)奏讀當(dāng)前/最大 HP │ ├── overlay_window.h/.cpp // 分層透明窗口、GDI 雙緩沖繪制 │ ├── config.h/.cpp // 偏移鏈、窗口坐標(biāo)、刷新間隔讀寫 ini │ └── util/ │ ├── log.h/.cpp // OutputDebugString 滾動(dòng)文件日志 │ └── str.h/.cpp // 寬窄字符轉(zhuǎn)換、窗口標(biāo)題匹配 ├── config/ │ └── offsets.ini // 基址模塊名、偏移數(shù)組、血量合理區(qū)間 ├── build/ │ └── LookHp.sln // VS 工程x86 配置 └── README.md文件職責(zé)改動(dòng)頻率process_reader.cpp所有ReadProcessMemory的出口低scanner.cpp一次性調(diào)試工具定位地址用低sampler.cpp采樣節(jié)奏、數(shù)據(jù)緩存中overlay_window.cpp繪制與窗口樣式高offsets.ini偏移鏈、血量區(qū)間極高把「讀內(nèi)存」和「畫界面」拆成兩個(gè)模塊是這份代碼里最值錢的一點(diǎn)。采樣線程只管往一個(gè)小的共享結(jié)構(gòu)里寫數(shù)據(jù)UI 線程只管從里面取中間用std::mutex或者原子變量隔開。后續(xù)想換繪制框架比如換成 Direct2D 或 ImGui只要不動(dòng)process_reader風(fēng)險(xiǎn)就鎖在一個(gè)文件里。2.2 技術(shù)棧與依賴選擇純 Win32 GDI沒有 MFC、沒有 Qt、沒有 ImGuiC11 就夠。這個(gè)選擇在 2024 年看著有點(diǎn)土但對(duì)這類工具是合適的最終 exe 只有一兩百 KB啟動(dòng)無依賴改顏色改布局也就是幾行FillRect。真上 ImGui光是引入imgui_impl_win32和imgui_impl_dx11就得多帶幾 MB 運(yùn)行庫收益并不對(duì)等。日志用OutputDebugStringW加一個(gè)文件句柄Release下編譯宏關(guān)掉輸出。配置用 ini 不用 JSON偏移鏈就那么幾個(gè)數(shù)字用GetPrivateProfileIntW讀一行就夠了還免了引第三方解析庫。這套組合的隱含要求是目標(biāo)客戶端必須是 32 位。工具跑 x86 配置讀出來的指針是 4 字節(jié)如果目標(biāo)進(jìn)程是 64 位指針變 8 字節(jié)偏移鏈上每一級(jí)都會(huì)錯(cuò)位讀出來的數(shù)字就是玄學(xué)。這一點(diǎn)后面避坑章節(jié)會(huì)再提一次。2.3 編譯與運(yùn)行的最小步驟環(huán)境準(zhǔn)備VS2019 或 VS2022安裝「使用 C 的桌面開發(fā)」工作負(fù)載。注意平臺(tái)一定要選 x86、配置選 ReleaseDebug 版在某些環(huán)境下和采樣線程配合會(huì)明顯掉幀。# 1. 用 VS 打開工程也可以走命令行 MSBuild msbuild build\LookHp.sln /p:ConfigurationRelease /p:PlatformWin32 # 2. 先以普通權(quán)限啟動(dòng)工具會(huì)自己枚舉進(jìn)程 build\Release\LookHp.exe # 3. 若日志里出現(xiàn) OpenProcess failed, err5右鍵以管理員身份重新運(yùn)行err5是ERROR_ACCESS_DENIED十有八九是目標(biāo)客戶端本身以管理員權(quán)限在跑權(quán)限低的進(jìn)程讀不了權(quán)限高的進(jìn)程這在 Windows 上是硬規(guī)則不是代碼 bug。msbuild那行里的/p:PlatformWin32不要省略很多人直接敲msbuild xxx.sln會(huì)默認(rèn)走 AnyCPU 或 x64編譯出來的 exe 一掛上去就讀不到數(shù)據(jù)。運(yùn)行起來之后工具會(huì)先讀一次配置里的偏移鏈成功就在游戲窗口左上角浮出一塊半透明面板。如果面板出來但數(shù)字是 0說明偏移鏈?zhǔn)Я巳onfig/offsets.ini檢查基址模塊名是不是寫錯(cuò)比如把Client.exe寫成了client.exe——GetModuleBaseNameW匹配區(qū)分大小寫時(shí)是比較嚴(yán)格的我一般統(tǒng)一轉(zhuǎn)小寫再比。3. 進(jìn)程附著與內(nèi)存讀取句柄、模塊基址與偏移鏈怎么走通3.1 打開進(jìn)程與權(quán)限的坑所有內(nèi)存讀取的第一步都是OpenProcess這一步錯(cuò)了后面全白搭。源碼里通常封裝成Attach(pid)bool ProcessReader::Attach(DWORD pid) { Detach(); // 先釋放舊句柄避免多開切換時(shí)句柄泄漏 m_handle OpenProcess( PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, // 只讀夠用 FALSE, pid); if (!m_handle) { DWORD err GetLastError(); // 5 ERROR_ACCESS_DENIED權(quán)限不足 // 87 ERROR_INVALID_PARAMETERPID 已經(jīng)退出 LOGW(LOpenProcess failed, pid%lu err%lu, pid, err); return false; } m_pid pid; return true; }權(quán)限掩碼是關(guān)鍵參數(shù)。PROCESS_VM_READ決定能不能讀內(nèi)存PROCESS_QUERY_INFORMATION決定能不能查模塊信息。有人圖省事直接傳PROCESS_ALL_ACCESS在開啟了部分防護(hù)的系統(tǒng)上反而更容易失敗因?yàn)橐淮涡陨暾?qǐng)全部權(quán)限更容易被拒。只申請(qǐng)需要的那兩位成功率明顯高。如果目標(biāo)進(jìn)程權(quán)限更高就得給自己的進(jìn)程提權(quán)。常見做法是啟動(dòng)時(shí)嘗試打開SE_DEBUG_NAMEbool EnableDebugPrivilege() { HANDLE token nullptr; if (!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, token)) return false; TOKEN_PRIVILEGES tp{}; tp.PrivilegeCount 1; LookupPrivilegeValueW(nullptr, SE_DEBUG_NAME, tp.Privileges[0].Luid); tp.Privileges[0].Attributes SE_PRIVILEGE_ENABLED; BOOL ok AdjustTokenPrivileges(token, FALSE, tp, sizeof(tp), nullptr, nullptr); CloseHandle(token); // AdjustTokenPrivileges 返回 TRUE 也可能沒生效必須再查一次 GetLastError return ok GetLastError() ERROR_SUCCESS; }這個(gè)函數(shù)有個(gè)經(jīng)典陷阱AdjustTokenPrivileges返回TRUE并不代表權(quán)限真的加上了必須再檢查一次GetLastError()是否等于ERROR_SUCCESS。我第一次寫這個(gè)函數(shù)時(shí)就被坑過日志顯示成功實(shí)際還是讀不到數(shù)據(jù)查了半天才發(fā)現(xiàn)是賬戶本身沒被授予調(diào)試特權(quán)。所以更穩(wěn)的做法是提權(quán)失敗不阻斷流程只在日志里記一條然后引導(dǎo)用戶用管理員身份重啟。3.2 模塊基址與多級(jí)指針拿到句柄后要解決「血量在哪」的問題。現(xiàn)代客戶端幾乎不會(huì)把血量放在固定絕對(duì)地址上因?yàn)槊看螁?dòng)模塊基址都會(huì)變ASLR。通用做法是先找模塊基址再沿偏移鏈逐級(jí)解引用uintptr_t ProcessReader::ModuleBase(const wchar_t* name) const { HMODULE mods[256]; DWORD needed 0; if (!EnumProcessModulesEx(m_handle, mods, sizeof(mods), needed, LIST_MODULES_ALL)) return 0; for (DWORD i 0; i needed / sizeof(HMODULE); i) { wchar_t path[MAX_PATH]{}; if (GetModuleBaseNameW(m_handle, mods[i], path, MAX_PATH) _wcsicmp(path, name) 0) { return reinterpret_castuintptr_t(mods[i]); } } return 0; } uintptr_t ProcessReader::ResolvePointer(uintptr_t base, const std::vectoruintptr_t offsets) const { uintptr_t addr base; for (size_t i 0; i offsets.size(); i) { uintptr_t next 0; if (!Read(addr, next)) return 0; // 任意一級(jí)失敗就返回 0交給上層判斷 addr next offsets[i]; } return addr; }ModuleBase里的LIST_MODULES_ALL是為了把 32 位模塊也一起列出來不加這個(gè)標(biāo)志在某些 64 位進(jìn)程里會(huì)漏掉模塊。ResolvePointer的語義要講清楚它從base開始讀一次內(nèi)存拿到指針值加上偏移再讀再加直到偏移鏈走完返回最終地址。偏移鏈通常形如[[[base 0x1A2B3C] 0x10] 0x24]在 ini 里就存成0x1A2B3C,0x10,0x24三個(gè)數(shù)字。注意Read的模板寫法要按目標(biāo)位數(shù)來。32 位進(jìn)程里指針是 4 字節(jié)所以next應(yīng)該聲明為uint32_t如果工具編譯成 64 位程序去讀 32 位目標(biāo)用uintptr_t會(huì)一次讀 8 字節(jié)把相鄰字段也讀進(jìn)來偏移鏈立刻錯(cuò)位。這就是前面強(qiáng)調(diào)必須編 x86 的原因不是玄學(xué)是字節(jié)數(shù)。3.3 內(nèi)存掃描定位血量偏移鏈不是天上掉的是掃出來的。源碼里scanner.cpp就是那個(gè)「一次性調(diào)試工具」先知道血量當(dāng)前值然后在目標(biāo)進(jìn)程的可讀寫內(nèi)存里找這個(gè)數(shù)改一下血量再篩一次直到候選地址收斂到個(gè)位數(shù)。// 首次掃描遍歷目標(biāo)進(jìn)程所有已提交且可讀寫的內(nèi)存區(qū)域 std::vectoruintptr_t ScanInt32(HANDLE h, int32_t target) { std::vectoruintptr_t hits; MEMORY_BASIC_INFORMATION mbi{}; uintptr_t addr 0; const size_t kChunk 64 * 1024; std::vectoruint8_t buf(kChunk); while (VirtualQueryEx(h, reinterpret_castLPCVOID(addr), mbi, sizeof(mbi))) { uintptr_t regionEnd reinterpret_castuintptr_t(mbi.BaseAddress) mbi.RegionSize; bool readable (mbi.State MEM_COMMIT) (mbi.Protect (PAGE_READWRITE | PAGE_WRITECOPY | PAGE_EXECUTE_READWRITE)); if (readable) { for (uintptr_t p reinterpret_castuintptr_t(mbi.BaseAddress); p regionEnd; p kChunk) { SIZE_T want static_castSIZE_T( minuintptr_t(kChunk, regionEnd - p)); SIZE_T got 0; if (!ReadProcessMemory(h, reinterpret_castLPCVOID(p), buf.data(), want, got)) continue; // 區(qū)域中間可能有空洞跳過即可不要中斷整輪掃描 for (size_t off 0; off sizeof(int32_t) got; off 4) { int32_t v *reinterpret_castint32_t*(buf.data() off); if (v target) hits.push_back(p off); } } } addr regionEnd; } return hits; }VirtualQueryEx的返回值和mbi.RegionSize是循環(huán)的兩個(gè)關(guān)鍵前者為 0 表示走到地址空間末尾后者告訴你這一段的長(zhǎng)度addr regionEnd就是往下一段推進(jìn)。mbi.State MEM_COMMIT過濾掉未提交的保留區(qū)Protect里帶PAGE_READWRITE才是候選數(shù)據(jù)區(qū)只讀區(qū)和代碼段基本不用掃。ReadProcessMemory在一整段里也可能失敗比如中間夾著保護(hù)頁。失敗時(shí)直接continue而不是break否則一個(gè)區(qū)域的頭部失敗會(huì)讓后面幾十 MB 全被跳過掃描結(jié)果里就會(huì)莫名其妙地少一堆候選。步長(zhǎng)用 4 是因?yàn)檠炕臼?32 位整型對(duì)齊訪問命中率最高有些客戶端血量是浮點(diǎn)或int64那就得把步長(zhǎng)和比較方式一起改。掃完之后還不是終點(diǎn)幾十萬候選地址里怎么收斂到真地址靠「值變化再篩」讓血量掉一點(diǎn)用新值在候選集里過一遍反復(fù)兩三次通常就剩兩三個(gè)。剩下的地址再反查是誰指向它一層層倒推回模塊基址得到的就是偏移鏈。這個(gè)過程沒有捷徑純手工加耐心屬于典型的血淚經(jīng)驗(yàn)。3.4 一個(gè)夠用的 Reader 封裝把上面這些揉在一起ProcessReader對(duì)外其實(shí)只需要四個(gè)方法Attach、Detach、ReadT、ResolvePointer。所有讀取都走同一個(gè)出口好處是錯(cuò)誤處理只需要寫一遍日志里也能帶上統(tǒng)一的 PID 和地址出問題時(shí)排查路徑非常短。template typename T bool Read(uintptr_t addr, T out) const { if (!m_handle) return false; SIZE_T got 0; BOOL ok ReadProcessMemory(m_handle, reinterpret_castLPCVOID(addr), out, sizeof(T), got); return ok got sizeof(T); }got sizeof(T)這個(gè)判斷別省。ReadProcessMemory返回TRUE但只讀了一部分的情況是存在的跨頁邊界此時(shí)out里是半截臟數(shù)據(jù)直接拿去算血量比例會(huì)得到離譜的數(shù)字。加上長(zhǎng)度校驗(yàn)讀失敗就整條鏈判廢比事后對(duì)著屏幕上詭異的數(shù)值發(fā)呆強(qiáng)。4. 懸浮窗與采樣節(jié)奏讓 HUD 貼在別人窗口上還不卡4.1 分層透明窗口與點(diǎn)擊穿透懸浮窗的核心是三個(gè)擴(kuò)展樣式WS_EX_LAYERED負(fù)責(zé)透明度WS_EX_TRANSPARENT負(fù)責(zé)鼠標(biāo)點(diǎn)擊穿透WS_EX_TOPMOST負(fù)責(zé)置頂。少任何一個(gè)體驗(yàn)都會(huì)崩沒有穿透面板擋住的地方點(diǎn)不動(dòng)沒有置頂切一下窗口面板就被蓋住。HWND OverlayWindow::Create(HINSTANCE hInst) { m_hwnd CreateWindowExW( WS_EX_LAYERED | WS_EX_TRANSPARENT | WS_EX_TOPMOST | WS_EX_TOOLWINDOW, kClassName, LLookHp HUD, WS_POPUP, // 無邊框純自繪 0, 0, 320, 96, nullptr, nullptr, hInst, nullptr); // 整體 alpha232 左右既能看清字又不至于完全擋住畫面 SetLayeredWindowAttributes(m_hwnd, 0, 232, LWA_ALPHA); ShowWindow(m_hwnd, SW_SHOWNOACTIVATE); // 不要搶焦點(diǎn) return m_hwnd; }WS_EX_TOOLWINDOW的作用是讓面板不出現(xiàn)在任務(wù)欄和 AltTab 列表里工具感更強(qiáng)。SW_SHOWNOACTIVATE保證窗口顯示時(shí)不搶焦點(diǎn)否則游戲會(huì)瞬間失去前臺(tái)狀態(tài)有些客戶端會(huì)因此暫停渲染看著就像工具把游戲搞卡了。窗口位置需要跟隨目標(biāo)窗口。常見做法是起一個(gè) 500ms 的定時(shí)器用GetWindowRect拿目標(biāo)窗口的客戶區(qū)坐標(biāo)再用SetWindowPos把 HUD 挪過去。這里要注意 DPI顯示器縮放 125% 或 150% 時(shí)GetWindowRect拿到的是物理像素如果進(jìn)程沒聲明 DPI 感知Windows 會(huì)幫你做一次虛擬化縮放坐標(biāo)就對(duì)不上。在工程里加一個(gè)SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)位置偏移的問題基本就消失了。4.2 采樣線程與刷新節(jié)奏讀內(nèi)存和畫界面必須分線程。放在 UI 線程里ReadProcessMemory偶爾的幾十微秒延遲會(huì)直接反映成面板抖動(dòng)拆成獨(dú)立線程采樣節(jié)奏和渲染幀率就各管各的。void Sampler::Run() { while (!m_stop.load(std::memory_order_relaxed)) { HpPair v{}; uintptr_t cur m_reader.ResolvePointer(m_base, m_offsets); // cur 0 表示偏移鏈任意一級(jí)讀失敗這一輪直接跳過 if (cur m_reader.Read(cur, v.current) m_reader.Read(cur 4, v.maximum)) { if (v.maximum 0 v.current 0 v.current v.maximum) { std::lock_guardstd::mutex lk(m_mtx); m_latest v; // 只有通過合理性校驗(yàn)的數(shù)據(jù)才寫進(jìn)共享區(qū) } } std::this_thread::sleep_for(std::chrono::milliseconds(m_intervalMs)); } }m_intervalMs一般取 150 到 200。取 16 跟著 60 幀刷新沒有意義血量不是每幀都變的量讀得太勤只會(huì)白燒 CPU還增加被目標(biāo)進(jìn)程察覺的概率。cur 4這種「結(jié)構(gòu)體相鄰字段」的寫法依賴具體客戶端的內(nèi)存布局源碼里把它抽成常量改的時(shí)候只改一處。m_latest的寫入條件加了合理性校驗(yàn)current不能小于 0也不能大于maximum。這條校驗(yàn)救過很多次因?yàn)橹羔樻湺虝菏r(shí)讀到的可能是堆上的隨機(jī)值不做校驗(yàn)就會(huì)在屏幕上畫出超過 100% 的血條看著像工具算錯(cuò)了實(shí)際是讀到了臟數(shù)據(jù)。用原子變量替換 mutex 也行HpPair是 8 字節(jié)在 x86 上不能保證原子所以這里老老實(shí)實(shí)用鎖開銷可以忽略。4.3 繪制與雙緩沖GDI 直接往窗口 DC 上畫會(huì)有閃爍標(biāo)準(zhǔn)解法是內(nèi)存 DC 雙緩沖先畫到CreateCompatibleBitmap最后一次BitBlt貼回去。void OverlayWindow::OnPaint(HDC hdc) { RECT rc; GetClientRect(m_hwnd, rc); HDC mem CreateCompatibleDC(hdc); HBITMAP bmp CreateCompatibleBitmap(hdc, rc.right, rc.bottom); HGDIOBJ old SelectObject(mem, bmp); // 背景半透明黑和窗口整體 alpha 疊加后大概 60% 不透明 HBRUSH bg CreateSolidBrush(RGB(16, 16, 16)); FillRect(mem, rc, bg); HpPair v{}; { std::lock_guardstd::mutex lk(m_mtx); v m_latest; } float ratio v.maximum 0 ? float(v.current) / float(v.maximum) : 0.f; RECT bar { 8, 40, 8 int(304 * ratio), 74 }; HBRUSH fill CreateSolidBrush(ratio 0.3f ? RGB(64, 190, 100) : RGB(210, 70, 70)); FillRect(mem, bar, fill); FrameRect(mem, bar, (HBRUSH)GetStockObject(GRAY_BRUSH)); wchar_t text[64]; swprintf_s(text, LHP %d / %d, v.current, v.maximum); SetBkMode(mem, TRANSPARENT); SetTextColor(mem, RGB(240, 240, 240)); DrawTextW(mem, text, -1, rc, DT_LEFT | DT_TOP | DT_SINGLELINE); BitBlt(hdc, 0, 0, rc.right, rc.bottom, mem, 0, 0, SRCCOPY); DeleteObject(bg); DeleteObject(fill); DeleteObject(bmp); SelectObject(mem, old); DeleteDC(mem); }血量低于 30% 換紅色是個(gè)很小的細(xì)節(jié)但對(duì)可用性幫助很大——余光掃一眼顏色就知道該不該撤不用去讀數(shù)字。每次CreateSolidBrush都要配對(duì)DeleteObjectGDI 對(duì)象泄漏在長(zhǎng)時(shí)間運(yùn)行的工具里是會(huì)累積的跑一整天之后面板開始變慢甚至畫不出來八成就是這里漏了。渲染觸發(fā)不要用WM_TIMER加InvalidateRect全量重繪直接開一個(gè) 250ms 定時(shí)器并只在數(shù)據(jù)變化時(shí)InvalidateRect(hwnd, nullptr, FALSE)。第三個(gè)參數(shù)給FALSE表示不擦背景配合雙緩沖就不會(huì)閃。4.4 多開場(chǎng)景下的窗口綁定多開玩家最常問的是「能不能一個(gè)面板顯示三個(gè)角色」。源碼默認(rèn)是單進(jìn)程綁定但改造空間留得挺足。常見做法是把「采樣線程 數(shù)據(jù)」打包成一個(gè)Session對(duì)象用一個(gè)std::vectorstd::unique_ptrSession管理每個(gè) Session 記自己的 PID、偏移鏈、窗口句柄。struct Session { ProcessReader reader; DWORD pid; HWND targetWnd; // 目標(biāo)客戶端主窗口 HWND hudWnd; // 自己創(chuàng)建的 HUD uintptr_t base; std::vectoruintptr_t offsets; };進(jìn)程枚舉用CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0)遍歷配合Process32FirstW/NextW按可執(zhí)行文件名過濾就能一次抓到所有同名客戶端。每個(gè) Session 獨(dú)享一個(gè)句柄避免多線程共用一個(gè)ProcessReader時(shí)的狀態(tài)競(jìng)爭(zhēng)。這個(gè)改法不難難點(diǎn)在于 HUD 的排布——多塊面板疊在一起會(huì)互相遮擋我一般按窗口在屏幕上的相對(duì)位置自動(dòng)錯(cuò)開或者干脆只在一塊面板里堆疊多行文本。5. 避坑與常見問題句柄失效、偏移漂移、殺軟誤報(bào)5.1 句柄與權(quán)限類問題現(xiàn)象工具啟動(dòng)后日志里反復(fù)出現(xiàn)OpenProcess failed, err5或者初始能讀到數(shù)據(jù)切個(gè)角色之后數(shù)值就卡住不動(dòng)了。原因err5是權(quán)限不足通常是目標(biāo)客戶端以管理員身份運(yùn)行而工具沒有數(shù)值卡住多半是客戶端重啟過PID 變了舊句柄已經(jīng)失效但代碼還拿著它讀ReadProcessMemory會(huì)持續(xù)返回失敗。解決啟動(dòng)時(shí)先嘗試提權(quán)失敗就提示用管理員重啟采樣線程里加一個(gè)輕量的存活檢測(cè)WaitForSingleObject(handle, 0)返回WAIT_OBJECT_0就說明進(jìn)程沒了此時(shí)重新枚舉進(jìn)程、重新Attach、重新解析基址。重連邏輯一定要寫否則用戶每次重啟客戶端都得關(guān)一次工具體驗(yàn)非常糟。5.2 偏移鏈與版本漂移現(xiàn)象昨天還好好的客戶端更新一次之后血量全是 0 或者顯示離譜的數(shù)字。原因客戶端版本一更新結(jié)構(gòu)體布局和全局基址都會(huì)動(dòng)偏移鏈直接失效。這是這類工具最典型的「版本漂移」幾乎跟客戶端更新周期同步。解決把偏移鏈全部挪進(jìn)offsets.ini代碼里不寫死任何一個(gè)數(shù)字。再加一層校驗(yàn)讀到的最大血量是否落在合理區(qū)間比如 1 到 10 萬不滿足就判定為無效并打日志。更新后只需要用scanner重新掃一遍改 ini 就行不用重新編譯。我自己的習(xí)慣是給 ini 加一個(gè)version字段和客戶端版本號(hào)對(duì)上出問題時(shí)一眼能看出是不是配置過期。5.3 位數(shù)與字節(jié)對(duì)齊現(xiàn)象明明偏移鏈?zhǔn)菑牧硪慌_(tái)機(jī)器上抄來的對(duì)方能用自己這邊解出來是個(gè)固定但毫無意義的地址。原因工具編成了 x64目標(biāo)是 32 位進(jìn)程。指針從 4 字節(jié)變成 8 字節(jié)每一級(jí)偏移都錯(cuò)位最終算出來的地址自然到處亂飛。解決工程配置鎖死 Win32代碼里所有指針中間變量用uint32_t而不是uintptr_t并在Attach時(shí)用IsWow64Process檢查一次位數(shù)不匹配就在日志里明確提示。多花這十行代碼能省掉后面幾個(gè)小時(shí)盯著地址發(fā)呆。5.4 殺毒軟件誤報(bào)現(xiàn)象自己編譯出來的 exe雙擊就沒了或者被攔下來提示可疑。原因OpenProcessReadProcessMemory這套組合本身就是大量灰色工具的標(biāo)準(zhǔn)動(dòng)作行為特征很扎眼加上個(gè)人編譯的 exe 沒有數(shù)字簽名啟發(fā)式引擎容易直接判可疑。解決最穩(wěn)的是自己從源碼編譯別用來源不明的成品 exe給工具目錄加白名單如果做團(tuán)隊(duì)內(nèi)部分發(fā)走代碼簽名。這類問題沒有根治辦法只能降低誤傷概率。順帶說一句這類工具在聯(lián)網(wǎng)對(duì)戰(zhàn)環(huán)境里使用會(huì)破壞公平性也可能違反用戶協(xié)議拿來做內(nèi)存讀寫的技術(shù)驗(yàn)證、自己搭的單機(jī)環(huán)境里跑跑是更合適的使用姿勢(shì)。5.5 懸浮窗的位置漂移現(xiàn)象HUD 明明跟著游戲窗口走但換到高分辨率或副屏上之后面板總是偏出一段距離。原因進(jìn)程沒有聲明 DPI 感知系統(tǒng)做了虛擬化縮放GetWindowRect返回的邏輯坐標(biāo)和實(shí)際物理坐標(biāo)之間差了一個(gè)縮放系數(shù)。解決進(jìn)程啟動(dòng)最早期調(diào)用SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)然后在WM_DPICHANGED里重新計(jì)算窗口尺寸。副屏坐標(biāo)可能是負(fù)數(shù)主屏左側(cè)的顯示器所有坐標(biāo)計(jì)算統(tǒng)一用LONG不要用UINT否則負(fù)數(shù)會(huì)被當(dāng)成一個(gè)巨大的正數(shù)窗口直接飛到屏幕外。6. 二次開發(fā)的改造思路從「看血」擴(kuò)成狀態(tài)面板把這份源碼跑通之后真正有意思的是往下擴(kuò)。它現(xiàn)在只讀一對(duì)current/maximum但偏移鏈機(jī)制是完全通用的只要你能定位到某個(gè)字段的地址就能把 MP、經(jīng)驗(yàn)、坐標(biāo)、背包數(shù)量一并讀出來做成一塊多行 HUD。改造路徑我建議按這個(gè)順序走風(fēng)險(xiǎn)從低到高。步驟改動(dòng)點(diǎn)驗(yàn)證方式1offsets.ini增加一組鍵值對(duì)改完直接重啟工具看日志是否解析成功2Sampler從讀一個(gè)字段擴(kuò)成讀一個(gè)結(jié)構(gòu)體在面板上多加一行文本數(shù)值與游戲內(nèi)對(duì)得上3Session化支持多 PID同時(shí)開兩個(gè)客戶端兩塊 HUD 各自獨(dú)立刷新4繪制換成可配置布局改 ini 里的坐標(biāo)和字號(hào)面板跟著變第 1 步純配置零風(fēng)險(xiǎn)。第 2 步要注意結(jié)構(gòu)體跨頁的問題如果血量、魔法值在內(nèi)存里隔得比較遠(yuǎn)別用一次ReadProcessMemory讀一大塊分開讀更穩(wěn)每次讀之前都做一次ResolvePointer雖然多幾微秒但某一級(jí)失效時(shí)不會(huì)把整塊數(shù)據(jù)帶臟。第 3 步是最容易翻車的地方。多個(gè) Session 共用一個(gè)std::vectorSession本身沒問題但每個(gè) Session 內(nèi)的ProcessReader持有獨(dú)立句柄絕對(duì)不能在采樣線程和 UI 線程之間共享同一個(gè) Reader——m_handle一旦在多處被Detach和Attach交錯(cuò)調(diào)用讀出來的東西就是隨機(jī)數(shù)這類問題在日志里幾乎沒有痕跡是個(gè)黑匣子。我的做法是給每個(gè) Reader 加一個(gè)std::atomic_flag做「使用中」標(biāo)記調(diào)試期一旦檢測(cè)到并發(fā)訪問就直接斷言退出上生產(chǎn)再關(guān)掉。驗(yàn)證方法也要配套。改完偏移鏈之后別只盯著面板看加一個(gè)隱藏的調(diào)試模式比如啟動(dòng)參數(shù)帶--dump每 5 秒往日志里打一行「地址、原始字節(jié)、解析值」和游戲內(nèi)數(shù)值人工比對(duì)三次以上。血量滿值、受傷、切圖、死亡各看一次四種狀態(tài)下都對(duì)得上才敢說這條鏈?zhǔn)欠€(wěn)的。只測(cè)一次滿血很容易漏掉指針在中途被重新分配的情況。繪制層面還有一個(gè)容易忽略的點(diǎn)HUD 窗口是置頂?shù)娜绻w住了目標(biāo)窗口的關(guān)閉按鈕或者輸入框用戶會(huì)很煩。給面板加一個(gè)可拖拽區(qū)域拖拽時(shí)臨時(shí)去掉WS_EX_TRANSPARENT松手再恢復(fù)這個(gè)小功能實(shí)現(xiàn)起來不到三十行但對(duì)日常使用的體感提升很明顯。從那以后我每次改偏移相關(guān)的東西都會(huì)強(qiáng)制先跑一遍--dump在四個(gè)狀態(tài)下比對(duì)再回頭看面板——直接盯著 UI 改是最容易騙自己的數(shù)字看著差不多就以為對(duì)了實(shí)際可能只是巧合。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取