Bryan,
Just want to add a few words to Maxim’s message. I agree that
hacking/hooking methods may appear dangerous for the working system, however
my experience of development and support several firewall/VPN solutions
discovered that NDIS-hooking approach is less painful in development and
support then IM (especially for 9x/ME and NT4.0). I know that IM technology
is enhanced in Windows 2000/XP, but still not as convenient as hooking,
which additionally allows sharing large chunks of code between 9x/ME and NT
drivers. As for hooking as technology, it’s widely used, and still more
effective then other approaches, and more convenient for end user
(completely invisible for him). Additionally, installation of such driver is
simple and performed without warning messages from system that driver is not
WHQL.
Best Regards,
Vadim
http://www.ntndis.com
-----Original Message-----
From: Bryan Burgin [mailto:xxxxx@microsoft.com]
Sent: Saturday, December 29, 2001 5:11 AM
To: NT Developers Interest List; xxxxx@storagecraft.com
Cc: brucie@263.net; xxxxx@pcausa.com
Subject: RE: [ntdev] Re: hook ndis under win2k like under Win9x
Maxim,
I will send your suggestion to the NDIS development folks (bcc’ed on
this e-mail). I work down the hall from them. Your points are well
taken.
In the meantime, if a commercial product is about to be unleashed on the
user community that will need to be maintained, I would encourage anyone
beginning a fresh development effort to use the PASSTHRU sample until
another method avails itself, if ever.
Bryan S. Burgin
xxxxx@microsoft.com
bburgin x58049 40/2153
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, December 28, 2001 5:44 PM
To: NT Developers Interest List
Cc: brucie@263.net; xxxxx@pcausa.com
Subject: [ntdev] Re: hook ndis under win2k like under Win9x
Brucie, Vadim, Maxim,
Again, I would strongly discourage you from using these undocumented,
reverse-
engineered methods to develop your NDIS Intermediate drivers and
instead use the well
Bryan, I agree with you, but why MS do not provide the NDIS hook API?
IM is surely an overkill for firewalls. What IM does is imposting
another network adapter driver with virtual adapters instead of
the real ones created by the NIC driver.
This is surely over-complex. Usually, firewalls do not need these
virtual adapter objects, not to say on NdisIMSwitchToMiniport
(well, this is a past, but nevertheless), overly complex NCPA binding
stuff and other stuff.
Having the usual adapter (created by the NIC) to be filtered is enough
for the firewall. No need in any NCPA work at least.
The suggested functionality is:
- adds a hook routine to the filter database of the given NDIS adapter
object.
- this hook routine is called before any protocol’s receive or receive
packet handlers
- it returns BOOLEAN, if it is FALSE - then the packet is dropped and
not indicated to the protocols.
Is it such bad? In fact, the firewall could even be implemented just as
a protocol driver using NdisOpenAdapter, if NDIS would
guarantee that the firewall will always be the first in the chain (by
using some “priority” parameter or such, which is absent for
now). Then the firewall’s receive handler will drop the packet and
return TRUE to prohibit delivery to other protocols and return
FALSE to allow such delivery.
Max
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com