NT intermediate network driver

NTDEV
1

Hi,

what would be the best approach to fulfill the following specs for an NT intermediate network driver? Haven’t I seen sample code for something like this somewhere?

The driver should act as a layer, appearing to be a network card to the protocol stack, and communicating with the physical network card. That is, TCP/IP would be bound to the driver, and upon receiving a packet, the driver makes modifications and send the packet to the actual network card. Similarly, upon the physical network card receiving a packet, it would be delivered to the driver which would modify it and send it to the protocol stack.

The code to process the packets is not a fixed part of the driver and will be written by a third party; the driver must provide hooks to link in the the modification code (DLL?).

Thanks in advance for any hints.

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

2

It is certainly possible to process packets this way. The PCAUSA “Packet
Redirector” (PktRedir) NDIS IM driver sample includes this capability.
PktRedir is not yet released, but some information is at:
http://www.rawether.net/ndisim.

However, it is a much better way to perform all processing in kernel mode.
There will be an observable performance hit if all packets are routed to
user-mode and back for the processing. At the very least, your NDIS IM
driver should include filter logic to insure that packets that do not need
proccessing are not passed to user-mode.

Good luck,

Thomas F. Divine

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

----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Monday, October 08, 2001 6:06 AM
Subject: [ntdev] NT intermediate network driver

> Hi,
>
> what would be the best approach to fulfill the following specs for an NT
intermediate network driver? Haven’t I seen sample code for something like
this somewhere?
>
> The driver should act as a layer, appearing to be a network card to the
protocol stack, and communicating with the physical network card. That is,
TCP/IP would be bound to the driver, and upon receiving a packet, the driver
makes modifications and send the packet to the actual network card.
Similarly, upon the physical network card receiving a packet, it would be
delivered to the driver which would modify it and send it to the protocol
stack.
>
> The code to process the packets is not a fixed part of the driver and will
be written by a third party; the driver must provide hooks to link in the
the modification code (DLL?).
>
> Thanks in advance for any hints.
>
> Max
>
> —
> 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</http:></http:>

3

> The driver should act as a layer, appearing to be a network card to the protocol stack, and

communicating with the physical network card.

Yes.
A classic NDIS IM driver.

The code to process the packets is not a fixed part of the driver and will be written by a third
party; the driver must provide hooks to link in the the modification code (DLL?).

Yes, you can do this both in kernel mode (with C runtime limitations for the processor code) or in user mode (with performance
loss).

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

4

Hi Thomas and Max,

Thanks a lot for your replies.

> The driver should act as a layer, appearing to be a network card to the
>protocol stack, and communicating with the physical network card.

Yes.
A classic NDIS IM driver.

The one and only DDK sample for this is the “passthru” driver, right? Or am I missing one?

You both warn of the performance hits that a user mode filter would introduce. That’s an obvious trade-off, but what’s not so obvious to me: How can I link the user mode filter to the driver? That is, what interface must I implement for the kernel/user mode transition? Will classic C DLL’s work at all?

Thanks again for your help.

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

5

Hello!

The one and only DDK sample for this is the “passthru” driver, right? Or am
I missing one?
If you target Windows 2000/XP yes.

You both warn of the performance hits that a user mode filter would
introduce. That’s an obvious trade-off, but what’s not so obvious to me: How
can I link the user mode
filter to the driver? That is, what interface must I implement for the
kernel/user mode transition? Will classic C DLL’s work at all?

Actually, there are different approaches to resolve your problem. I don’t
think that I’m the only one who had the same work to do, but I’ll try to
ppoint some tips. You can use IM driver (documented by MS in DDK) or
NDIS-hooking driver. There could be real discussion what approach is better,
but as for me I prefer NDIS-hooking. It allows to have single binary driver
working from NT4.0 till XP, simple in installation (just new service entry
in registry), transparent dial-up support. You could say that hooking is
terrible thing and MS never certify such driver, but this does not mean that
it can’t be succefully implemented and robust in use. Btw, many developers
implement non-standard ideas in drivers. If you took a look into tdimsys.sys
driver (TDI-filtering driver from TCPView utility provided by
www.winternals.com), you will see that it also using non-standard idea.
Instead of attaching to TCPIP.SYS created devices via
IoAttachDeviceToDeviceStack it gets pointer to TCPIP.SYS driver object and
modifies MajorFunction array substituting it’s own dispatcher handler.
Anyway, first you should decide there your packets will be processed, in
driver or in user-mode application. If you choose to process packets in
kernel, you can manage your driver via IOCTL interface (loading NAT table,
keys for encryption/decryption, filtering rules and etc…). If you choose
user mode, it’s also can be easily implemented and I’ve even did it once for
one commercial product. I send and receive handlers of your driver you will
have to pass packets to user-mode app. via Read or IoControl interface
copying data from packets and completion of proprietary IRPs. Then you
instead of passing packets up or down of network stack block them and return
succesfull statuses do upper and lower drivers. Additionally, you will have
to implement pair of routines in your driver, first for sending packets to
protocol layer, and second for sending packets on the network layer (network
interface). After processing packets in user mode appication may (or may not
in case of block decision) return modified (or unmodified) packets to kernel
(directing them to protocol or network interface) via Write or IoControl
interface.

This is in short what you have to do. I don’t clearly understand why are you
asking about DLL, but you can place there code which will communicate
driver.

Best Regards,

Vadim

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

6

> ----------

From: Vadim Smirnov[SMTP:xxxxx@pcausa.com]
Reply To: NT Developers Interest List
Sent: Wednesday, October 10, 2001 1:39 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NT intermediate network driver

NDIS-hooking driver. There could be real discussion what approach is
better,
but as for me I prefer NDIS-hooking. It allows to have single binary
driver
working from NT4.0 till XP, simple in installation (just new service entry
in registry), transparent dial-up support. You could say that hooking is
terrible thing and MS never certify such driver, but this does not mean
that
it can’t be succefully implemented and robust in use.

Vadim, it is interesting. How do you implement hooking driver for NT?

As for “terrible thing”, I don’t think so. If I return 5 years back when
started IM driver project for NT4 and know about future problems, I would
prefer such solution and to avoid them all. w2k introduced NDIS filter
drivers which is IMHO good solution but it doesn’t solve compatibility
problem you mentioned. The only problem I see is performance degradation but
it is low comparing to mentioned user mode solution and maybe even
inconsiderable.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.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

7

>driver? That is, what interface must I implement for the kernel/user mode transition?

A set of IOCTLs of your own.

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

8

Michal,

I’ve simply modified export table of NDIS.SYS (my driver loads after
NDIS.SYS and before any protocol drivers), hooking NdisRegisterProtocol,
NdisDeregisterProtocol, NdisOpenAdapter, NdisCloseAdapter entries. After
this I can intercept any registering protocol and adapter opening. In
NdisRegisterProtocol I modify NDIS_PROTOCOL_CHARACTERISTICS structure
substituting my own handlers, this gives control on incoming trafic
(ProtocolReceive) and completion handlers. In NdisOpenAdapter I modify
NDIS_OPEN_BLOCK structure (returned parameter NdisBindingHandle actually is
a pointer to this structure and such functions like NdisSend are defined as
macros calling handlers from this structure in ndis.h ) and substitute such
handlers like SendHandler, SendPacketsHandler, RequestHandler. Other work is
very similar to PIM for 9x/ME. Actually, I’ve moved code from NT/XP to 9x/ME
for two days. Of course this was not my first driver based on this
technology(elsewhere it was not so fast, I’ve already knew what I’m doing),
I just wanted to create packet filtering framework for my own needs.

Another way could be modification of the NDIS.SYS code in the beginning of
functions mentioned before, putting there jump to your own code. Then in new
handler after call processing you could restore original function code, call
it, then modify code back. This is what Dan Lanciany (www.danlan.com) did in
his driver. It works but IMHO it’s not the best way because require multiply
code modifications (and WP bit resetting for 2000/XP).

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.

As for perfomance impact, it even less then in case of using IM driver,
especially if you implement pass/block decision, because it does not require
repacketization (IM always does).

Regards,

Vadim

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Michal Vodicka
Sent: Wednesday, October 10, 2001 10:07 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NT intermediate network driver

