Rewriting Live TCP/IP (Layer 4) (i.e. Socket Layer) Streams - python

I have a simple problem which I'm sure someone here has done before...
I want to rewrite Layer 4 TCP/IP streams (Not lower layer individual packets or frames.) Ettercap's etterfilter command lets you perform simple live replacements of Layer 4 TCP/IP streams based on fixed strings or regexes. Example ettercap scripting code:
if (ip.proto == TCP && tcp.dst == 80) {
if (search(DATA.data, "gzip")) {
replace("gzip", " ");
msg("whited out gzip\n");
}
}
if (ip.proto == TCP && tcp.dst == 80) {
if (search(DATA.data, "deflate")) {
replace("deflate", " ");
msg("whited out deflate\n");
}
}
http://ettercap.sourceforge.net/forum/viewtopic.php?t=2833
I would like to rewrite streams based on my own filter program instead of just simple string replacements. Anyone have an idea of how to do this? Is there anything other than Ettercap that can do live replacement like this, maybe as a plugin to a VPN software or something?
I would like to have a configuration similar to ettercap's silent bridged sniffing configuration between two Ethernet interfaces. This way I can silently filter traffic coming from either direction with no NATing problems. Note that my filter is an application that acts as a pipe filter, similar to the design of unix command-line filters:
>[eth0] <----------> [my filter] <----------> [eth1]<
My filter will be a userspace Python function.
What I am already aware of, but are not suitable:
Tun/Tap - Works at the lower packet layer, I need to work with the higher layer streams.
Ettercap - I can't find any way to do replacements other than the restricted capabilities in the example above.
Hooking into some VPN software? - I just can't figure out which or exactly how.
libnetfilter_queue - Works with lower layer packets, not TCP/IP streams.
Again, the rewriting should occur at the transport layer (Layer 4) as it does in this example, instead of a lower layer packet-based approach. Exact code will help immensely!
Thanks!

Take a look on Scapy, or another packet crafting tool. There are not much of this type out there.

Ettercap is seemingly an open source project, since it is hosted on SourceForge. Perhaps you should look at how it does it.

At the time I was writing a network traffic analysis tool using libpcap for the capture and libnids for the stream assembly.
I haven't tried reinjecting traffic, but you can use TAP to forward traffic to a user program that will use libnids to assemble the packets, put out streams to a filter code, then take the stream and disassemble them (I'm pretty sure libnids has this capability as well) and reinject them into where you need it to go.
If you want python, pynids seems to do what you need, but I have no experience with it.

It looks like you would be able to write an ettercap plugin that loads filters written in python. Or write your custom filter in C instead.

Why not just access DATA.data directly with whatever filters you want?
I don't think you have to use search() you'll just have to build your own analyzer / state machine.
e.g.
for (int i = 0; i < DATA.len; i++) {
if ( DATA.data[i] == 'c' ) {
DATA.data[i] = q
}
}
Final Thoughts;
(1) I don't know that DATA.len exists but seems likely there's something.
(2) I know I replicated your search / replace but wanted to show how you may be able to do the equiv. 'manually'. You can get fancy w/ stuff later.
(3) If you were to adjust the length of the packet (or even the contents for that matter) you probably need to consider shifting window sizes / CRC checks, etc.
e.g. DATA.data[i] = "cc" would overwrite two characters (possibly not what you want) or would change the side of the packet.
I'd assume there are some library calls to set things right again.

PyPCAP is worth checking out since this all hinges around libpcap underneath to begin with. Cut out the middle man!

Since Ettercap is opensource you can change its source code to do what you want. Running your own C code to rewrite a TCP stream should be relatively easy. The hard work has already been done.
Take a look at the etterfilter man page to get started. Search in the source code for the filter engine (apparently it's a JIT interpreter).
I would also try to mail this question to the etterfilter authors, maybe they like stackoverflow :-)
Note: to use Python instead of C, see http://docs.python.org/release/2.5.2/ext/embedding.html

Related

Control Libreoffice Impress from Python

