Spying Windows Software by Sniffing and Decoding Packets including SSL with oSpy

Sniffing packets of a software is one of the reverse engineering method to find out what data is being sent and received. Packet sniffing is mostly done by more advanced users and most of the time, hackers themselves. Many years ago when I was in the 8th-wonder team, our leader of the clan ad4 used packet sniffer and discovered that anyone can change a person’s ICQ details without logging in to that user account. He created a simple tool which is able to change the details of any ICQ account, unfortunately one of the clan member masta abused the tool and ICQ found out about that exploit and fixed it within 24 hours.

Other than that, it is also useful to check if a program is harvesting any sensitive data from your computer. If you do not have a firewall, you wouldn’t know if the program that you installed is connecting to the Internet or not. The most popular packet sniffer that is free today is Wireshare (last time was called Ethereal), but I’d like to introduce a different one called oSpy which has the capability of even decrypting encrypted SSL packets.

oSpy is a packet sniffing tool which aids in reverse-engineering software running on the Windows platform. The sniffing is done on the API level which allows a much more fine-grained view of what’s going on. Seeing return-addresses for each recv/send call (for example), can prove useful when you want to look at the processing code at that spot in a debugger or static analysis tool. And if an application uses encrypted communication it’s easy to intercept these calls as well. oSpy already intercepts one such API, and is the API used by MSN Messenger, Google Talk, etc. for encrypting/decrypting HTTPS data.
Another neat feature is when wanting to see how an application behaves when in a firewalled environment. Normally you would have to simulate such an environment by configuring firewalls etc., which not only is time-consuming, but might also cripple the rest of the applications you’ve got running. oSpy solves this problem by a feature called softwalling which allows you to set rules based on the type of function-call, the return-address, local/remote address/port, etc., and lets you choose which error to signal back to the application when the rule matches. This way you can make the application think that for example a connect() timed out, connection was refused, there was no route to host, etc.
Here is a simple test on how oSpy decrypts the SSL packet and display it in clear text.
1. I opened Maybank2u login webpage which has SSL.

2. I attached iexplorer.exe process to oSpy and start capturing the packets. Press F5 in oSpy, chose iexplorer.exe and click Start to start capturing packets on Internet Explorer.
3. I typed the username and password on the Maybank2u login page and click the login button.
4. oSpy shows the username and password that I typed in clear text!

I’ve tried capturing the packets using Wireshark but it only shows the encrypted data and nothing about the username and login even though all the protocols are enabled. The above is only one example of what you can do with oSpy and there are many other reasons to use this tool. What I like about oSpy is its portable, you don’t need to install WinPcap like most packet sniffer requires, small and it’s free!
There’s an annoying bug with oSpy which is if you do not terminate the program properly, you won’t be able to use it to capture packets on any process. It will ask you run a few gacutil commands in command prompt to cleanup the left-over .NET assemblies in your system-wide Global Assembly Cache. For gacutil to work, you will need to download and install .NET Framework SDK or Visual Studio. This might be fixed in the future versions…
[ Download oSpy ]