From: Vadim Smirnov[SMTP:xxxxx@pcausa.com]
Reply To: NT Developers Interest List
Sent: Wednesday, October 10, 2001 1:39 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NT intermediate network driver

NDIS-hooking driver. There could be real discussion what approach is
better,
but as for me I prefer NDIS-hooking. It allows to have single binary
driver
working from NT4.0 till XP, simple in installation (just new service entry
in registry), transparent dial-up support. You could say that hooking is
terrible thing and MS never certify such driver, but this does not mean
that
it can’t be succefully implemented and robust in use.

Vadim, it is interesting. How do you implement hooking driver for NT?

As for “terrible thing”, I don’t think so. If I return 5 years back when
started IM driver project for NT4 and know about future problems, I would
prefer such solution and to avoid them all. w2k introduced NDIS filter
drivers which is IMHO good solution but it doesn’t solve compatibility
problem you mentioned. The only problem I see is performance degradation but
it is low comparing to mentioned user mode solution and maybe even
inconsiderable.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.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

9

Vadim,

thanks for detailed description. I like the technique you’re using and
regret again I hadn’t this idea when worked on NT4 IM driver :wink: It seems
reliable if you’re able modify NDIS export table before any protocol driver
starts. Other techniques you showed doesn’t seem reliable on SMP but maybe
they use some protection against race conditions.

As for performance, you’re right. Common functions you’re hooking don’t have
impact on network performance and you neednot hook packet processing
functions as on w9x and decide which protocol called for example NdisSend.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]

From: Vadim Smirnov[SMTP:xxxxx@pcausa.com]
Reply To: NT Developers Interest List
Sent: Thursday, October 11, 2001 8:36 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NT intermediate network driver

Michal,

I’ve simply modified export table of NDIS.SYS (my driver loads after
NDIS.SYS and before any protocol drivers), hooking NdisRegisterProtocol,
NdisDeregisterProtocol, NdisOpenAdapter, NdisCloseAdapter entries. After
this I can intercept any registering protocol and adapter opening. In
NdisRegisterProtocol I modify NDIS_PROTOCOL_CHARACTERISTICS structure
substituting my own handlers, this gives control on incoming trafic
(ProtocolReceive) and completion handlers. In NdisOpenAdapter I modify
NDIS_OPEN_BLOCK structure (returned parameter NdisBindingHandle actually
is
a pointer to this structure and such functions like NdisSend are defined
as
macros calling handlers from this structure in ndis.h ) and substitute
such
handlers like SendHandler, SendPacketsHandler, RequestHandler. Other work
is
very similar to PIM for 9x/ME. Actually, I’ve moved code from NT/XP to
9x/ME
for two days. Of course this was not my first driver based on this
technology(elsewhere it was not so fast, I’ve already knew what I’m
doing),
I just wanted to create packet filtering framework for my own needs.

Another way could be modification of the NDIS.SYS code in the beginning of
functions mentioned before, putting there jump to your own code. Then in
new
handler after call processing you could restore original function code,
call
it, then modify code back. This is what Dan Lanciany (www.danlan.com) did
in
his driver. It works but IMHO it’s not the best way because require
multiply
code modifications (and WP bit resetting for 2000/XP).

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.

As for perfomance impact, it even less then in case of using IM driver,
especially if you implement pass/block decision, because it does not
require
repacketization (IM always does).

Regards,

Vadim

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

10

Hello Vadim !
Can You tell a bit more about subsituting miniport functions in
NDIS_OPEN_BLOCK ?
My OpenAdapter returns with NDIS_STATUS_PENDING and
Handlers inside NDIS_OPEN_BLOCK are set to 0…

Can You give an advise how can I get Miniport-routines and where to replace
them ?

thank You in advance.

Michal,

