Windows下網(wǎng)絡(luò)數(shù)據(jù)報(bào)的監(jiān)聽和攔截技術(shù)

1、Win dows下網(wǎng)絡(luò)數(shù)據(jù)報(bào)的監(jiān)聽和攔截技術(shù) 1Windows 下網(wǎng)絡(luò)數(shù)據(jù)報(bào)的監(jiān)聽和攔截技術(shù)是一個(gè)比較古老的話題， 應(yīng)用 也很廣泛，例如防火墻等等。這篇小文只是對(duì)該技術(shù)的一個(gè)總結(jié)，沒有新技術(shù)，高手免看：)要監(jiān)聽和攔截 Windows下的數(shù)據(jù)報(bào)，基本可以在兩個(gè)層次進(jìn)行，一個(gè)是 用戶態(tài) (user-mode) ，一個(gè)是核心態(tài) (kernel-mode) 。在用戶態(tài)下，從高到低大概有四種方法。1 、原是套結(jié)字(Raw Socket)。Winsock2以后提供了原始套結(jié)字功能， 可以在用戶態(tài)用Win sock函數(shù)接收所有流經(jīng) Win sock的IP包。這種方法在MSDNH面有敘述，是 MS官方支持的方

2、法，在網(wǎng)上也有很多資料。 但是這種方法只能監(jiān)聽但是不能攔截?cái)?shù)據(jù)報(bào)， 所 以可以作為網(wǎng)絡(luò)監(jiān)視器的選擇技術(shù)， 但是不能實(shí)現(xiàn)防火墻等更高要求的功能。 另外最致 命的缺點(diǎn)就是只能在 Winsock 層次上進(jìn)行，而對(duì)于網(wǎng)絡(luò)協(xié)議棧中底層協(xié)議的數(shù)據(jù)包例如 TDI 無法進(jìn)行處理。對(duì)于一些木馬和病毒來說很容易避開這個(gè)層次的監(jiān)聽。2 、替換系統(tǒng)自帶的 WINSOC動(dòng)態(tài)連接庫(kù)。這種方法可以在很多文章里 面找到詳細(xì)的實(shí)現(xiàn)細(xì)節(jié)。 通過替換系統(tǒng) Winsock 庫(kù)的部分導(dǎo)出函數(shù)，實(shí)現(xiàn)數(shù)據(jù)報(bào)的監(jiān)聽和攔截。 缺點(diǎn)同 1。3、Win sock 服務(wù)提供者（SPI）。SPI 是 Win sock 的另一面，是 Win sock2

3、的一個(gè)新特性。起初的Win sock是圍繞著TCP/IP協(xié)議運(yùn)行的，但是在 Win sock 2中卻增加了對(duì) 更多傳輸協(xié)議的支持。Winsock2不僅提供了一個(gè)供應(yīng)用程序訪問網(wǎng)絡(luò)服務(wù)的Windowssocket應(yīng)用程序編程接口（ API），還包含了由傳輸服務(wù)提供者和名字解析服務(wù)提供者實(shí)現(xiàn)的Winsock服務(wù)提供者接口（ SPI ）和ws2_32.dll。Win sock 2的傳輸服務(wù)提供者是以動(dòng)態(tài) 鏈接庫(kù)的形式（DLL存在的。以下是 win sock 2在傳輸服務(wù)提供者上的 WOSAWi ndows 開放服務(wù)結(jié)構(gòu)） :|Windows socket 2 應(yīng)用程序 |Windows socket

4、 2 API| WS2_32.DLL |Windows socket 2傳輸 SPI| 傳輸服務(wù)提供者（ DLL） |Windows socket SPI 提供三種協(xié)議：分層協(xié)議，基礎(chǔ)協(xié)議和協(xié)議鏈。分層協(xié)議 是在基礎(chǔ)協(xié)議的上層，依靠底層基礎(chǔ)協(xié)議實(shí)現(xiàn)更高級(jí)的通信服務(wù)?；A(chǔ)協(xié)議是能夠獨(dú)立， 安全地和遠(yuǎn)程端點(diǎn)實(shí)現(xiàn)數(shù)據(jù)通信的協(xié)議， 它是相對(duì)與分層協(xié)議而言的。 協(xié)議鏈?zhǔn)菍⒁幌?列的基礎(chǔ)協(xié)議和分層協(xié)議按特點(diǎn)的順序連接在一起的鏈狀結(jié)構(gòu)， 可以通過 Platform SDK 附帶的工具Sporder.exe察看系統(tǒng)已經(jīng)安裝的SPI，請(qǐng)參見下圖：API| WS2_32.DLL |SPI| 分層協(xié)議 |SPI|

5、分層協(xié)議 |SPI| 基礎(chǔ)協(xié)議 |每個(gè)應(yīng)用程序通過 Ws2_32.dll 和相應(yīng)的服務(wù)提供者進(jìn)行嚴(yán)格的數(shù)據(jù)交 換。 Ws2_32.dll根據(jù)應(yīng)用程序在創(chuàng)建套接字時(shí)所提供的參數(shù)來選擇特定的服務(wù)提供者， 然后把應(yīng)用 程序的實(shí)現(xiàn)過程轉(zhuǎn)發(fā)由所選創(chuàng)建套接字的服務(wù)提供者來管理。也就是說， Ws2_32.dll 只是一個(gè)中間過程， 而應(yīng)用程序只是一個(gè)接口， 數(shù)據(jù)通信的實(shí)現(xiàn)卻是由服務(wù)提供者來完成 的。所以我們通過適當(dāng)?shù)脑黾幼约旱姆謱訁f(xié)議服務(wù)提供者， 使其位于 SPI 的頂端，那么 就能將 Ws2_32.dll傳給服務(wù)提供者的數(shù)據(jù)報(bào)攔截下來。由于是MS的官方方法，具體的使用方法在其Platform SDK里面有

6、詳細(xì)的例子（LSP），在MSDN!面也有詳細(xì)的解釋。這種 方法的優(yōu)點(diǎn)是能夠獲得調(diào)用Win sock的進(jìn)程的詳細(xì)信息，并能實(shí)現(xiàn)Qos和數(shù)據(jù)加密。所以 SPI 是用戶態(tài)數(shù)據(jù)攔截的較好地點(diǎn)。缺點(diǎn)同 1。4 、Windows2000包過濾接口。由于過濾規(guī)則限制太多不靈活而應(yīng)用不 多。5 、網(wǎng)絡(luò)監(jiān)視器SDK MS官方的實(shí)時(shí)監(jiān)視分析網(wǎng)絡(luò)數(shù)據(jù)的方法。但是由 于封裝的太復(fù) ?使用起來不靈活。在核心態(tài)下， 數(shù)據(jù)報(bào)的監(jiān)視和攔截方法比較復(fù)雜， 由于大多個(gè)人防火墻 都是在核心 ?實(shí)現(xiàn)的，所以在這里比較詳細(xì)的敘述一下。具體的請(qǐng)參見 nt/2kDDK 文檔。大概 有下面幾個(gè)方法。1、 TDI 過濾驅(qū)動(dòng)程序( TDI Fi

7、lter Driver )。2、 NDIS 中間層驅(qū)動(dòng)程序( NDIS Intermediate Driver )。編寫 IM DRIVER 在 NDIS 中間層對(duì)MINIPORT(網(wǎng)卡驅(qū)動(dòng)程序)和協(xié)議驅(qū)動(dòng)程序之間的數(shù)據(jù)包進(jìn)行攔截。這是微 軟提供的一種技術(shù)。在DDK中MS提供了 Passthru例子，很多中間層過濾驅(qū)動(dòng)都可以由之 改編。但編寫該過濾程序攔截程序非常的復(fù)雜，安裝也很麻煩。3、 Win2k Filter-Hook Driver 。4、NDIS Hook Driver這種方法又有兩種實(shí)現(xiàn)方式(1)向NDIS注冊(cè)假協(xié)議(fake protocol )。這是在協(xié)議層上的處理。在 Wind

8、ows內(nèi)核中 ，所有已注冊(cè)的協(xié)議是通過一個(gè)單向的協(xié)議鏈表來維護(hù)的。 這個(gè)單向鏈表保存了 所有已 注冊(cè)協(xié)議的NDIS_PROTOCOL_BL結(jié)CK的地址，在這個(gè)結(jié)構(gòu)中保存了協(xié)議驅(qū)動(dòng)所 指定的相 應(yīng)的派發(fā)函數(shù)的地址如RECEIVE_HANDL等R struct _NDIS_PROTOCOL_BLOCKPNDIS_OPEN_BLOCK OpenQueue; / queue of opens for this protocolREFERENCE Ref; / contains spinlock for OpenQueueUINT Length; / of this NDIS_PROTOCOL_BLOC

9、K structNDIS50_PROTOCOL_CHARACTERISTICS ProtocolCharacteristics;/ handleraddresses struct _NDIS_PROTOCOL_BLOCK * NextProtocol; / Link to next ULONG MaxPatternSize;#if defined(NDIS_WRAPPER)/ / Protocol filters/ struct _NDIS_PROTOCOL_FILTER * ProtocolFilterNdisMediumMax+1;WORK_QUEUE_ITEM WorkItem; / U

10、sed during NdisRegisterProtocol to/ notify protocols of existing drivers.KMUTEX Mutex; / For serialization of Bind/Unbind requestsPKEVENT DeregEvent; / Used by NdisDeregisterProtocol#endif;typedef struct _NDIS_PROTOCOL_BLOCK NDIS_PROTOCOL_BLOCK, *PNDIS_PROTOCOL_BLOCK;并且，每個(gè)協(xié)議驅(qū)動(dòng)還對(duì)應(yīng)一個(gè) NDIS_OPEN_BLO的單向鏈

11、表來維護(hù)其所綁 定的網(wǎng)卡信息。當(dāng)協(xié)議驅(qū)動(dòng)調(diào)用 NdisRegisterProtocol 之后，EXPORTVOIDNdisRegisterProtocol(OUT PNDIS_STATUS Status,OUT PNDIS_PROTOCOL_BLOCK NdisProtocolHandle,注意 NDIS_HANDL所指向 的就是 PNDIS_PROTOCOL_BLOC結(jié)構(gòu)，不要有什么懷疑。*/IN PNDIS_PROTOCOL_CHARACTERISTICS ProtocolCharacteristics,IN UINT CharacteristicsLength);NDIS總是會(huì)把新注冊(cè)的

12、協(xié)議放在協(xié)議鏈表的表頭并返回這張表，所以只要我們 注冊(cè)一個(gè)新的協(xié)議通過新協(xié)議注冊(cè)返回的鏈表頭就可以輕而易舉的遍歷系統(tǒng)中所有協(xié)議表。但是，如果要成功地掛接派發(fā)函數(shù)，還需要對(duì)協(xié)議所對(duì)應(yīng)的NDIS_OPEN_BLO結(jié)勾里 的派發(fā)函數(shù)進(jìn)行掛接，因?yàn)镹DIS并不是直接調(diào)用協(xié)議驅(qū)動(dòng)在NDIS_PROTOCOL_CHARACTERIS所注S冊(cè)的派發(fā)函數(shù)地址，而是調(diào)用 NDIS_OPEN_BLO里的派發(fā)函數(shù)。struct _NDIS_OPEN_BLOCKPNDIS_MAC_BLOCK MacHandle; / pointer to our MACNDIS_HANDLE MacBindingHandle; /

13、context when calling MacXX funcsPNDIS_ADAPTER_BLOCK AdapterHandle; / pointer to our adapterPNDIS_PROTOCOL_BLOCK ProtocolHandle; / pointer to our protocolNDIS_HANDLPErotocolBindingContext;/ context when calling ProtXX funcsPNDIS_OPEN_BLOCK AdapterNextOpen; / used by adapter's OpenQueuePNDIS_OPEN_

14、BLOCK ProtocolNextOpen; / used by protocol's OpenQueuePFILE_OBJECT FileObject; / created by operating systemBOOLEAN Closing; / TRUE when removing this structBOOLEAN Unloading; / TRUE when processing unloadBOOLEAN NoProtRsvdOnRcvPkt; / Reflect the protocol_optionsNDIS_HANDLE CloseRequestHandle; /

15、 0 indicates an internal closeKSPIN_LOCK SpinLock; / guards ClosingPNDIS_OPEN_BLOCK NextGlobalOpen;/ These are optimizations for getting to MAC routines. They are not/ necessary, but are here to save a dereference through the MAC block./SEND_HANDLER SendHandler;TRANSFER_DATA_HANDLER TransferDataHand

16、ler;/ These are optimizations for getting to PROTOCOroLutines. They are not/ necessary, but are here to save a dereference through the PROTOCOL block./SEND_COMPLETE_HANDLER SendCompleteHandler;TRANSFER_DATA_COMPLETE_HANDLER TransferDataCompleteHandler;RECEIVE_HANDLER ReceiveHandler;RECEIVE_COMPLETE_

17、HANDLER ReceiveCompleteHandler;/ Extentions to the OPEN_BLOCK since Product 1./RECEIVE_HANDLER PostNt31ReceiveHandler;RECEIVE_COMPLETE_HANDLER PostNt31ReceiveCompleteHandler;/ NDIS 4.0 extensions/RECEIVE_PACKET_HANDLER ReceivePacketHandler;SEND_PACKETS_HANDLER SendPacketsHandler;/ More NDIS 3.0 Cach

18、ed Handlers/RESET_HANDLER ResetHandler;REQUEST_HANDLER RequestHandler;/ Needed for PnP/UNICODE_STRING AdapterName; / Upcased name of the adapter we are bound to;這張表是一個(gè)單向鏈接表，并且存放了和 PNDIS_OPEN_BLOCK->ProtocolCharacteristic一樣的數(shù)據(jù)收發(fā)派發(fā)函數(shù)，當(dāng)?shù)贜塊網(wǎng)卡發(fā)送數(shù)據(jù)包到第N個(gè)協(xié)議時(shí)，就會(huì)調(diào)用 第 N 個(gè)協(xié)議與第 N 個(gè)網(wǎng)卡之間建立的NDIS_OPEN_BLO表K!的 Sen

19、dHandler 或 SendPacketHandler。所以我們還需要 對(duì)這張表里的派發(fā)函數(shù)進(jìn)行處理（勾掛）。義是值得注意的是，在 Windows9x/Me/NT的 DDK中 NDIS_PROTOCOL_BL的 很明確的， 而在Windows2000/xp的DD知，并沒有該結(jié)構(gòu)的詳細(xì)定義，也就是說該結(jié)構(gòu)在Windows2000/xp 下是非公開的，因此開發(fā)人員需要利用各種調(diào)試工具來發(fā)掘該結(jié)構(gòu)的詳 細(xì)定義。也正是因?yàn)槿绱耍?這種方法對(duì)平臺(tái)的依賴性比較大， 需要在程序中判斷不同的操 作系統(tǒng)版本而使用不同的結(jié)構(gòu)定義。 可以用 NdisOpenProtocolConfiguration 打開協(xié)議 配

20、置，用NdisReadC on figuration 查詢 NDIS 版本。下面的函數(shù)注冊(cè)fake protocol 并將PNDIS_PROTOCOL_BL結(jié)CK存在 ProtHandle 中 NDIS_HANDLE GetProtocolBlock()NDIS_PROTOCOL_CHARACTERISTICS PChars;NDIS_STRINGName;NDIS_HANDLEProtHandle;NDIS_STATUSStatus;NdisZeroMemory(&PChars, sizeof(NDIS_PROTOCOL_CHARACTERISTICS);PChars.MajorNd

21、isVersion = 5;PChars.MinorNdisVersion = 0;NdisInitUnicodeString(&Name, L"WssFW"); / Protocol namePChars.Name = Name;PChars.OpenAdapterCompleteHandler = NULL;PChars.CloseAdapterCompleteHandler = NULL;PChars.SendCompleteHandler = NULL;PChars.TransferDataCompleteHandler = NULL;PChars.Rese

22、tCompleteHandler = NULL; PChars.RequestCompleteHandler = NULL; PChars.ReceiveHandler = NULL; PChars.ReceiveCompleteHandler = NULL; PChars.StatusHandler = NULL; PChars.StatusCompleteHandler = NULL; PChars.BindAdapterHandler = NULL; PChars.UnbindAdapterHandler = NULL; PChars.UnloadHandler = NULL; PCha

23、rs.ReceivePacketHandler = NULL; PChars.PnPEventHandler= NULL;NdisRegisterProtocol(&Status,&ProtHandle, &PChars,sizeof(NDIS_PROTOCOL_CHARACTERISTICS);ASSERT(Status = NDIS_STATUS_SUCCESS);if(Status = NDIS_STATUS_SUCCESS)return ProtHandle;elsereturn NULL;F面的函數(shù)掛接 PNDIS_PROTOCOL_BLOCKPNDIS PR

24、OTOCOL CHARACTERI結(jié)TC的 R eceiveHandler 和 ReceivePacketHandlerPVOIDHookProtoFunc(PNDIS_PROTOCOL_CHARACTERISTICSpCharacteristics,DWORD dwFunctionCode,PVOID pfuncNew,DWORD dwNdisVersion)PVOID pOldFunc = NULL;/Check parametersif( (!pCharacteristics ) | (!pfuncNew) )return NULL;switch(dwFunctionCode)case

25、PROTO_RECEIVE_HANDLER:/Just hook once!if(pCharacteristics->ReceiveHandler != pfuncNew )pOldFunc = pCharacteristics->ReceiveHandler;if( pOldFunc )pCharacteristics->ReceiveHandler = pfuncNew; break;pfuncNew)case PROTO_RECEIVE_PACKET_HANDLER: if(pCharacteristics->ReceivePacketHandler != /if

26、 pOpenBlock is NULL or pOpenBlock->ReceivePacketHandler is NULL,/just hook Characteristics;pOldFunc = pCharacteristics->ReceivePacketHandler;if(pOldFunc)pCharacteristics->ReceivePacketHandler = pfuncNew break;default:break;return pOldFunc;下面的函數(shù)掛接PNDIS_OPEN_BLO結(jié)構(gòu)里的ReceiveHandler和ReceivePacke

27、tHandlerPVOIDHookBlockFunc(PNDIS_OPEN_BLOCK pFirstOpenBlock,DWORD dwFunctionCode,PVOID pfuncNew,DWORD dwNdisVersion)RECEIVE_HANDLER * pReceiveHandler = NULL;RECEIVE_PACKET_HANDLER * pReceivePacketHandler = NULL; / PVOID pFuncHandler = NULL;PVOID pOldFunc = NULL;PNDIS_OPEN_BLOCK pOpenBlock = pFirstOpenBlock;if(!pFirstOpenBlock)return NULL;if