20th of April Google has announced the accepted students for Google Summer of Code 2009 and I'm proud to say I was accepted again by Umit Project to develop UMPA library.
So be prepare that upcoming weeks will bring some noise and massive commits for UMPA ;-)
Anyway, I would like to share ideas which I'm going to develop during the summer.
There are 4 main features which I would like to hack.
Sniffinglibpcap wrappingCurrently, UMPA doesn't receive packet. It works only in one way (sending). The ideal option to support receiving packets is to use the common library called libpcap. By this, we can use well known format to save and load files with network data. The common and compatible format, allows to reuse files with other applications. To use this library with UMPA, python wrapper is needed. There are several wrappers, like impacket[1], pylibpcap[2] and pypcap[3]. Due to licence incompatiblity or unsupported Windows platform, I would like to use pypcap as a python wrapper for libpcap library. There are still some problems with the wrapper (e.g. function pcap_dispatch() is not supported) but by summing all prons and cons up, this choice fits better our needs than others.
So first, I'm planning to extend pypcap for our needs. I will add pcap_dispatch() functionality and any others if needed. I will test the wrapper against the most common operating systems like GNU/Linux, MS Windows or MacOSX. I have already talked with the main author of pypcap and he agrees this idea and is glad that I would join to pypcap's community.
receiving packetsAfter preparing and testing pypcap, I'm going to write receiving support for UMPA. It will be done by providing API to functions like available_devices(), receive_one(), receive_loop() and others. I'm going to talk with the author of PacketManipulator about his needs in this scope and to set common API together. Filtering packets will be available too.
Also, I will provide a function for simple action-reaction system (by using pcap_dispatch()). In this system, user could to register callback functions for expected network's frames. Simple scenerio: user send packet A and expect the respond B or C. He registers 2 callbacks for receiving system. And depending which respond will be received (B or C), appropriate function will be called.
Asynchronous SchedulerUMPA provides an extension called scheduler. It provides functionality to set initial delay for sending packets and interval between sending next frames. This extension in current state is blocking. It means that during a delay or interval time, library freezes process (UMPA uses time.sleep() function). My goal is to write new scheduler which will be non-blocking. Because UMPA is a library, using multiprocessing is improper. Threads are not the best option neither. They would solve some part of problems, like not freezing process, so GUI like PacketManipulator wouldn't be freezed too. On the other hand, new problems will occur with synchronization of threads during receiving packets. To avoid this, I'm going to use asynchronous technique. There are several already done frameworks for this (Twisted[4], asyncore[5] and others). I'm going to use asyncore for several reasons like:
it's distributed with Python Standard Library (no additional dependencies)
it's very lightweight (minimal additional CPU load)
it avoids to write asynchronous scheduler from a scratch (and speeds up developing process)
The only problem is that currently asyncore doesn't support future callbacks. There is an opened ticket for this issue[6] with attached patches and it's going to be commited soon. I'm going to rewrite this patch, to get back-compatibility with older Python's versions than trunk and distribute own version of asyncore with UMPA (with all compatible manner).
After all, UMPA will provide both schedulders, blocking and non-blocking. The reason to keep both is to give users a chance to pick appropriate for own needs (blocking scheduling will provide more friendly environment and its easier to use it for short applications).
Template SystemThe third feature which I'm going to implement is the template system.
Longterm simulation usecase describes goals of this idea:
User prepares a scenerio of the network simulation. He set rules and behaviours for received packets. UMPA will create new packets on demand and will be able to use information received from the packets to construct suitable packets to send them back. By creating complex scenerio, it's possible to keep UMPA alive for weeks and simulate some hardwares or softwares behaviours.
UMPA will become really powerful tool with this feature. It can be use in many simulation processes by hackers or even scientists (for analyse or provide scientist theories). Template system will be useful also in daily short-term cases. Like for checking stability of the network hardware by administrators. This feature is providing some intelligent for created packets!
Template system will be based on Python files for 2 reasons.
it will get some features by low cost (like loops, conditions)
user who is using UMPA library knows Python and he doesn't have to learn another (template) language
Additional functions will be provided to get easy way to write templates, especially for long-term cases where using too many conditions may fail (e.g. to generate sequence of packets). To clarify, async scheduler will be strongly integrated part of template system.
Protocol ImplementationI will implement missing protocols like ICMP or ARP. There is few limitation in core of UMPA to implement e.g. ICMP. I will restructure or rewrite part of core code if I would come across any problems during implementation phase.
So, this is how I see it now. Hope to see this (and more) done in August. UMPA would be incredible powerful then.
Check
UMPA website for current status!
References[1]
http://oss.coresecurity.com/projects/impacket.html[2]
http://pylibpcap.sourceforge.net[3]
http://code.google.com/p/pypcap/[4]
http://twistedmatrix.com[5]
http://docs.python.org/library/asyncore.html[6]
http://bugs.python.org/issue1641
