So the TCP fuzzing server is somewhat working. There are a few features I’d like to add, but I have been actually putting it to use for the time being and writing an IRC client fuzzer.

So far this supports:

  • Banners
  • Ability to read from an input file.
  • Saves its spot if a client disconnects.
  • Basic functionality like being able to specify IP and port to bind to.
  • It is very easy to write a fuzzer for a basic TCP-based client. The IRC fuzzer’s code is roughly 10 lines of Python with a big protocol defining file.

The things I’ve noticed that are going to need to be addressed:

  • The server doesn’t display the string that actually made the client quit/crash.
  • Some protocols require authentication or some sort of start up procedure. This can kind of be worked around with the few things I’ve tried, but it will be a burden to use this in its current form against a more robust protocol.
  • This does not support non-ASCII streams.
  • This does not support SSL yet.
  • Many client software applications rely on specific responses from a server and will error out or just not process bunk data sent to them. Things such as PING/PONG requests to make sure connections are still active, if not addressed, will cause a client to abort the session prematurely. Some sort of “expect” style definition is needed to handle this kind of issue.
  • Writing a protocol definition sucks.

One of the next things I’d like to do is be able to take a packet capture of communications against a protocol and generate a script to use. I have been manually doing this for IRC, and I am not even 2% done yet. I have numerics 001-005, the start of the MOTD, the body of the MOTD, the MOTD footer, and maybe a couple more informational numerics plugged in so far. I still need to do:

  • MODE
  • CTCP
  • DCC
  • KICK
  • QUIT
  • LIST
  • WHO
  • Quite a few more! IRC is not a small protocol.

Being able to parse a packet capture and intelligently pinpoint locations to fuzz, outputting a script that this software could use wouldn’t be too terribly hard. It will probably still not be 100% complete or correct, but it would be a good start and take a lot of the manual effort out of building these.

The more I think about this project, the more that I realize that making some one size fits all solution to fuzz everything is not going to be possible. If I keep going with this, I will end up with dozens of tools to attack a number of programs, protocols, formats, and all sorts of crap. I just hope that I am able to build enough tools to cover testing the things that I care about.