无标题.txt

NDIS的经典源码

"NDIS Hooking" and "NDIS IM Driver" 

----- Original Message ----- 
From: 
To: 
Sent: Thursday, August 30, 2001 10:01 PM 
Subject: [discussion-pcausa] "NDIS Hooking" and "NDIS IM Driver" 


I will develop a personal firewall under Windows NT/2000. From 
the survey I've done, I find that "NDIS Hooking" is adopted by most 
products for personal firewall。To develop the personal firewall for 
Windows NT/2000, can "NDIS IM Driver" be adopted instead of "NDIS 
Hooking"? Which is better？Why do most personal firewalls use "NDIS 
Hooking" instead of "NDIS IM Driver"？ 
Expect to reply. 

Thanks 
xianguo chen 



The Figure at the URL below illustrates the Windows Network Architecture: 

http://www.pcausa.com/resources/winpktfilter.htm 

Here are some rambling comments that may help you. 

NDIS Intermediate (IM) Drivers 
--------------------------------- 
Generally NDIS IM drivers are installed using the Network Control Panel. On 
Windows 2000 and higher the process of installing NDIS IM drivers can be 
automated to some extent using the NetCFG and SetupDi APIs. This probably 
can be done in a way that is "invisible" to the user. However, it cannot be 
done at all unless the user installing the NDIS IM driver (or any driver for 
that matter) has Administrative priviledges. 

On Windows NT it is difficult to filter WAN in an IM driver because of the 
propritary nature of the internal APIs of some Microsoft drivers. In 
addition, the WAN API differs between some versions of NT. For example the 
"Steelhead" Terminal server APIs are different from the normal NT 
workstation APIs. 

NDIS Hooking 
---------------- 
Now the question about NDIS hooking. 

A hooking solution has at least these four possible benefits: 

1.) It is easy (or can be made to appear easy) to install. 
2.) It allows filtering of WAN/PPP adapter. 
3.) It does not require re-wrapping of passthru packets. 
4.) It provides total control of packets being sent or received. 

NDIS hooking the Windows 95/98/ME platforms can be implemented using hooking 
services provided by Microsoft and usually employs only documented system 
services and documented structure definitions. 

NDIS hooking is not quite as straight forward on Windows NT and Windows 2000 
(and higher). 

In particular, there is no Microsoft-provided hooking API. Instead, the NDIS 
hooking code may need to use undocumented methods and undocumented data 
structures. One would at least say that the techniques used for NDIS hooking 
on Windows NT are similar to the techniques used to implement a debugger. 
One could also say the thechniques are similar to kernel "hacking" methods. 
In any case, if properly done the Windows NT and Windows 2000 NDIS hooks can 
be quite reliable and provide the same benefits mentioned above. 

Why would one NOT consider NDIS hooking? 

For one thing, since the Window NT and Windows 2000 NDIS hooking techniques 
are not documented you must learn them for yourself. You must be familiar 
with both NDIS and the undocumented details of the Windows kernel 
implementation. A NDIS hooking product is certainly be sensitive to changes 
that Microsoft might introduce in new product releases. For example, the 
NDIS hooking method used for Windows NT does not work without change on 
Windows 2000. 

It would certainly be difficult to get a Microsoft logo for any product 
known to use the undocumented hooking techniques. 

Other Thoughts 
---------------- 
A firewall may, in fact, perform filtering at more then one point in the 
network stack. 

For example, process information (i.e., information about the application 
performing a network operation) can be determined most reliably above the 
TCP/IP transport driver; here one would use a Transport Data Interface (TDI) 
filter. Per-packet filtering is done below the TCP/IP transport driver; here 
one would use a NDIS Intermediate (IM) driver or a NDIS-hooking filter. 

There are other things to consider. The so called "user experiance' is a 
factor. Consider the apparently trivial idea of blocking access to a 
specific IP address. Obviously, this could be done either in a TDI filter 
above the TCP/IP transport or in drivers below the TCP/IP transport. 
However, the user will see a difference. If the IP address is blocked by a 
TDI filter the connection attempt will fail immediately (because the TDI 
filter fails it immediately); however, if outgoing packets to the specificed 
IP address are dropped below the TCP/IP transport, the connection attempt 
won't fail until TCP/IP transport performs several re-try attempts - which 
can be several seconds of wasted user time. 

One must also consider fragmentation. Filters (or firewall components) above 
the TCP/IP transport driver can examine unfragmented or re-assembled 
portions of a data stream. Filters below the TCP/IP transport driver examine 
individual packets; they must be re-assembled in the filter if unfragmented 
stream data must be examined. 

If the propose of the firewall is to "protect" the TCP/IP transport from 
receiving malformed packets known to cause failures in the stack, then the 
firewall must include filtering below the TCP/IP transport driver. 

Hope this helps a little. 

Good luck, 

Thomas F. Divine 

PCAUSA - Toolkits & Resources For Network Software Developers 
NDIS Protocol - NDIS Intermediate - TDI Client 
-