Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

A driver that listens to traffic

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Basically I want a driver that hook the networking functions in the kernel so I can monitor which processes called connect,send, bind etc. At first,I was expecting the winsock functions in windows would be calling a system call in the SSDT table but it seems the table has no functions that would do networking? So how to make a driver that listens to these function calls ?

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,103
    xxxxx@gmail.com wrote:
    > Basically I want a driver that hook the networking functions in the kernel so I can monitor which processes called connect,send, bind etc. At first,I was expecting the winsock functions in windows would be calling a system call in the SSDT table but it seems the table has no functions that would do networking?

    Of course not. Networking is not a fundamental kernel concept. A
    network is just another driver providing I/O services. You talk to it
    through ReadFile, WriteFile, and DeviceIoControl, just like every other
    I/O service.


    > So how to make a driver that listens to these function calls ?

    Certainly not by SSDT hooking. You should probably look at the Windows
    Filtering Platform, which was designed to allow that kind of operation
    without hackery.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Don_BurnDon_Burn Member - All Emails Posts: 1,653
    You need the Windows Filtering Platform, I just did a driver like this for a
    client. No, you never want to use SSDT hooking.


    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com



    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
    Sent: Friday, July 29, 2016 5:23 PM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: [ntdev] A driver that listens to traffic

    Basically I want a driver that hook the networking functions in the kernel
    so I can monitor which processes called connect,send, bind etc. At first,I
    was expecting the winsock functions in windows would be calling a system
    call in the SSDT table but it seems the table has no functions that would do
    networking? So how to make a driver that listens to these function calls ?

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:
    <http://www.osronline.com/showlists.cfm?list=ntdev>;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
    drivers!
    Details at <http://www.osr.com/seminars>;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer>;
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    Forget SSDT hooking. Forever. With the Device Guard in Srv2016, it is now totally impossible in a production environment. And yes, Win10 can also be deployed using the same policies which are default in Srv2016.

    What you need is a Windows Filtering Platform plugin to tcpip.sys, which is well-documented.

    You do not need to track the socket APIs exactly. You only need to know what socket belongs to what process and what data is going via it. WFP allows this.

    --
    Maxim S. Shatskih
    Microsoft MVP on File System And Storage
    xxxxx@storagecraft.com
    http://www.storagecraft.com

    <xxxxx@gmail.com> wrote in message news:xxxxx@ntdev...
    > Basically I want a driver that hook the networking functions in the kernel so I can monitor which processes called connect,send, bind etc. At first,I was expecting the winsock functions in windows would be calling a system call in the SSDT table but it seems the table has no functions that would do networking? So how to make a driver that listens to these function calls ?
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    @Don Burn

    Can I retrieve the process of every packet ? Are there any packets that we cannot associate to a process ?
  • Don_BurnDon_Burn Member - All Emails Posts: 1,653
    I was able to get the PID and Port for all the calls my client was concerned
    about namely BIND, UNBIND and CONNECT. BIND will also provide the path to
    the executable.

    Be aware that the recommend sample is the "Windows Filtering Platform
    Sample" which is huge. In my case I was able to bring it down to a little
    over 1100 lines of code to monitor and log those calls including comments.

    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com



    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
    Sent: Saturday, July 30, 2016 3:06 PM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: RE:[ntdev] A driver that listens to traffic

    @Don Burn

    Can I retrieve the process of every packet ? Are there any packets that we
    cannot associate to a process ?





    ---
    NTDEV is sponsored by OSR

    Visit the list online at:
    <http://www.osronline.com/showlists.cfm?list=ntdev>;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
    drivers!
    Details at <http://www.osr.com/seminars>;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer>;
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    @ Don

    Can a process make the OS sends a packet on its behalf? Or can a malware do that to hide it's identity?

    Thanks.
  • Don_BurnDon_Burn Member - All Emails Posts: 1,653
    For any normal situation the filter will catch all the packets, including
    ones from the OS. If you can insert code into the OS there is never a
    guarantee that someone can't figure out a way to bypass any protection
    mechanism you have. This is why if you look back in the archives most of us
    emphasize that if the kernel is infected there is no way to fix things.


    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com



    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
    Sent: Sunday, July 31, 2016 7:16 AM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: RE:[ntdev] A driver that listens to traffic

    @ Don

    Can a process make the OS sends a packet on its behalf? Or can a malware do
    that to hide it's identity?

    Thanks.

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:
    <http://www.osronline.com/showlists.cfm?list=ntdev>;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
    drivers!
    Details at <http://www.osr.com/seminars>;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer>;
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I compiled the driver and used net start inspect to start the service. The code seems to complex for me but I found some functions in inspect.c

    TLInspectALERecvAcceptClassify

    TLInspectALERecvAcceptNotify

    I put a dbgPrint statement in them but they don's seem to be the functions that are called when recv is called because they are only called once or twice! Also there is something called "ale" which I don't seem to understand!
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I was able to capture all the packets. but still have no idea how to get
    the process associated with each packer?

    On Sun, Jul 31, 2016 at 4:38 PM, Don Burn wrote:

    > For any normal situation the filter will catch all the packets, including
    > ones from the OS. If you can insert code into the OS there is never a
    > guarantee that someone can't figure out a way to bypass any protection
    > mechanism you have. This is why if you look back in the archives most of
    > us
    > emphasize that if the kernel is infected there is no way to fix things.
    >
    >
    > Don Burn
    > Windows Driver Consulting
    > Website: http://www.windrvr.com
    >
    >
    >
    > -----Original Message-----
    > From: xxxxx@lists.osr.com
    > [mailto:xxxxx@lists.osr.com] On Behalf Of
    > xxxxx@gmail.com
    > Sent: Sunday, July 31, 2016 7:16 AM
    > To: Windows System Software Devs Interest List
    > Subject: RE:[ntdev] A driver that listens to traffic
    >
    > @ Don
    >
    > Can a process make the OS sends a packet on its behalf? Or can a malware do
    > that to hide it's identity?
    >
    > Thanks.
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at:
    >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software
    > drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    >
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Don_BurnDon_Burn Member - All Emails Posts: 1,653
    Take a look at https://msdn.microsoft.com/en-us/library/windows/hardware/ff559179(v=vs.85).aspx If you test for TRUE
    "FWPS_IS_METADATA_FIELD_PRESENT( MetaValues, FWPS_METADATA_FIELD_PROCESS_ID )" you can then retrieve the
    PID from MetaValues->processId;

    This is in the WFP sample, but as I warned you at the beginning it is a huge sample. You are going to have to study the MSDN
    Documentation to know what you can get where to get data, start you doc search at https://msdn.microsoft.com/en-us/library/windows/hardware/ff546100(v=vs.85).aspx


    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com




    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zaid ALYAFEY
    Sent: Friday, August 05, 2016 3:02 PM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: Re: [ntdev] A driver that listens to traffic

    I was able to capture all the packets. but still have no idea how to get the process associated with each packer?

    On Sun, Jul 31, 2016 at 4:38 PM, Don Burn <xxxxx@windrvr.com wrote:


    For any normal situation the filter will catch all the packets, including
    ones from the OS. If you can insert code into the OS there is never a
    guarantee that someone can't figure out a way to bypass any protection
    mechanism you have. This is why if you look back in the archives most of us
    emphasize that if the kernel is infected there is no way to fix things.


    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com



    -----Original Message-----
    From: xxxxx@lists.osr.com <mailto:xxxxx@lists.osr.com>
    [mailto:xxxxx@lists.osr.com <mailto:xxxxx@lists.osr.com> ] On Behalf Of xxxxx@gmail.com <mailto:xxxxx@gmail.com>
    Sent: Sunday, July 31, 2016 7:16 AM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com
    Subject: RE:[ntdev] A driver that listens to traffic


    @ Don

    Can a process make the OS sends a packet on its behalf? Or can a malware do
    that to hide it's identity?

    Thanks.

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:
    <http://www.osronline.com/showlists.cfm?list=ntdev

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
    drivers!
    Details at <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

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <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 Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    One more question,

    What I understood that we can get the process id at the layers for connect,
    accept and bind (handshake layers). But what about the packets generated by
    (send, recv) function calls ? Also from msdn I have the following "only the
    first TCP *send()*

    and
    the first TCP *recv()*

    over
    raw sockets will be filtered. " what does that mean ?

    On Fri, Aug 5, 2016 at 10:20 PM, Don Burn wrote:

    > Take a look at https://msdn.microsoft.com/en-us/library/windows/hardware/
    > ff559179(v=vs.85).aspx If you test for TRUE
    > "FWPS_IS_METADATA_FIELD_PRESENT( MetaValues,
    > FWPS_METADATA_FIELD_PROCESS_ID )" you can then retrieve the
    > PID from MetaValues->processId;
    >
    > This is in the WFP sample, but as I warned you at the beginning it is a
    > huge sample. You are going to have to study the MSDN
    > Documentation to know what you can get where to get data, start you doc
    > search at https://msdn.microsoft.com/en-us/library/windows/hardware/
    > ff546100(v=vs.85).aspx
    >
    >
    > Don Burn
    > Windows Driver Consulting
    > Website: http://www.windrvr.com
    >
    >
    >
    >
    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-613882-122747@
    > lists.osr.com] On Behalf Of zaid ALYAFEY
    > Sent: Friday, August 05, 2016 3:02 PM
    > To: Windows System Software Devs Interest List
    > Subject: Re: [ntdev] A driver that listens to traffic
    >
    > I was able to capture all the packets. but still have no idea how to get
    > the process associated with each packer?
    >
    > On Sun, Jul 31, 2016 at 4:38 PM, Don Burn xxxxx@windrvr.com> > wrote:
    >
    >
    > For any normal situation the filter will catch all the packets,
    > including
    > ones from the OS. If you can insert code into the OS there is
    > never a
    > guarantee that someone can't figure out a way to bypass any
    > protection
    > mechanism you have. This is why if you look back in the archives
    > most of us
    > emphasize that if the kernel is infected there is no way to fix
    > things.
    >
    >
    > Don Burn
    > Windows Driver Consulting
    > Website: http://www.windrvr.com
    >
    >
    >
    > -----Original Message-----
    > From: xxxxx@lists.osr.com xxxxx@lists.osr.com>
    > [mailto:xxxxx@lists.osr.com xxxxx@lists.osr.com> ] On Behalf Of xxxxx@gmail.com
    >
    > Sent: Sunday, July 31, 2016 7:16 AM
    > To: Windows System Software Devs Interest List <
    > xxxxx@lists.osr.com >
    > Subject: RE:[ntdev] A driver that listens to traffic
    >
    >
    > @ Don
    >
    > Can a process make the OS sends a packet on its behalf? Or can a
    > malware do
    > that to hide it's identity?
    >
    > Thanks.
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at:
    > http://www.osronline.com/showlists.cfm?list=ntdev>; >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals
    > and software
    > drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer>; >
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev showlists.cfm?list=ntdev> >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals
    > and software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer <
    > http://www.osronline.com/page.cfm?name=ListServer>; >
    >
    >
    >
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    > on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at To unsubscribe, visit the List Server section of OSR Online at
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Jason_StephensonJason_Stephenson Member Posts: 53
    > only the first TCP *send()* <https://msdn.microsoft.com/en-us/library/windows/desktop/ms740149(v=vs.85).aspx> and the first TCP *recv()* <https://msdn.microsoft.com/en-us/library/windows/desktop/ms740121(v=vs.85).aspx> over raw sockets will be filtered. " what does that mean ?

    This is only relavent at the ALE layers: https://msdn.microsoft.com/en-us/library/windows/desktop/bb613460(v=vs.85).aspx

    If you want to associate every packet with a process you'll need to look at the Transport / IP layers. It looks like the processid is not immediately available at these layers. (https://msdn.microsoft.com/en-us/library/windows/hardware/ff559179(v=vs.85).aspx)

    Looks like you'll need to maintain your own state tables for this or store it the processid in the flow context and retrieve it at these layers.

    J
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Since I know the process id of each packet in ale connect , can't I
    associate every send or receive packet with the corresponding connection?
    On 15 Aug 2016 17:37, wrote:

    > > only the first TCP *send()* en-us/library/windows/desktop/ms740149(v=vs.85).aspx> and the first TCP
    > *recv()* ms740121(v=vs.85).aspx> over raw sockets will be filtered. " what does
    > that mean ?
    >
    > This is only relavent at the ALE layers: https://msdn.microsoft.com/en-
    > us/library/windows/desktop/bb613460(v=vs.85).aspx
    >
    > If you want to associate every packet with a process you'll need to look
    > at the Transport / IP layers. It looks like the processid is not
    > immediately available at these layers. (https://msdn.microsoft.com/
    > en-us/library/windows/hardware/ff559179(v=vs.85).aspx)
    >
    > Looks like you'll need to maintain your own state tables for this or store
    > it the processid in the flow context and retrieve it at these layers.
    >
    > J
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Chris_AseltineChris_Aseltine Member Posts: 1,228
    Zaid alyafeai wrote:

    >> Looks like you'll need to maintain your own state tables for
    >> this or store it the processid in the flow context and retrieve
    >> it at these layers.
    >
    > Since I know the process id of each packet in ale connect , can't I
    > associate every send or receive packet with the corresponding
    > connection?

    Uh, isn't that what you were *just* told?
  • ashish_kohliashish_kohli Member - All Emails Posts: 60
    Hi


    As far as I know,ale connect and ale recv accept flow context cannot be got in transport layers.

    We need to maintain our own context for example search key will be 5 tuple.


    ________________________________
    From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
    Sent: Thursday, August 18, 2016 8:50 AM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] A driver that listens to traffic

    Zaid alyafeai wrote:

    >> Looks like you'll need to maintain your own state tables for
    >> this or store it the processid in the flow context and retrieve
    >> it at these layers.
    >
    > Since I know the process id of each packet in ale connect , can't I
    > associate every send or receive packet with the corresponding
    > connection?

    Uh, isn't that what you were *just* told?

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:
    OSR Online NTDEV List
    www.osronline.com
    OSR Online is the homepage for Windows driver writers. The NTDEV, NTFSD, and NTTALK lists are world-wide peer support forums administered by OSR.




    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
  • ashish_kohliashish_kohli Member - All Emails Posts: 60
    As far as I know,ale connect and ale recv accept flow context cannot be got in
    transport layers.

    We need to maintain our own context for example search key will be 5 tuple.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    How do I know that two packets in the transport layer belong to the same
    tcp connection ?
    On 18 Aug 2016 13:01, wrote:

    > As far as I know,ale connect and ale recv accept flow context cannot be
    > got in
    > transport layers.
    >
    > We need to maintain our own context for example search key will be 5
    > tuple.
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Don_BurnDon_Burn Member - All Emails Posts: 1,653
    At least for most cases check out FWPS_METADATA_FIELD_TRANSPORT_ENDPOINT_HANDLE


    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com




    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zaid ALYAFEY
    Sent: Friday, August 19, 2016 5:22 PM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: RE:[ntdev] A driver that listens to traffic

    How do I know that two packets in the transport layer belong to the same tcp connection ?

    On 18 Aug 2016 13:01, <xxxxx@hotmail.com wrote:


    As far as I know,ale connect and ale recv accept flow context cannot be got in
    transport layers.

    We need to maintain our own context for example search key will be 5 tuple.

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <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 Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
  • ashish_kohliashish_kohli Member - All Emails Posts: 60
    A network 5 tuple uniquely identifies a TCP connection.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Could you please explain more? What are the members of the tuple ?
    On 20 Aug 2016 21:11, wrote:

    > A network 5 tuple uniquely identifies a TCP connection.
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • ashish_kohliashish_kohli Member - All Emails Posts: 60
    local address,remote address,local port,remote port and protocol
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    @Don

    What do you mean by most cases ?

    So transportEndpointHandle will have a unique value in both ale and
    transport callouts for the same tcp connecting ? Also I noticed that the
    value of transportEndpointHandle is sometimes equal to zero what does that
    mean ?


    On Sat, Aug 20, 2016 at 12:36 AM, Don Burn wrote:

    > At least for most cases check out FWPS_METADATA_FIELD_TRANSPORT_
    > ENDPOINT_HANDLE
    >
    >
    > Don Burn
    > Windows Driver Consulting
    > Website: http://www.windrvr.com
    >
    >
    >
    >
    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-614816-122747@
    > lists.osr.com] On Behalf Of zaid ALYAFEY
    > Sent: Friday, August 19, 2016 5:22 PM
    > To: Windows System Software Devs Interest List
    > Subject: RE:[ntdev] A driver that listens to traffic
    >
    > How do I know that two packets in the transport layer belong to the same
    > tcp connection ?
    >
    > On 18 Aug 2016 13:01, xxxxx@hotmail.com> > wrote:
    >
    >
    > As far as I know,ale connect and ale recv accept flow context
    > cannot be got in
    > transport layers.
    >
    > We need to maintain our own context for example search key will
    > be 5 tuple.
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev showlists.cfm?list=ntdev> >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals
    > and software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer <
    > http://www.osronline.com/page.cfm?name=ListServer>; >
    >
    >
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    > on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at To unsubscribe, visit the List Server section of OSR Online at
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Don_BurnDon_Burn Member - All Emails Posts: 1,653
    The transportEndpointHandle (when it is not zero) will allow to match a unique value for the duration of the bind/connect to unbind. See https://social.msdn.microsoft.com/Forums/en-US/6280b002-f93d-4dab-b892-1e138ceabfcd/fwpsmetadatafieldtransportendpointhandle-bit-is-set-but-meta-data-field-0?forum=wfp for some instances that you get zero. I don't have a good solution for the zero value case.


    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com



    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zaid ALYAFEY
    Sent: Sunday, August 21, 2016 6:21 PM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: Re: [ntdev] A driver that listens to traffic

    @Don

    What do you mean by most cases ?

    So transportEndpointHandle will have a unique value in both ale and transport callouts for the same tcp connecting ? Also I noticed that the value of transportEndpointHandle is sometimes equal to zero what does that mean ?


    On Sat, Aug 20, 2016 at 12:36 AM, Don Burn <xxxxx@windrvr.com wrote:


    At least for most cases check out FWPS_METADATA_FIELD_TRANSPORT_ENDPOINT_HANDLE


    Don Burn
    Windows Driver Consulting
    Website: http://www.windrvr.com




    -----Original Message-----
    From: xxxxx@lists.osr.com <mailto:xxxxx@lists.osr.com> [mailto:xxxxx@lists.osr.com <mailto:xxxxx@lists.osr.com> ] On Behalf Of zaid ALYAFEY
    Sent: Friday, August 19, 2016 5:22 PM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com
    Subject: RE:[ntdev] A driver that listens to traffic

    How do I know that two packets in the transport layer belong to the same tcp connection ?

    On 18 Aug 2016 13:01, <xxxxx@hotmail.com > wrote:


    As far as I know,ale connect and ale recv accept flow context cannot be got in
    transport layers.

    We need to maintain our own context for example search key will be 5 tuple.

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev >

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <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 Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at



    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <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 Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    So this is just a bug ?

    On Mon, Aug 22, 2016 at 2:13 AM, Don Burn wrote:

    > The transportEndpointHandle (when it is not zero) will allow to match a
    > unique value for the duration of the bind/connect to unbind. See
    > https://social.msdn.microsoft.com/Forums/en-US/6280b002-
    > f93d-4dab-b892-1e138ceabfcd/fwpsmetadatafieldtransportendp
    > ointhandle-bit-is-set-but-meta-data-field-0?forum=wfp for some instances
    > that you get zero. I don't have a good solution for the zero value case.
    >
    >
    > Don Burn
    > Windows Driver Consulting
    > Website: http://www.windrvr.com
    >
    >
    >
    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-614890-122747@
    > lists.osr.com] On Behalf Of zaid ALYAFEY
    > Sent: Sunday, August 21, 2016 6:21 PM
    > To: Windows System Software Devs Interest List
    > Subject: Re: [ntdev] A driver that listens to traffic
    >
    > @Don
    >
    > What do you mean by most cases ?
    >
    > So transportEndpointHandle will have a unique value in both ale and
    > transport callouts for the same tcp connecting ? Also I noticed that the
    > value of transportEndpointHandle is sometimes equal to zero what does that
    > mean ?
    >
    >
    > On Sat, Aug 20, 2016 at 12:36 AM, Don Burn xxxxx@windrvr.com> > wrote:
    >
    >
    > At least for most cases check out FWPS_METADATA_FIELD_TRANSPORT_
    > ENDPOINT_HANDLE
    >
    >
    > Don Burn
    > Windows Driver Consulting
    > Website: http://www.windrvr.com
    >
    >
    >
    >
    > -----Original Message-----
    > From: xxxxx@lists.osr.com xxxxx@lists.osr.com> [mailto:bounce-614816-122747@
    > lists.osr.com ] On Behalf Of
    > zaid ALYAFEY
    > Sent: Friday, August 19, 2016 5:22 PM
    > To: Windows System Software Devs Interest List <
    > xxxxx@lists.osr.com >
    > Subject: RE:[ntdev] A driver that listens to traffic
    >
    > How do I know that two packets in the transport layer belong to
    > the same tcp connection ?
    >
    > On 18 Aug 2016 13:01, xxxxx@hotmail.com> xxxxx@hotmail.com> > > wrote:
    >
    >
    > As far as I know,ale connect and ale recv accept flow
    > context cannot be got in
    > transport layers.
    >
    > We need to maintain our own context for example search
    > key will be 5 tuple.
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev showlists.cfm?list=ntdev> showlists.cfm?list=ntdev showlists.cfm?list=ntdev> > >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows
    > internals and software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR
    > Online at http://www.osronline.com/page.cfm?name=ListServer>; <
    > http://www.osronline.com/page.cfm?name=ListServer <
    > http://www.osronline.com/page.cfm?name=ListServer>; > >
    >
    >
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY
    > seminars on crash dump analysis, WDF, Windows internals and software
    > drivers! Details at To unsubscribe, visit the List Server section of OSR
    > Online at
    >
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev showlists.cfm?list=ntdev> >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals
    > and software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer <
    > http://www.osronline.com/page.cfm?name=ListServer>; >
    >
    >
    >
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    > on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at To unsubscribe, visit the List Server section of OSR Online at
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE