views:

405

answers:

4

There are two problems here:

  1. What if content is encoded:gzip...
  2. Do I also need to change the header part to make the HTTP packet valid(checksums if any?)

UPDATE

Can someone with actual experience elaborate the steps involved?

I'm using winpcap and bpf tcp and src port 80 to filter the traffic,so my job lies in this callback function:

void packet_handler(u_char *param, const struct pcap_pkthdr *header, const u_char *pkt_data)
+1  A: 
  1. Decompress it with a GZIP decompresser.
  2. Remove the Content-Encoding header and add a Content-Length header representing the new length in bytes.

That said, for a better answer you'll need to supply more context in the question. This is namely a smell. What is it you're trying to achieve and for which you think that modifying the HTTP response is the right solution?

BalusC
I'm doing it for interest. Are you sure I don't need to change other header info like checksums in ethernet/tcp/ip/http layers?
httpinterpret
The HTTP specification doesn't tell anything about headers with checksums. It are apparently custom headers. You should read the HTTP specification for interest as well :)
BalusC
But there are checksums in tcp/ip layers. I'm afraid the packet will be invalid if I just change the content but not the checksums.
httpinterpret
Ah, that way. You want to modify a TCP/IP packet which represents part of gzipped HTTP response? No, you cannot do it on a per TCP/IP packet basis. You'll have to buffer all packets representing the entire HTTP response, decompress its body and resend it with the changed headers.
BalusC
Again, do I need to take care of the checksums mentioned?
httpinterpret
Yes, certainly if there are already any checksums in the header. You need to recalculate them based on the new packet contents. But as @symcbean mentions: you'll really need to get all the material straight for yourself first. TCP/IP is a network protocol. HTTP is a data transfer protocol.
BalusC
Whether you need to care about checksums depends on how you are going to implement your solution. How and where will you capture the packets ? Are you making a transparent proxy server, or are you just sniffing packets and intend to send them out again - in which case, how do you stop the original packet ?- you can't really send duplicates to the destination.
nos
*how do you stop the original packet ?- * I'm also looking for the answer.
httpinterpret
+3  A: 

WinPcap doesn't allow you to change a packet that was already sent.

If the packet was sent, WinPcap won't prevent it from reaching its destination.

If you want to send another response - in addition to the response that was sent - I'm not sure what you're trying to achieve.

brickner
+1  A: 

libpcap is used for capturing. If you want to do modification and injection of network packets you need another library, such as libnet.

Michael Foukarakis
But seems `libnet` can't be used for packet mangling either.
httpinterpret
It can 1) do packet injection and 2) complete packet handling (even without automatic constructors). I don't see what else you need, besides some external routine for gzip decompression.
Michael Foukarakis
+1  A: 

winpcap is an odd way to try modifying a TCP stream - you don't explain why you are trying to do this, but you should probably be able to achieve this by writing your own HTTP proxy instead. That way, you get presented with a straight datastream you can intercept, log and modify to your heart's content. Once you do that, strip out Accept-Encoding from the request headers, then you'll never need to deal with gzipped responses in the first place.

There are no HTTP checksums, but the lower layers do have checksums; by operating on the application level as a proxy server, you let the network stack deal with all this for you.