Im writing an application oriented to speakers and conferences. Im writing it with Python and focused on Linux.
I would like to know if its possible to control LibreOffice Impress with Python, under Linux in some way.
I want to start an instance of LibreOffice Impress with some .odp file loaded, from my Python app. Then, I would like to be able to receive from the odp some info like: previous, current and next slide. Or somehow generate the images of the slides on the go.
Finally, I want to control LibreOffice in real time. This is: move through the slides using direction keys; right and left.
The idea is to use python alone, but I don't mind using external libraries or frameworks.
Thanks a lot.
Take a look at AOO UNO . You may also check some application projects like docvert. This framework is shared between LO and Apache OO, but perhaps there some minor differences due to separate development of the two projects.
For a simple tutorial-like code you may take a look at this project. The rest depends on your actual needs and you should study corresponding UNO API, it's (almost) language-neutral.
The answer from #user3159253 describes how to connect to a presentation file, which is the first part of your question. Then, to control the presentation you will need to use XPresentation2 and XSlideShowController. Here is some code to do this, using the doc variable from the other example:
def runSlideShow(doc):
presentation = doc.getPresentation()
presentation.start()
while not presentation.isRunning():
pass
presentation_controller = presentation.getController()
presentation_controller.gotoNextSlide()
print("isRunning() == %s" % presentation_controller.isRunning())
I adapted this code from http://openoffice.2283327.n4.nabble.com/XPresentation2-returns-a-null-XSlideShowController-td2771599.html.
Responding to your comment: You need to add the following towards the bottom of the code,
similar to what is in highlight.py.
Did you try running the impress-code-highlighter example?
def do_runSlideShow(*args):
ctx = XSCRIPTCONTEXT
doc = ctx.getDocument()
runSlideShow(doc)
g_exportedScripts = (do_runSlideShow,)
if __name__ == "__main__":
doc = remote_get_doc()
runSlideShow(doc)
Finally, I found a way to solve this using Python, in an elegant and easy way. Instead of libraries or APIs, Im using a socket to connect to Impress and control it.
At the end of the post you can read the full-text that indicates how to control Impress this way. It is easy, and amazing.
You send a message using Python to Impress ( that is listening in some port ), it receives the message and does things based on your request.
You must enable this "remote control" feeature in the app. I solved my problem using this.
Thanks for your replies!.
LibreOffice Impress Remote Protocol Specification
Communication is over a UTF-8 encoded character stream.
(Using RTL_TEXTENCODING_UTF8 in the LibreOffice portion.)
TCP
More TCP-specific details on setup and initial handshake to be
written, but the actual message protocol is the same as for Bluetooth.
Message Format
A message consists of one or more lines. The first line is the message description,
further lines can add any necessary data. An empty line concludes the message.
I.e. "MESSAGE\n\n" or "MESSAGE\nDATA\nDATA2...\n\n"
You must keep reading a message until an empty line (i.e. double
new-line) is reached to allow for future protocol extension.
Intialisation
Once connected the server sends "LO_SERVER_SERVER_PAIRED".
(I.e. "LO_SERVER_SERVER_PAIRED\n\n" is sent over the stream.)
Subsequently the server will send either slideshow_started if a slideshow is running,
or slideshow_finished if no slideshow is running. (See below for details of.)
The current server implementation then proceeds to send all slide notes and previews
to the client. (This should be changed to prevent memory issues, and a preview
request mechanism implemented.)
Commands (Client to Server)
The client should not assume that the state of the server has changed when a
command has been sent. All changes will be signalled back to the client.
(This is to allow for cases such as multiple clients requesting different changes, etc.)
Any lines in [square brackets] are optional, and should be omitted if not needed.
transition_next
transition_previous
goto_slide
slide_number
presentation_start
presentation_stop
presentation_resume // Resumes after a presentation_blank_screen.
presentation_blank_screen
[Colour String] // Colour the screen will show (default: black). Not
// implemented, and format hasn't yet been defined.
As of gsoc2013, these commands are extended to the existing protocol, since server-end are tolerant with unknown commands, these extensions doesn't break backward compatibility
pointer_started // create a red dot on screen at initial position (x,y)
initial_x // This should be called when user first touch the screen
initial_y // note that x, y are in percentage (from 0.0 to 1.0) with respect to the slideshow size
pointer_dismissed // This dismiss the pointer red dot on screen, should be called when user stop touching screen
pointer_coordination // This update pointer's position to current (x,y)
current_x // note that x, y are in percentage (from 0.0 to 1.0) with respect to the slideshow size
current_y // unless screenupdater's performance is significantly improved, we should consider limit the update frequency on the
// remote-end
Status/Data (Server to Client)
slideshow_finished // (Also transmitted if no slideshow running when started.)
slideshow_started // (Also transmitted if a slideshow is running on startup.)
numberOfSlides
currentSlideNumber
slide_notes
slideNumber
[Notes] // The notes are an html document, and may also include \n newlines,
// i.e. the client should keep reading until a blank line is reached.
slide_updated // Slide on server has changed
currentSlideNumber
slide_preview // Supplies a preview image for a slide.
slideNumber
image // A Base 64 Encoded png image.
As of gsoc2013, these commands are extended to the existing protocol, since remote-end also ignore all unknown commands (which is the case of gsoc2012 android implementation), backward compatibility is kept.
slideshow_info // once paired, the server-end will send back the title of the current presentation
Title

