Traffic Monitor Using TDI or NDIS - Programmer

This is a discussion on Traffic Monitor Using TDI or NDIS - Programmer ; Hi All, I want to write an application that can monitor network traffic while installed on the machine under surveillance. My initial choice was LSP but after having certain issues with it, i have almost abandoned this approach. Please look ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Traffic Monitor Using TDI or NDIS

  1. Traffic Monitor Using TDI or NDIS

    Hi All,

    I want to write an application that can monitor network traffic while
    installed on the machine under surveillance. My initial choice was LSP
    but after having certain issues with it, i have almost abandoned this
    approach. Please look at the following link if you want further
    details.

    http://groups.google.com.pk/group/mi...e5caca9f7e3119

    Now i am thinking about writing kernel drivers to accomplish this
    task. After conducting some research, i have come to know about TDI
    and NDIS. Before delving deep into both of these approaches, i have a
    few questions. These are:

    - Is there any framework/sample code (both for TDI and NDIS) available
    that can be used as a starting point to develop a driver that can
    intercept network traffic? I know about the PassThru sample which uses
    NDIS.

    - Can there be a scenario or a way by means of which TDI can be
    completely bypassed? In other words, can a network operation (listen,
    send, receive etc) bypass TDI and directly access transport layer (or
    beyond) to execute network operation?

    - Is calling process information is available at TDI or NDIS level?
    For example if there is a send call then is it possible at TDI or NDIS
    level to identify which user level process made that call?

    - Which approach (TDI or NDIS) is better when it comes to implementing
    network activity monitoring functionality?

    Thank you for your help.

    sarshah.

  2. Re: Traffic Monitor Using TDI or NDIS

    > - Can there be a scenario or a way by means of which TDI can be
    > completely bypassed? In other words, can a network operation (listen,
    > send, receive etc) bypass TDI and directly access transport layer (or
    > beyond) to execute network operation?


    Pre-Vista no (TDI is native upper edge of TCPIP), in Vista and 2008, yes (TDI
    is a shim over I think Wsk which is the native upper edge of TCPIP).

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    maxim@storagecraft.com
    http://www.storagecraft.com


  3. Re: Traffic Monitor Using TDI or NDIS

    sarshah20@yahoo.com wrote:
    > - Is there any framework/sample code (both for TDI and NDIS) available
    > that can be used as a starting point to develop a driver that can
    > intercept network traffic? I know about the PassThru sample which uses
    > NDIS.


    There's a TDI firewall around on the net. Badly written, IMHO.

    TDI is complex and poorly documented, however. Walter Oney's posts here
    are about a third of the documentation. You could easily spend a year
    learning the ins and outs. I know, I did.

    > - Can there be a scenario or a way by means of which TDI can be
    > completely bypassed? In other words, can a network operation (listen,
    > send, receive etc) bypass TDI and directly access transport layer (or
    > beyond) to execute network operation?


    I believe so, but it would require extensive knowledge which is probably
    only available internally to Microsoft.

    > - Is calling process information is available at TDI or NDIS level?
    > For example if there is a send call then is it possible at TDI or NDIS
    > level to identify which user level process made that call?


    TDI yes, NDIS no.

    However, be aware you will be at DISPATCH_LEVEL for incoming data in
    TDI, which makes dealing with incoming data difficult. I have a patent
    in the works which describes a (bad) solution to this.

    > - Which approach (TDI or NDIS) is better when it comes to implementing
    > network activity monitoring functionality?


    I would say a blend of the two. TDI to get process information for
    sockets, NDIS for the grunt work.

    You are aware you're looking at about two years of full-time work?
    that's how long it took me to write the software you're about to
    write...

  4. Re: Traffic Monitor Using TDI or NDIS

    Thanks for all the responses. My scope indeed is very limited. I don't
    want to modify any data. All i need is to identify 2 or 3 operations
    such as listen call and log any such event. The only data i will be
    dealing and extracting from is DNS queries. The machine (XP base and
    w2k) will be running in a strictly controlled environment and i will
    be aware of the new and old processes. Considering these requirements,
    i hope that i can accomplish it in a couple of month tops.

    I was going through various articles related to TDI and i have
    developed some confusion (probably a stupid one). The confusion is the
    number of various terms that use TDI. So the questions are:

    - What is the difference between TDI Driver, TDI Filter Driver and TDI
    Client? Are they the same?

    - If i am writing a network traffic monitor using TDI then what i
    would have to write from the above?

    Thanks

    sarshah

    On Feb 28, 7:12 am, Toby Douglass 45mercystreet.com> wrote:
    > sarsha...@yahoo.com wrote:
    > > - Is there any framework/sample code (both forTDIandNDIS) available
    > > that can be used as a starting point to develop a driver that can
    > > intercept networktraffic? I know about the PassThru sample which uses
    > >NDIS.

    >
    > There's aTDIfirewall around on the net. Badly written, IMHO.
    >
    > TDIis complex and poorly documented, however. Walter Oney's posts here
    > are about a third of the documentation. You could easily spend a year
    > learning the ins and outs. I know, I did.
    >
    > > - Can there be a scenario or a way by means of whichTDIcan be
    > > completely bypassed? In other words, can a network operation (listen,
    > > send, receive etc) bypassTDIand directly access transport layer (or
    > > beyond) to execute network operation?

    >
    > I believe so, but it would require extensive knowledge which is probably
    > only available internally to Microsoft.
    >
    > > - Is calling process information is available atTDIorNDISlevel?
    > > For example if there is a send call then is it possible atTDIorNDIS
    > > level to identify which user level process made that call?

    >
    > TDIyes,NDISno.
    >
    > However, be aware you will be at DISPATCH_LEVEL for incoming data inTDI, which makes dealing with incoming data difficult. I have a patent
    > in the works which describes a (bad) solution to this.
    >
    > > - Which approach (TDIorNDIS) is better when it comes to implementing
    > > network activity monitoring functionality?

    >
    > I would say a blend of the two. TDIto get process information for
    > sockets,NDISfor the grunt work.
    >
    > You are aware you're looking at about two years of full-time work?
    > that's how long it took me to write the software you're about to
    > write...



  5. Re: Traffic Monitor Using TDI or NDIS

    For DNS only, I would use NDIS IM. Take the PASSTHRU sample as a base.

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    maxim@storagecraft.com
    http://www.storagecraft.com

    wrote in message
    news:87818d5b-dcab-4a1c-b6ae-573d68d098c8@z17g2000hsg.googlegroups.com...
    > Thanks for all the responses. My scope indeed is very limited. I don't
    > want to modify any data. All i need is to identify 2 or 3 operations
    > such as listen call and log any such event. The only data i will be
    > dealing and extracting from is DNS queries. The machine (XP base and
    > w2k) will be running in a strictly controlled environment and i will
    > be aware of the new and old processes. Considering these requirements,
    > i hope that i can accomplish it in a couple of month tops.
    >
    > I was going through various articles related to TDI and i have
    > developed some confusion (probably a stupid one). The confusion is the
    > number of various terms that use TDI. So the questions are:
    >
    > - What is the difference between TDI Driver, TDI Filter Driver and TDI
    > Client? Are they the same?
    >
    > - If i am writing a network traffic monitor using TDI then what i
    > would have to write from the above?
    >
    > Thanks
    >
    > sarshah
    >
    > On Feb 28, 7:12 am, Toby Douglass > 45mercystreet.com> wrote:
    > > sarsha...@yahoo.com wrote:
    > > > - Is there any framework/sample code (both forTDIandNDIS) available
    > > > that can be used as a starting point to develop a driver that can
    > > > intercept networktraffic? I know about the PassThru sample which uses
    > > >NDIS.

    > >
    > > There's aTDIfirewall around on the net. Badly written, IMHO.
    > >
    > > TDIis complex and poorly documented, however. Walter Oney's posts here
    > > are about a third of the documentation. You could easily spend a year
    > > learning the ins and outs. I know, I did.
    > >
    > > > - Can there be a scenario or a way by means of whichTDIcan be
    > > > completely bypassed? In other words, can a network operation (listen,
    > > > send, receive etc) bypassTDIand directly access transport layer (or
    > > > beyond) to execute network operation?

    > >
    > > I believe so, but it would require extensive knowledge which is probably
    > > only available internally to Microsoft.
    > >
    > > > - Is calling process information is available atTDIorNDISlevel?
    > > > For example if there is a send call then is it possible atTDIorNDIS
    > > > level to identify which user level process made that call?

    > >
    > > TDIyes,NDISno.
    > >
    > > However, be aware you will be at DISPATCH_LEVEL for incoming data inTDI,

    which makes dealing with incoming data difficult. I have a patent
    > > in the works which describes a (bad) solution to this.
    > >
    > > > - Which approach (TDIorNDIS) is better when it comes to implementing
    > > > network activity monitoring functionality?

    > >
    > > I would say a blend of the two. TDIto get process information for
    > > sockets,NDISfor the grunt work.
    > >
    > > You are aware you're looking at about two years of full-time work?
    > > that's how long it took me to write the software you're about to
    > > write...

    >



  6. Re: Traffic Monitor Using TDI or NDIS

    sarshah20@yahoo.com wrote:
    > Thanks for all the responses. My scope indeed is very limited. I don't
    > want to modify any data. All i need is to identify 2 or 3 operations
    > such as listen call and log any such event. The only data i will be
    > dealing and extracting from is DNS queries. The machine (XP base and
    > w2k) will be running in a strictly controlled environment and i will
    > be aware of the new and old processes. Considering these requirements,
    > i hope that i can accomplish it in a couple of month tops.


    I could be wrong, but my gut feeling is: not a chance in hell.

    Right now, you're only seeing the outlines of the problem and from the
    questions you're asking, you've not got them nailed down yet. The
    outlines aren't actually too hard; but the actually nitty gritty of
    getting a TDI filter driver to work is a nightmare. All of that right
    now is invisible to you, so you cannot judge it in your gut measurement
    of this task.

    Sincerely though, I wish you the best of luck.

    > I was going through various articles related to TDI and i have
    > developed some confusion (probably a stupid one). The confusion is the
    > number of various terms that use TDI. So the questions are:
    >
    > - What is the difference between TDI Driver, TDI Filter Driver and TDI
    > Client? Are they the same?


    There is no TDI driver. Probably they mean the Transport Provider.

    The TDI client is the bottom edge of the user application. It emits TDI
    commands to the Transport Provider. The top edge of the Transport
    Provider accepts these commands and implements them. The TDI filter
    driver is your driver, which places itself above the Transport Provider,
    such that it intercepts IRPs between the two.

    You need to read the TDI and network stack pages in the kernel docs.

    Your driver maintains a shadow of the current TCP/IP state, by inferring
    it from the contents of the IRPs that it sees go by. You need to
    understand everything that goes on in TDI, because all of it can happen
    (and usually does, and in weird and unexpected ways) and all of it
    affects the shadow state you're keeping.

    > - If i am writing a network traffic monitor using TDI then what i
    > would have to write from the above?


    One approach is a Windows service to communicate with the driver, and
    then a client which communicates with the service. Or you could write a
    single app which communicates directly with the driver.


  7. Re: Traffic Monitor Using TDI or NDIS

    Thank you guys for your responses.

    > For DNS only, I would use NDIS IM. Take the PASSTHRU sample as a base.


    But like i said before, i need to associate a user level process with
    any network activity under my scope. So writting just an NDIS IM
    Driver wont do the trick for me.


    >I could be wrong, but my gut feeling is: not a chance in hell.
    >
    >Right now, you're only seeing the outlines of the problem and from the
    >questions you're asking, you've not got them nailed down yet. The
    >outlines aren't actually too hard; but the actually nitty gritty of
    >getting a TDI filter driver to work is a nightmare. All of that right
    >now is invisible to you, so you cannot judge it in your gut measurement
    >of this task.
    >
    >Sincerely though, I wish you the best of luck.


    I was planning to base my code by taking ideas from the open source
    TDI firewall. I will be careful since u said it was badly written but
    all i will be looking at is how a basic TDI filter driver is written
    including how it maintains a shadow of the current TCP/IP state.

    In addition to TDI and network stack pages in the kernel docs, could
    you please refer some more readings that are particularly about how to
    write a TDI client.......something like a tutorial.

    Thanks Toby for your detailed reply.

    sarshah.


    On Feb 29, 1:20*am, Toby Douglass 45mercystreet.com> wrote:
    > sarsha...@yahoo.com wrote:
    > > Thanks for all the responses. My scope indeed is very limited. I don't
    > > want to modify any data. All i need is to identify 2 or 3 operations
    > > such as listen call and log any such event. The only data i will be
    > > dealing and extracting from is DNS queries. The machine (XP base and
    > > w2k) will be running in a strictly controlled environment and i will
    > > be aware of the new and old processes. Considering these requirements,
    > > i hope that i can accomplish it in a couple of month tops.

    >
    > I could be wrong, but my gut feeling is: not a chance in hell.
    >
    > Right now, you're only seeing the outlines of the problem and from the
    > questions you're asking, you've not got them nailed down yet. *The
    > outlines aren't actually too hard; but the actually nitty gritty of
    > getting aTDIfilter driver to work is a nightmare. *All of that right
    > now is invisible to you, so you cannot judge it in your gut measurement
    > of this task.
    >
    > Sincerely though, I wish you the best of luck.
    >
    > > I was going through various articles related toTDIand i have
    > > developed some confusion (probably a stupid one). The confusion is the
    > > number of various terms that useTDI. So the questions are:

    >
    > > - What is the difference betweenTDIDriver,TDIFilter Driver andTDI
    > > Client? Are they the same?

    >
    > There is noTDIdriver. *Probably they mean the Transport Provider.
    >
    > TheTDIclient is the bottom edge of the user application. *It emitsTDI
    > commands to the Transport Provider. *The top edge of the Transport
    > Provider accepts these commands and implements them. *TheTDIfilter
    > driver is your driver, which places itself above the Transport Provider,
    > such that it intercepts IRPs between the two.
    >
    > You need to read theTDIand network stack pages in the kernel docs.
    >
    > Your driver maintains a shadow of the current TCP/IP state, by inferring
    > it from the contents of the IRPs that it sees go by. *You need to
    > understand everything that goes on inTDI, because all of it can happen
    > (and usually does, and in weird and unexpected ways) and all of it
    > affects the shadow state you're keeping.
    >
    > > - If i am writing a networktrafficmonitorusingTDIthen what i
    > > would have to write from the above?

    >
    > One approach is a Windows service to communicate with the driver, and
    > then a client which communicates with the service. *Or you could write a
    > single app which communicates directly with the driver.



  8. Re: Traffic Monitor Using TDI or NDIS

    sarshah20@yahoo.com wrote:
    > I was planning to base my code by taking ideas from the open source
    > TDI firewall. I will be careful since u said it was badly written but
    > all i will be looking at is how a basic TDI filter driver is written
    > including how it maintains a shadow of the current TCP/IP state.


    Yees-s-s-s...I'm not sure that particular code keeps track very much.
    OTOH I didn't look much into it - it was hard to figure out what it
    thought it was doing. I'm not sure you'll find it useful; I didn't, and
    I *already* knew what it had to be doing.

    > In addition to TDI and network stack pages in the kernel docs, could
    > you please refer some more readings that are particularly about how to
    > write a TDI client.......something like a tutorial.


    But you're not writing a TDI client, you're writing a TDI filter driver.
    Very different animal. There are no tutorials for either, although
    there is a post in Usenet, let me see if I can find it, which gives the
    basic code for a TDI client.

    Hmm, here's a set of Usenet threads which you might find interesting
    (the second one is the source code to a simple TDI client);

    http://groups.google.com/group/comp....mer.nt.kernel-
    mode/browse_frm/thread/b32a9bac149cafa/a25598fa87173a2f?
    hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%
    3DUTF-8%26oe%3DUTF-8%26q%3DTDI_EVENT_RECEIVE%2Blevel%26btnG%3DGoogle%
    2BSearch#a25598fa87173a2f

    http://groups.google.com/group/comp....mer.nt.kernel-
    mode/browse_frm/thread/985b7b85a36670a8/74a3650b84d4700e?
    hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=1&prev=/groups%3Fas_q%
    3DTdiBuildInternalDeviceControlIrp%2520TdiBuildRec eive%26safe%3Dimages%
    26ie%3DUTF-8%26oe%3DUTF-8%26lr%3D%26hl%3Den#74a3650b84d4700e

    http://groups.google.com/group/comp....mer.nt.kernel-
    mode/browse_frm/thread/30594f827bc214e3/350cabc8948e31e6?
    hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&rnum=6&prev=/groups%3Fas_q%
    3DSTATUS_MORE_PROCESSING_REQUIRED%2520IoFreeIrp%26 safe%3Doff%26ie%3DUTF-
    8%26oe%3DUTF-8%26lr%3D%26hl%3Den#350cabc8948e31e6

    http://groups.google.com/group/comp....mer.nt.kernel-
    mode/browse_frm/thread/4fa4500a2b666233/d6d5a54bf05496ac?
    hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=7&prev=/groups%3Fas_q%3DBytesTaken%
    2520BytesAvailable%26safe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26lr%3D%
    26hl%3Den#d6d5a54bf05496ac


  9. Re: Traffic Monitor Using TDI or NDIS

    Oh sorry I meant tutorial/articles for writing TDI filter driver

    thanks,

    sarshah.


    On Mar 2, 5:42*am, Toby Douglass 45mercystreet.com> wrote:
    > sarsha...@yahoo.com wrote:
    > > I was planning to base my code by taking ideas from the open source
    > >TDIfirewall. I will be careful since u said it was badly written but
    > > all i will be looking at is how a basicTDIfilter driver is written
    > > including how it maintains a shadow of the current TCP/IP state.

    >
    > Yees-s-s-s...I'm not sure that particular code keeps track very much. *
    > OTOH I didn't look much into it - it was hard to figure out what it
    > thought it was doing. *I'm not sure you'll find it useful; I didn't, and
    > I *already* knew what it had to be doing.
    >
    > > In addition to *TDIand network stack pages in the kernel docs, could
    > > you please refer some more readings that are particularly about how to
    > > write aTDIclient.......something like a tutorial.

    >
    > But you're not writing aTDIclient, you're writing aTDIfilter driver. *
    > Very different animal. *There are no tutorials for either, although
    > there is a post in Usenet, let me see if I can find it, which gives the
    > basic code for aTDIclient.
    >
    > Hmm, here's a set of Usenet threads which you might find interesting
    > (the second one is the source code to a simpleTDIclient);
    >
    > http://groups.google.com/group/comp....mer.nt.kernel-
    > mode/browse_frm/thread/b32a9bac149cafa/a25598fa87173a2f?
    > hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%
    > 3DUTF-8%26oe%3DUTF-8%26q%3DTDI_EVENT_RECEIVE%2Blevel%26btnG%3DGoogle%
    > 2BSearch#a25598fa87173a2f
    >
    > http://groups.google.com/group/comp....mer.nt.kernel-
    > mode/browse_frm/thread/985b7b85a36670a8/74a3650b84d4700e?
    > hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=1&prev=/groups%3Fas_q%
    > 3DTdiBuildInternalDeviceControlIrp%2520TdiBuildRec eive%26safe%3Dimages%
    > 26ie%3DUTF-8%26oe%3DUTF-8%26lr%3D%26hl%3Den#74a3650b84d4700e
    >
    > http://groups.google.com/group/comp....mer.nt.kernel-
    > mode/browse_frm/thread/30594f827bc214e3/350cabc8948e31e6?
    > hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&rnum=6&prev=/groups%3Fas_q%
    > 3DSTATUS_MORE_PROCESSING_REQUIRED%2520IoFreeIrp%26 safe%3Doff%26ie%3DUTF-
    > 8%26oe%3DUTF-8%26lr%3D%26hl%3Den#350cabc8948e31e6
    >
    > http://groups.google.com/group/comp....mer.nt.kernel-
    > mode/browse_frm/thread/4fa4500a2b666233/d6d5a54bf05496ac?
    > hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=7&prev=/groups%3Fas_q%3DBytesTaken%
    > 2520BytesAvailable%26safe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26lr%3D%
    > 26hl%3Den#d6d5a54bf05496ac



  10. Re: Traffic Monitor Using TDI or NDIS


    I was going through the TDI firewall code and found that it not only
    uses TDI filter driver approach (i did not look too much into it) but
    also TDI Hooking mechanism. If i use this approach then this can
    actually make things a lot easier for me when compared with TDI filter
    driver implementation. The basic idea behind this is to get a pointer
    to the device object and replace all major functions with our own
    dispatch functions. What do you think about this idea? I have
    developed a driver with just hooking installed (very basic with no
    logging yet) and it seems to work ok with various protocols.

    The basic idea has been described in this article:

    http://www.lookcode.net/Article/172749.aspx

    Let me know what you think.

    sarshah.


    On Mar 3, 6:48*pm, sarsha...@yahoo.com wrote:
    > Oh sorry I meant tutorial/articles for writingTDIfilter driver
    >
    > thanks,
    >
    > sarshah.
    >
    > On Mar 2, 5:42*am, Toby Douglass >
    >
    >
    > 45mercystreet.com> wrote:
    > > sarsha...@yahoo.com wrote:
    > > > I was planning to base my code by taking ideas from the open source
    > > >TDIfirewall. I will be careful since u said it was badly written but
    > > > all i will be looking at is how a basicTDIfilter driver is written
    > > > including how it maintains a shadow of the current TCP/IP state.

    >
    > > Yees-s-s-s...I'm not sure that particular code keeps track very much. *
    > > OTOH I didn't look much into it - it was hard to figure out what it
    > > thought it was doing. *I'm not sure you'll find it useful; I didn't, and
    > > I *already* knew what it had to be doing.

    >
    > > > In addition to *TDIand network stack pages in the kernel docs, could
    > > > you please refer some more readings that are particularly about how to
    > > > write aTDIclient.......something like a tutorial.

    >
    > > But you're not writing aTDIclient, you're writing aTDIfilter driver. *
    > > Very different animal. *There are no tutorials for either, although
    > > there is a post in Usenet, let me see if I can find it, which gives the
    > > basic code for aTDIclient.

    >
    > > Hmm, here's a set of Usenet threads which you might find interesting
    > > (the second one is the source code to a simpleTDIclient);

    >
    > >http://groups.google.com/group/comp....mer.nt.kernel-
    > > mode/browse_frm/thread/b32a9bac149cafa/a25598fa87173a2f?
    > > hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%
    > > 3DUTF-8%26oe%3DUTF-8%26q%3DTDI_EVENT_RECEIVE%2Blevel%26btnG%3DGoogle%
    > > 2BSearch#a25598fa87173a2f

    >
    > >http://groups.google.com/group/comp....mer.nt.kernel-
    > > mode/browse_frm/thread/985b7b85a36670a8/74a3650b84d4700e?
    > > hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=1&prev=/groups%3Fas_q%
    > > 3DTdiBuildInternalDeviceControlIrp%2520TdiBuildRec eive%26safe%3Dimages%
    > > 26ie%3DUTF-8%26oe%3DUTF-8%26lr%3D%26hl%3Den#74a3650b84d4700e

    >
    > >http://groups.google.com/group/comp....mer.nt.kernel-
    > > mode/browse_frm/thread/30594f827bc214e3/350cabc8948e31e6?
    > > hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&rnum=6&prev=/groups%3Fas_q%
    > > 3DSTATUS_MORE_PROCESSING_REQUIRED%2520IoFreeIrp%26 safe%3Doff%26ie%3DUTF-
    > > 8%26oe%3DUTF-8%26lr%3D%26hl%3Den#350cabc8948e31e6

    >
    > >http://groups.google.com/group/comp....mer.nt.kernel-
    > > mode/browse_frm/thread/4fa4500a2b666233/d6d5a54bf05496ac?
    > > hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=7&prev=/groups%3Fas_q%3DBytesTaken%
    > > 2520BytesAvailable%26safe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26lr%3D%
    > > 26hl%3Den#d6d5a54bf05496ac- Hide quoted text -

    >
    > - Show quoted text -



  11. Re: Traffic Monitor Using TDI or NDIS

    Bad idea.

    1) 2 hookers will cause an interop with a crash with a good probability
    2) hooker cannot unload, since you cannot unhook reliably

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    maxim@storagecraft.com
    http://www.storagecraft.com

    wrote in message
    news:dfe9b15d-ff3e-430d-aa86-a18d612e9a1f@d21g2000prf.googlegroups.com...

    I was going through the TDI firewall code and found that it not only
    uses TDI filter driver approach (i did not look too much into it) but
    also TDI Hooking mechanism. If i use this approach then this can
    actually make things a lot easier for me when compared with TDI filter
    driver implementation. The basic idea behind this is to get a pointer
    to the device object and replace all major functions with our own
    dispatch functions. What do you think about this idea? I have
    developed a driver with just hooking installed (very basic with no
    logging yet) and it seems to work ok with various protocols.

    The basic idea has been described in this article:

    http://www.lookcode.net/Article/172749.aspx

    Let me know what you think.

    sarshah.


    On Mar 3, 6:48 pm, sarsha...@yahoo.com wrote:
    > Oh sorry I meant tutorial/articles for writingTDIfilter driver
    >
    > thanks,
    >
    > sarshah.
    >
    > On Mar 2, 5:42 am, Toby Douglass >
    >
    >
    > 45mercystreet.com> wrote:
    > > sarsha...@yahoo.com wrote:
    > > > I was planning to base my code by taking ideas from the open source
    > > >TDIfirewall. I will be careful since u said it was badly written but
    > > > all i will be looking at is how a basicTDIfilter driver is written
    > > > including how it maintains a shadow of the current TCP/IP state.

    >
    > > Yees-s-s-s...I'm not sure that particular code keeps track very much.
    > > OTOH I didn't look much into it - it was hard to figure out what it
    > > thought it was doing. I'm not sure you'll find it useful; I didn't, and
    > > I *already* knew what it had to be doing.

    >
    > > > In addition to TDIand network stack pages in the kernel docs, could
    > > > you please refer some more readings that are particularly about how to
    > > > write aTDIclient.......something like a tutorial.

    >
    > > But you're not writing aTDIclient, you're writing aTDIfilter driver.
    > > Very different animal. There are no tutorials for either, although
    > > there is a post in Usenet, let me see if I can find it, which gives the
    > > basic code for aTDIclient.

    >
    > > Hmm, here's a set of Usenet threads which you might find interesting
    > > (the second one is the source code to a simpleTDIclient);

    >
    > >http://groups.google.com/group/comp....mer.nt.kernel-
    > > mode/browse_frm/thread/b32a9bac149cafa/a25598fa87173a2f?
    > > hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%
    > > 3DUTF-8%26oe%3DUTF-8%26q%3DTDI_EVENT_RECEIVE%2Blevel%26btnG%3DGoogle%
    > > 2BSearch#a25598fa87173a2f

    >
    > >http://groups.google.com/group/comp....mer.nt.kernel-
    > > mode/browse_frm/thread/985b7b85a36670a8/74a3650b84d4700e?
    > > hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=1&prev=/groups%3Fas_q%
    > > 3DTdiBuildInternalDeviceControlIrp%2520TdiBuildRec eive%26safe%3Dimages%
    > > 26ie%3DUTF-8%26oe%3DUTF-8%26lr%3D%26hl%3Den#74a3650b84d4700e

    >
    > >http://groups.google.com/group/comp....mer.nt.kernel-
    > > mode/browse_frm/thread/30594f827bc214e3/350cabc8948e31e6?
    > > hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&rnum=6&prev=/groups%3Fas_q%
    > > 3DSTATUS_MORE_PROCESSING_REQUIRED%2520IoFreeIrp%26 safe%3Doff%26ie%3DUTF-
    > > 8%26oe%3DUTF-8%26lr%3D%26hl%3Den#350cabc8948e31e6

    >
    > >http://groups.google.com/group/comp....mer.nt.kernel-
    > > mode/browse_frm/thread/4fa4500a2b666233/d6d5a54bf05496ac?
    > > hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=7&prev=/groups%3Fas_q%3DBytesTaken%
    > > 2520BytesAvailable%26safe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26lr%3D%
    > > 26hl%3Den#d6d5a54bf05496ac- Hide quoted text -

    >
    > - Show quoted text -



  12. Re: Traffic Monitor Using TDI or NDIS

    sarshah20@yahoo.com wrote:
    > I was going through the TDI firewall code and found that it not only
    > uses TDI filter driver approach (i did not look too much into it) but
    > also TDI Hooking mechanism. If i use this approach then this can
    > actually make things a lot easier for me when compared with TDI filter
    > driver implementation. The basic idea behind this is to get a pointer
    > to the device object and replace all major functions with our own
    > dispatch functions. What do you think about this idea?


    Terrifying! it breaks the driver model rather than attaching in the way
    the driver model provides, it won't work with another device driver
    using the same method, it makes it very easy for you to make a mistake
    and shag the rest of the driver chain.

    It's also completely needless, because you don't get anything for it;
    you can do everything attaching normally using IoAttachDevice().
    Hooking won't get you anything extra, and IoAttachDevice() is not
    difficult - in fact, it's as simple as you can get in kernel code.

  13. Re: Traffic Monitor Using TDI or NDIS

    I was really excited to read the article and when i actually took the
    code out of the firewall and it was working fine (except for the point
    where it unloads the driver) i thought may this is it. Seeing so many
    positives, i thought thats the path i need to take. But after valuable
    feedback from you guys i guess i will have to drop this idea as well.
    I am really gratefull for all your help and time.

    sarshah.

    On Mar 5, 12:14*am, Toby Douglass 45mercystreet.com> wrote:
    > sarsha...@yahoo.com wrote:
    > > I was going through theTDIfirewall code and found that it not only
    > > usesTDIfilter driver approach (i did not look too much into it) but
    > > alsoTDIHooking mechanism. If i use this approach then this can
    > > actually make things a lot easier for me when compared withTDIfilter
    > > driver implementation. The basic idea behind this is to get a pointer
    > > to the device object and replace all major functions with our own
    > > dispatch functions. What do you think about this idea?

    >
    > Terrifying! *it breaks the driver model rather than attaching in the way
    > the driver model provides, it won't work with another device driver
    > using the same method, it makes it very easy for you to make a mistake
    > and shag the rest of the driver chain.
    >
    > It's also completely needless, because you don't get anything for it;
    > you can do everything attaching normally using IoAttachDevice(). *
    > Hooking won't get you anything extra, and IoAttachDevice() is not
    > difficult - in fact, it's as simple as you can get in kernel code.



+ Reply to Thread