I was curious about possible ways to see what my Windows Phone 7 handset is actually doing whenever I am opening an application or service. Not that I am interested in getting the actual process behind specific actions but rather seeing the web services and sites accessed.
My idea for this was quite simple – I needed WireShark to monitor the traffic and a phone connected to the machine. The connection should not be physical, but rather wireless – through an ad-hoc Wi-Fi connection so that everything that is called from inside Windows Phone 7 OS (web-wise) goes through the inspecting machine first.
My initial thoughts were to build the link like this:
One flaw of this idea was the fact that since I am already connected to a wireless network on my laptop, I am not able to share the same network with default Windows tools – a wireless connection can’t be set to act as an ad-hoc connection (therefore creating a duplicate wireless network). I would have to use some hotspot software but since I don’t really want lots of third-party components installed on my machine, I decided that I can go another way around and since I have an Ethernet output anyway, the new link was decided to be like this:
This is a more common connection sequence so it worked pretty well. What I noticed is sometime my Windows Phone 7 device (a Samsung Taylor) had some troubles connecting to an ad-hoc network while at the same time it was able to instantly connect to the “full-sized” Wi-Fi connection. What worked in my case is connect to an actual Wi-Fi network first and then switch to the shared one.
Once connected, start WireShark and select the correct interface for which traffic will be captured. In my case, I had only two – the actual Ethernet adapter and the wireless link represented by an interface called Microsoft:
To test the actual capture capabilities, I tried opening the Facebook application and see if there is any outgoing traffic. The first sign that tells that the WireShark is able to track device web input/output is the device name (in my case – the name of the manufacturer) listed as the source:
Once this is captured, you can proceed with monitoring traffic. Generally, if you do not want to be swamped with info about transported packets, set the filter to HTTP protocol only and you will see a bunch of GET and POST request – exactly what’s needed to track down the accessed locations.
After working with this method a bit, I found out a couple of things about the Windows Phone 7. Here is what’s interesting:
- Internally, the platform is named Windows Mobile 7.0 and is referenced so in platform-specific URLs (e.g. connected to the Marketplace).
- The device manufacturer is identified and is sent to the Zune service whenever the user accesses the marketplace.
- The carrier is also identified and the ID is sent to the Zune service whenever the Marketplace is accessed.
- Zune Marketplace information (e.g. related to application categories), in fact, is passed to the phone as a set of ATOM feeds that are deserialized internally and structured as separate models.
Here is where I get the information from:
Needless to say, I understand why the carrier and device manufacturer are used. There are carrier and manufacturer-specific sections in the Zune Marketplace – Samsung Zone (for Samsung devices) and AT&T AppCenter (for those who have selected AT&T as the primary carrier).
Developer wise, WireShark can also be used to capture transported (via HTTP) content. You can check that by opening the File menu and going to Export > Objects > HTTP:
You will get an entire list of object WireShark detected that can be saved locally for analysis.