p0c has asked for the wisdom of the Perl Monks concerning the following question:
Hey all,
I'm looking for some modules or example script on how to capture packets, modify and then send them further.
Net::Packet is good for capturing, but I can't see how to edit the packets. I can only manage to look at the packet itself, but the packet itself is already send to it final destination then. Maybe Net::Packet isn't the right way to go?
Say for example I want to replace <img src=bla.jpg> to <img src=lala.jpg> in every HTTP packet..
Can anyone give me some pointers in the right direction?
|
Re: Packet editing
by ikegami (Patriarch) on May 21, 2009 at 15:34 UTC
|
Surely there already exists an intercepting proxy server you can use.
Note that working with a packet at a time won't work since you'll need to adjust the Content-Length header.
| [reply] |
Re: Packet editing
by Polyglot (Chaplain) on May 21, 2009 at 15:39 UTC
|
Are you planning on piecing the individual packets together first, doing your substitution, and then re-splitting the packets?
If not, I think you will run into complications on the splitting points of the packets. How will you know that the entire URL of your image is contained in one single packet, all of the time? Do packets always respect URLs in such a way as to make sure that they will not get chopped in two? I don't think so.
As one website put it:
- TCP/IP implementations differ in the approach they take to deciding on packet size. It is fairly common for implementations to use 576-byte packets whenever they can't verify that the entire path is able to handle larger packets. The problem is that many implementations have bugs in the code to reassemble pieces. So many implementors try to avoid ever having splits occur. Different implementors take different approaches to deciding when it is safe to use large packets. Some use them only for the local network. Others will use them for any network on the same campus. 576 bytes is a safe size, which every implementation must support.
So, what are the odds of your URL always landing somewhere in the middle of that packet, and never on the joint between two packets?
Blessings,
~Polyglot~ | [reply] |
|
|
Yes I knew that, forgot a bit about it. It doesn't matter if it's a bit hit and miss with the replacing. First reassembling the packets first will cause to much delay..
Is there a way to do this?
| [reply] |
Re: Packet editing
by ig (Vicar) on May 22, 2009 at 00:51 UTC
|
As you are wanting to manipulate the HTTP protocol payload, you should probably use something more structured and high level than raw IP packet manipulation.
Net::Proxy::Tutorial provides an introduction to what you can do with the Net::Proxy module. You might also be able to use HTTP::Proxy. There are proxy modules for many protocols.
| [reply] |
|
|
Yes, but the thing is that i can't use a proxy for this. The only thing I can do is intercept the packets.
The thing I want to do looks like what ettercap filters do.
Like this:
http://www.irongeek.com/i.php?page=security/ettercapfilter
| [reply] |
|
|
Yes, but the thing is that i can't use a proxy for this. The only thing I can do is intercept the packets.
I take it that you mean you cannot reconfigure the clients to direct their queries to the proxy explicitly. This does not prevent you using software that provides easy access to the HTTP protocol layer and HTML documents therein.
Software that allows you to intercept relevant packets on the network and manipulate the communications protocols without configuration of the clients are sometimes called "transparent" or "intercepting" proxies.
You can do this with ettercap but there are other packages that provide easier access to the HTTP protocol layer. There are Perl modules that do this and many other applications, as ikegami has pointed out in Re: Packet editing.
There are Perl modules that provide rich features for inspecting and modifying HTTP protocol communications and HTML documents.
There are intercepting proxies that are not written in Perl that provide access to the HTTP protocol and HTML documents and may provide better performance than you could achieve with Perl. Wikipedia has links to some of these.
The squid proxy is popular and I have successfully used it many times. It can be used as an intercepting proxy, though I have not used it to manipulate the HTML myself. But, as noted previously, there are many others that you might investigate.
I suggest that you cannot create a reasonably competent proxy to manipulate HTML documents in HTTP protocol streams by manipulation of individual IP packets, whether with ettercap or any other packet filtering software. You will have better results with less effort if you start with a better tool.
| [reply] |
|
|