Inject data into an already existing TCP connection

NTDEV
1

Hi All,
I’ve successfully built a TDI filter driver (from a tdi_flt.zip code example I got while searching in this forum). My question is how do I inject data into the tcp connection which is already existing. The scenario would be like this

  1. The TDI filter detect a certain word in the sent data (TCP on port 80).
  2. The TDI filter will not send the data (I already managed to do that) to the below driver (tcp)
  3. The TDI filter will return to the driver above the TDI a small http data with the reason why the data was not sent to the sending connection. The sending process will not know that the data it sent did not make it thru but would receive an answer from the socket (the small http phrase) AS IF it came from the destination address. The TCP/IP stack would have to remain legal as well.
    In short, the browser will send a certain http request with a certain word but the TDI filter will return a formatted http reply as to why the requesto could not be sent. The destination would however NOT receive the request at all.
    Looking at the networking model under windows it looks like I have to create and IRP and send it to afd.sys directly but I don’t think its that easy
    Any lead would be greatly appreciated.
    Thanks
    Lior
2

> Looking at the networking model under windows it looks like I have to create and

IRP and send it to afd.sys directly

The above logic is faulty - it is AFD.SYS who is TCPIP’s client, and not the other way around. Therefore, TCPIP does not send IRPs to AFD.SYS, and, hence, your driver should not do it either - AFD.SYS is not expecting these IRPs, so that it has no idea what to do with them. Instead, you should either present your data in the subsequent receive request as TCPIP’s output and complete this request without passing it down to TCPIP, or invoke a callback that AFD.SYS registers for receive event on a given connection - after all, the client socket will be able to get your message only when it calls recv().

Another option is introducing NDIS IM filter into the model - all modifications will get done at NDIS level, and TDI filter will be just relating packets to their source/destination process. This is how all more-or-less serious packet filters work. However, please note that writing modifying NDIS IM filter properly involves quite a lot of work, so I don’t know if this option is suitable for your project…

Anton Bassov

3

On Sat, Jul 07, 2007 at 04:36:29AM -0400, xxxxx@gmail.com wrote:

I’ve successfully built a TDI filter driver (from a tdi_flt.zip code
example I got while searching in this forum). My question is how do
I inject data into the tcp connection which is already existing. The
scenario would be like this

  1. The TDI filter detect a certain word in the sent data (TCP on port 80).
  2. The TDI filter will not send the data (I already managed to do that) to
    the below driver (tcp)
  3. The TDI filter will return to the driver above the TDI a small
    http data with the reason why the data was not sent to the sending
    connection. The sending process will not know that the data it sent did
    not make it thru but would receive an answer from the socket (the small
    http phrase) AS IF it came from the destination address. The TCP/IP
    stack would have to remain legal as well.
    In short, the browser will send a certain http request with a certain
    word but the TDI filter will return a formatted http reply as to why the
    requesto could not be sent. The destination would however NOT receive
    the request at all.

Why on earth would you reach for the DDK first? The traditional, the
easiest, and by far the best supported method for doing this would be to
change your web server to serve on a private port (like port 81), create
a simple proxy web server to sit on port 80 and read external requests,
perform your filtering, and forward the requests to the real server on
port 81.

Looking at the networking model under windows it looks like I have to
create and IRP and send it to afd.sys directly but I don’t think its that
easy.

On the contrary, you have made this problem far harder than it needs to be.

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

4

Please note that just “dropping” TCP packets is not possible.
That is, TCP has sequence numbers and it will try to send that data
again. So if you want to go in this way, you can either pass a modified
packet, or change the sequence number of all other packets (not that
easy).

As a result this approach looks very hard as well.

Thanks
Tzachi

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, July 07, 2007 12:37 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Inject data into an already existing TCP
connection

> Looking at the networking model under windows it looks like
I have to
> create and IRP and send it to afd.sys directly

The above logic is faulty - it is AFD.SYS who is TCPIP’s
client, and not the other way around. Therefore, TCPIP does
not send IRPs to AFD.SYS, and, hence, your driver should not
do it either - AFD.SYS is not expecting these IRPs, so that
it has no idea what to do with them. Instead, you should
either present your data in the subsequent receive request as
TCPIP’s output and complete this request without passing it
down to TCPIP, or invoke a callback that AFD.SYS registers
for receive event on a given connection - after all, the
client socket will be able to get your message only when it
calls recv().

Another option is introducing NDIS IM filter into the model

  • all modifications will get done at NDIS level, and TDI
    filter will be just relating packets to their
    source/destination process. This is how all more-or-less
    serious packet filters work. However, please note that
    writing modifying NDIS IM filter properly involves quite a
    lot of work, so I don’t know if this option is suitable for
    your project…

Anton Bassov

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

5

> Please note that just “dropping” TCP packets is not possible.

That is, TCP has sequence numbers and it will try to send that data again.

The above statement is totally irrelevant in context of this discusion. It describes how TCP requests get internally processed, but it has nothing to do with TDI-level filtering - TDI filters see only those requests that get submitted by TCPIP clients. TCPIP clients are unaware of the above mentioned internal details. For example, TCP client is unaware of the fact that TCP send involves both sending and receiving data - it just submits TDI_SEND request with IRP_MJ_INTERNAL_DEVICE_CONTROL, and gets informed about successfull (or unsuccessfull) request completion.

Therefore, your statement applies only at the level of NDIS layer, because NDIS IM sees absolutely all IP packets that TCPIP send and receives. However, what the OP speaks about is dropping the request *before* it reaches TCPIP.SYS

Anton Bassov