With the release of windows 11, Microsoft announced the Windows Subsystem for Android or WSA. This following their previous release, Windows Subsystem for Linux or WSL. These enable you to run a virtual Linux or Android environment directly on your Windows Operating System, without the prerequisite compatibility layer provided by third-party software. In this post I’ll show you how to use WSA for Android mobile application pentesting, such that you can perform all of the usual steps using only Windows, with no physical Android device or emulator needed.
Experience
The WSA experience is great; when installing applications within WSA, they are automatically available to the Windows host. Likewise, all files and resources from the Windows host can interact with the Android Subsystem. In the past, Android emulation has been notoriously tricky. Third party applications always required you to place your trust somewhere else, and have always been slow and resource heavy.
This got me thinking about how WSA could potentially be used for Android security testing, without the need for an Android device. In order for this to be successful, I would need to be able to install, patch, and run Android applications, as well as intercept traffic… in same manner as on a physical Android device. This would serve two purposes – the first being removing the need for a potentially expensive device, and secondly creating a uniform and reproducible testing platform.
Step 1 – Prerequisite Applications
The following applications are often needed to conduct Android application security testing. Not all of them are not necessary for WSA itself, but are useful for Android testing and connectivity in general.
- Android Studio is a must for any Android testing. It provides a debugger, and a way to view the components of an APK in an easily digestible format.
- Android SDK Tools are needed for the Android Debug Bridge (ADB), which will be used to connect to WSA from the command line, transfer files, and install applications.
- We will be using Objection to patch APKs prior to installation as well as to perform some instrumentation of the target application. Objection has various prerequisites which are mentioned in the Wiki and should be installed as well.
- Windows 11 – with the virtual machine platform enabled in the Windows Features settings.
- Lastly, we’ll be needing Python to run objection.
On my system, I added the paths to all of the above-mentioned tools to my Windows environment variables so that they can be run from any directory. I recommend this for a smoother experience. It can be done by clicking Start, and then typing environmental variables, and editing the system-wide variables.
Step 2 – Installation
Microsoft has detailed instructions on how to install “base” WSA here.
At the time of writing this post, in order to install WSA directly from the Microsoft Store, you need to be part of the Windows Insider Program, and running on the Beta channel. This will change in future releases. It is also currently only possible to install a small subset of applications from the Amazon Appstore, which is installed from the Microsoft Store here – it’s just stores all the way down!
These limitations don’t help us when a client sends an APK or AAB bundle, so we need a way to side load applications, the same as we would on a regular physical device. Thankfully this is made possible following my second installation method below.
Installation method 1 – Limited WSA
For demonstration purposes, let’s see how to install Microsoft’s limited WSA distributed through the insider program. We won’t modify it to allow Google Play Services to work, or to side load applications, that’s done in the next section, and you’ll have to uninstall this. So this is really just to show the difference. The MSIXBundle that you will get when signing up for the Insiders Program file can be discovered using this service. This site is a link aggregator for downloading directly from the Microsoft store. Credits to RG_Adguard for this.
Within the URL field, enter the following (which is the URL for the Amazon Appstore):
https://www.microsoft.com/store/productId/9P3395VX91NRThen select the SLOW channel and hit search. This should reveal the URL to download the WSA application directly from Microsoft.
Once downloaded, open Windows Terminal as Administrator and run the following:
Add-AppxPackage -Path "C:\path\to\wsa.msixbundle"This should then give you the Windows Subsystem for Android in your Windows start menu.
Once the application is open, you’ll see a couple of options. The first is choosing to have the subsystem resources available as needed, or continuously available. This is a personal preference. I chose to have them running continuously, as I have resources to spare.
The second option is not personal preference. You MUST enable developer mode within WSA, or you will not be able to connect via the Android Debug Bridge or ADB.
You will see that you currently have no IP assigned, and this is expected. Even though the WSA settings are open, WSA itself is not necessarily running.
In order to actually start WSA, you need to click the open icon next to the FILES option, which will present you with a very basic Android file browser GUI.
At this point you’ll have a basic WSA installation up and running. However, it is limited to the Amazon app store, and that is not very useful for what we want to do!
Installation method 2 – Google Play enabled WSA with root
Let’s redo the installation step-by-step using a method which provides more functionality, such as the ability to install applications directly from Google Play within Windows, the ability to sideload applications, and the ability to Root your WSA “device”.
Firstly, if you were previously playing around with WSA, or you followed my initial method, you’re going to need to uninstall all traces of WSA from your system.
Next, Open your Windows settings and enable Developer Mode within Windows itself, as opposed to within WSA (although both are needed). This will allow you to install third party application bundles from outside of the Microsoft Store.
Next you’ll need to create and download a patched WSA installer and platform tools. This can be done by following the description on the Github repo here. In essence you will fork the repo, and specify the version of the open source Google Play Store you want by name, based on OpenGApps. A small selection of the different variants descriptions are below:
- Pico: This package is designed for users who want the absolute minimum GApps installation available.
- Nano: This package is designed for users who want the smallest Google footprint possible while still enjoying native “Okay Google” and Google Search support.
- Stock: This package includes all the Google Apps that come standard on Pixel smartphones.
Once forked, click Actions, and click on the Build WSA workflow, specifying the OpenGApps version you selected from above. In summary, the workflow will:
- Download WSA from the Microsoft Store (via RD-Adguard)
- Download Magisk from the Canary branch on the Magisk repo
- Download your specified version of OpenGApps
- Unzip the OpenGApps
- Mount all images
- Integrate OpenGApps
- Unmount all images
- Shrink the resultant image
- Integrate ADB
- Package everything into the final zip file.
You can see this workflow in action in this file.
You will see a download link included for a specific version of Magisk in the build options, which currently works 100% with WSA. Magisk is an application used to Root android devices. Rooting is NOT necessary for patching or intercepting to work, but does provide extra functionality which may be useful to you.
Extract the resultant WSA-with-magisk-GApps.zip contents and open a Terminal window as Admin within the unzipped directory. Then run:
Add-AppxPackage -Register .\AppManifest.xml
You can now re-open windows Subsystem for Android from the Windows Start menu. You’ll need to enable Developer Mode from within the WSA settings, and click on the open files button, just as before.
Back in the terminal, we can now run ADB (either directly from the platform tools directory, or from any directory if you modified your environment variables). Typing ADB devices will give a list of all the current available devices which will initially be empty. We’ll fix that in a moment.
Looking at the WSA settings, an IP address should now be configured.
We can connect to this “device” using ADB connect `IP`. We can then re-list the devices and confirm we have connectivity.
Installing applications is as simple as ADB install ‘APK Name’. We will be installing Magisk in this manner with ADB install magisk.apk. Once installed, click on Start and search for Magisk. As WSA shares resources with Windows, Magisk can be opened from the Start menu as if it is installed in windows directly, however it is running seamlessly under WSA.
In the terminal, type ADB shell to gain access to the WSA “device”. We can confirm the current user with whoami.
Typing su to become root will result in a pop-up within Magisk, asking to allow root access. Once allowed, the SuperUser tab within Magisk will show that we have granted root access within the ADB shell.
We can confirm we have rooted the device with whoami.
From this point, we have full read/write access to the WSA filesystem.
Step 3 – Objection
Objection works in much the same way from this point. Simply running objection patchapk -s 'sourceapk' will allow ADB to determine the device architecture the same way as it would from a mobile device via USB. I will be using the “Purposefully Insecure and Vulnerable Android Application” (PIVAA) for demonstration purposes.
Once patched, install the application with
adb install .\pivaa.objection.apk
As before, it is now available directly within Windows. However, starting the application will cause it to “pause” until we use Objection explore to hook into the Frida server.
You will see this device show up as a “Pixel 5”, which seems to be the archetype for the virtual device, and may change in future updates. It’s important to note that no USB, nor a physical Pixel 5 are involved.
I now had a working WSA installation, a rooted device, patching with Objection, and hooking into running patched applications with Objection. The main question that I was faced with at this stage was how to do the final step – intercepting traffic with Burp Suite.
Step 4 – Intercept with Burpsuite
As I had no way of seeing the virtual network settings or installing a certificate authority on the device, I decided to try installing an Android Launcher. A launcher is similar to a desktop environment on a Linux distribution, and is what you see when you unlock your physical android device. Some popular ones include Niagara, Nova, Lawnchair, and Stock launchers from the likes of Google and Samsung.
After trying multiple launchers, third party settings applications, and Windows specific proxy applications, I had the idea that the launcher with the highest probability of being compatible was the Microsoft Launcher. You can install it directly onto the device by using OpenGapps and using the official play store link. I opted to side load the APK from here (however multiple other APK mirroring sites exist, so use your preferred one), and installed it with adb install. This gave me exactly what I was looking for, a settings application.
Within the Network and Internet settings, I finally had a Virtual WiFi adapter, which I was able to set proxies for.
When in the VirtWiFi settings, I was able to select the Advanced options to install certificates. Knowing this, I generated a certificate from Burp Suite and moved it to the “device” using:
adb push .\burpwsa.cer /storage/emulated/0/DownloadI knew I had access to all folders after rooting with Magisk, but the Downloads folder was visible within the files application of WSA itself, so I selected this as the destination directory.
Installing the certificate needed to be done through the settings however.
Once installed, I set my proxy listener in Burp to that of my host Ethernet IP, and a port of my choosing as per usual.
Within the VirtWifi I edited the proxy to have the same settings.
Now when running the PIVAA application, hook into it with Objection as before, however this time specifying Android SSLPinning Disable as the startup command, I was able to intercept the traffic from WSA.
Summary
We can see that using the initial method, we’re severely limited to what we can do, but there’s always workarounds and more we can do!
Digging a bit deeper, we’re able to install WSA without using the Microsoft store, and without being on the Windows 11 Beta program, but that wasn’t quite where we needed to be.
Taking it one step further allows us to install any application we want, and obtain root privileges on WSA itself, which is a critical step in terms of security testing Android.
The final step from here, which undoubtedly took the longest, was figuring out how to intercept traffic from this virtual device in Burpsuite, in order to perform dynamic testing, and modify the data in transit, but with this done, there is now no longer a need for a physical android device to perform security testing on Android applications.
Please feel free to reach out to me with any questions you may have. This is still a new and evolving technology, and I hope to add to this as new methods emerge.