I’ve simply modified export table of NDIS.SYS (my driver loads after
NDIS.SYS and before any protocol drivers), hooking NdisRegisterProtocol,
NdisDeregisterProtocol, NdisOpenAdapter, NdisCloseAdapter entries. After
this I can intercept any registering protocol and adapter opening. In
NdisRegisterProtocol I modify NDIS_PROTOCOL_CHARACTERISTICS structure
substituting my own handlers, this gives control on incoming trafic
(ProtocolReceive) and completion handlers. In NdisOpenAdapter I modify
NDIS_OPEN_BLOCK structure (returned parameter NdisBindingHandle actually
is
a pointer to this structure and such functions like NdisSend are defined
as
macros calling handlers from this structure in ndis.h ) and substitute
such
handlers like SendHandler, SendPacketsHandler, RequestHandler. Other work
is
very similar to PIM for 9x/ME. Actually, I’ve moved code from NT/XP to
9x/ME
for two days. Of course this was not my first driver based on this
technology(elsewhere it was not so fast, I’ve already knew what I’m
doing),
I just wanted to create packet filtering framework for my own needs.

Another way could be modification of the NDIS.SYS code in the beginning of
functions mentioned before, putting there jump to your own code. Then in
new
handler after call processing you could restore original function code,
call
it, then modify code back. This is what Dan Lanciany (www.danlan.com) did
in
his driver. It works but IMHO it’s not the best way because require
multiply
code modifications (and WP bit resetting for 2000/XP).

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.

As for perfomance impact, it even less then in case of using IM driver,
especially if you implement pass/block decision, because it does not
require
repacketization (IM always does).

Regards,

Vadim

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Michal Vodicka
Sent: Wednesday, October 10, 2001 10:07 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NT intermediate network driver

> ----------
> From: Vadim Smirnov[SMTP:xxxxx@pcausa.com]
> Reply To: NT Developers Interest List
> Sent: Wednesday, October 10, 2001 1:39 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: NT intermediate network driver
>
> NDIS-hooking driver. There could be real discussion what approach is
> better,
> but as for me I prefer NDIS-hooking. It allows to have single binary
> driver
> working from NT4.0 till XP, simple in installation (just new service
entry
> in registry), transparent dial-up support. You could say that hooking is
> terrible thing and MS never certify such driver, but this does not mean
> that
> it can’t be succefully implemented and robust in use.
>
Vadim, it is interesting. How do you implement hooking driver for NT?

As for “terrible thing”, I don’t think so. If I return 5 years back when
started IM driver project for NT4 and know about future problems, I would
prefer such solution and to avoid them all. w2k introduced NDIS filter
drivers which is IMHO good solution but it doesn’t solve compatibility
problem you mentioned. The only problem I see is performance degradation
but
it is low comparing to mentioned user mode solution and maybe even
inconsiderable.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.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: xxxxx@beep.ru
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

11

Yes, but I suppose you already hooked TCPIP protocol handlers. You’ll get
NDIS_OPEN_BLOCK initialized in ProtocolOpenAdapter complete handler.

Good Luck,

Vadim

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of jenson
Sent: Wednesday, October 17, 2001 6:19 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NT intermediate network driver

Hello Vadim !
Can You tell a bit more about subsituting miniport functions in
NDIS_OPEN_BLOCK ?
My OpenAdapter returns with NDIS_STATUS_PENDING and
Handlers inside NDIS_OPEN_BLOCK are set to 0…

Can You give an advise how can I get Miniport-routines and where to replace
them ?

thank You in advance.

Michal,

I’ve simply modified export table of NDIS.SYS (my driver loads after
NDIS.SYS and before any protocol drivers), hooking NdisRegisterProtocol,
NdisDeregisterProtocol, NdisOpenAdapter, NdisCloseAdapter entries. After
this I can intercept any registering protocol and adapter opening. In
NdisRegisterProtocol I modify NDIS_PROTOCOL_CHARACTERISTICS structure
substituting my own handlers, this gives control on incoming trafic
(ProtocolReceive) and completion handlers. In NdisOpenAdapter I modify
NDIS_OPEN_BLOCK structure (returned parameter NdisBindingHandle actually
is
a pointer to this structure and such functions like NdisSend are defined
as
macros calling handlers from this structure in ndis.h ) and substitute
such
handlers like SendHandler, SendPacketsHandler, RequestHandler. Other work
is
very similar to PIM for 9x/ME. Actually, I’ve moved code from NT/XP to
9x/ME
for two days. Of course this was not my first driver based on this
technology(elsewhere it was not so fast, I’ve already knew what I’m
doing),
I just wanted to create packet filtering framework for my own needs.

