Introduction and Background:

In the First article of the series, we have covered the introduction and background required to start learning Windows Mobile Application Penetration Testing. We have also seen the requirements for setting up Windows Phone 8.1 emulators as well as Windows 10 mobile emulators. In this article, we will discuss the basics of Windows Phone 8.1 applications and UWP applications.

How are apps distributed?

Windows Phone 8.1 and UWP apps are distributed as appx files.

When developers create App Packages, all the files required by the application to run on a device will be bundled as one appx file. That means appx file comes as a bundle of the main executable file (entry point), referenced DLL files, resources such as images, the AppxManifest.xml file, etc.

The location of these files mentioned above may slightly differ in Windows 8.1 and UWP.

Before Windows 8.1, application packages used to have XAP file format. appx format has been introduced in Windows 8.1 as a part of Microsoft’s journey towards the convergence. This means appx files can be run on Windows Phone 8.1 as well as Desktops running Windows 8.1. The convergence has been fully accomplished with Universal Windows Platform. Now, these appx files can be run on multiple platforms such as Windows 10 Desktops, Windows 10 Mobile, Xbox, IoT devices, etc. with minimal changes.

If an app is developed for Windows Phone 8.1, it can still be installed and run on Windows 10 mobile.

However, porting Windows Phone 8.1 apps to UWP is also possible. If a developer has an application already written for Windows Phone 8.1, it is possible to port it to UWP with minimal efforts.

It is important to note that apps downloaded from Windows Store are DRM protected and encrypted. During a penetration test, we need to ask developers for an unencrypted version of the application. This means, our target application has to come from developers rather than Windows Store.

Application Development:

The following figure shows that various programming languages that can be chosen by developers for Windows Phone 8.1 app development.

As you can see in the following figure, Windows Universal Platform also provides support for multiple programming languages along with bridging technologies. These bridging technologies help developers to port their apps already written for other platforms such as Android and iOS.

From the two figures shown above, it is clear that developers have many options when it comes to what programming language to choose for their development.

Most of the times, it is the type of application that decides which programming language/technology to choose though the choice is left to the developer.

Following are some common practices we see.

If it is a gaming application, it is common to choose C++ and DirectX.

Most of the traditional Windows Apps we download from Store are built using C# and XAML. XAML (eXtensible Application Markup Language) is something similar to HTML for web applications. It is used to build the user interface in Windows Applications, and the processing will be done by C#. Some apps are also developed using XAML with a combination of Visual Basic rather than C#.

The test applications we use in this series are also built using C# and XAML.

It is also possible to develop apps using HTML5, JavaScript, and WinJS. Another option is to build hybrid apps using a combination of technologies like HTML5, JavaScript, and C#.

Aside to the technologies supported by Universal Windows Platform, developers can still develop applications such as Windows Forms apps using old school technologies.

The following figure shows the structure of Windows Phone 8.1 application in the solution explorer of Visual Studio. This app is created using C# and XAML.

Though this is a simple HelloWorld application with limited functionality, it is enough to explain the things.

The Application is named as HelloWorldInfosec8.1 since it is built for Windows Phone 8.1 and we have another app for UWP.

Properties | AssemblyInfo.cs contains some basic information about the assembly. This information includes assembly title, version, etc.

References contain the references as the name suggests. If we add any third party references to our current project, they will also be available in this directory. For example, if an application needs JSON parsing APIs, the developer may use a third party JSON library. When he adds a reference to this library, this will appear under References. The following figure shows Newtonsoft.Json library added under References.

Assets directory contains resources such as images.

App.xaml is the XAML page for App.xaml.cs. This App.xaml.cs file contains the code equivalent to main() function, which is the entry point for the app.

MainPage.xaml is the file that contains the user interface created for this app. MainPage.xaml.cs contains the C# code that performs the actual processing of the application.

Finally, Package.appxmanifest is the file that contains information such as application identifier, publisher name, capabilities used by the application, etc. In other words, Package.appxmanifest file is similar to AndroidManifest.xml file we see in Android Apps.

Similarly, the following figure shows the directory structure for a UWP app.

As you can see in the above figure, most of the structure is similar to Windows Phone 8.1 apps. Additionally, we have a file named project.json. This is used by UWP projects to manage the NuGet packages installed.

Structure of the bundled packages:

This section discusses, how a bundled application looks like when you get it from the developers. You can download the test applications shown here from the downloads section.

The test apps provided are two simple HelloWorld apps built for Windows Phone 8.1 and UWP.

Installation instructions for both Windows Phone 8.1 and Windows 10 will be discussed in the next article. You don’t need to install them in this article. But, just in case if you want to know what these apps do when they are run, here are the details.

When these apps are installed and launched on an emulator, they show the following screen.

When we click the Say Hello! button, it displays simple text as shown in the figure below.

