The first article of the series 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 and 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 the application requires to run on a device will be bundled as one appx file. That means the 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 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 the Universal Windows Platform. 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 effort.
It is important to note that apps downloaded from Windows Store are DRM protected and encrypted. We need to ask developers for an unencrypted application version during a penetration test. This means our target application has to come from developers rather than Windows Store.
The following figure shows 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 port their apps already written for platforms such as Android and iOS.
From the two figures shown above, it is clear that developers have many options regarding what programming language to choose for their development.
Most of the time, 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 traditional Windows Apps we download from Store are built using C# and XAML. XAML (eXtensible Application Markup Language) is 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.
Aside from the technologies supported by the Universal Windows Platform, developers can still develop applications such as Windows Forms apps using old-school technologies.
The following figure shows the structure of the 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 things.
The Application is named 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 the 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, the developer may use a third-party JSON library if an application needs JSON parsing APIs. 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.
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 what 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 are two simple HelloWorld apps built for Windows Phone 8.1 and UWP.
The next article will discuss installation instructions for Windows Phone 8.1 and Windows 10. You don’t need to install them in this article. But, just in case 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 cases. We can rename the extension appx to zip and then unzip the files using traditional unzipping tools.
We have renamed the Windows Phone 8.1 app from HelloWorldInfosec8.1_18.104.22.168_x86_Debug.appx to HelloWorldInfosec8.1.zip.
Similarly, we have renamed the UWP app from HelloWorldInfosecUWP_22.214.171.124_x86_Debug.appx to HelloWorldInfosecUWP.zip.
As mentioned earlier, we can extract the contents of these apps using unzip command.
If you notice the extracted contents, some differences exist between 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 the UWP app.
This file is located in the current directory in the case of Windows Phone 8.1.
But, it is located in a subdirectory named entrypoint in the case of the UWP app.
Unlike Windows Phone 8.1 app, the 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 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 app’s isolated storage on the device/emulator, you don’t have full file system access.
|<Identity Name=”2341e0db-f991-4a6e-b0ee-db8cc46e3883″ Publisher=”CN=srini0x00″ Version=”126.96.36.199″ />|
Similarly, the following is the entry from the UWP app.
|<Identity Name=”59151709-e9e5-4d33-80e8-3f7303dee9b3″ Publisher=”CN=srini0x00″ Version=”188.8.131.52″ />|
Next, we have the DisplayName of the application and PublisherDisplayName, as shown below.
Following is the entry from Windows Phone 8.1 app.
Following is the entry from the UWP app.
Next, we have the application’s entry point and the executable file’s name. 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 the 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 the UWP app.
<Capability Name=”internetClient” />
You may notice the difference in the default capability for Windows Phone 8.1 app and the UWP app.
Microsoft’s documentation states, “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.
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=”10.0.0.0″ MaxVersionTested=”10.0.0.0″ />
This is added to UWP apps. The above entry shows that the app is built for the Universal Windows Platform, the minimum version it is built for is 10.0.0.0, and the maximum version it is tested on is 10.0.0.0. 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, some other elements 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 explored the appx files, followed by the AppxManifest.xml files.