What a weekend

Had the most counter-productive weekend ever, or so I thought. Stayed late at work on Friday, came home and spent most of the night just relaxing and listening to Dream Theater. Slept until 19:30 and had to hurry out of bed to get to the closest grocery store before closing time. Ate pizza and watched Alien 3, a really disappointing movie (I knew that, but hey, about time I catch up with the so-called classics). Thought about hacking a little on pymsn, but felt completely useless, just like the night before. Went to bed at around 04:00, slept until 11:00, spent one hour to get out of the bed. Fired up my beloved La Pavoni Professional and made myself a huge cup of cappuccino and enjoyed it while hacking a little on pymsn.

Chatted with Ali (asabil), agreed to split up the work so that he would write the SOAP building blocks after I had pieced together some protocol transcripts that he could work from (since I’ve always got XP running in vmware, standing by to make traces with oSpy). The plan was that he would do the SOAP building blocks one by one while I’d do the actual logic with each, in order to parallelise our efforts as much as possible.

As oSpy does an ok job on parsing HTTP and even provides pretty-printing with syntax-highlighting of bodies containing XML, this wasn’t any problem. However, due to how much data is captured with a typical trace of Windows Live Messenger, with all the interception that is being done, scrolling through thousands and thousands of rows to find the ones I’m looking for isn’t exactly fun. Filtering out most of the stuff, like the WinCrypt API interception and output from WLM’s internal debugging infrastructure, wasn’t too good an option either because then I could miss out on some details surrounding the stuff I was looking for. Like for example some interesting debug message being output just before that could shed some light on what it was doing (and/or point me to the interesting bits of code for static analysis). I could’ve used the search function, but it just didn’t feel right in this case. Then I thought, “a feature to jump to the next packet row, and another one to jump to the next row being part of a transaction (i.e. HTTP), now that would be useful, and it’s not that much work to do it”. So I went ahead and implemented it, and after that going through the traces became a real breeze. I made the transcripts that Ali needed and put them online.

Now, what does making such a transcript mean in this case? Well, the idea was to take the HTTP headers of each interesting request, paste them into a text file, inspect the body and have oSpy pretty-print it, copy-paste that into the text file after the headers. Add a separator, i.e. along the lines of “\n—\n”, and do the same for the response. There were two different requests being made, and each was actually two request/response pairs in the first trace, as there’s a redirect when the client logs in for the first time (on a freshly created user account). This means that you have to repeat this boring operation 8 times for the first trace, and 4 times for the subsequent ones. I did it, but didn’t like it, as oSpy’s mission is to eliminate the boring tasks associated with reverse-engineering protocols.

Anyway, I handed off the transcripts to Ali, and mentioned briefly “now it would be really cool to have oSpy generate such transcripts automatically”. Then I thought, “hmm, this isn’t that hard to do, I’ve already got the visualization stuff in oSpy that visualizes TCP and MSNP2P transactions.. it’s easy enough to write an HTTP visualizer and have it pretty-print bodies containing XML automatically, using the same code that’s already in there”. I dug in, and a few hours later the feature was implemented and working like a champ. What surprised me was how little time was actually necessary to implement the feature itself. I didn’t time it, but if I were to guess I’d say 10-15 minutes. The most time-consuming part was actually adding an optional headline to the “VisualTransaction” widgets that the conversation view organizes in a timeline view, and to refactor some code here and there.

The next thing I thought about was, “ok, now a simple visualizer for the MSN switchboard protocol would be useful”. I hacked one together, and apart from a few protocol parsing fixes that I did to the existing code, the hack itself took only about 5-10 minutes to do. The unified diff of the first version can be seen here. A screenshot of this in action here.

Not very useful alone, basically almost the same as viewing the TCP session in the dump view except that you don’t get pretty-printed XML for the commands with XML in the payload, and fancy timestamps.

Anyway, as you might have guessed by now, there was a cunning plan behind all of this. What good is a timeline view with lots of fancy drawing if you can only visualize one protocol at the same time?

So to make a long story short, I implemented this and added a separate dialog to make it possible to customize how you want the visualization. A couple of screenshots here and here. And, better, you can see this in action through the screencast here.

Needless to say I’ve released oSpy 1.9.3 with all of these features at the usual place. 🙂


~ by oleandre on February 5, 2007.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: