Note: This was originally posted by me on the Intrepidus Group blog ( on September 16, 2011. Lightly formatted and reproduced here for posterity.

With over 30,000 apps in the marketplace within a year of launch, Microsoft’s Windows Phone 7 platform seems to grabbing consumer attention slowly but steadily. Though the installed user base is nowhere close to that of Android or iOS, Gartner’s predictions notwithstanding, in the last few months we’ve seen an increasing interest from companies on this new mobile platform. One of the questions we hear a lot is how we go about pentesting WP7 apps, and what tools their QA teams should be looking at. This post, and others in this series, is aimed at answering some of these questions.

Application Package Structure

WP7 apps are zip files renamed as “.xap” archives, and can be opened by standard archival programs such as 7-Zip and WinRar. Rename the application package “MyApp.xap” to “”, and then unzip the archive. Generally, the following files will be found inside application package:

  • AppManifest.xaml – Lists assemblies required by the application, application code entry point, runtime version.
  • MyApplication.dll – Main application DLL. This contains the application logic and embedded resources like XAML layouts and images.
  • Background.png, ApplicationIcon.png – Images for the application
  • WMAppManifest.xml – Lists capabilities requested by the application, application GUID, application XAML entry point, app icons and live tile/hub bindings.
  • WMAppPRHeader.xml – DRM header for app (in case of download from Marketplace).
  • WPInteroptManifest.xml* – Optional. If it exists, the application is probably making use of interop services.
  • MyInteropDll.dll* – Optional. If it exists, the application is probably making use of interop services.
  • System assemblies – Default WP7 assemblies, e.g. Microsoft.Phone.Controls.dll, System.Windows.Controls.dll, etc.
  • Images/ - Application icon / app bar images

* Note – With the Mango update release, interop services will probably be blocked. This provided the COM interoperability bridge, allowing applications to call unmanaged code from managed binaries. This shouldn’t concern you unless you develop OEM or mobile operator apps, as Microsoft restricts use of the interop capability.

Many applications also have accompanying resource folders, which hold static content like configuration files, sounds, etc., which might be worth looking at.

The WMAppManifest.xml file lists the capabilities requested by the application, which should be as minimal as possible. Capabilities define what resources an app requests access to, similar to permissions in an Android app. The capabilities required by application, based on the libraries it references, can be determined by using the Windows Phone Capability Detection Tool, packaged with the WP7 SDK.

C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.0\Tools\CapDetect> CapabilityDetection.exe Rules.xml MyApplication.dll

The main point of analysis is the MyApplicationName.dll file. This contains the primary application logic. Though theoretically any .NET language is supported, typically WP7 applications are written in C# and compiled as managed binaries. Though WP7 apps may be relatively new, the .NET language has been around a while, and a number of tools exist to aid in reversing .NET binaries.

Decompilation and Static Analysis

After extracting XAP contents, identify the main DLL file. This is usually the assembly pointed to by the “EntryPointAssembly” field in AppManifest.xaml. The DLL is a .NET managed code binary, and depending on any obfuscation used, can be decompiled back into C# by tools like .NET Reflector and dotPeek.

  • .NET Reflector – This is my preferred tool for decompilation of .NET binaries. The interface is simple and easy to use – however, I find myself getting better results with dotPeek (see below). The standard version of the tool costs $35, though a 14-day evaluation license is available.
  • dotPeek – This is a recent tool from JetBrains, still in development. It’s free, and managed to decompile some binaries that Reflector bailed out on. I’m expecting good things from this.

I’ll use .NET Reflector below.

Once the target binary has been identified, in our case MyApplication.dll, load it in .NET Reflector by clicking on File -> Open and selecting the file. The tool may complain about missing assemblies; this happens because it wasn’t built to support WP7 and cannot resolve the assembly names automatically. Whenever it complains about an assembly, for example “could not find Microsoft.Phone.dll”, it also offers the user a chance to load the file manually. Click on the “…” and browse to “Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone”, where you will find all the system DLLs that are generally used by WP7 applications. You may need to install the WP7 Developer Tools SDK ( if you don’t have that folder already. If you’re using a 64-bit flavor of Windows, replace “Program Files” with “Program Files (x86)”.

Right click the assembly on the tree to the left and click on “Disassemble”. The tree should now be expandable, and will have two nodes, “MyApplication.dll” and “Resources”. Resources contains all the embedded resources for the app, like XAML and image files. These can be extracted and saved for perusal – sometimes, the XAML files have interesting tidbits left by the developer. Double click the resources file to load it into the right tree, then right click -> “Save As” on the resource you want to save.

Decompiled xap with namespaces obfuscated

[note: I couldn’t retrieve the screenshot :(]

The screenshot above shows a typical decompiled binary. I’ve obfuscated the namespace, since it’s a real app in the Marketplace. The second node contains reference points to system DLLs, and the application code namespaces. This is essentially the meat of the application – it represents the code tree of the application and allows to look for bugs in the decompiled code. Expand the code tree and click on any node to view the source. The structure is DLL -> Namespace -> Class -> Class Members. It’s more expedient to view it by class – click on the class you want to investigate, and you can see declarations for all methods and variables used by the class. Click on “Expand Methods” on the right hand pane to view method definitions.

Clicking on “Tools” -> “Search” on the main window bar will bring up the search interface. Type in the desired search string in the search box, results should dynamically update. Results can be refined by type, member, string/constant, or exact match by the little icons to the right of the search bar.

That’s all I have this time – I’ll talk about exploring Isolated Storage, interop DLLs, analyzing network traffic, and other points of interest in the next post.