Using WinpkFilter to modify the payload of TCP/IP packets

Home Forums Discussions Support Portal Using WinpkFilter to modify the payload of TCP/IP packets

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #5086
    Daneel
    Participant

    Hi all,

    I’m analysing the possibility of modifying the payload of TCP/IP packets. I’m on Windows XP with VC++ 6.0.

    My original approach was to:

    1) Get the next ethernet packet (as shown in PassThru.cpp)
    2) Modify its payload according to my appliation
    3) Recalculate TCP and IP Checksums
    4) Send the modified ethernet packet to its intended destination

    Unfortunately it is not so easy, as there may be many ethernet packets for each TCP/IP packet.

    My current understanding of what needs to be done is:

    1) Buffer all ethernet packets which belong to a TCP/IP packet
    2) Discard / Modify the unneeded ethernet packets according to my application
    3) Recalculate TCP and IP Checksums
    4) Send all ethernet packets (with TCP/IP headers inserted into the first one)

    Can I implement this with WinpkFilter? Is there a better way?
    Am I missing something in the walkthrough provided above?
    How do I buffer multiple ethernet packets and (after processing) send them to their intended destination using WinpkFilter? I know how it works for one packet at a time, but what about multiple?

    Many thanks,
    Michael

    #6210
    Vadim Smirnov
    Moderator

    Unfortunately it is not so easy, as there may be many ethernet packets for each TCP/IP packet.

    Well, yes, IP packet can be fragmented and you may have to gather all fragments before processing the packet. However, fragmented IP packets are rather rare in modern networks, also these packets are recommended to be blocked by firewalls. Basically, I don’t think you will ever meet fragmented TCP packet, but it is still possible to generate fragmented ICMP or UDP packets.

    Can I implement this with WinpkFilter? Is there a better way?
    Am I missing something in the walkthrough provided above?
    How do I buffer multiple ethernet packets and (after processing) send them to their intended destination using WinpkFilter? I know how it works for one packet at a time, but what about multiple?

    In general the approach is correct. Sending multiply packets does not differ from sending a single one.

    #6211
    Daneel
    Participant

    Hi SerpentFly

    @SerpentFly wrote:

    Well, yes, IP packet can be fragmented and you may have to gather all fragments before processing the packet. However, fragmented IP packets are rather rare in modern networks, also these packets are recommended to be blocked by firewalls. Basically, I don’t think you will ever meet fragmented TCP packet, but it is still possible to generate fragmented ICMP or UDP packets.

    Many thanks. I’m downloading content from one node in my LAN to another node and my experimentation with WinpkFilter showed me that there are many ethernet headers for each IP header. From this I (wrongly) concluded that each IP packet consists of many ethernet frames with the IP header appearing only in the first of these ethernet frames.

    I’ve now read some of the relevant literature and I think this was a misconception. Actually, each ethernet frame also includes the IP header and consequently the TCP header, i.e., each ethernet packet looks like this:

    payload

    Is this ethernet checksum (http://folk.uio.no/od/tcp-ip-intro/subsection3_2_3.html) something which I need to care about (in addition to the length / checksum fields in the other headers)? Or is this computed automatically?

    This definitely makes my life easier … I think 😉

    Many thanks,
    Michael

    #6212
    Vadim Smirnov
    Moderator

    payload

    Correct for TCP packet, for UDP an example it would be

    payload

    and so on…

    Is this ethernet checksum (http://folk.uio.no/od/tcp-ip-intro/subsection3_2_3.html) something which I need to care about (in addition to the length / checksum fields in the other headers)? Or is this computed automatically?

    It is hardware checksum and you won’t even see it on NDIS level.

    #6213
    Daneel
    Participant

    Hi SerpentFly,

    @SerpentFly wrote:

    payload

    Correct for TCP packet, for UDP an example it would be

    payload

    and so on…

    I see. But this still means that I have to do the following actions if I want to modify the contents of a TCP/IP packet:

    1) Buffer the payload of all ethernet packets which belong to the same TCP/IP packet, i.e., which have the same TCP sequence number.

    2) Modify this buffer (which now contains the TCP/IP payload) according to the needs of my application.

    3) Recalculate the TCP and IP checksum of the modified buffer.

    4) Refragment the buffer into ethernet packets (size of 1500 bytes).

    5) Attach the ethernet header to each of these packets.

    6) Attach the modified (checksums, length) TCP/IP header to each of these packets.

    Is this – in principle – accomplishable using the WinpkFilter framework or should I look for another solution (which?)?

    Many thanks,
    Michael

    #6214
    Vadim Smirnov
    Moderator

    IP fragmentation does not cares about upper protocols, so only first fragment of the fragmented TCP packet has a TCP header. You should buffer fragments by IP ID, not by TCP sequence number and so on…

    I would advise to look through some good book devoted TCP/IP protocols before trying to implement something like this. You definitely need better understanding of the networking basics. I would recommend Richard Stevens books (TCP/IP Illustrated), but ofc this is not the only option.

    #6215
    Daneel
    Participant

    Hi SerpentFly,

    thanks.

    A small clarification: I’m not talking about fragmentation between TCP and IP packets (which is very seldom as you state above). I’m talking about fragmentation of TCP/IP packets into ethernet packets in my last post.

    I’ll get that book.

    All the best,
    Michael

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.