Hi All,
-
If I want to ensure that only a specific set of drivers should be loaded under my IM driver - I dont worry much about NDIS miniport drivers - I am worried only about the IM drivers between my IM driver and the NDIS miniports - whats the best way to ensure this? I know I can control the loading order using the tag in the registry. Can I rely on the packet stacking count, registry monitoring to detect the number and type of IM drivers between my IM driver and the miniports.
-
I understand that IM drivers get to all packets sent to and from between the miniport drivers and the TCP/IP stack. Is this a good assumption? Will this fail in any condition? Is there a way for a miniport to bypass me in the stack and get packets directly to TCP/IP without going through my IM driver?
-
Is there a way to disable IM drivers i.e. take then out of the stack. Do the IM drivers get disabled/unloaded when the miniports are disabled ? - I know the lower edge will get unbound… Can I rely on not registering a unload function to avoid being unloaded?
Thanks in advance for your time and help.
regards
y
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.
On 5/10/06 7:06 PM, “v s” wrote:
Did you miss a question? You have no question labeled “1” and two labeled
“3”. Just thought I’d toss that out there.
> 2. If I want to ensure that only a specific set of drivers should be loaded
> under my IM driver - I dont worry much about NDIS miniport drivers - I am
> worried only about the IM drivers between my IM driver and the NDIS miniports
> - whats the best way to ensure this? I know I can control the loading order
> using the tag in the registry. Can I rely on the packet stacking count,
> registry monitoring to detect the number and type of IM drivers between my IM
> driver and the miniports.
You can indeed alter the FilterClass value in the registry to manipulate the
stacking order. However, so can anyone else. You could do a coinstaller or
some sort of monitor program to put it back. So could someone else. Etc.
Why does this matter to you? It’s (obviously) very weak security, if that’s
what you’re after.
Incidentally, I assume you’re doing a filter IM. Right?
> 3. I understand that IM drivers get to all packets sent to and from between
> the miniport drivers and the TCP/IP stack. Is this a good assumption?
Only if you’re actually bound over every miniport in the system; you can
easily un-check your IM to prevent it from binding to certain interfaces.
This can, of course, be done programmatically as well.
> Will
> this fail in any condition? Is there a way for a miniport to bypass me in the
> stack and get packets directly to TCP/IP without going through my IM driver?
There’s the above, of course, and there’s the theoretical possibility of an
IM driver binding under you and stealing your packets and (through fairly
evil means) bypassing you. Or it could send the packets back to usermode
through an inverted call to a registered device object. Or someone could
hook you or NDIS or the miniport to patch you out (again through evil
means). None of these are remotely reasonable ways to build a product, but
if you’re the blackhat, these options are very real.
And don’t forget, there’s more to NDIS than miniports.
> 3. Is there a way to disable IM drivers i.e. take then out of the stack. Do
> the IM drivers get disabled/unloaded when the miniports are disabled ? - I
> know the lower edge will get unbound… Can I rely on not registering a unload
> function to avoid being unloaded?
Yes; see above. Unloading depends on binding; once they’re not loaded over
anything else any more, they can be unloaded (sometimes). NDIS gets to
decide when to load and unload you, and you can’t really influence it much
beyond coding intentional bugs to stay pinned in memory. You can set an
unload handler and add a DbgPrint to it to see when you’re getting unloaded
during testing. But, as is generally the case with miniport/port models,
you’re better off only caring about the things the framework tells you to
care about. NDIS driver don’t usually care when or if they unload. (Adjust
this advice for your circumstances; if you do one-time stuff in DriverEntry
that needs to be undone, UnloadHandler is a good place).
As to the last question, the driver’s unload routine is handled internally
by NDIS. You get a callback if you register for one, but whether or not you
have an unload routine depends on what NDIS decides, not on whether or not
you register an unload handler.
-Steve
> 3. I understand that IM drivers get to all packets sent to and from between
the
miniport drivers and the TCP/IP stack. Is this a good assumption? Will this
fail in
any condition? Is there a way for a miniport to bypass me in the stack and get
packets directly to TCP/IP without going through my IM driver?
Yes, unless some software will hook the functions in the undocumented structure
of NDIS binding handle. In this case, it can probably bypass your IM.
Nevertheless, the only such software I know is ZoneAlarm firewall, and it just
does filtering and not bypassing anything, being the security software.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com