Python/Scapy Performance on embedded device using Wi-Fi

I am using Scapy to capture Wi-Fi client request frames. I am only interested in the MAC and requested SSID address of the clients. I do something like the following.
sniff(iface="mon0", prn=Handler)
def Handler(pkt):
if pkt.hasLayer(Dot11):
if pkt.type == 0 and pkt.subtype == 4:
print pkt.addr2 + " " + pkt.info
My issue is that I am doing this on a embedded device with limited processing power. When I run my script, my processor utilization rises to nearly 100%. I assume this is because of the sheer volume of frames that Scapy is sniffing and passing to my Python code. I also assume that if I could employ the right filter in my sniff command, I could eliminate many of the frames that are not being used and thus reduce the processor load.
Is there a filter statement that could be used to do this?
With Scapy it is possible to sniff with an BPF Filter applied to the capture. This will filter out packets at a much lower level then your Handler function is doing, and should significantly improve performance.
There is a simple example in the Scapy documentation.
# Could also add a subtype to this.
sniff(iface="mon0", prn=Handler, filter="type mgt")
Filter pieced together from here specifically.
Unfortunately I can't test this right now, but this information should provide you with a stepping stone to your ultimate solution, or someone else to post exactly what you need. I believe you will also need to set the interface to monitor mode.
You may also find this question of interest - Accessing 802.11 Wireless Management Frames from Python.
Scapy is extremely slow due to the way it decodes the data. You may
Use a BPF-filter on the input to only get the frames you are looking for before handing them to scapy. See this module for example. The module uses libpcap to get the data from the air or from a file first and passes it through a dynamically updated BPF-filter to keep unwanted traffic out
Write your own parser for wifi in c (which is not too hard, given the limited amount of information you need, there are things like prismhead though)
Use tshark from wireshark as a subprocess and collect data from there
I highly recommend the third approach although wiresharek comes with a >120mb library that your embedded device might not be able to handle.

Linux libnetfilter_queue delayed packet problem

I have to filter and modify network traffic using Linux kernel libnetfilter_queue (precisely the python binding) and dpkt, and i'm trying to implement delayed packet forward.
Normal filtering works really well, but if i try to delay packets with function like this
def setVerdict(pkt, nf_payload):
nf_payload.set_verdict_modified(nfqueue.NF_ACCEPT, str(pkt), len(pkt))
t = threading.Timer(10, setVerdict, [pkt, nf_payload])
t.start()
It crashs throwing no exception (surely is a low level crash). Can i implement delay using directly libnetfilter like this or I must copy pkt, drop it and send the copy using standard socket.socket.send()?
Thank you
Sorry for the late reply, but I needed to do something like this, although slightly more complicated. I used the C-version of the library and I copied packets to a buffer inside my program, and then issued a DROP verdict. After a timeout relating to your delay, I reinject the packet using a raw socket. This works fine, and seems quite efficient.
I think the reason for your crash was due to the fact that you didnt issue a verdict fast enough.
I can't answer your question, but why not use the "netem" traffic-queue module on the outgoing interface to delay the packet?
It is possible to configure tc queues to apply different policies to packets which are "marked" in some way; the normal way to mark such packets is with a netfilter module (e.g. iptables or nfqueue).

How to use tun/tap interface to split packets, tunnel and then reassemble. (similar to MLPPP)

