Hi, all
Under Win9x, we can use hook_device_service to implement
a pseudo-intermediate driver to filtering the ethernet packets.
How can it be done under win2k?
Please help me. Thanks
best regards
yours brucie
brucie@263.net
???y˫???+.n?+???u?ڲ˛??^r*D???kN???r??zǧu??jy???^j???ׯ??? 0?j?b??(??(
It can be implemented by simple modification of export table of NDIS.SYS
(driver loads after NDIS.SYS and before any protocol drivers), or
alternatively you can patch the body of each function (put jmp to your code
into the beggining of it).
BR, Vadim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of brucie
Sent: Thursday, December 27, 2001 4:48 PM
To: NT Developers Interest List
Subject: [ntdev] hook ndis under win2k like under Win9x
Hi, all
Under Win9x, we can use hook_device_service to implement
a pseudo-intermediate driver to filtering the ethernet packets.
How can it be done under win2k?
Please help me. Thanks
best regards
yours brucie
brucie@263.net
b??箷????vڵ?j˚*??j?r???ޱ??i?Z?G?j)m?W???u???^U?-??+
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
Brucie,
The hooking scheme in Windows 9x, as you pointed out, uses the VMM call Hook_Device_Service to hook VxDCalls. This was never supported or recommended – but was a common solution that many vendors used. And it failed to work without hooking additional services in Windows ME because the Windows ME TCPIP stack, as a Windows 2000-based driver, doesn’t use VxDCalls.
There is not a similar mechanism in Windows 2000/XP. The proper model, even for Windows 98 and ME, is to use a NDIS Intermediate Driver based off of the Windows XP DDK sample PASSTHRU or MUX.
Hope this helps.
Bryan S. Burgin
xxxxx@microsoft.com
bburgin x58049 40/2153
-----Original Message-----
From: brucie [mailto:brucie@263.net]
Sent: Thursday, December 27, 2001 5:48 AM
To: NT Developers Interest List
Subject: [ntdev] hook ndis under win2k like under Win9x
Hi, all
Under Win9x, we can use hook_device_service to implement
a pseudo-intermediate driver to filtering the ethernet packets.
How can it be done under win2k?
Please help me. Thanks
best regards
yours brucie
brucie@263.net
b??箷????vڵ?jƺ??h??~י:?˱?m??֕?zf??y?????۲?
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
Brucie,
I would strongly suggest that you follow the proper NDIS Intermediate Driver model based on the PASSTHRU or MUX samples and not patch NDIS.SYS’ export table.
Bryan S. Burgin
xxxxx@microsoft.com
bburgin x58049 40/2153
-----Original Message-----
From: Vadim Smirnov [mailto:xxxxx@pcausa.com]
Sent: Thursday, December 27, 2001 7:46 AM
To: NT Developers Interest List
Subject: [ntdev] RE: hook ndis under win2k like under Win9x
It can be implemented by simple modification of export table of NDIS.SYS
(driver loads after NDIS.SYS and before any protocol drivers), or
alternatively you can patch the body of each function (put jmp to your code
into the beggining of it).
BR, Vadim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of brucie
Sent: Thursday, December 27, 2001 4:48 PM
To: NT Developers Interest List
Subject: [ntdev] hook ndis under win2k like under Win9x
Hi, all
Under Win9x, we can use hook_device_service to implement
a pseudo-intermediate driver to filtering the ethernet packets.
How can it be done under win2k?
Please help me. Thanks
best regards
yours brucie
brucie@263.net
b嫮绠范\够?v诘譲藲*Ⅹj雛墦㈤旃??薇檩i筞濭)m毥轫u膪隵U?-矉+
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
???y˫???+.n?+???u?ڲ˛??^r*D???kN???r??zǧu??jy???^j???ׯ??? 0?j?b??(??(
At 21.47 27/12/2001 +0800, you wrote:
Under Win9x, we can use hook_device_service to implement a
pseudo-intermediate driver to filtering the ethernet packets. How can it
be done under win2k?
have a look at tcpdump:
http://netgroup-serv.polito.it/windump/
hooks anything but the PPP adapter. Works great on Ethernet
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
Windump just listen the packets on the local network but cannt filter the
packets. Although NDIS IM driver is the best solution to filtering the
packets, but I want to know the way some products such as Norton Personal
Firewall achieve this? As I know many commercial products use the method
like under Win9x to hook the NDIS services, but not patch the export
table of “ndis.sys”.As I know, there are two important structures defined
in ndis.h: NDIS_PROTOCOL_BLOCK and NDIS_OPEN_BLOCK.
At 21.47 27/12/2001 +0800, you wrote:
>Under Win9x, we can use hook_device_service to implement a
>pseudo-intermediate driver to filtering the ethernet packets. How can it
>be done under win2k?have a look at tcpdump:
http://netgroup-serv.polito.it/windump/
hooks anything but the PPP adapter. Works great on Ethernet
You are currently subscribed to ntdev as: brucie@263.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
(???r??z{e?˛???m?m?{]z???&j)@u?Ӣ?칻?&ޱ??i?Z?G?j)m?W???u?칻-E?"?Ǧm??(Z?X???,??&
> Windump just listen the packets on the local network but cannt filter the
packets. Although NDIS IM driver is the best solution to filtering the
packets, but I want to know the way some products such as Norton Personal
Firewall achieve this?
By hooking the NDIS function pointers in protocol blocks. The way suggested by Vadim.
Max
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
Brucie,
In addition to patching NDIS.SYS export table (which is used in some
commercial products) or direct code modification (look www.danlan.com )there
is one more way is like well-known personal firewall ZoneAlarm
(www.zonealarm.com) works. It register it’s own fake protocol (most of the
handlers are null subroutines, others like ReceiveHandler returnes
NDIS_STATUS_NOT_ACCEPTED). I was a bit confused what for it register
protocol. Then found that just for getting ProtocolBindingHandle, which is
actually a pointer to internal NDIS structure NDIS_PROTOCOL_BLOCK (defined
on different wayes for different NDIS versions). This structure contains a
pointer to NDIS_PROTOCOL_BLOCK list of all previously registered
protocols, NDIS_PROTOCOL_CHARACTERISTICS given in NdisRegisterProtocol and
pointer to
a list of all adapters (described by NDIS_OPEN_BLOCK structure) binded to
this protocol. So having this pointer you may substitute all protocol
handlers
you want and NDIS_OPEN_BLOCK handlers also, getting ful control over all
network trafic. Additionally, it tracks all working processes and threads
in the system and hooks TDI for originated call process determination, but
this is out of our subject. However, I suspect that in comparison to
NDIS.SYS patching export table this approach can be unsafe for SMP systems.
Regards,
Vadim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of brucie
Sent: Friday, December 28, 2001 6:00 AM
To: NT Developers Interest List
Subject: [ntdev] Re: hook ndis under win2k like under Win9x
Windump just listen the packets on the local network but cannt filter the
packets. Although NDIS IM driver is the best solution to filtering the
packets, but I want to know the way some products such as Norton Personal
Firewall achieve this? As I know many commercial products use the method
like under Win9x to hook the NDIS services, but not patch the export
table of “ndis.sys”.As I know, there are two important structures defined
in ndis.h: NDIS_PROTOCOL_BLOCK and NDIS_OPEN_BLOCK.
At 21.47 27/12/2001 +0800, you wrote:
>Under Win9x, we can use hook_device_service to implement a
>pseudo-intermediate driver to filtering the ethernet packets. How can it
>be done under win2k?have a look at tcpdump:
http://netgroup-serv.polito.it/windump/
hooks anything but the PPP adapter. Works great on Ethernet
You are currently subscribed to ntdev as: brucie@263.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
b???v?j??jr???ޱ??i?Z?G?j)m?W???u???^U?-??+
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
Thanks for reply. I have some ideas after read your article.
I will go to write some codes:)))
Thank u very much
Brucie,
In addition to patching NDIS.SYS export table (which is used in some
commercial products) or direct code modification (look www.danlan.com )there
is one more way is like well-known personal firewall ZoneAlarm
(www.zonealarm.com) works. It register it’s own fake protocol (most of the
handlers are null subroutines, others like ReceiveHandler returnes
NDIS_STATUS_NOT_ACCEPTED). I was a bit confused what for it register
protocol. Then found that just for getting ProtocolBindingHandle, which is
actually a pointer to internal NDIS structure NDIS_PROTOCOL_BLOCK (defined
on different wayes for different NDIS versions). This structure contains a
pointer to NDIS_PROTOCOL_BLOCK list of all previously registered
protocols, NDIS_PROTOCOL_CHARACTERISTICS given in NdisRegisterProtocol and
pointer to
a list of all adapters (described by NDIS_OPEN_BLOCK structure) binded to
this protocol. So having this pointer you may substitute all protocol
handlers
you want and NDIS_OPEN_BLOCK handlers also, getting ful control over all
network trafic. Additionally, it tracks all working processes and threads
in the system and hooks TDI for originated call process determination, but
this is out of our subject. However, I suspect that in comparison to
NDIS.SYS patching export table this approach can be unsafe for SMP systems.Regards,
Vadim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of brucie
Sent: Friday, December 28, 2001 6:00 AM
To: NT Developers Interest List
Subject: [ntdev] Re: hook ndis under win2k like under Win9xWindump just listen the packets on the local network but cannt filter the
packets. Although NDIS IM driver is the best solution to filtering the
packets, but I want to know the way some products such as Norton Personal
Firewall achieve this? As I know many commercial products use the method
like under Win9x to hook the NDIS services, but not patch the export
table of “ndis.sys”.As I know, there are two important structures defined
in ndis.h: NDIS_PROTOCOL_BLOCK and NDIS_OPEN_BLOCK.
>At 21.47 27/12/2001 +0800, you wrote:
>>Under Win9x, we can use hook_device_service to implement a
>>pseudo-intermediate driver to filtering the ethernet packets. How can it
>>be done under win2k?
>
>have a look at tcpdump:
>
>http://netgroup-serv.polito.it/windump/
>
>hooks anything but the PPP adapter. Works great on Ethernet
>
>
>—
>You are currently subscribed to ntdev as: brucie@263.net
>To unsubscribe send a blank email to xxxxx@lists.osr.com
b???v?j??jr???ޱ??i?Z?G?j)m?W???u???^U?-??+
You are currently subscribed to ntdev as: brucie@263.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
(???r??z{e?˛???m?m?{]z???&j)@u?Ӣ?칻?&ޱ??i?Z?G?j)m?W???u?칻-E?"?Ǧm??(Z?X???,??&
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 documented, sanctioned examples I cited previously. My chief concern is application compatibility. There have been instances where firewall products have broken because these unsupported hacks were used, and it is likely that any driver based on this broken model will cease to work in the future as enhancements are made to NDIS. Furthermore, as incompliant drivers are introduced into the system, an undue burden is placed on NDIS development to keep these rogue drivers working, if they are discovered in time.
In the Windows 98 days, there was no clearly defined solution, and hooking NDIS became a common method in the development community. I personally helped several companies get their Windows 98 NDIS hooking driver to work in Windows ME. It was a time consuming and, in some cases, a painful and expensive exercise.
I’d like to leverage that experience and try to learn from it. Today, there are samples in the DDK to properly develop NDIS IM drivers, and in my opinion, it is irresponsible not to base your development effort on the prescribed methods.
I have other concerns, which include performance and overall system stability.
Bryan S. Burgin
xxxxx@microsoft.com
This posting is provided “AS IS” with no warranties, and confers no rights © 2001 Microsoft Corporation. All rights reserved.
-----Original Message-----
From: brucie [mailto:brucie@263.net]
Sent: Friday, December 28, 2001 12:47 AM
To: NT Developers Interest List
Subject: [ntdev] Re: hook ndis under win2k like under Win9x
Thanks for reply. I have some ideas after read your article.
I will go to write some codes:)))
Thank u very much
Brucie,
In addition to patching NDIS.SYS export table (which is used in some
commercial products) or direct code modification (look www.danlan.com )there
is one more way is like well-known personal firewall ZoneAlarm
(www.zonealarm.com) works. It register it’s own fake protocol (most of the
handlers are null subroutines, others like ReceiveHandler returnes
NDIS_STATUS_NOT_ACCEPTED). I was a bit confused what for it register
protocol. Then found that just for getting ProtocolBindingHandle, which is
actually a pointer to internal NDIS structure NDIS_PROTOCOL_BLOCK (defined
on different wayes for different NDIS versions). This structure contains a
pointer to NDIS_PROTOCOL_BLOCK list of all previously registered
protocols, NDIS_PROTOCOL_CHARACTERISTICS given in NdisRegisterProtocol and
pointer to
a list of all adapters (described by NDIS_OPEN_BLOCK structure) binded to
this protocol. So having this pointer you may substitute all protocol
handlers
you want and NDIS_OPEN_BLOCK handlers also, getting ful control over all
network trafic. Additionally, it tracks all working processes and threads
in the system and hooks TDI for originated call process determination, but
this is out of our subject. However, I suspect that in comparison to
NDIS.SYS patching export table this approach can be unsafe for SMP systems.Regards,
Vadim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of brucie
Sent: Friday, December 28, 2001 6:00 AM
To: NT Developers Interest List
Subject: [ntdev] Re: hook ndis under win2k like under Win9xWindump just listen the packets on the local network but cannt filter the
packets. Although NDIS IM driver is the best solution to filtering the
packets, but I want to know the way some products such as Norton Personal
Firewall achieve this? As I know many commercial products use the method
like under Win9x to hook the NDIS services, but not patch the export
table of “ndis.sys”.As I know, there are two important structures defined
in ndis.h: NDIS_PROTOCOL_BLOCK and NDIS_OPEN_BLOCK.
>At 21.47 27/12/2001 +0800, you wrote:
>>Under Win9x, we can use hook_device_service to implement a
>>pseudo-intermediate driver to filtering the ethernet packets. How can it
>>be done under win2k?
>
>have a look at tcpdump:
>
>http://netgroup-serv.polito.it/windump/
>
>hooks anything but the PPP adapter. Works great on Ethernet
>
>
>—
>You are currently subscribed to ntdev as: brucie@263.net
>To unsubscribe send a blank email to xxxxx@lists.osr.com
b豆畍礿殺jr墦㈤旃??薇檩i筞濭)m毥轫u膪隵U?-矉+
You are currently subscribed to ntdev as: brucie@263.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
b嫐.Ф\??辷?底痡欺焊"瀐湲?~??.炈洷殊m?澲洉╀zf?y炞^繛4?b槽(卜(
b???.???????&?v?'?ׯj?.n?Qyȩf??]?:.?˛???m??֛???zf???%y?ޞ?^?˛??^r*Lzfެ? ???l??ܢ
> 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:
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: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
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:
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
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:
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
Hello,
Certainly, you are right. A few month ago, I developed a packet driver using NDIS hooks. I could not found another method to capture outgoing packets on “dial-up” MAC adapters (PSTN, ISDN-modems) on NT4.
But the disadvantage of using NDIS hooks is impossibility to use two or more drivers implement such technique. My driver crashes on systems on which either Winroute or Wingate or something like these are installed.
Thanks.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Saturday, December 29, 2001 7:44 AM
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 wellBryan, 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@online.sinor.ru
To unsubscribe send a blank email to xxxxx@lists.osr.com
(???r??z{e?˛???m?m?{]z???&j)@u?Ӣ?칻?&ޱ??i?Z?G?j)m?W???u?칻-E?"?Ǧm??(Z?X???,??&
> But the disadvantage of using NDIS hooks is impossibility to use two or more drivers
implement such technique. My driver crashes on systems on which either Winroute or
Wingate or something like these are installed.
Try using InterlockedExchange for hook install and build a hook chain.
Max
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
Some problems trouble me and the users.
As u know, if we developed im driver under win2k without digital signature,
When the user want to install the driver some dialogs will prompt to ask whether
to continue install. This makes the user uncomfortable, why digital signature?
As a personal firewall, im driver seems too complex.
Thanks for suggestions.
> 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 wellBryan, 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
(???r??z{e?˛???m?m?{]z???&j)@u?Ӣ?칻?&ޱ??i?Z?G?j)m?W???u?칻-E?"?Ǧm??(Z?X???,??&
Bryan,
One more small question: “How could I detect trojan protocol stack (loaded
dynamicaly) without installed hook on NdisRegisterProtocol?”. Everyone knows
that trojan/virus developers have enough skills to develop their own
protocol driver and use it in kernel instead TDI interface provided by
original TCPIP. I would even say that with currently avalable Open Source
TCP/IP implementations it is not too difficult task. Sure, NDIS-hooking is
not universal decision, but gives more control over network subsystem then
IM-drivers.
Best Regards,
Vadim
http://www.ntndis.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Bryan Burgin
Sent: Saturday, December 29, 2001 5:11 AM
To: NT Developers Interest List
Cc: brucie@263.net; xxxxx@pcausa.com
Subject: [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:
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: xxxxx@pcausa.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