This is all the functionality the apps have.

Similar to Android and iOS, these appx files are nothing but zip files.

Following is the app built for Windows Phone 8.1

Following is the app built for UWP

As you can see in the above figures, we have .appx files in both the cases. We can rename the extension appx to zip and then unzip the files using any traditional tools used for unzipping.

We have renamed the Windows Phone 8.1 app from HelloWorldInfosec8.1_1.0.0.0_x86_Debug.appx to as shown in the figure below.

Similarly, we have renamed the UWP app from HelloWorldInfosecUWP_1.0.0.0_x86_Debug.appx to as shown in the figure below.

As mentioned earlier, we can extract the contents of these apps using unzip command as shown in the figure below.

Similarly, the following figure is for UWP app.

If you notice the extracted contents, there are some differences between both the apps’ extracted contents.

For example, the location of the main executable file in Windows Phone 8.1, which is the Entry Point for the app, is different than that of UWP app.

This file is located in the current directory in case of Windows Phone 8.1 as shown in the figure below.

But, it is located in a subdirectory named entrypoint in the case of the UWP app.

Unlike Windows Phone 8.1 app, UWP app is bundled with many dll files.

Apart from these, the manifest file now has a different name than what we have seen in Visual Studio. If you notice, it is AppxManifest.xml now.

The contents of AppxManifest.xml may provide interesting information during a penetration test.

Let us take a look at some of the elements in AppxManifest.xml file.

The following entry from Windows Phone 8.1 app provides the application name, Publisher and the app version. The name represents the unique package name of the application. Each app will have a unique package identifier when it is developed. This identifier is useful in some cases. For example, while exploring the isolated storage of the app on the device/emulator, where you don’t have full file system access.

Ethical Hacking Training – Resources (InfoSec)

<Identity Name=”2341e0db-f991-4a6e-b0ee-db8cc46e3883″ Publisher=”CN=srini0x00″ Version=”″ />

Similarly, the following is the entry from UWP app.

<Identity Name=”59151709-e9e5-4d33-80e8-3f7303dee9b3″ Publisher=”CN=srini0x00″ Version=”″ />

Next, we have DisplayName of the application and PublisherDisplayName as shown below.

Following is the entry from Windows Phone 8.1 app.


Following is the entry from UWP app.


Next, we have the entry point of the application and name of the executable file. This information can be useful if there are multiple assemblies found in the unzipped app and if you are looking for the main executable to analyze.

Following is the entry from Windows Phone 8.1 app.

<Application Id=”App” Executable=”HelloWorldInfosec8.1.exe” EntryPoint=”HelloWorldInfosec8._1.App”>








Following is the entry from Windows Phone 8.1 UWP.

<Application Id=”App” Executable=” HelloWorldInfosec.exe” EntryPoint=”HelloWorldInfosec.App”>








Finally, we have Capabilities section. This section is interesting as it tells us what are all the capabilities used by the app. This is similar to <uses-permission> tag in AndroidManifest.xml file. By default, all the apps will have Internet capability. The following entry is from Windows Phone 8.1 application.

<Capability Name=”internetClientServer” />


The following entry is from UWP app.

<Capability Name=”internetClient” />


You may notice the difference in the default capability for Windows Phone 8.1 app and UWP app.

According to Microsoft’s documentation, “There are two capabilities that provide different levels of access to the Internet and public networks.

The internetClient capability indicates that apps can receive incoming data from the Internet. Cannot act as a server. No local network access.

The internetClientServer capability indicates that apps can receive incoming data from the Internet. Can act as a server. No local network access.

Most apps that have a web service component will use¬†internetClient. Apps that enable peer-to-peer (P2P) scenarios where the app needs to listen for incoming network connections should use¬†internetClientServer. The¬†internetClientServer¬†capability includes the access that the¬†internetClientcapability provides, so you don’t need to specify¬†internetClient¬†when you specify¬†internetClientServer”.

When the end user installs the application, all the permissions required by the application will be shown as follows.

If you have closely observed the differences, there is another entry in UWP app’s AppxManifest.xml file as shown below.

<TargetDeviceFamily Name=”Windows.Universal” MinVersion=”″ MaxVersionTested=”″ />


This is added to UWP apps. The above entry shows that the app is built for Universal Windows Platform, the minimum version it is built for is and the maximum version it is tested on is This also means that, when a developer ports his app from Windows Phone 8.1 to UWP, he has to add this entry into his Package.appxmanifest.

Apart from the elements we have explored in these simple applications, there are some other elements that may help us during analysis. Examples include, <FileTypeAssociation> , <Protocol> etc. We will discuss them when we come across applications that use these elements.


In this article, we have discussed how Windows Phone 8.1 apps and UWP apps are built. Next, we have explored the appx files followed by AppxManifest.xml files.