簡介面向Windows網(wǎng)絡(luò)編程、安全審計與逆向分析開發(fā)者的實戰(zhàn)資源以VC6工程形式演示如何攔截ws2_32.dll中的send()函數(shù)在數(shù)據(jù)發(fā)出前捕獲并寫入OB文件這一思路可自然延展至recv()實現(xiàn)雙向收發(fā)記錄適用于網(wǎng)絡(luò)監(jiān)控、性能分析、底層通信行為驗證也適合作為學習Windows下函數(shù)攔截與hook技術(shù)的入門范例還可作為課程設(shè)計或畢業(yè)設(shè)計的參考資料。資源整體為23個文件、約898KB的rar壓縮包內(nèi)容覆蓋完整開發(fā)鏈路既有ws2_32.cpp、StdAfx.cpp等核心源碼與頭文件也有dll、lib、exp、obj、pdb、ilk等編譯鏈接與調(diào)試產(chǎn)物同時保留dsp、dsw、opt、plg等VC6工程配置及ReadMe、說明文檔可直接打開工程對照代碼理解鉤子從編寫到生成可執(zhí)行文件的完整過程。目前已有1258人學習下載適合具備C/C與Winsock基礎(chǔ)、希望深入研究系統(tǒng)底層攔截機制的開發(fā)者與安全研究者屬于輕量且可直接編譯運行的完整范例無需復雜依賴與額外配置。資源在示例代碼中詳細展示了send()函數(shù)的四個參數(shù)含義呈現(xiàn)了基于導入地址表(IAT)的API鉤子掛載方式以及調(diào)用原始send()前捕獲發(fā)送緩沖區(qū)并寫入OB文件的處理流程保留的pdb調(diào)試信息和obj中間文件有助于分析鉤子在編譯鏈接層面的工作機理同時在Detours等庫的基礎(chǔ)上可繼續(xù)改造也可結(jié)合recv()擴展雙向通信記錄為自制網(wǎng)絡(luò)監(jiān)控工具、安全審計腳本或協(xié)議分析插件提供直接參考。此外這類攔截技術(shù)會直接影響系統(tǒng)穩(wěn)定性與數(shù)據(jù)隱私資源中也未回避對安全性和合法性的提醒使用者需在合規(guī)場景下實踐。 最近在分析一個老客戶端的通信協(xié)議抓包工具看著流量一頭霧水——應(yīng)用層自己套了一層異或加密wireshark 只能看到密文。我決定換一條路從進程內(nèi)部下手直接攔截 ws2_32.dll 的 send 函數(shù)把程序發(fā)送出去的原始內(nèi)容寫進一個 ob 文件慢慢逆向它的明文協(xié)議。說白了就是做一個“同目錄版”的 ws2_32.dll導出表里把 send 換成自己的實現(xiàn)其余函數(shù)全部轉(zhuǎn)發(fā)給原版副本這樣目標程序根本不知道自己已經(jīng)被監(jiān)控。這個方案不需要驅(qū)動、不需要全局 hook只要把兩個 DLL 放到目標 exe 旁邊就能跑起來。想搞懂 Windows 網(wǎng)絡(luò)程序底層的同學或者經(jīng)常做老程序逆向、沙箱行為分析的人看完這篇應(yīng)該能直接落地。1. 抓包工具看不見的那一層為什么要做進程內(nèi)攔截很多人的第一反應(yīng)是“抓包不就行了嗎”但實際做過協(xié)議分析就明白基于 WinPcap/Npcap 的抓包工具工作在協(xié)議棧下層只能看到 IP 分片、TCP 段和重組后的字節(jié)流。問題在于程序在應(yīng)用層發(fā)送的數(shù)據(jù)很可能不是你想分析的那份明文。常見的情況有這么幾種。第一種是程序?qū)Πl(fā)送內(nèi)容做了自加密。比如私服客戶端、網(wǎng)游登錄器它們通常在應(yīng)用層先把 payload 加密或異或一遍再交給 send。抓包工具拿到的已經(jīng)是密文你要么去逆向它的加密算法要么在數(shù)據(jù)加密之前或解密之后的位置插入觀察點。第二種是程序用了 TLS/SSL雖然數(shù)據(jù)在網(wǎng)絡(luò)上也是密文但你并不想為了分析一個老協(xié)議去折騰 TLS 密鑰導出。第三種更輕微但也很煩抓包工具看不到發(fā)送這個動作的上下文比如這個 socket 是誰創(chuàng)建的、是哪個線程調(diào)用、flags 參數(shù)是什么。這些信息對定位問題特別有價值。進程內(nèi)攔截剛好能補上這幾塊空白。攔截 send 函數(shù)意味著你在數(shù)據(jù)真正進入系統(tǒng)協(xié)議棧之前就能拿到它而且可以順帶拿到 socket 句柄、flags、時間戳、進程 ID。從這個角度看它更像“應(yīng)用層行為審計”而不是“網(wǎng)絡(luò)流量鏡像”。我選擇“攔截 send 并寫入 ob 文件”這個切入點是因為它足夠簡單、足夠直觀。ob 文件不是某個官方格式而是我自定義的一種二進制日志原始內(nèi)容是什么文件里就存什么。這樣后續(xù)無論是寫 Python 腳本解析還是用 010 Editor 對照協(xié)議結(jié)構(gòu)看都非常方便。做這種分析工作最忌諱的就是在還原數(shù)據(jù)這一步給自己增加額外負擔。2. 為什么“同名 DLL 劫持”就相當于替 send 換了一個入口要理解這個方案先得說清楚程序調(diào)用 send 時實際發(fā)生了什么。一個 C/C 程序編譯時如果鏈接了 ws2_32.lib并且調(diào)用了 send那么它生成的可執(zhí)行文件里導入表會記錄一條“從 ws2_32.dll 導入名為 send 的函數(shù)”的記錄。程序啟動時Windows 加載器找到 ws2_32.dll把 send 這個函數(shù)的真實地址寫入進程內(nèi)存里的一個表這個表就是 IATImport Address Table。之后程序每一次調(diào)用 send實際是從 IAT 里取地址再跳過去。所以攔截 send 有兩種經(jīng)典思路。第一種叫 Inline Hook直接修改系統(tǒng) ws2_32.dll 里 send 函數(shù)入口處的機器碼讓它跳轉(zhuǎn)到我們的函數(shù)。這種做法的優(yōu)勢是攔截能力強只要程序最終調(diào)用了系統(tǒng) DLL 里的 send 就一定躲不過缺點是風險高需要考慮指令長度對齊、線程并發(fā)、調(diào)試器兼容、多次 Hook 沖突等一系列問題。第二種就是這里要用的思路既然加載器是按“模塊名 函數(shù)名”來填 IAT 的那我們就讓加載器把 IAT 里的 send 項直接指向我們自己的實現(xiàn)。做法就是做一個同目錄的偽 ws2_32.dll讓加載器優(yōu)先加載它再讓它的導出表里的 send 變成我們的代碼。這兩種方案的對比很直觀對比維度Inline Hook同名 DLL 劫持 替換導出原理修改系統(tǒng) DLL 函數(shù)入口字節(jié)碼利用 DLL 搜索順序加載偽 DLL替換導出函數(shù)實現(xiàn)難度高需要考慮指令修復、重定位低只要寫好 def 文件和導出函數(shù)穩(wěn)定性中容易被安全軟件查殺或與其他 Hook 沖突高屬于加載器的正常行為攔截范圍能攔截所有對 send 的調(diào)用能攔截通過導入表或 GetProcAddress 獲取 send 的調(diào)用風險寫錯一個字節(jié)可能直接崩進程導出表不全會在啟動時報缺函數(shù)這個方案之所以可行還有一個關(guān)鍵前提ws2_32.dll 不在系統(tǒng)的 KnownDLLs 列表里。KnownDLLs 是一組被系統(tǒng)提前鎖定加載路徑的模塊比如 kernel32.dll、user32.dll這些模塊即使在 exe 同目錄放了同名文件也不會被劫持。而 ws2_32.dll 不在這份名單中加上 Windows 默認的 DLL 搜索順序是“應(yīng)用程序目錄優(yōu)先于系統(tǒng)目錄”所以把偽 ws2_32.dll 放到目標 exe 同目錄加載器就會優(yōu)先加載它。很多惡意軟件以前就是靠這個機制做 DLL 劫持我這里只是把它用在合法的協(xié)議分析場景里。有人可能會問如果目標程序不是靜態(tài)導入 send而是自己用 LoadLibrary 加 GetProcAddress 動態(tài)獲取函數(shù)地址這個方案還生效嗎答案是仍然生效。因為動態(tài)獲取時 GetProcAddress 拿到的是偽 ws2_32.dll 導出表里的 send 地址也就是我們的函數(shù)。唯一攔不住的情況是程序加載了完整路徑下的系統(tǒng)原版 ws2_32.dll比如 LoadLibraryA(C:\Windows\System32\ws2_32.dll)這種少數(shù)情況才需要上 Inline Hook 或者做驅(qū)動層方案那不是本文討論的范圍。3. 動手做復制原版、寫 def、實現(xiàn) MySend 和 ob 日志3.1 先把原版 ws2_32.dll 復制成 ws2_32_org.dll構(gòu)建偽 DLL 之前要先把“原版函數(shù)”準備好。思路是讓偽 ws2_32.dll 的導出表里除了 send 之外的所有函數(shù)都“轉(zhuǎn)發(fā)”給另一個 DLL 里的對應(yīng)函數(shù)這個 DLL 就是原版 ws2_32.dll 的副本。我給這個副本起名 ws2_32_org.dll和偽 DLL 放在同一個目錄。復制時注意位數(shù)如果你的目標程序是 32 位的就去 C:\Windows\SysWOW64 下復制 ws2_32.dll如果是 64 位的就去 C:\Windows\System32 下復制。弄反了的話后面雖然加載不會報錯但函數(shù)調(diào)用時會因為約定不一致直接崩潰。把原版復制到項目目錄后改名為 ws2_32_org.dll。這樣偽 DLL 里所有轉(zhuǎn)發(fā)符號都會指向 ws2_32_org再由它去調(diào)用真正的系統(tǒng)實現(xiàn)等于替目標程序維護了一個完整的“原版替身”。3.2 用 def 文件構(gòu)建一個“只替換 send”的偽 DLL先在 Visual Studio 里建一個空的 Win32 動態(tài)鏈接庫項目項目名隨意最后生成的 DLL 名字必須改成 ws2_32.dll。核心工作集中在 .def 文件上它決定了導出的符號集合。def 文件大致長這樣LIBRARY ws2_32 EXPORTS sendMySend recvws2_32_org.recv sendtows2_32_org.sendto recvfromws2_32_org.recvfrom bindws2_32_org.bind listenws2_32_org.listen acceptws2_32_org.accept connectws2_32_org.connect closesocketws2_32_org.closesocket shutdownws2_32_org.shutdown selectws2_32_org.select WSAStartupws2_32_org.WSAStartup WSACleanupws2_32_org.WSACleanup socketws2_32_org.socket ioctlsocketws2_32_org.ioctlsocket gethostnamews2_32_org.gethostname gethostbynamews2_32_org.gethostbyname gethostbyaddrws2_32_org.gethostbyaddr getaddrinfows2_32_org.getaddrinfo freeaddrinfows2_32_org.freeaddrinfo getnameinfows2_32_org.getnameinfo htonlws2_32_org.htonl htonsws2_32_org.htons ntohlws2_32_org.ntohl ntohsws2_32_org.ntohs inet_addrws2_32_org.inet_addr inet_ntoaws2_32_org.inet_ntoa WSASendws2_32_org.WSASend WSARecvws2_32_org.WSARecv WSAAsyncSelectws2_32_org.WSAAsyncSelect WSAAcceptws2_32_org.WSAAccept WSAEventSelectws2_32_org.WSAEventSelect WSASocketAws2_32_org.WSASocketA WSASocketWws2_32_org.WSASocketW WSAGetLastErrorws2_32_org.WSAGetLastError WSASetLastErrorws2_32_org.WSASetLastError關(guān)鍵就一句話sendMySend是把我們的實現(xiàn)暴露成 send其余所有行都是轉(zhuǎn)發(fā)。這條語法的含義是程序從 ws2_32.dll 導入 send 時會拿到 MySend 函數(shù)地址程序從 ws2_32.dll 導入 recv 時加載器會繼續(xù)沿著 ws2_32_org.recv 的轉(zhuǎn)發(fā)記錄找到原版 recv 并填入 IAT。這樣一來目標程序只是“以為”自己用到了完整的 ws2_32.dll實際只有 send 被掉了包。如果你懶得手敲 def 里的幾百個函數(shù)可以先用 dumpbin 查看原版導出表再寫腳本把導出名批量生成轉(zhuǎn)發(fā)行。我一般直接這樣看dumpbin /exports C:\Windows\System32\ws2_32.dll輸出里每個導出函數(shù)都有名稱和序號照著生成轉(zhuǎn)發(fā)行就成。這里補充一句盡量別只按名稱轉(zhuǎn)發(fā)而丟了序號。極少數(shù)老程序是按序號導入 ws2_32 函數(shù)的如果我們的導出表缺了對應(yīng)序號的導出項加載階段照樣報錯。穩(wěn)妥的做法是讓 def 里的序號和原版保持一致比如寫成WSASocketAws2_32_org.WSASocketA 123這種形式。3.3 MySend 的實現(xiàn)記日志再走原函數(shù)現(xiàn)在我們有了偽 DLL 的殼下一步就是把 MySend 寫出來。先定義 send 的函數(shù)指針類型和原函數(shù)地址變量#include winsock2.h #include windows.h #include stdio.h #pragma comment(lib, ws2_32.lib) typedef int (WSAAPI* SendFunc)(SOCKET s, const char* buf, int len, int flags); static SendFunc realSend nullptr; static CRITICAL_SECTION g_logCs; static BOOL g_logInited FALSE;獲取原函數(shù)地址很簡單因為加載器在解析偽 DLL 的轉(zhuǎn)發(fā)導出時已經(jīng)自動把 ws2_32_org.dll 加載進進程了我直接用 GetModuleHandleW 拿到它的模塊句柄再去 GetProcAddress 取 sendstatic void InitSendHook() { if (g_logInited) return; InitializeCriticalSection(g_logCs); HMODULE org GetModuleHandleW(Lws2_32_org.dll); if (org nullptr) { org LoadLibraryW(Lws2_32_org.dll); } realSend (SendFunc)GetProcAddress(org, send); g_logInited TRUE; }緊接著是 MySend 本體。它要做兩件事先把 send 的入?yún)⑦B同原始數(shù)據(jù)寫入 ob 文件再調(diào)用原版 send 把數(shù)據(jù)真正發(fā)出去。注意這里不能換成別的函數(shù)比如不能用 WSASend 代替因為調(diào)用約定雖然類似但語義不同可能影響程序行為。static void WriteSendLog(SOCKET s, const char* buf, int len, int flags) { EnterCriticalSection(g_logCs); HANDLE hFile CreateFileA( send_log.ob, FILE_APPEND_DATA, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, nullptr); if (hFile ! INVALID_HANDLE_VALUE) { DWORD wrote 0; DWORD magic 0x0B5E4E44; ULONGLONG tick GetTickCount64(); DWORD pid GetCurrentProcessId(); WriteFile(hFile, magic, sizeof(magic), wrote, nullptr); WriteFile(hFile, tick, sizeof(tick), wrote, nullptr); WriteFile(hFile, pid, sizeof(pid), wrote, nullptr); WriteFile(hFile, s, sizeof(s), wrote, nullptr); WriteFile(hFile, flags, sizeof(flags), wrote, nullptr); WriteFile(hFile, len, sizeof(len), wrote, nullptr); WriteFile(hFile, buf, len, wrote, nullptr); CloseHandle(hFile); } LeaveCriticalSection(g_logCs); } int WSAAPI MySend(SOCKET s, const char* buf, int len, int flags) { InitSendHook(); WriteSendLog(s, buf, len, flags); return realSend(s, buf, len, flags); }這里我用 CreateFileA 而不是 CRT 的 fopen原因有兩個。一是 CreateFile 可以指定 FILE_SHARE_READ 和 FILE_SHARE_WRITE允許其他工具在程序運行時同時讀這個文件而 fopen 默認會占住文件共享二是 FILE_APPEND_DATA 模式保證寫文件時從尾部追加配合臨界區(qū)就能避免多線程同時寫導致的數(shù)據(jù)錯亂。每條記錄我都單獨打開、寫入、關(guān)閉文件雖然效率不高但好處是即使程序崩潰最后一條日志也已經(jīng)落盤不會丟在未刷新的緩沖區(qū)里。3.4 DllMain 處理與部署要點DllMain 里主要是初始化臨界區(qū)和保證線程庫通知不干擾BOOL WINAPI DllMain(HINSTANCE hInstDll, DWORD reason, LPVOID reserved) { if (reason DLL_PROCESS_ATTACH) { DisableThreadLibraryCalls(hInstDll); InitSendHook(); } return TRUE; }這里有一點要留意DllMain 里并不需要去 LoadLibrary 原版 ws2_32因為 ws2_32_org.dll 作為轉(zhuǎn)發(fā)目標會由加載器自動加載進來。這比在 DllMain 里手動 LoadLibrary 安全得多規(guī)避了 DllMain 在 Loader Lock 下加載模塊出現(xiàn)死鎖的經(jīng)典風險。部署時把 VS 生成的 DLL 改名成 ws2_32.dll與 ws2_32_org.dll 一起放到目標程序 exe 同目錄。然后把目標程序一運行send 就已經(jīng)被劫持了。日志文件 send_log.ob 會生成在程序的當前工作目錄下一般也就是 exe 同目錄如果目標程序主動改了工作目錄那日志文件就會寫到它改后的目錄。想固定輸出位置的話把 CreateFileA 里的相對路徑改成絕對路徑即可。4. “無法定位程序輸入點 gethostnamew”是怎么冒出來的完整排障鏈路第一次做這個方案的人十有八九會踩到“啟動即崩”的坑彈窗提示是“無法定位程序輸入點 gethostnamew 于動態(tài)鏈接庫 ws2_32.dll 上”。我第一次看到這個報錯也懵了一下以為系統(tǒng) DLL 壞了后來一排查問題出在我那個偷懶的 def 文件上。這個報錯的本質(zhì)是加載器在啟動目標程序時發(fā)現(xiàn)目標程序的導入表里需要從 ws2_32.dll 導入一個名為 gethostnamew 的函數(shù)但偽 DLL 的導出表里沒有這個名字。于是加載器在進程正式執(zhí)行第一條指令之前就放棄了加載直接彈出這個錯誤。注意此時我們的 DllMain 可能根本沒機會執(zhí)行完整的初始化因為加載器對導入表的解析和綁定是啟動階段就完成的。復現(xiàn)這個坑很簡單。你可以寫一個最小的 Win32 測試程序在里面調(diào)用 gethostname 或者任何 ws2_32 里的函數(shù)然后只讓偽 DLL 導出 send 一個函數(shù)其余全不導出。運行時你就會看到那條熟悉的彈窗。完整的排查鏈路大概是這樣的先用 Process Monitor 確認目標進程加載的 ws2_32.dll 路徑是不是 exe 同目錄那個。如果路徑正確說明劫持生效了問題出在導出表上。用 dumpbin 查看目標程序?qū)肓?ws2_32 的哪些函數(shù)dumpbin /imports 目標程序.exe找到 ws2_32.dll 這組導入項記下所有需要的函數(shù)名。用 dumpbin 查看偽 DLL 的導出表dumpbin /exports ws2_32.dll逐一比對第二步列出的函數(shù)缺哪個就補哪個。把原版 ws2_32.dll 復制成 ws2_32_org.dll并在 def 里把缺的函數(shù)用轉(zhuǎn)發(fā)行補上。重新編譯部署再次運行直到不再報錯。這里有個很容易忽略的差異不同 Windows 版本的 ws2_32.dll 導出表并不完全一致。老的 XP/2003 系統(tǒng)沒有一些后來新增的函數(shù)而新的 Win10/Win11 系統(tǒng)會多出不少。所以在做劫持時最好直接用目標機器上的原版作為對照基準也就是“目標程序運行在哪臺機器就用那臺機器的 ws2_32.dll 去生成轉(zhuǎn)發(fā)列表”。另外一個常見問題是位數(shù)不匹配。把 64 位編譯出來的偽 DLL 放進 32 位程序的目錄系統(tǒng)加載器會拒絕加載同樣會報出口函數(shù)找不到之類的錯誤。排查時先確認三點目標程序是多少位、偽 DLL 是多少位、ws2_32_org.dll 是從 System32 還是 SysWOW64 復制的。三者必須一致缺一個都會在啟動階段出幺蛾子。5. 驗證鉤子是否生效從 ob 文件反推 Hook 鏈路代碼寫完了最重要的就是驗證。我的測試環(huán)境很樸素一臺 Windows 10 虛擬機一個用 C 寫的簡易 TCP 發(fā)送端本地起一個回環(huán)服務(wù)器接收數(shù)據(jù)。發(fā)送端的核心邏輯就幾行WSAStartup、socket、connect、send、closesocket。把編譯好的偽 ws2_32.dll 和 ws2_32_org.dll 丟到發(fā)送端 exe 的同目錄運行發(fā)送端服務(wù)器正常收到數(shù)據(jù)說明 send 基本沒有影響程序本身。然后打開當前目錄的 send_log.ob用十六進制工具看能看到發(fā)送的明文內(nèi)容。我自定義的 ob 記錄格式是這樣的字段大小說明magic4 字節(jié)固定值 0x0B5E4E44用于識別文件類型tick8 字節(jié)GetTickCount64 的毫秒時間戳pid4 字節(jié)進程 IDsocket4 字節(jié)調(diào)用 send 時的 socket 句柄flags4 字節(jié)send 的 flags 參數(shù)len4 字節(jié)payload 長度payloadlen 字節(jié)實際發(fā)送的原始數(shù)據(jù)這種自定義二進制格式比直接寫文本日志好在哪主要是不需要處理轉(zhuǎn)義和編碼問題。send 發(fā)送的可能是二進制協(xié)議里面什么字節(jié)都有如果寫進文本文件分析時還得考慮不可見字符、換行符、空字節(jié)被截斷的問題。二進制日志則是原樣保留后續(xù)用腳本解析時想怎么處理都行。解析腳本用 Python 寫起來非常短import struct with open(send_log.ob, rb) as f: data f.read() off 0 while off 28 len(data): magic, tick, pid, sock, flags, length struct.unpack_from(IQQIII, data, off) off 28 payload data[off:off length] off length if magic 0x0B5E4E44: print(ftick{tick} pid{pid} sock{sock} flags{flags} len{length}) print(payload)除了看日志內(nèi)容我還建議用 Process Explorer 或 x64dbg 做一次反查確認 Hook 路徑真的走對了。打開 Process Explorer選中目標進程查看 DLL 列表正常情況下能看到兩個關(guān)鍵條目ws2_32.dll 的路徑指向 exe 同目錄ws2_32_org.dll 也在進程里。這證明加載器確實加載了偽 DLL并且因為轉(zhuǎn)發(fā)關(guān)系把原版副本也拉了進來。想進一步確認 send 調(diào)用的具體跳轉(zhuǎn)可以在 x64dbg 里對 MySend 函數(shù)下斷點或者查看目標程序 IAT 中 send 項的地址是否指向偽 DLL 模塊范圍內(nèi)。不過一般來說ob 日志里出現(xiàn)了數(shù)據(jù)就已經(jīng)能說明問題了。6. 穩(wěn)定性和擴展從 send 到 sendto、WSASend 以及高頻寫日志的取舍這套方案跑通很容易但要長期穩(wěn)定運行還有幾個地方值得打磨。多線程是一個繞不開的問題。真實的網(wǎng)絡(luò)程序里多個線程同時調(diào)用 send 太常見了。我上面的實現(xiàn)里用 CRITICAL_SECTION 保護了文件寫入這能防止日志記錄互相覆蓋但要注意鎖的粒度。我的鎖只覆蓋 CreateFile、寫入、CloseHandle 這段沒有覆蓋 realSend 調(diào)用本身否則會讓所有線程的發(fā)送操作串行化對性能影響太大。實際使用中如果發(fā)現(xiàn)寫日志拖慢了程序可以考慮用內(nèi)存環(huán)形緩沖區(qū)把數(shù)據(jù)先拷貝到內(nèi)存由后臺線程異步刷盤。這樣做的好處是 send 調(diào)用幾乎不受影響壞處是程序崩潰時可能丟失最后幾秒的日志。另一個容易踩的坑是在被 Hook 的函數(shù)里再次調(diào)用網(wǎng)絡(luò) API。雖然 MySend 里只是寫文件和調(diào)用 realSend但萬一有人在里面加了一段代碼又去 connect 或者 send就可能出現(xiàn)遞歸調(diào)用輕則死循環(huán)重則爆棧。原則是鉤子函數(shù)內(nèi)部只做與記錄相關(guān)的操作不調(diào)用任何可能觸發(fā)網(wǎng)絡(luò)行為的 API。我自己就吃過一次虧想順手記錄一下 DNS 解析結(jié)果在 MySend 里調(diào)了 getaddrinfo結(jié)果某些版本的 Winsock 內(nèi)部對同一把鎖加了重入保護直接卡死。所以我現(xiàn)在堅持最簡原則進函數(shù)鎖文件寫記錄解鎖調(diào)原函數(shù)返回。如果目標程序用 UDP 偏多那需要順帶把 sendto 也一起截了。sendto 比 send 多了目標地址參數(shù)記錄日志時可以把 sockaddr_in 里的 IP 和端口一起寫進 ob 文件這樣你就能看到每個 UDP 數(shù)據(jù)包發(fā)給了誰。同理如果是重疊 IO 場景程序用 WSASend 而不是 send那也要在 def 里把 WSASend 指向自己的實現(xiàn)。擴展的方式完全一樣只是函數(shù)簽名不同。最后說一個方向上的建議這種“同名 DLL 劫持”方案只適合分析自己可控環(huán)境下的程序做協(xié)議逆向、行為分析、老軟件兼容性調(diào)查都是很好的切入點。如果要把它放到生產(chǎn)環(huán)境或者別人機器上那就越過了技術(shù)討論的邊界我不建議那么用。技術(shù)本身是中性的關(guān)鍵是拿它做什么。就我個人的經(jīng)驗來說這套東西的價值不在于“炫技”而在于幫你把一個黑盒程序變成能看清楚內(nèi)部脈絡(luò)的透明盒子。下一次再遇到加密流量不知道怎么下手的場景不妨先想想是不是可以繞到 send 這個路口去等明文路過。本文還有配套的精品資源點擊獲取