locked
Filter sample to redirect packet RRS feed

  • Question

  • Hello everyone,

    I'm new to developping drivers and I wanted to modify the Sample NDIS filter driver so that it redirects incomming packet to a different IP.

    Now I don't really understand where the IP is located in the NET_BUFFER, but in another thread I found this:

     

    At INBOUND_IPPACKET --

    1. Retreat oiginal NBL/NB by size of inMetaValues->ipHeaderSize
    2. make a clone
    3. Advance the clone by size of inMetaValues->ipHeaderSize
    4. call NdisGetDataBuffer, and this should now point to the TCP header
    5. modify the port; adjust the TCP checksum.
    6. Retreat the clone by the same amount as 3.
    7. Advance the original by the same amount as 1.
    8. FwpsInjectNetworkReceiveAsync0
    9. block and aborb the original NBL.

    At INBOUND_TRANSPORT_/DISCARD --

    1. Retreat oiginal NBL/NB by size of inMetaValues->ipHeaderSize + inMetaValues->transportHeaderSize
    2. make a clone
    3. Advance the clone by size of inMetaValues->ipHeaderSize
    4. call NdisGetDataBuffer, and this should now point to the TCP header
    5. modify the port; adjust the TCP checksum.
    6. Retreat the clone by the same amount as 3.
    7. Advance the original by the same amount as 1.
    8. FwpsInjectTransportReceiveAsync0
    9. block the original NBL.

    I know that I don't need to recalculate the TCP checksum if I simply change the destination IP (Only the IP checksum I believe), but that's of later concern :P

    In every related example I see people cloning the Netbuffer first, and later inject it again. Would I have to do this for my situation as well or can I directly change the data in the netbuffer?

     

    Thanks, lordstyx.

     

    [edit]

    I didn't realize that this forum is not about WDK.. I'm talking about a NDIS sample filter that came with the WDK..

    Friday, August 6, 2010 8:34 PM

All replies

  • I'd recommend using WFP, and perform your redirection at the FWPM_LAYER_INBOUND_IPPACKET layers.  The concept is the same, except WFP makes guarantees (in most cases) where in the NBL you are at.  i.e. at INBOUND_IPPACKET, you are are the start of the Transport Header.  This means you need to retreat the size of the IPHeader.  For WFP, at the current layers, you need to clone the NBL, modify the clone, and inject it.

    WFP offers a rich arbitration model which allows multiple network security vendors to coincide with one another.  WFP supplies an API for re-calculating the checksums as well.

    http://msdn.microsoft.com/en-us/library/aa366510(v=VS.85).aspx

    Packet Modification Sample:
         http://msdn.microsoft.com/en-us/library/ff571070(VS.85).aspx

    Hope this helps, 


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Tuesday, August 10, 2010 6:30 PM
    Moderator
  • Very interesting.

    I saw that the ddproxy driver works with the UDP protocol. Would it be much of a hassle to change it into TCP?

    Sunday, August 15, 2010 4:35 PM
  • not much of a hassle.  all of the principles are the same.  TCP requires all modifications at done at transport to be done out of band (i.e. using a worlker thread).

    Also note that starting with Win7, it is recommended to use the REDIRECT layers (FWPM_LAYER_ALE_BIND_REDIRECT_V{4|6} & FWPM_LAYER_ALE_CONNECT_REDIRECT_V{4|6})  these layers will simplify things significanly, however as stated they are only available to Win7+ 

    Hope this helps


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Sunday, August 15, 2010 8:38 PM
    Moderator
  • Hmm too bad that I need this to work on XP as well.

    Can you tell me a bit more about what exactly has to be changed in order to let this work for TCP packets?

     

    I mean, is the NET_BUFFER construction the same for UDP and TCP packets? If not, what's the difference exactly?

    Also I don't really understand how I get to IP Header. I don't have to change the ports, so I can leave the TCP Header alone.

    Would this do?

     

    typedef struct _IP_HEADER {
     UCHAR VersionAndLength;
     UCHAR TOS;
     USHORT Length;
     USHORT ID;
     USHORT Flags;
     UCHAR TTL;
     UCHAR Protocol;
     USHORT Checksum;
     ULONG Source;
     ULONG Destination; 
    } IP_HEADER; 

     

     

    ...

     

     

    IP_HEADER* ipHeader;
    ipHeader = NdisGetDataBuffer( netBuffer, sizeof(IP_HEADER), NULL, 1, 0 );

     

    Monday, August 16, 2010 11:58 AM
  • I already called this out.  TCP requires Out of Band Injection. 

    What layer you are classifying will determine where you are in the NBL.  i.e. at INBOUND_TRANSPORT, you are at the beginning of the data, but at OUTBOUND_TRANSPORT, you are at the begining of the Transport Header.

    http://msdn.microsoft.com/en-us/library/ff546324(v=VS.85).aspx

    Use NdisRetreatNetBufferListDataStart and NdisAdvanceNetBufferListDataStart to traverse the packet offsets.  Be sure to put the offset back to the original position when finished.

    Also if you are expecting XP, then WFP will not help you there.  WFP is Vista+.

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Monday, August 16, 2010 7:46 PM
    Moderator
  • Ah okay.

    I will focus on XP later.

    Using this method, would a packet sniffer like winpcap see the source/destination as changed? I need the source destination on INBOUND packets to be changed before it reaches the OS, and change the destination on OUTBOUND packets after it's 'left' the OS

    Monday, August 16, 2010 8:02 PM
  • It depends on your definition of OS.  WFP is part of the TCP/IP stack.  It would see the original, and the modified.  However if you follow the injection model, only the modified version will be received by the endpoint (internal or external).  The change would not be seen by NetMon, because it is implemented using LWFs, which are an NDIS concept (so depending on the sniffer and how it is implemented, your change would likely not be seen via sniffer (for inbound)).

     

    Hope this helps


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Tuesday, August 17, 2010 2:52 AM
    Moderator
  • Oh that's not really good.

    I want this driver to do what a NAT system would do.

    For outbound, are the changes done after the packet leaves a raw socket, and inbound before it reaches a raw socket?

    Tuesday, August 17, 2010 8:49 AM
  • Of course.  That's the same for non-raw sockets.  The socket is the endpoint.  The stack is the path taken to reach that endpoint.  For a NAT, you are able to see the packet in it's unchanged and changed state because it is forwarded out an interface.  This requires you to be sniffing on both interfaces.  Essentially what happens is a packet comes into the NIC, travels through NDIS which passes it off to the TCP/IP stack.  The NAT service does a lookup and modifies the packet (for WFP this could be done at INBOUND_IPPACKET or INBOUND_TRANSPORT) and send the modified packet out an interface (usually a different interface.

    Sniffing the Original interface of Arrival would show the unModifiedpacket, and sniffing of the outgoing interface would show the modified packet.

    ENDPOINT
    WinSock
    TCP /IP Stack <-- WFP is entwined with the stack essentially as a bunch of inpection points
    NDIS <-- Light Weight Filters (Netmon sits here)
    NIC

    Hope this helps clear things up a bit.


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Tuesday, August 17, 2010 11:51 AM
    Moderator