關(guān)鍵字：
封濾技術(shù)，NDIS鉤子，應(yīng)用程序訪問(wèn)網(wǎng)絡(luò)控制，TDI鉤子，智能行為監(jiān)控，反流氓軟件，自我保護(hù)技術(shù)。
本文簡(jiǎn)要介紹了目前流行的Windows軟件防火墻的各個(gè)功能組件，及其實(shí)現(xiàn)方法。
內(nèi)容目錄：
• Windows軟件防火墻的發(fā)展概況
• 封濾技術(shù)
• 應(yīng)用程序訪問(wèn)網(wǎng)絡(luò)控制
• 智能行為監(jiān)控
• 反流氓軟件技術(shù)
• 自我保護(hù)技術(shù)
• 附錄
Windows軟件防火墻的發(fā)展概況
從Windows軟件防火墻的誕生開(kāi)始，這種安全防護(hù)產(chǎn)品就在跟隨著不斷深入的黑客病毒與反黑反毒之爭(zhēng)，不斷的進(jìn)化與升級(jí)。從最早期的只能分析來(lái)源地址，端口號(hào)以及未經(jīng)處理的報(bào)文原文的封濾防火墻，后來(lái)出現(xiàn)了能對(duì)不同的應(yīng)用程序設(shè)置不同的訪問(wèn)網(wǎng)絡(luò)權(quán)限的技術(shù)；近年來(lái)由ZoneAlarm等國(guó)外知名品牌牽頭，還開(kāi)始流行了具有未知攻擊攔截能力的智能行為監(jiān)控防火墻；最后，由于近來(lái)垃圾插件和流氓軟件的盛行，很多防火墻都在考慮給自己加上攔截流氓軟件的功能。綜上，Windows軟件防火墻從開(kāi)始的時(shí)候單純的一個(gè)截包丟包，堵截IP和端口的工具，發(fā)展到了今天功能強(qiáng)大的整體性的安全套件。
接下來(lái)本文就對(duì)一個(gè)Windows軟件防火墻應(yīng)當(dāng)擁有的這些組件進(jìn)行一個(gè)簡(jiǎn)要的技術(shù)介紹。
封濾技術(shù)
封濾技術(shù)是最原始的防火墻所擁有的第一種功能。但是該功能簡(jiǎn)單強(qiáng)大，直到現(xiàn)在都是任何一個(gè)防火墻必不可少的功能。
想要在網(wǎng)絡(luò)數(shù)據(jù)包到達(dá)應(yīng)用程序之前攔截之，就要在系統(tǒng)的網(wǎng)絡(luò)協(xié)議棧上面安裝過(guò)濾鉤子。對(duì)Windows NT系列內(nèi)核來(lái)說(shuō)，可能安裝過(guò)濾鉤子的地方大致是這么幾個(gè)，從高層到底層排序：SPI層（早期的天網(wǎng)防火墻 ），AFD層（資料缺乏，尚無(wú)例子），TDI層（不少國(guó)內(nèi)墻），NDIS層（ZoneAlarm，Outpost等）。越位于高層，則產(chǎn)品開(kāi)發(fā)難度越低，但是功能越弱，越容易被攻擊者所穿越。由于NDIS層的防火墻具有功能強(qiáng)大，不易被穿透等優(yōu)點(diǎn)，近來(lái)各大防火墻廠商的趨勢(shì)是選擇NDIS層來(lái)做濾。
目前比較流行的NDIS鉤子技術(shù)有兩種。一種是掛接ndis.sys模塊的導(dǎo)出函數(shù)，從而能夠在每個(gè)ndis protocol注冊(cè)的時(shí)候截獲其注冊(cè)過(guò)程，從而替換其send(packets)handler和receive(packet)handler。這個(gè)方法的缺點(diǎn)是在第一次安全之后無(wú)法立刻生效，必須要重起一次，而且要禁用的話，也必須重起。
2004年12月的時(shí)候，www.rootkit.com上面的一名黑客發(fā)表了一篇的文章：“Hooking into NDIS and TDI, part 1”（http://www.rootkit.com/newsread.php?newsid=219）。這篇文章本意是為rootkit作者們提供一種掛接底層驅(qū)動(dòng)實(shí)現(xiàn)端口重用的方法，但是這篇文章揭示了一個(gè)全新的技術(shù)：通過(guò)動(dòng)態(tài)的注冊(cè)ndis假協(xié)議，可以獲得ndis protocol的鏈表地址。得到這個(gè)地址之后就能不通過(guò)重起，就能替換并監(jiān)控每個(gè)ndis protocol的send(packets)handler和receive(packet)handler，并且可以動(dòng)態(tài)的卸載監(jiān)控模塊不需要重起。在這篇文章出現(xiàn)之后，很多防火墻廠商都悄悄地對(duì)自己的產(chǎn)品進(jìn)行了升級(jí)。目前的ZoneAlarm等產(chǎn)品就是使用這種技術(shù)，可以在安裝后即時(shí)發(fā)揮作用。這個(gè)例子更充分的體現(xiàn)了，黑客和反黑技術(shù)本來(lái)就是相輔相成的，本源同一的。
這里給出一個(gè)尋找該鏈表頭的代碼例子：
該函數(shù)返回的NDIS_HANDLE就是鏈表頭地址。
NDIS_HANDLE RegisterBogusNDISProtocol(void)
{
NTSTATUS Status = STATUS_SUCCESS;
NDIS_HANDLE hBogusProtocol = NULL;
NDIS_PROTOCOL_CHARACTERISTICS BogusProtocol;
NDIS_STRING ProtocolName;
NdisZeroMemory(&BogusProtocol,sizeof(NDIS_PROTOCOL_CHARACTERISTICS));
BogusProtocol.MajorNdisVersion = 0x04;
BogusProtocol.MinorNdisVersion = 0x0;
NdisInitUnicodeString(&ProtocolName,L"BogusProtocol");
BogusProtocol.Name = ProtocolName;
BogusProtocol.ReceiveHandler = DummyNDISProtocolReceive;
BogusProtocol.BindAdapterHandler = dummyptbindadapt;
BogusProtocol.UnbindAdapterHandler = dummyptunbindadapt;
NdisRegisterProtocol(&Status,&hBogusProtocol,&BogusProtocol,
sizeof(NDIS_PROTOCOL_CHARACTERISTICS));
if(Status == STATUS_SUCCESS){ return hBogusProtocol;}
else {
#ifdef bydbg
DbgPrint("ndishook:cannot register bogus protocol:%x\n",Status);
DbgBreakPoint();
#endif
return NULL;
}
}
得到這個(gè)ndis protocol的鏈表后，遍歷表中的每一個(gè)ndis protocol，對(duì)于每一個(gè)ndis protocol，又各有一個(gè)鏈表，用來(lái)描述和該ndis protocol有聯(lián)系的所有ndis miniport和該ndis protocol綁定的狀態(tài)。每個(gè)這種狀態(tài)塊，叫做一個(gè)ndis open block。每個(gè)綁定的send(packets)handler和receive(packet)handler都在這個(gè)ndis open block里面。
struct _NDIS_OPEN_BLOCK
{
#ifdef __cplusplus
NDIS_COMMON_OPEN_BLOCK NdisCommonOpenBlock;
#else
NDIS_COMMON_OPEN_BLOCK;
#endif
#if defined(NDIS_WRAPPER)
//
// The stuff below is for CO drivers/protocols. This part is not allocated for CL drivers.
//
struct _NDIS_OPEN_CO
{
....
};
#endif
};
typedef struct _NDIS_COMMON_OPEN_BLOCK
{
PVOID MacHandle; // needed for backward compatibility
NDIS_HANDLE BindingHandle; // Miniport's open context
PNDIS_MINIPORT_BLOCK MiniportHandle; // pointer to the miniport
PNDIS_PROTOCOL_BLOCK ProtocolHandle; // pointer to our protocol
NDIS_HANDLE ProtocolBindingContext;// context when calling ProtXX funcs
PNDIS_OPEN_BLOCK MiniportNextOpen; // used by adapter's OpenQueue
PNDIS_OPEN_BLOCK ProtocolNextOpen; // used by protocol's OpenQueue
NDIS_HANDLE MiniportAdapterContext; // context for miniport
BOOLEAN Reserved1;
BOOLEAN Reserved2;
BOOLEAN Reserved3;
BOOLEAN Reserved4;
PNDIS_STRING BindDeviceName;
KSPIN_LOCK Reserved5;
PNDIS_STRING RootDeviceName;
//
// These are referenced by the macros used by protocols to call.
// All of the ones referenced by the macros are internal NDIS handlers for the miniports
//
union
{
SEND_HANDLER SendHandler;
WAN_SEND_HANDLER WanSendHandler;
};
TRANSFER_DATA_HANDLER TransferDataHandler;
//
// These are referenced internally by NDIS
//
SEND_COMPLETE_HANDLER SendCompleteHandler;
TRANSFER_DATA_COMPLETE_HANDLER TransferDataCompleteHandler;
RECEIVE_HANDLER ReceiveHandler;
RECEIVE_COMPLETE_HANDLER ReceiveCompleteHandler;
WAN_RECEIVE_HANDLER WanReceiveHandler;
REQUEST_COMPLETE_HANDLER RequestCompleteHandler;
//
// NDIS 4.0 extensions
//
RECEIVE_PACKET_HANDLER ReceivePacketHandler;
SEND_PACKETS_HANDLER SendPacketsHandler;
//
// More Cached Handlers
//
RESET_HANDLER ResetHandler;
REQUEST_HANDLER RequestHandler;
RESET_COMPLETE_HANDLER ResetCompleteHandler;
STATUS_HANDLER StatusHandler;
STATUS_COMPLETE_HANDLER StatusCompleteHandler;
#if defined(NDIS_WRAPPER)
....
#endif
} NDIS_COMMON_OPEN_BLOCK;
需要處理的，是ndis open block里面的SendHandler，ReceiveHandler，WanReceiveHandler，ReceivePacketHandler和SendPacketsHandler。
一定要注意的是，不同于很多文章中的描述，主要處理SendHandler和ReceiveHandler，正確的應(yīng)該是主要處理ReceivePacketHandler和SendPacketsHandler，現(xiàn)在的主流網(wǎng)卡和系統(tǒng)驅(qū)動(dòng)，都是使用后面兩者。
應(yīng)用程序訪問(wèn)網(wǎng)絡(luò)控制
以往的防火墻只能古板的允許或者禁止整個(gè)系統(tǒng)去訪問(wèn)網(wǎng)絡(luò)上的目標(biāo)，比如允許了系統(tǒng)可以訪問(wèn)外網(wǎng)的http端口，就允許了所有進(jìn)程，不能只控制IE等幾個(gè)進(jìn)程有權(quán)這樣做。該技術(shù)的出現(xiàn)解決了這個(gè)問(wèn)題，對(duì)每個(gè)陌生的進(jìn)程都會(huì)詢問(wèn)客戶是否允許訪問(wèn)網(wǎng)絡(luò)，因此還有一定的查殺未知木馬病毒的能力。
由于NDIS里面的那些send/receive handler全都是由tdi緩沖之后再調(diào)用的，運(yùn)行的上下文全都是kernel，并且不保存原先進(jìn)行tdi操作的進(jìn)程號(hào)，因此在封濾的NDIS鉤子層次無(wú)法取得進(jìn)行操作的進(jìn)程ID。想要解決應(yīng)用程序訪問(wèn)網(wǎng)絡(luò)控制的問(wèn)題，就需要在tdi或者更高的層次上使用鉤子。一般來(lái)說(shuō)，主流是使用tdi鉤子，在進(jìn)程的網(wǎng)絡(luò)調(diào)用棧進(jìn)行到tdi的TDI_CONNECT，TDI_LISTEN，TDI_RECEIVE，TDI_SET_EVENT_HANDLER等調(diào)用時(shí)，進(jìn)行進(jìn)程判斷和提示。
對(duì)于winsock的應(yīng)用程序來(lái)說(shuō)，最重要的是主動(dòng)連接請(qǐng)求，TDI_CONNECT；接受連接請(qǐng)求，TDI_SET_EVENT_HANDLER中的TDI_EVENT_CONNECT。對(duì)于udp收發(fā)，還要處理TDI_SEND_DATAGRAM，TDI_RECEIVE_DATAGRAM和TDI_SET_EVENT_HANDLER中的TDI_EVENT_RECEIVE_DATAGRAM請(qǐng)求。這個(gè)時(shí)候，直接PsGetCurrentProcessId就可以得到進(jìn)程號(hào)。
tdi鉤子有一個(gè)問(wèn)題，就是對(duì)于TDI_SET_EVENT_HANDLER的hook，很可能不能及時(shí)發(fā)揮作用，必須要重起以后。由于不像ndis鉤子需要hook系統(tǒng)函數(shù)或者修改系統(tǒng)數(shù)據(jù)結(jié)構(gòu)，tdi鉤子可以直接使用微軟提供的過(guò)濾器驅(qū)動(dòng)程序接口，在安裝編寫(xiě)上要比ndis鉤子簡(jiǎn)單的多，IoAttachDeviceToDeviceStack就可以了。
封濾技術(shù)，NDIS鉤子，應(yīng)用程序訪問(wèn)網(wǎng)絡(luò)控制，TDI鉤子，智能行為監(jiān)控，反流氓軟件，自我保護(hù)技術(shù)。
本文簡(jiǎn)要介紹了目前流行的Windows軟件防火墻的各個(gè)功能組件，及其實(shí)現(xiàn)方法。
內(nèi)容目錄：
• Windows軟件防火墻的發(fā)展概況
• 封濾技術(shù)
• 應(yīng)用程序訪問(wèn)網(wǎng)絡(luò)控制
• 智能行為監(jiān)控
• 反流氓軟件技術(shù)
• 自我保護(hù)技術(shù)
• 附錄
Windows軟件防火墻的發(fā)展概況
從Windows軟件防火墻的誕生開(kāi)始，這種安全防護(hù)產(chǎn)品就在跟隨著不斷深入的黑客病毒與反黑反毒之爭(zhēng)，不斷的進(jìn)化與升級(jí)。從最早期的只能分析來(lái)源地址，端口號(hào)以及未經(jīng)處理的報(bào)文原文的封濾防火墻，后來(lái)出現(xiàn)了能對(duì)不同的應(yīng)用程序設(shè)置不同的訪問(wèn)網(wǎng)絡(luò)權(quán)限的技術(shù)；近年來(lái)由ZoneAlarm等國(guó)外知名品牌牽頭，還開(kāi)始流行了具有未知攻擊攔截能力的智能行為監(jiān)控防火墻；最后，由于近來(lái)垃圾插件和流氓軟件的盛行，很多防火墻都在考慮給自己加上攔截流氓軟件的功能。綜上，Windows軟件防火墻從開(kāi)始的時(shí)候單純的一個(gè)截包丟包，堵截IP和端口的工具，發(fā)展到了今天功能強(qiáng)大的整體性的安全套件。
接下來(lái)本文就對(duì)一個(gè)Windows軟件防火墻應(yīng)當(dāng)擁有的這些組件進(jìn)行一個(gè)簡(jiǎn)要的技術(shù)介紹。
封濾技術(shù)
封濾技術(shù)是最原始的防火墻所擁有的第一種功能。但是該功能簡(jiǎn)單強(qiáng)大，直到現(xiàn)在都是任何一個(gè)防火墻必不可少的功能。
想要在網(wǎng)絡(luò)數(shù)據(jù)包到達(dá)應(yīng)用程序之前攔截之，就要在系統(tǒng)的網(wǎng)絡(luò)協(xié)議棧上面安裝過(guò)濾鉤子。對(duì)Windows NT系列內(nèi)核來(lái)說(shuō)，可能安裝過(guò)濾鉤子的地方大致是這么幾個(gè)，從高層到底層排序：SPI層（早期的天網(wǎng)防火墻 ），AFD層（資料缺乏，尚無(wú)例子），TDI層（不少國(guó)內(nèi)墻），NDIS層（ZoneAlarm，Outpost等）。越位于高層，則產(chǎn)品開(kāi)發(fā)難度越低，但是功能越弱，越容易被攻擊者所穿越。由于NDIS層的防火墻具有功能強(qiáng)大，不易被穿透等優(yōu)點(diǎn)，近來(lái)各大防火墻廠商的趨勢(shì)是選擇NDIS層來(lái)做濾。
目前比較流行的NDIS鉤子技術(shù)有兩種。一種是掛接ndis.sys模塊的導(dǎo)出函數(shù)，從而能夠在每個(gè)ndis protocol注冊(cè)的時(shí)候截獲其注冊(cè)過(guò)程，從而替換其send(packets)handler和receive(packet)handler。這個(gè)方法的缺點(diǎn)是在第一次安全之后無(wú)法立刻生效，必須要重起一次，而且要禁用的話，也必須重起。
2004年12月的時(shí)候，www.rootkit.com上面的一名黑客發(fā)表了一篇的文章：“Hooking into NDIS and TDI, part 1”（http://www.rootkit.com/newsread.php?newsid=219）。這篇文章本意是為rootkit作者們提供一種掛接底層驅(qū)動(dòng)實(shí)現(xiàn)端口重用的方法，但是這篇文章揭示了一個(gè)全新的技術(shù)：通過(guò)動(dòng)態(tài)的注冊(cè)ndis假協(xié)議，可以獲得ndis protocol的鏈表地址。得到這個(gè)地址之后就能不通過(guò)重起，就能替換并監(jiān)控每個(gè)ndis protocol的send(packets)handler和receive(packet)handler，并且可以動(dòng)態(tài)的卸載監(jiān)控模塊不需要重起。在這篇文章出現(xiàn)之后，很多防火墻廠商都悄悄地對(duì)自己的產(chǎn)品進(jìn)行了升級(jí)。目前的ZoneAlarm等產(chǎn)品就是使用這種技術(shù)，可以在安裝后即時(shí)發(fā)揮作用。這個(gè)例子更充分的體現(xiàn)了，黑客和反黑技術(shù)本來(lái)就是相輔相成的，本源同一的。
這里給出一個(gè)尋找該鏈表頭的代碼例子：
該函數(shù)返回的NDIS_HANDLE就是鏈表頭地址。
NDIS_HANDLE RegisterBogusNDISProtocol(void)
{
NTSTATUS Status = STATUS_SUCCESS;
NDIS_HANDLE hBogusProtocol = NULL;
NDIS_PROTOCOL_CHARACTERISTICS BogusProtocol;
NDIS_STRING ProtocolName;
NdisZeroMemory(&BogusProtocol,sizeof(NDIS_PROTOCOL_CHARACTERISTICS));
BogusProtocol.MajorNdisVersion = 0x04;
BogusProtocol.MinorNdisVersion = 0x0;
NdisInitUnicodeString(&ProtocolName,L"BogusProtocol");
BogusProtocol.Name = ProtocolName;
BogusProtocol.ReceiveHandler = DummyNDISProtocolReceive;
BogusProtocol.BindAdapterHandler = dummyptbindadapt;
BogusProtocol.UnbindAdapterHandler = dummyptunbindadapt;
NdisRegisterProtocol(&Status,&hBogusProtocol,&BogusProtocol,
sizeof(NDIS_PROTOCOL_CHARACTERISTICS));
if(Status == STATUS_SUCCESS){ return hBogusProtocol;}
else {
#ifdef bydbg
DbgPrint("ndishook:cannot register bogus protocol:%x\n",Status);
DbgBreakPoint();
#endif
return NULL;
}
}
得到這個(gè)ndis protocol的鏈表后，遍歷表中的每一個(gè)ndis protocol，對(duì)于每一個(gè)ndis protocol，又各有一個(gè)鏈表，用來(lái)描述和該ndis protocol有聯(lián)系的所有ndis miniport和該ndis protocol綁定的狀態(tài)。每個(gè)這種狀態(tài)塊，叫做一個(gè)ndis open block。每個(gè)綁定的send(packets)handler和receive(packet)handler都在這個(gè)ndis open block里面。
struct _NDIS_OPEN_BLOCK
{
#ifdef __cplusplus
NDIS_COMMON_OPEN_BLOCK NdisCommonOpenBlock;
#else
NDIS_COMMON_OPEN_BLOCK;
#endif
#if defined(NDIS_WRAPPER)
//
// The stuff below is for CO drivers/protocols. This part is not allocated for CL drivers.
//
struct _NDIS_OPEN_CO
{
....
};
#endif
};
typedef struct _NDIS_COMMON_OPEN_BLOCK
{
PVOID MacHandle; // needed for backward compatibility
NDIS_HANDLE BindingHandle; // Miniport's open context
PNDIS_MINIPORT_BLOCK MiniportHandle; // pointer to the miniport
PNDIS_PROTOCOL_BLOCK ProtocolHandle; // pointer to our protocol
NDIS_HANDLE ProtocolBindingContext;// context when calling ProtXX funcs
PNDIS_OPEN_BLOCK MiniportNextOpen; // used by adapter's OpenQueue
PNDIS_OPEN_BLOCK ProtocolNextOpen; // used by protocol's OpenQueue
NDIS_HANDLE MiniportAdapterContext; // context for miniport
BOOLEAN Reserved1;
BOOLEAN Reserved2;
BOOLEAN Reserved3;
BOOLEAN Reserved4;
PNDIS_STRING BindDeviceName;
KSPIN_LOCK Reserved5;
PNDIS_STRING RootDeviceName;
//
// These are referenced by the macros used by protocols to call.
// All of the ones referenced by the macros are internal NDIS handlers for the miniports
//
union
{
SEND_HANDLER SendHandler;
WAN_SEND_HANDLER WanSendHandler;
};
TRANSFER_DATA_HANDLER TransferDataHandler;
//
// These are referenced internally by NDIS
//
SEND_COMPLETE_HANDLER SendCompleteHandler;
TRANSFER_DATA_COMPLETE_HANDLER TransferDataCompleteHandler;
RECEIVE_HANDLER ReceiveHandler;
RECEIVE_COMPLETE_HANDLER ReceiveCompleteHandler;
WAN_RECEIVE_HANDLER WanReceiveHandler;
REQUEST_COMPLETE_HANDLER RequestCompleteHandler;
//
// NDIS 4.0 extensions
//
RECEIVE_PACKET_HANDLER ReceivePacketHandler;
SEND_PACKETS_HANDLER SendPacketsHandler;
//
// More Cached Handlers
//
RESET_HANDLER ResetHandler;
REQUEST_HANDLER RequestHandler;
RESET_COMPLETE_HANDLER ResetCompleteHandler;
STATUS_HANDLER StatusHandler;
STATUS_COMPLETE_HANDLER StatusCompleteHandler;
#if defined(NDIS_WRAPPER)
....
#endif
} NDIS_COMMON_OPEN_BLOCK;
需要處理的，是ndis open block里面的SendHandler，ReceiveHandler，WanReceiveHandler，ReceivePacketHandler和SendPacketsHandler。
一定要注意的是，不同于很多文章中的描述，主要處理SendHandler和ReceiveHandler，正確的應(yīng)該是主要處理ReceivePacketHandler和SendPacketsHandler，現(xiàn)在的主流網(wǎng)卡和系統(tǒng)驅(qū)動(dòng)，都是使用后面兩者。
應(yīng)用程序訪問(wèn)網(wǎng)絡(luò)控制
以往的防火墻只能古板的允許或者禁止整個(gè)系統(tǒng)去訪問(wèn)網(wǎng)絡(luò)上的目標(biāo)，比如允許了系統(tǒng)可以訪問(wèn)外網(wǎng)的http端口，就允許了所有進(jìn)程，不能只控制IE等幾個(gè)進(jìn)程有權(quán)這樣做。該技術(shù)的出現(xiàn)解決了這個(gè)問(wèn)題，對(duì)每個(gè)陌生的進(jìn)程都會(huì)詢問(wèn)客戶是否允許訪問(wèn)網(wǎng)絡(luò)，因此還有一定的查殺未知木馬病毒的能力。
由于NDIS里面的那些send/receive handler全都是由tdi緩沖之后再調(diào)用的，運(yùn)行的上下文全都是kernel，并且不保存原先進(jìn)行tdi操作的進(jìn)程號(hào)，因此在封濾的NDIS鉤子層次無(wú)法取得進(jìn)行操作的進(jìn)程ID。想要解決應(yīng)用程序訪問(wèn)網(wǎng)絡(luò)控制的問(wèn)題，就需要在tdi或者更高的層次上使用鉤子。一般來(lái)說(shuō)，主流是使用tdi鉤子，在進(jìn)程的網(wǎng)絡(luò)調(diào)用棧進(jìn)行到tdi的TDI_CONNECT，TDI_LISTEN，TDI_RECEIVE，TDI_SET_EVENT_HANDLER等調(diào)用時(shí)，進(jìn)行進(jìn)程判斷和提示。
對(duì)于winsock的應(yīng)用程序來(lái)說(shuō)，最重要的是主動(dòng)連接請(qǐng)求，TDI_CONNECT；接受連接請(qǐng)求，TDI_SET_EVENT_HANDLER中的TDI_EVENT_CONNECT。對(duì)于udp收發(fā)，還要處理TDI_SEND_DATAGRAM，TDI_RECEIVE_DATAGRAM和TDI_SET_EVENT_HANDLER中的TDI_EVENT_RECEIVE_DATAGRAM請(qǐng)求。這個(gè)時(shí)候，直接PsGetCurrentProcessId就可以得到進(jìn)程號(hào)。
tdi鉤子有一個(gè)問(wèn)題，就是對(duì)于TDI_SET_EVENT_HANDLER的hook，很可能不能及時(shí)發(fā)揮作用，必須要重起以后。由于不像ndis鉤子需要hook系統(tǒng)函數(shù)或者修改系統(tǒng)數(shù)據(jù)結(jié)構(gòu)，tdi鉤子可以直接使用微軟提供的過(guò)濾器驅(qū)動(dòng)程序接口，在安裝編寫(xiě)上要比ndis鉤子簡(jiǎn)單的多，IoAttachDeviceToDeviceStack就可以了。