How to enumerate installed ndis miniport driver in kernel space

NTDEV
1

Hi,

We are developing an ndis im filter driver which we wish to enforce the binding to all eligible ndis miniport driver. After searching, it seems that one way of doing it is to use notify object. However, the user can simple delete the dll file to bypass it. We’d like to enforce or at least detect unbound miniport device driver in our im driver. So, is there any way to enumerate all installed miniport driver in kernel space? Anything similar to the user space SetupDiXXXX function, or do we have to dig into the undocumented registry?

Appreciated if anyone can help. Thanks

Cheers
Zheng Lei

2

You are about to embark on a waste of time.

If the user has the privilege to delete a notify object (DLL) the user has
the privilege to just uninstall your driver or run BindView and unbind your
IM driver, or do darn near anything else they want to do.

So let me ask some questions:

  1. Let’s say you have a way to discover from kernel mode that your IM is not
    bound to a particular adapter that your think you should be bound to? Then
    what? You cannot do much more than just ‘know’ this. You surely cannot
    ‘remediate’ it from kernel mode.

  2. If all you want to do is know the condition exists, what about having a
    helper service application which watches for PnP notifications regarding Net
    Class device installations and ‘evaluates’ if your IM driver has been
    properly installed by using the documented SetupDi and INetCfg facilities?

  3. Just what are you trying to accomplish for real?

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, May 26, 2010 3:26 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to enumerate installed ndis miniport driver in kernel
space

Hi,

We are developing an ndis im filter driver which we wish to enforce the
binding to all eligible ndis miniport driver. After searching, it seems that
one way of doing it is to use notify object. However, the user can simple
delete the dll file to bypass it. We’d like to enforce or at least detect
unbound miniport device driver in our im driver. So, is there any way to
enumerate all installed miniport driver in kernel space? Anything similar to
the user space SetupDiXXXX function, or do we have to dig into the
undocumented registry?

Appreciated if anyone can help. Thanks

Cheers
Zheng Lei

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

wrote in message news:xxxxx@ntdev…
> Hi,
>
> We are developing an ndis im filter driver which we wish to enforce the
> binding to all eligible ndis miniport driver. After searching, it seems
> that one way of doing it is to use notify object. However, the user can
> simple delete the dll file to bypass it. We’d like to enforce or at least
> detect unbound miniport device driver in our im driver. So, is there any
> way to enumerate all installed miniport driver in kernel space? Anything
> similar to the user space SetupDiXXXX function, or do we have to dig into
> the undocumented registry?
>
> Appreciated if anyone can help. Thanks
>
> Cheers
> Zheng Lei

NDIS will enumerate the miniports to your IM, when it is correctly
installed.

If users are motivated to bypass your software , and are local admins,
there is NOTHING you can do to stop them.
Place your “security enforcement” (or whatever) outside of their machines,
and deny network access to machines where your software is not installed.

Regards,
– pa

4

Detecting any unbound situation is all that’s necessary for our case. We have a second driver which provides essential services. And it can deny such services once any unbound miniport driver is detected. Now, if I put the detection code into this critical second driver of ours, I don’t think there is any way the user can bypass it.

So, the question remains. Is there any to detect any unbound miniport driver. The way I see it, if we can enumerate all miniport driver installed, it’ll be easy to achieve that.

I know that when the im driver is initially installed, it will be bounded to all miniport drivers. However, there is no sure way to trace all the binding and unbinding activities.

5

Perhaps a different perspective…

I assume that you want to interpose your IM driver between adapters and some set of protocols like say, TCPIP. It would be unusual for instance to build an IM driver capable of binding to every conceivable type of adapter type. One need only ponder doing this for CoNdis miniports, WAN Miniports, IRDA miniports, etc. etc. to see that you probably don’t want to know about every conceivable NDIS miniport adapter instance in the system.

So now the question becomes can you tell if your IM driver is in every binding stack that it should be in at the time you check.

Another way of looking at that question migth be “can I tell that my IM driver is in in the stack of every adapter that protocol XXXX is bound too?” And if that protocol XXXX happens to be the one and only protocol of interest to the real world (TCPIP) then you have a chance of doing this without hammering your head against the unbounded and painful problem of answering your first question.

