It's a clever idea. It's a simple, yet ingenious method of testing if your web browsing streams are truly in an encrypted tunnel, testing VPN tunnels, etc. Granted, this would be a very quick diagnostic test, and not very thorough, but if you see images on an SSL site or VPN tunnel, likely, something isn't as secure as it should be.
Fun program. I know there has been some interest in using driftnet on wireless packets via a device in monitor mode. Is there any particular reason this capability has never been added?
> It would appear that Driftnet (in its
> current version anyway) doesn't support
> the capture and display of PNG images,
This is on the todo list (among many other items), but it seems development on this project has ceased. :(
It would be really cool if someone would continue work on this project.
It would appear that Driftnet (in its current version anyway) doesn't support the capture and display of PNG images, either that or something in my build died (i don'tthink so because everything else is working fine).
Any chance of a PNG fix? Great software otherwise, scary and cool at the same time :D
Re: Pretty Cool
> % It would be nice to have an option to
> % tag the images with the source and
> % destination IP addresses, yeah I know
> % that would be a pain.
> It very deliberately doesn't do this.
> Feel free to add this yourself,
> but I won't accept such a patch into the
I actually have a need for this as well, but not for the Big Brother reasons you were probably thinking in your quote above. I spent some time trying to hack out just the parts of driftnet that I needed today but it hasn't been quite as easy as I had hoped.
I am interested in just grabbing the JPEG images off the wire, checking them for the JPEG buffer overflow vulnerability. If they are infected, log the source and destination address, and URL/image name if possible, but that can be obtained via other means. I actually can take a stock driftnet and use the "-a -m 1000 -d /myjpgs" params and pipe the output to a simple little Perl script that will check the JPEG file for the buffer overflow vulnerability and successfully detect infected JPEGS but it doesn't do me a lot of good without knowing where it came from and where it was going.
I would like to just get rid of the Perl part and strip out the JPEG grabber from driftnet and check for the vulnerability in memory and only write out the infected files along with the addresses (high utulization circuit). I know if I keep plucking at it I could hack out what I need but if anyone would be interested in helping I could use it.
You can find the simple details on how to check for the overflow here:
If anyone is interested in helping create a tool for this using driftnet (or something more appropriate) let me know. Here's a good place to post:
I know this wasn't the intended purpose for driftnet but it has most of the parts needed for this needed security app.
Re: Reasons for writing such a software
> There is also the image of an
> environment with a large screen showing
> all information, shared by everyone, a
> place with no secrets. Could such a
> place exist?
I think at one of the last CCC congresses there was a public
screen showing sniffed cleartext-passswords for everyone to
view.... Better encrypt!
Just wanted to say thanks for releasing driftnet.
It's great. Part of my job entails monitoring
computer usage to ensure our policies are being
complied with. Driftnet helps a lot.
Also, thanks for coding it so clearly. It would have
been a nightmare adding IP logging if it wasn't so
I wish it displayed like etherPEG
I really like the way that etherPEG writes newer pictures in random places, over the older ones, providing a constantly changing tapestry (so to speak) that shows current image viewing trends. Having an option to display in a similar way, rather than the default scrolling method would be very cool.
Re: Reasons for writing such a software
> My take is that your position is
> therefore unsupportable - and
when I reconsidered my posting then two thinks
come to my mind:
First, You are right. Every kind of software gets
written. To publish it on freshmeat is probably the
best way to ensure that it will be used in a right
way. Therefore, I regret my posting and I have
already sent an excuse to the author.
Second, my posting is just as wrong as the reaction
As You may have guessed, English is not my first
language. Therefore, I was more offensive than I
wanted to be. By asking "I wonder why such software was written"
I was actually looking for answers
and did not mean to blame the author.
> I wonder why this software was written?
> What is its intended purpose?
> Therefore, I think it was not a good
> idea to publish it, what do You think?
I manage multiple websites, all of which are directly controlled by my company. This software gives an immediate visual indication of what is being viewed, right now, on the site. This (among other things), used in conjunction with another tool that I wrote which dumps currently visited URLs in realtime in a neighboring window, has enabled me to visually spot deep-linked images that are being lifted from our sites (the page holding the image was not fetched); that's going to lead in turn to a controlled response to that unauthorized use of our bandwidth which we are paying for, for our own specific purposes. This benefits our company in a very reasonable and legitmate manner, saving our bandwidth for our legitimate visitors, and in no way invades anyone's privacy. These are our images, after all. And our bandwidth.
So there are perfectly legitimate uses of the software, and in fact, that was the first thing that occurred to me when I learned of it.
You know that old saw, "guns don't shoot people, people shoot people"? That applies everywhere. This is just a tool. You can use it neutrally, defensively, or offensively. If there is blame to be laid, lay it at the feet of the user who uses it offensively. Not at the feet of the designer.
One last thing; you mentioned that you can see what images are being surfed in the server logs. Yes. That's right, you can. Furthermore, you can see the IP that was surfing them. In point of fact, that is much more invasive than driftnet is, because not only do you have a link to the actual station doing the surfing, and hence some accountability, but you also have the ability to parse the logs with a program, sorting out images and users, deriving correlations and hence characterizing the station use. Driftnet provides none of that type of correlating functionality.
My take is that your position is therefore unsupportable - and inconsequential.
An open, cross-platform journaling program.
A scientific plotting package.