Word Gems

A personal interest blog about computergraphics, rendering and usefull C++ and Python stuff.

Intercepting network traffic using Wireshark

Have you ever wondered what any specific application was sending over your network? If you want to know that, or even want to find out how a proprietary protocol works, you should give Wireshark (www.wireshark.org) a try! Today i’m going to peek into the network traffic of my email client. First I have to check the ip of the mailserver i’m using. I am going to use the ip to filter out network traffic which is send to or received from that specific server.

As we can clearly see by using ping, the ip is 212.227.17.185, so lets fire up Wireshark. Lucky for us that Wireshark brings some very mighty, built in protocol parsing features. Lets just select the pop-protocol, which is used to transfer the emails from the server to my client.

Additionally we want to fitler by the servers ip, which is possible by further specifying the filter expression.

Now lets select the network interface of my wlan stick, which is the second one. If you can’t tell the interfaces apart just click on “details” to get some hints. Click start to start the capturing of packets.

After you started capturing packets you should, of course, generate some traffic to be captured by triggering a network event. I let Thunderbird check if I received a new email and expectet to see some packets flowing back. But what happend is: Nothing! The packet list stays empty. Maybe the ip was wrong? Let’s send another ping.

Well thats interesting! I get different ip’s for the same hostname. Looks like the mail hoster is distributing the clients over different servers by just returning different ip’s. Lets just filter all traffic coming from any ip in that range by changing the filter to be “pop and ip.src==212.227.17.0/8”. Apply the changes an suddenly I can see all the packets which were received from the sever. To see the packets send from my client to the server just change “ip.src” to be “ip.dst”.

The second request send to the server is “STLS”, which asks the server to start an encrypted TLS or SSL connection. And it looks like the request was succesfull since the following packets are encrypted. If that wouldn’t be the case I could see my email account and password being send to the server. Since I’m using a wlan to transmit my network traffic everybody else using the network can see the exact same packts i’m seeing now. Good to know the encrpytion of my email client works as expected. But what about usernames and passwords I enter on websites? As you can guess by now, they are send in clear text if i’m not using https, which is the encrypted equivilant of http protocol.

Filed under: Network

Using jpcap under win 7 (x64)

While using the jpcap project unter Windows 7 I stumbled upon this error:

Exception in thread “main” java.lang.UnsatisfiedLinkError: no jpcap in java.library.path
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1738)
    at java.lang.Runtime.loadLibrary0(Runtime.java:823)
    at java.lang.System.loadLibrary(System.java:1028)
    at jpcap.JpcapCaptor.<clinit>(JpcapCaptor.java:251)
    at PacketReceiver.run(PacketReceiver.java:19)
    at Main.main(Main.java:16)

It was caused by using the 64 bit java JDK. I installed the x86 version of the JDK and set it in the Eclipse preferences. That fixed the linking error and should help anybody having the same problem.

Eclipse Preferences

The newest JRE and JDK can be found here: http://www.oracle.com/technetwork/java/javase/downloads/

Filed under: Java, jpcap, Network