Another way could be modification of the NDIS.SYS code in the beginning of
functions mentioned before, putting there jump to your own code. Then in
new
handler after call processing you could restore original function code,
call
it, then modify code back. This is what Dan Lanciany (www.danlan.com) did
in
his driver. It works but IMHO it’s not the best way because require
multiply
code modifications (and WP bit resetting for 2000/XP).

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.

As for perfomance impact, it even less then in case of using IM driver,
especially if you implement pass/block decision, because it does not
require
repacketization (IM always does).

Regards,

Vadim

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Michal Vodicka
Sent: Wednesday, October 10, 2001 10:07 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NT intermediate network driver

> ----------
> From: Vadim Smirnov[SMTP:xxxxx@pcausa.com]
> Reply To: NT Developers Interest List
> Sent: Wednesday, October 10, 2001 1:39 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: NT intermediate network driver
>
> NDIS-hooking driver. There could be real discussion what approach is
> better,
> but as for me I prefer NDIS-hooking. It allows to have single binary
> driver
> working from NT4.0 till XP, simple in installation (just new service
entry
> in registry), transparent dial-up support. You could say that hooking is
> terrible thing and MS never certify such driver, but this does not mean
> that
> it can’t be succefully implemented and robust in use.
>
Vadim, it is interesting. How do you implement hooking driver for NT?

As for “terrible thing”, I don’t think so. If I return 5 years back when
started IM driver project for NT4 and know about future problems, I would
prefer such solution and to avoid them all. w2k introduced NDIS filter
drivers which is IMHO good solution but it doesn’t solve compatibility
problem you mentioned. The only problem I see is performance degradation
but
it is low comparing to mentioned user mode solution and maybe even
inconsiderable.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.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: xxxxx@beep.ru
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

12

Thank You ! It works now … :slight_smile:
Now I Have another question, concerning this topic …
During initialization process NdisOpenAdapter executes several times. It
means, that there
is number of Protocols, that execute this function …

  1. How can I find out the name of protocol, that executes NdisOpenAdapter ?
  2. NdisOpenAdapter has parameter called AdapterName. This is the name of an
    Adapter.
    I guess, that registry contains a list of all adapters, registred in system.
    Where is it located ?

Thank You in advance.

----- Original Message -----
From: “Vadim Smirnov”
To: “NT Developers Interest List”
Sent: Wednesday, October 17, 2001 8:42 PM
Subject: [ntdev] Re: NT intermediate network driver