I am looking to create a client/server application that I can use to slit network packets in half, tunnel each half of the packet over a separate udp connection (because each udp connection will be going over a different wifi link) and then reassemble the split packets on the other end. In addition to splitting the packets each half packet will also have to have an ID and sequence number so that they can be reassembled properly.
Basically I am trying to do something similar to MLPPP
I am looking to do this using python and the TUN/TAP network driver.
I have found the following python code samples and modules that I think might be helpful for this project.
Python tun/tap
http://www.secdev.org/projects/tuntap_udp/files/tunproxy.py
http://twistedmatrix.com/trac/browser/trunk/twisted/pair/tuntap.py
http://pastebin.com/gMB8zUfj
Python raw packet manipulation
http://libdnet.sourceforge.net/
http://pypi.python.org/pypi/pyip/
http://code.google.com/p/python-packet/
My question is can the necessary packet modification be done using python and what would be a possible way to approach this? Can I use the modules above to do this or is there a better solution? I am looking for some input that will steer me in the right direction as I am not an experienced programmer. Any code samples or additional links are welcome.
We are doing something like this in production and it works quite well. We don't split individual packets though. We set fractional weights for each connection (unlimited) and send the packets out. We have some code in place to deal with different latencies on each line. On the other end we buffer them and reorder. Performance is pretty good - we have sites with 5+ ADSL lines and get good speeds, 40+ Mbps on the download.
Splitting packets (eg 1500/2 = 750) would introduce unnecessary overhead... keep your packets as big as possible.
We have developed our own protocol (header format) for the UDP packets. We have done loopback testing on the tun/tap up to 200 Mbps, so definitely the kernel to user space interaction works well. Previously we used NFQUEUE but that had reliability issues.
All of the above was written in Python.
It looks perfectly possible to me.
The tun/tap modules you've discovered look like they would do the job. Twisted will be high performance and the cost of hurting your head working it all out.
As for splitting the packets, you don't need to interpret the data in any way, just treat it as a blob of binary data, split it in two and add a header - I wouldn't use any 3rd party modules for that, just normal python string handling.
Or you could use netstrings if you want an easy to use packet encapsulation format.
I don't suppose it would go like a rocket, but I'm sure you would learn lots doing it!

Best approach to a command line proxy?

I'd like to write a simple command line proxy in Python to sit between a Telnet/SSH connection and a local serial interface. The application should simply bridge I/O between the two, but filter out certain unallowed strings (matched by regular expressions). (This for a router/switch lab in which the user is given remote serial access to the boxes.)
Basically, a client established a Telnet or SSH connection to the daemon. The daemon passes the client's input out (for example) /dev/ttyS0, and passes input from ttyS0 back out to the client. However, I want to be able to blacklist certain strings coming from the client. For instance, the command 'delete foo' should not be allowed.
I'm not sure how best to approach this. Communication must be asynchronous; I can't simply wait for a carriage return to allow the buffer to be fed out the serial interface. Matching regular expressions against the stream seems tricky too, as all of the following must be intercepted:
delete foo(enter)
del foo(enter)
el foo(ctrl+a)d(enter)
dl(left)e(right) foo(enter)
...and so forth. The only solid delimiter is the CR/LF.
I'm hoping someone can point me in the right direction. I've been looking through Python modules but so far haven't come up with anything.
Python is not my primary language, so I'll leave that part of the answer for others. I do alot of security work, though, and I would urge a "white list" approach, not a "black list" approach. In other words, pick a set of safe commands and forbid all others. This is much much easier than trying to think of all the malicious possibilities and guarding against all of them.
As all the examples you show finish with (enter), why is it that...:
Communication must be asynchronous; I
can't simply wait for a carriage
return to allow the buffer to be fed
out the serial interface
if you can collect incoming data until the "enter", and apply the "edit" requests (such as the ctrl-a, left, right in your examples) to the data you're collecting, then you're left with the "completed command about to be sent" in memory where it can be matched and rejected or sent on.
If you must do it character by character, .read(1) on the (unbuffered) input will allow you to, but the vetting becomes potentially more problematic; again you can keep an in-memory image of the edited command that you've sent so far (as you apply the edit requests even while sending them), but what happens when the "enter" arrives and your vetting shows you that the command thus composed must NOT be allowed -- can you e.g. send a number of "delete"s to the device to wipe away said command? Or is there a single "toss the complete line" edit request that would serve?
If you must send every character as you receive it (not allowed to accumulate them until decision point) AND there is no way to delete/erase characters already sent, then the task appears to be impossible (though I don't understand the "can't wait for the enter" condition AT ALL, so maybe there's hope).
After thinking about this for a while, it doesn't seem like there's any practical, reliable method to filter on client input. I'm going to attempt this from another angle: if I can identify persistent patterns in warning messages coming from the serial devices (e.g. confirmation prompts) I may be able to abort reliably. Thanks anyway for the input!
Fabric is doing a similar thing.
For SSH api you should check paramiko.

Categories