TDI Filtering (I guess?)
Davide DG
I have the need to modify an incoming TCP packet based on its content.
Specifically, I have to modify the *payload* when it contains a
particular data, with other data.
An application receives in the payload of a tcp packet a list of ip
addresses and server names; I must modify one of those ip-addresses.
To let the application work in our environment, I wrote a user-mode
application that searches in the process user space (ReadProcessMemory
api) and, when it finds a certain ip address, it modifies it
(WriteProcessMemory).
This solution works, but it is extremely slow, and virtual address
changees every time.
I searched a little, and found out that perhaps (?!) I have to write a
kernel mode network driver to intercept the packet and modify it before
it reaches the application level.
Looking in the MSDN documentation, I found that I should write a network
TDI driver.
>>> Is this correct? I am new to driver development, I can't understand
>>> if this layer of driver will allow me to modify an incoming tcp
>>> packet and will let me see which application (pid?) the packet is
>>> being sent to.
Thanks in advance for any help :)
Regards.
--
Davide DG.
Maxim S. Shatskih
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
"Davide DG" <davi...@ngi.it> wrote in message
news:Xns947FB73092C705F...@194.185.88.6...
Thomas F. Divine [DDK MVP]
then by far the best approach is to use a NDIS Intermediate driver. This is
probably easy if the list of IP addresses and server names is small enough
to fit into a single packet without fragmentation/reassembly.
Filtering at the TDI level is tedious, but may work for you since your
requirements are fairly simple.
There are other approaches that may work for you on various platforms. See
the Windows Network Data Filtering page at the URL:
http://www.ndis.com/papers/winpktfilter.htm
Good luck,
Thomas F. Divine
www.pcausa.com
"Davide DG" <davi...@ngi.it> wrote in message
news:Xns947FB73092C705F...@194.185.88.6...
Davide DG
> If you can make your change based on the information in individual
> packets, then by far the best approach is to use a NDIS Intermediate
> driver. This is probably easy if the list of IP addresses and server
> names is small enough to fit into a single packet without
> fragmentation/reassembly.
Packets are 95% of the times smaller than 650bytes (header+payload), but
if the list of servers is "very" long, they can become larger
What happens if a packet arrives fragmented? Will I have to trace the
reassembly operation?
> Filtering at the TDI level is tedious, but may work for you since your
> requirements are fairly simple.
> http://www.ndis.com/papers/winpktfilter.htm
From the picture I argue that packets arrive at TDI level already
reassembled... will this avoid any fragm./reass. issues ?
Can I make my changes based on packet contents *and* packet destination
(Pid) ?
Why is it the best approach a NDIS IM driver? performance / coding ?
Sorry for my big and deep ignorance ;P
Thanks for your time.
--
Davide DG.
Thomas F. Divine [DDK MVP]
> "Thomas F. Divine [DDK MVP]" <tdi...@NOpcausaSPAM.com> scrisse:
>
> > If you can make your change based on the information in individual
> > packets, then by far the best approach is to use a NDIS Intermediate
> > driver. This is probably easy if the list of IP addresses and server
> > names is small enough to fit into a single packet without
> > fragmentation/reassembly.
>
> Packets are 95% of the times smaller than 650bytes (header+payload), but
> if the list of servers is "very" long, they can become larger
>
> What happens if a packet arrives fragmented? Will I have to trace the
> reassembly operation?
>
You will almost certainly have to deal with a server list that spans
multiple packets.
>
> > Filtering at the TDI level is tedious, but may work for you since your
> > requirements are fairly simple.
>
> > http://www.ndis.com/papers/winpktfilter.htm
>
> From the picture I argue that packets arrive at TDI level already
> reassembled... will this avoid any fragm./reass. issues ?
>
Since data is reassembled at the interface above the kernel-mode TCP/IP
driver you will not need to deal with packets at all.
> Can I make my changes based on packet contents *and* packet destination
> (Pid) ?
>
You can change the data payload if you must.
You can detect the packet destination by understanding and tracking TDI
address and connection objects as they are created.
It is difficult to alter the destination on the local host (i.e., switch to
a different AO or CO).
> Why is it the best approach a NDIS IM driver? performance / coding ?
>
The documentation and samples for filtering using a NDIS IM driver is much
more complete then for TDI. Filtering at TDI is very tedious and requires a
fairly thorough understanding of 1.) kernel-mode programming, 2.) TCP/IP and
3.) the TDI interface (which is not the most intuitive). A TDI filter should
not be one's first experiance in kernel-mode development.
Good luck,
Thomas F. Divine
>
Callas
> It is difficult to alter the destination on the local host (i.e., switch to
> a different AO or CO).
A bit more descriptive: I'd say that the TDI filter you write has to be
fully comprehensive, to permit such behaviour. Writing a fully
comprehensive TDI filter is difficult.
> > Why is it the best approach a NDIS IM driver? performance / coding ?
> The documentation and samples for filtering using a NDIS IM driver is much
> more complete then for TDI. Filtering at TDI is very tedious and requires a
> fairly thorough understanding of 1.) kernel-mode programming, 2.) TCP/IP and
> 3.) the TDI interface (which is not the most intuitive). A TDI filter should
> not be one's first experiance in kernel-mode development.
lol!
That's exactly what it was for me! poor me :)
--
Callas
Davide DG
> There are other approaches that may work for you on various platforms.
> See the Windows Network Data Filtering page at the URL:
>
> http://www.ndis.com/papers/winpktfilter.htm
First, I would like to thank everybody for the answers!
I started analyzing the code in the examples:
ndisprot (ddk)
passthru (ddk)
passthruex (www.wd-3.com)
imsamp (support.microsoft.com)
ndis_hk (http://ntdev.h1.ru/ndis_fw.html)
tdi_hk (http://tdifw.sourceforge.net)
I think the Passthru/Ex one is the simplest and nearest to what I have
to do.
But it seems that, either I choose to use an IM filter, or a NDIS
hooking (as in the ndis_hk) solution, there always are
controindications:
NDIS hooking is discouraged by Microsoft and even by te authors of the
sample.
While NDIS IM has its own issues: http://tdifw.sourceforge.net
So, again, I am asking advices on what kind of solution should I (try
to) implement and which ddk-sample I should start from ?
Thanks again for the answers!!
Good bye :)
--
Davide DG.