To wit:

An IM driver knows the “Adapter GUID” of the binding stack in which it is bound. Well, it can know anyway.

It is also possible via TDI (NT5) or K-Mode IPHLP (NT6) to find out all of the interfaces that TCPIP is actively bound and communicating on and generally a wealth of related info (MAC address is an example, but not particulary useful). But clearly enough information to corrolate those interfaces with the ones your IM driver is actively bound in.

And thus with only a small bit of head scratching you can calculate if every adapter that TCPIP is talking to, your IM driver is interposed between. If the answer is no, well you can call in the artillery and blow up the silly user if you want.

If your protocol XXXX is TP4, IPX, or some science project from the 80s then good luck. If it is TCPIP then it is not such a hard question to answer. Just ask a better question.

Good Luck,

Dave Cattley

Date: Thu, 27 May 2010 00:44:30 -0400
From: xxxxx@hotmail.com
To: xxxxx@lists.osr.com
Subject: RE:[ntdev] How to enumerate installed ndis miniport driver in kernel space

Detecting any unbound situation is all that’s necessary for our case. We have a second driver which provides essential services. And it can deny such services once any unbound miniport driver is detected. Now, if I put the detection code into this critical second driver of ours, I don’t think there is any way the user can bypass it.

So, the question remains. Is there any to detect any unbound miniport driver. The way I see it, if we can enumerate all miniport driver installed, it’ll be easy to achieve that.

I know that when the im driver is initially installed, it will be bounded to all miniport drivers. However, there is no sure way to trace all the binding and unbinding activities.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

What an insightful post. I’ll choose the TDI approach. Thank you so much!

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Cattley
Sent: Thursday, 27 May, 2010 11:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to enumerate installed ndis miniport driver in
kernel space

Perhaps a different perspective…

I assume that you want to interpose your IM driver between adapters and some
set of protocols like say, TCPIP. It would be unusual for instance to build
an IM driver capable of binding to every conceivable type of adapter type.
One need only ponder doing this for CoNdis miniports, WAN Miniports, IRDA
miniports, etc. etc. to see that you probably don’t want to know about every
conceivable NDIS miniport adapter instance in the system.

So now the question becomes can you tell if your IM driver is in every
binding stack that it should be in at the time you check.

Another way of looking at that question migth be “can I tell that my IM
driver is in in the stack of every adapter that protocol XXXX is bound too?”
And if that protocol XXXX happens to be the one and only protocol of
interest to the real world (TCPIP) then you have a chance of doing this
without hammering your head against the unbounded and painful problem of
answering your first question.

To wit:

An IM driver knows the “Adapter GUID” of the binding stack in which it is
bound. Well, it can know anyway.

It is also possible via TDI (NT5) or K-Mode IPHLP (NT6) to find out all of
the interfaces that TCPIP is actively bound and communicating on and
generally a wealth of related info (MAC address is an example, but not
particulary useful). But clearly enough information to corrolate those
interfaces with the ones your IM driver is actively bound in.

And thus with only a small bit of head scratching you can calculate if every
adapter that TCPIP is talking to, your IM driver is interposed between. If
the answer is no, well you can call in the artillery and blow up the silly
user if you want.

If your protocol XXXX is TP4, IPX, or some science project from the 80s then
good luck. If it is TCPIP then it is not such a hard question to answer.
Just ask a better question.

Good Luck,
Dave Cattley

Date: Thu, 27 May 2010 00:44:30 -0400
From: xxxxx@hotmail.com
To: xxxxx@lists.osr.com
Subject: RE:[ntdev] How to enumerate installed ndis miniport driver in
kernel space

Detecting any unbound situation is all that’s necessary for our case. We
have a second driver which provides essential services. And it can deny such
services once any unbound miniport driver is detected. Now, if I put the
detection code into this critical second driver of ours, I don’t think there
is any way the user can bypass it.

So, the question remains. Is there any to detect any unbound miniport
driver. The way I see it, if we can enumerate all miniport driver installed,
it’ll be easy to achieve that.

I know that when the im driver is initially installed, it will be bounded
to all miniport drivers. However, there is no sure way to trace all the
binding and unbinding activities.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer