I am looking for volunteers to help and build a full GUI based analyzer/sniffer in java. The application will be open-source and build by the community. My goal is to build an application that is order of magnitude better then anything else "open-source" or "commercial" out there.
First off, the next generation of jnetpcap (jnetpcap2 nearly ready) can perform full protocol analysis in realtime using multiple threads/CPUs/CPU-Cores. This is something not available with open source tools right now. Lets use this power to build an analyzer that goes way beyond what is currently possible.
Second, instead of building and releasing the software as a monolithic application, lets build it so that users can build their own applications layered on top. Instead of monolithic application, lets built it on top of libraries that developers can use to build their own application. For example, develop all the swing/AWT/swt/pivot components stand alone for our app, so that other users can reuse in their own projects. Let all analysis and other "high order code" be included in the low level protocol modules which are already getting pretty powerful and available "A-La-Carte" (new jnetpcap2 protocol modules.)
Why now? Here is the honest truth:
jNetPcap is used by hundreds of companies around the world and in various projects. I always get nothing but the best comments and complements on the software. However, the bugs that creep up from time to time are only possible to detect when a full blown application is using jNetPcap. There are hundreds of jUnit testcases that test the most purpular and recommended ways of use jNetPcap software part of the build process. However in the real world, things never go according to plan or recommendations.
So a real life implementation of the library will go a long way to head off any potential bugs out there. As the library gets more and more complex, a stand-alone application that uses jNetPcap to its full potential is more important then ever.
So honestly, this is my number 1 reason for asking the community to help.
The second reason is my personal goal of making available my own, nearly 3 decades worth of network analysis, design and troubleshooting experience in "code" form. Combine that with all the experience the user community can contribute in a form that is readily, easily and most abundantly available to anyone with a little bit of java and networking experience, and its a proposition that moves everyone forward. Libpcap/Winpcap/Ethereal/Wireshark did exactly that a decade ago, lets do a one better in the 21st century.
Will my company, Sly Technologies Inc., make any money off of this project. Not directly, but probably, in the form of selling more support for our library and some future hardware that we will be releasing to go along with the library. The more users use the library, the more orders for "commercial" support we get. So yes, we will probably make some money because of the extra volume and a better "library" because of this project. We don't make a killing on jNetPcap now and we need to make money to stay in business so that we can continue to work on jNetPcap. This way everybody wins.
These aren't the only reasons however. How cool and fun will it be to build the best ever analyzer. I have always had big ideas and this new standalone analyzer is no exception. Here are some of the off-the-top-of-my-head goals/features for this new project.
Lets start with basics of what every other application provides: packet capture and analysis. I can't name an analyzer/sniffer that doesn't provide these basic features. There is also some rudimentary "reassembly" or "follow the stream" type functionality, none of which I find user friendly or intuitive. This is something jNetPcap could do as of release 1.2:
This feature has been deprecated, because the native memory management used at the time wasn't ready to handle this extra complexity. However all of that and more has been put back into jnetpcap2.
So how about we do full HTML page reassembly and display/preview right in the app/analyzer. Instead of looking at raw packets and tcp streams, why not look at the end result which is the webpage with all the images and text inside? Webkit and other tools are there to let us provide the end result and let users dig down to packet level if they need to.
How about video/audio stream reassembly, same thing. IPSec, https and everything else falls under the same umbrella.
Mobile devices are everywhere and wouldn't you like to be able to do trouble shooting right on your phone/ipad/android device? jNetPcap is already working on android, so how about combining server and mobile technology to do things no one else is doing.
I am sure we can architect an application that is an order of magnitude better then anything out there. A full blown application can help catch bugs, provide direction of API architecture, things that are needed in real life etc. jNetPcap as a libpcap wrapper is pretty decent in itself, deep packet inspection functionality is fairly robust although still need of never ending list of protocols. What we need now is something to bring all these components together and guide the development forward with real life application.
I look forward to your comments and ideas.
I'm developing a graphical analyzer right now, called Atheris,
which will be released as open source project in the next weeks.
I'm always postponing the release since there are constantly new
features coming to my mind and due to testing reasons.
Atheris is already multi-threaded and should serve as a workbench
for traffic analysis. However, my focus is mainly
on flow and conversation analysis, not so much into protocol analysis,
since I didn't want to rebuild Wireshark. But this functionality
could be added without too much work and you can already feed Wireshark
with packets from Atheris to use its protocol analysis functionality.
So let's see, perhaps we can merge our efforts and if there are enough
volunteers, we could build the next generation of traffic analysis software.
BTW: When do you plan to release the next snapshot of version 1.3.1 ?
Philipp, that would be great if we could piggy back off of your work. The only thing is, that I would first like to assemble a team, then go over functional goals we want to achieve and settle on implementation details. It may mean that we would need to rewrite or re-implement certain aspects of your work, if you are OK with that.
Is it checked in on SF.net or anywhere else? If not, I can create a new module under SVN area for the application to reside. I would add the team members as developers on the overall jnetpcap project on SF.net which would allow everyone to make changes.
I am still chasing down 1 major bug (TCP header lengths get calculated incorrectly once in a blue moon for some reason) and a couple of tiny bugs that still need my attention. If it wasn't for the tcp bug, I would have already released it. I will build a new JAR file that works with existing 1.3.0 native library and has all the fixes so far (about 10 bugs) in it. I will make this jar file available for download from slytechs server today.
As to 2.0 capabilities and changes, here is a link to a story I have already prepared but not published to the front page, since I'm still working on it. But the details in there are already set in stone, so I can now start publishing that article:
sorry for the late response, but I didn't receive your reply automatically per email.
I have already registered a project on sourceforge, but didn't upload anything yet.
As said, the code needs some cleaning, but I will inform you when it's out.
The whole project will be open source, so of course I would be glad, if you found