> Yes, but I suppose you already hooked TCPIP protocol handlers. You’ll get
> NDIS_OPEN_BLOCK initialized in ProtocolOpenAdapter complete handler.
>
> Good Luck,
>
> Vadim
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of jenson
> Sent: Wednesday, October 17, 2001 6:19 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: NT intermediate network driver
>
>
> Hello Vadim !
> Can You tell a bit more about subsituting miniport functions in
> NDIS_OPEN_BLOCK ?
> My OpenAdapter returns with NDIS_STATUS_PENDING and
> Handlers inside NDIS_OPEN_BLOCK are set to 0…
>
> Can You give an advise how can I get Miniport-routines and where to
replace
> them ?
>
> thank You in advance.
>
> > Michal,
> >
> > I’ve simply modified export table of NDIS.SYS (my driver loads after
> > NDIS.SYS and before any protocol drivers), hooking NdisRegisterProtocol,
> > NdisDeregisterProtocol, NdisOpenAdapter, NdisCloseAdapter entries. After
> > this I can intercept any registering protocol and adapter opening. In
> > NdisRegisterProtocol I modify NDIS_PROTOCOL_CHARACTERISTICS structure
> > substituting my own handlers, this gives control on incoming trafic
> > (ProtocolReceive) and completion handlers. In NdisOpenAdapter I modify
> > NDIS_OPEN_BLOCK structure (returned parameter NdisBindingHandle actually
> is
> > a pointer to this structure and such functions like NdisSend are defined
> as
> > macros calling handlers from this structure in ndis.h ) and substitute
> such
> > handlers like SendHandler, SendPacketsHandler, RequestHandler. Other
work
> is
> > very similar to PIM for 9x/ME. Actually, I’ve moved code from NT/XP to
> 9x/ME
> > for two days. Of course this was not my first driver based on this
> > technology(elsewhere it was not so fast, I’ve already knew what I’m
> doing),
> > I just wanted to create packet filtering framework for my own needs.
> >
> > Another way could be modification of the NDIS.SYS code in the beginning
of
> > functions mentioned before, putting there jump to your own code. Then in
> new
> > handler after call processing you could restore original function code,
> call
> > it, then modify code back. This is what Dan Lanciany (www.danlan.com)
did
> in
> > his driver. It works but IMHO it’s not the best way because require
> multiply
> > code modifications (and WP bit resetting for 2000/XP).
> >
> > 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.
> >
> > As for perfomance impact, it even less then in case of using IM driver,
> > especially if you implement pass/block decision, because it does not
> require
> > repacketization (IM always does).
> >
> > Regards,
> >
> > Vadim
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Michal Vodicka
> > Sent: Wednesday, October 10, 2001 10:07 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: NT intermediate network driver
> >
> >
> > > ----------
> > > From: Vadim Smirnov[SMTP:xxxxx@pcausa.com]
> > > Reply To: NT Developers Interest List
> > > Sent: Wednesday, October 10, 2001 1:39 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: NT intermediate network driver
> > >
> > > NDIS-hooking driver. There could be real discussion what approach is
> > > better,
> > > but as for me I prefer NDIS-hooking. It allows to have single binary
> > > driver
> > > working from NT4.0 till XP, simple in installation (just new service
> entry
> > > in registry), transparent dial-up support. You could say that hooking
is
> > > terrible thing and MS never certify such driver, but this does not
mean
> > > that
> > > it can’t be succefully implemented and robust in use.
> > >
> > Vadim, it is interesting. How do you implement hooking driver for NT?
> >
> > As for “terrible thing”, I don’t think so. If I return 5 years back when
> > started IM driver project for NT4 and know about future problems, I
would
> > prefer such solution and to avoid them all. w2k introduced NDIS filter
> > drivers which is IMHO good solution but it doesn’t solve compatibility
> > problem you mentioned. The only problem I see is performance degradation
> but
> > it is low comparing to mentioned user mode solution and maybe even
> > inconsiderable.
> >
> > Best regards,
> >
> > Michal Vodicka
> > Veridicom
> > (RKK - Skytale)
> > [WWW: http://www.veridicom.com , http://www.skytale.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: xxxxx@beep.ru
> > 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: xxxxx@beep.ru
> 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

13

Hello,

I would be very glad if you order your questions and formalize them more
exact, my english is not so good ;))

  1. How can I find out the name of protocol, that executes NdisOpenAdapter ?

Wnen NdisRegisterProtocol called you have protocol name and should associate
it with protocol handle. After this you can get protoco name in OpenAdapter.

  1. NdisOpenAdapter has parameter called AdapterName. This is the name of an
    Adapter.

Yes

I guess, that registry contains a list of all adapters, registred in
system.
Where is it located ?

Don’t remember exactly now, try to search.

Btw, you’d better order ready sample driver and wont spend time.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of jenson
Sent: Thursday, October 18, 2001 3:56 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NT intermediate network driver

Thank You ! It works now … :slight_smile:
Now I Have another question, concerning this topic …
During initialization process NdisOpenAdapter executes several times. It
means, that there
is number of Protocols, that execute this function …

  1. How can I find out the name of protocol, that executes NdisOpenAdapter ?

Thank You in advance.

----- Original Message -----
From: “Vadim Smirnov”
To: “NT Developers Interest List”
Sent: Wednesday, October 17, 2001 8:42 PM
Subject: [ntdev] Re: NT intermediate network driver

> Yes, but I suppose you already hooked TCPIP protocol handlers. You’ll get
> NDIS_OPEN_BLOCK initialized in ProtocolOpenAdapter complete handler.
>
> Good Luck,
>
> Vadim
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of jenson
> Sent: Wednesday, October 17, 2001 6:19 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: NT intermediate network driver
>
>
> Hello Vadim !
> Can You tell a bit more about subsituting miniport functions in
> NDIS_OPEN_BLOCK ?
> My OpenAdapter returns with NDIS_STATUS_PENDING and
> Handlers inside NDIS_OPEN_BLOCK are set to 0…
>
> Can You give an advise how can I get Miniport-routines and where to
replace
> them ?
>
> thank You in advance.
>
> > Michal,
> >
> > I’ve simply modified export table of NDIS.SYS (my driver loads after
> > NDIS.SYS and before any protocol drivers), hooking NdisRegisterProtocol,
> > NdisDeregisterProtocol, NdisOpenAdapter, NdisCloseAdapter entries. After
> > this I can intercept any registering protocol and adapter opening. In
> > NdisRegisterProtocol I modify NDIS_PROTOCOL_CHARACTERISTICS structure
> > substituting my own handlers, this gives control on incoming trafic
> > (ProtocolReceive) and completion handlers. In NdisOpenAdapter I modify
> > NDIS_OPEN_BLOCK structure (returned parameter NdisBindingHandle actually
> is
> > a pointer to this structure and such functions like NdisSend are defined
> as
> > macros calling handlers from this structure in ndis.h ) and substitute
> such
> > handlers like SendHandler, SendPacketsHandler, RequestHandler. Other
work
> is
> > very similar to PIM for 9x/ME. Actually, I’ve moved code from NT/XP to
> 9x/ME
> > for two days. Of course this was not my first driver based on this
> > technology(elsewhere it was not so fast, I’ve already knew what I’m
> doing),
> > I just wanted to create packet filtering framework for my own needs.
> >
> > Another way could be modification of the NDIS.SYS code in the beginning
of
> > functions mentioned before, putting there jump to your own code. Then in
> new
> > handler after call processing you could restore original function code,
> call
> > it, then modify code back. This is what Dan Lanciany (www.danlan.com)
did
> in
> > his driver. It works but IMHO it’s not the best way because require
> multiply
> > code modifications (and WP bit resetting for 2000/XP).
> >
> > 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.
> >
> > As for perfomance impact, it even less then in case of using IM driver,
> > especially if you implement pass/block decision, because it does not
> require
> > repacketization (IM always does).
> >
> > Regards,
> >
> > Vadim
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Michal Vodicka
> > Sent: Wednesday, October 10, 2001 10:07 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: NT intermediate network driver
> >
> >
> > > ----------
> > > From: Vadim Smirnov[SMTP:xxxxx@pcausa.com]
> > > Reply To: NT Developers Interest List
> > > Sent: Wednesday, October 10, 2001 1:39 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: NT intermediate network driver
> > >
> > > NDIS-hooking driver. There could be real discussion what approach is
> > > better,
> > > but as for me I prefer NDIS-hooking. It allows to have single binary
> > > driver
> > > working from NT4.0 till XP, simple in installation (just new service
> entry
> > > in registry), transparent dial-up support. You could say that hooking
is
> > > terrible thing and MS never certify such driver, but this does not
mean
> > > that
> > > it can’t be succefully implemented and robust in use.
> > >
> > Vadim, it is interesting. How do you implement hooking driver for NT?
> >
> > As for “terrible thing”, I don’t think so. If I return 5 years back when
> > started IM driver project for NT4 and know about future problems, I
would
> > prefer such solution and to avoid them all. w2k introduced NDIS filter
> > drivers which is IMHO good solution but it doesn’t solve compatibility
> > problem you mentioned. The only problem I see is performance degradation
> but
> > it is low comparing to mentioned user mode solution and maybe even
> > inconsiderable.
> >
> > Best regards,
> >
> > Michal Vodicka
> > Veridicom
> > (RKK - Skytale)
> > [WWW: http://www.veridicom.com , http://www.skytale.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: xxxxx@beep.ru
> > 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: xxxxx@beep.ru
> 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

14

> 2. NdisOpenAdapter has parameter called AdapterName. This is the name of an

Adapter.
I guess, that registry contains a list of all adapters, registred in system.

In NDIS4, NdisOpenAdapter must be called only from your ProtocolBindAdapter callback.
NDIS supplies you the adapter name as a parameter to ProtocolBindAdapter.
Forget about scanning the registry for adapter names - this is ancient NDIS3 thing.

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