So here’s the thing. The Internet is AWESOME for finding articles and videos on hacking mobile apps and APIs. The problem is, the well-indexed stuff is… well… just wrong.

Let me explain.

When you first start looking at hacking mobile APIs, you will find guidance on how to do it on Android using an Android emulator. 

That is great advice. 

But it quickly falls apart when you realize that there are dozens of Android operating system versions, along with hundreds of phones that use different release versions. In fact, most of the API hacking guidance doesn’t actually work unless you select really old versions of Android phones. In many cases, this just isn’t compatible with the latest versions of the modern apps you want to attack.

In this article, I will fix that. I will show you how to circumvent the security restrictions of modern Android operating systems like Android 14 and 15 and get it working with Burp Suite.

Let’s get to it.

So what’s the problem?

Since the release of Android 7.0 (Nougat) in 2016, the operating system no longer allows user-installed Certificate Authority (CA) certificates. This change was introduced to enhance security and prevent user-installed CAs from compromising the security of apps that depend on encrypted connections.

The problem is, that made it difficult to install the Burp Suite self-signed root CA certificate that allows Burp to intercept and proxy traffic from mobile apps.  

Side Note: This is why so many articles and videos show the content creator/hacker-influencer picking an older Android device. They usually say it’s because “it’s more stable”. The reality is that they just didn’t know or want to show you the more complex steps to make it work by injecting it into the System certificate store in /system/etc/security/cacerts.

Then it all changed…

And now for a twist. 

As of the release of Android 14, Google has created an even stricter certificate store segregation. Using their new Android Pony EXpress (APEX) container format, they have moved certificate trust into a container so that you can no longer inject directly into the file system. This blocks the normal methods of injecting into the system store. 

In fact, you have to jump through hoops to make it work now on modern Android devices. Let me show you how. 

Setting up your mobile hacking environment   

To hack mobile APIs on modern versions of Android (e.g., 14, 15, etc.), you will need to install and set up a few things. 

Step 1 – Install an Android Emulator and Tools

While a lot of guidance says to use Genymotion because it’s so easy to use, I want to discourage you from doing that. While the emulator itself is pretty good, to use modern versions of Android in a commercial environment (e.g., bug bounty / security testing) you must pay for their business license, which is over $400/year. 

There is no need for that cost. Google offers Android Studio to developers for free, and you can use it too. In fact, you will install Android Studio to get all the command-line tools and emulators but never have to create or open a project with the product. You just need access to the Virtual Device Manager, which we will get into shortly.

So go ahead, install it. 

TIP: If you are using Apple silicon (MacOS on M1/M2/M3), do NOT use Brew to install Android Studio. The cask is designed to install the Intel version of the product. You want to use the ARM version, which gives you native emulation with qemu, which is much faster. Just go to the Android Studio download page and select “Mac with Apple chip” when prompted.

Step 2 – Setup an Android Emulator

Now that you have Android Studio installed, run it. Its initial screen will ask you to create or open a project. 

Ignore all that.

Instead, click the “More Actions” link and select “Virtual Device Manager.”

Here, you can manage the emulators you want to build. The system usually comes preconfigured with a single phone emulator, but I don’t want you to touch that. 

We will build our own instead.

Click the “+” button on the top left. It will load the “Select Hardware” dialog.

I recommend you select “Pixel 8”. It defaults with the Google Play store pre-installed and a more modern Android 15 (as of this writing).

Hit “Next” and select the System Image. By default it will be API 35 (Android 15), and will select the correct chipset for your current device. In these screenshots, you will notice it shows arm64-v8a, as I am writing this on my MacBook Air, which uses Apple silicon.

Hit “Next” again. Give your Android Virtual Device (AVD) a name. I’d recommend something simple like “Pixel 8”. YMMV. 

We aren’t finished yet though. To help us with some later steps, we want to adjust the hardware profile to ensure the emulator starts the phone from a cold state. 

Here’s how to do that.

Hit the “Show Advanced Settings” button. Scroll down to the section titled “Emulated Performance” and choose the “Boot Option” of “Cold boot.” 

Now click “Finish”. You’ve created your base image to hack with. You can close Device Manager, and Android Studio completely. From now on, we will use the command line to do stuff.

Step 3 – Setup Android SDK Tools

By default, during the installation of Android Studio it will install the Android SDK, which includes their platform tools, and the emulators. However, these tools aren’t directly exposed to you until you set up your paths correctly.

As this will differ between Windows, Linux, and Mac I won’t provide detailed instructions. Just ensure you add the Android/sdk/platform-tools and Android/sdk/emulator directories to your path. 

As an example, here is what I added to my .zshrc on my Mac:

export PATH="$PATH:/Users/silverstr/Library/Android/sdk/platform-tools:/Users/silverstr/Library/Android/sdk/emulator"

Ensure you reload your environment (aka source ~/.zshrc or equivalent) so the new path can be loaded.

YMMV. Just make sure you can type adb --help and emulator --help successfully.

Step 4 – Start your Android device for the first time

With the Android emulator setup, we want to start it. But let’s first make sure we can see it. Using Android’s emulator CLI tool, let’s see if we can list all the emulated devices it knows of:

emulator -list-avds

You should see your new Android device listed there.

Now to start it:

emulator -avd <name_of_device>

At this point, you have your Android device up and running. You can use the Android Debug Bridge (ADB) to get yourself a shell on the device. Open a new console window and type this:

adb shell

At this point, a lot of guidance on the Internet tells you to “su” into root to get full access to the device. But you can’t do that on a modern version of Android. Permission will be denied.

This is where we need to “root” the device to give us these kinds of privileges.

Step 5 – Install rootAVD and root the device

Since Android doesn’t ship with an environment that allows root access directly, we will have to modify the device somehow. This is called “rooting” a device and in the past required complex exploitation to do so.

But it’s much easier now, thanks to Magisk and a neat script called rootAVD. 

Magisk is the “magic mask” that offers an environment that provides root access to Android and offers modules that can reconfigure and manipulate how Android runs. rootAVD leverages Magisk to root a running AVD to give you the access that you need.

You can download/clone rootAVD directly from GitLab using Git:

git clone https://gitlab.com/newbit/rootAVD.git

Once downloaded, you will find a rootAVD.sh and rootAVD.bat in the main directory. Run the appropriate script for your operating system.

By default, it will dump example commands specifically for your system (chipset, emulator version, etc). This is how it looks on my machine:

Select the first example, and rerun rootAVD with that argument. 

./rootAVD.sh system-images/android-35/google_apis_playstore/arm64-v8a/ramdisk.img

This will kick off the rooting process for your running AVD. When it’s done, it will shut down your emulator.

Now restart the AVD using the previous command I showed you. Jump into the other console window where you were running adb, and reconnect to the shell. Now type “su” and watch what happens inside your Android device.

It will prompt you to grant superuser privileges. Click “Grant”.

Once complete, tab back to your console window and notice you are now root on the phone.

At this point, you have a working Android virtual device that is rooted, which will allow us to configure it to hack with Burp.

Setting up Burp Suite to work with modern Android

By default, the Burp Suite attack proxy is configured to capture loopback/localhost traffic on port 8080. To allow it to work with your Android virtual device, you need to create a new listener or alter the default one to listen on all interfaces or a specific one that both Burp and Android can communicate on (e.g., your primary ethernet or Wi-Fi network interface).

The easiest way is to edit the default listener and set it to “all interfaces”. You can do this by going to Settings > Tools > Proxy and finding the “Proxy Listeners” section. Click “Edit” and then change the radio button that allows you to “Bind to address”. It will look something like this:

At this point, Burp Suite will be able to intercept requests coming through the proxy. The problem is that Android won’t trust it. 

We need to grab Burp’s CA certificate and load it into Android in a method it accepts.

Here’s how.

Start by downloading the cert directly from Burp:

curl -s -L http://localhost:8080/cert -o burp.der

Android will expect the certificate to be in a PEM format, so we need to convert what Burp gave us. We can do that with OpenSSL tools:

openssl x509 -inform der -in burp.der -out burp.pem

burp.pem is all you need. Don’t let anyone tell you differently.

Burp.pem vs 9a5ba575.0

I am going to squash all the confusion on Burp certs on Android. 

Most guidance on the Internet will tell you Android requires that you rename the PEM file to a hash of some of the subject metadata. In fact, as PortSwigger hasn’t changed that metadata in a long time, I can tell you that the file name is 9a5ba575.0. 

The guidance isn’t wrong, but it’s moot.

Since Android 14, even with root access, you cannot successfully inject that file into the system. Even though you can write to /system/etc/security/cacarts, that ISN’T where the operating system gets its CA certs from. 

They are actually stored in /apex/com.android.conscrypt/cacerts, which is a read-only mount point.

This is that secure container I was talking about earlier. 

So what are we to do?

We need to alter the Android virtual device a bit more to get it to work with Burp Suite.

Setting up Android to work with Burp Suite 

OK, so we need to get Android to trust Burp’s CA certificate. But we can’t write to the apex container. 

What do we do?

This is where Magisk is helpful. Because we can load custom modules into the framework, we can leverage a special module that the NCC Group has built called ConscryptTrustUserCerts. This module runs as a service to copy Trusted User certificates and place them everywhere Android needs them for system-level trust… including the APEX secure container.

So download the module zip file from the Releases tab in Github:

curl -s -L https://github.com/nccgroup/ConscryptTrustUserCerts/releases/download/v0.1/ConscryptTrustUserCerts.zip -o ConscryptTrustUserCerts.zip

Now we need to upload the certificate and the Magisk module to the Android device. Luckily, ADB can do this for us. Let’s put it in the primary Download folder:

adb push burp.pem /sdcard/Download
adb push ConscryptTrustUserCerts.zip /sdcard/Download

With the files on the phone, now we can go to the device, and install everything.

Step 1 – Load the Burp CA certificate into the Trusted User Store

Within the Android virtual device, click on the Settings app.

Search for “Trusted credentials”. When found, click on it. This will load up the “Encryption & credentials” settings page.

Click on “Install a certificate”.

Select “CA certificate”. When prompted about the fact “Your data won’t be private”, click “INSTALL ANYWAY”.

Click on the menu with three horizontal lines at the top left (sometimes called the hamburger menu) and select “Downloads.” You should see the two files we uploaded to the sdcard with the Android Debug Bridge.

Click burp.pem and the CA cert will be installed.

You can verify that by hitting the back arrow, selecting “Trusted Credentials”, and clicking the User tab. You should see the Portswigger certificate installed.

Step 2 – Install the ConscryptTrustUserCerts module

With Burp’s CA certificate installed in the Trusted User store, we need to move it to the System store. This is where the NCC Group’s Magisk module comes into play. To access the Magisk framework, we simply need to click on its icon.

That’s right. There’s an app for that.

You may need to install some bits the first time you run it. You may notice the “Modules” tab on the bottom right is grayed out and inaccessible. 

Let’s fix that.

If under the “Magisk” section it says “Installed: N/A” and that the App versions don’t match, click the “Update” button in the Apps section, and click the slider button to “Allow from this source”.

Now hit the back arrow to return to the app’s homepage and hit “Install”. When prompted, select “Direct install”; when it completes, hit the “Reboot” button to reload everything.

Once the device reboots, click on the Magisk icon again. You will notice Magisk will now show as installed, and the Modules tab on the bottom right is now accessible.

Click the “Modules” tab.

Click “Install from storage”.

Select the module you uploaded to the sdcard. When asked to confirm installation, click OK.

Once it completes the installation, you will be asked to reboot. Click Reboot.

After the Android device reboots, head back into Settings and find the Trusted Certificates section. You can now see the Portswigger’s Burp CA certificate in both the User and System stores. 

Step 3 – Configure Android to proxy through Burp Suite 

Go back into Settings, select “Network & internet”, and click on “Internet”.

Click on “AndroidWifi”, and then click the pencil to edit the configuration.

In the Proxy drop-down menu, select “Manual.” Enter the IP address of the host running the Burp Suite attack proxy and set the port to 8080 (or whatever you configured your listener to).

Then click “Save”.

That’s it. If you have done everything correctly, you should now be able to see traffic from apps on your Android virtual device connecting to APIs through Burp Suite. To be sure, open up an app like YouTube and click on Shorts. You should see/hear the video, and see the corresponding API requests in the Burp Suite Proxy History.

You’re welcome.

Conclusion

There you have it. I’m sure this article will grow stale in a few years as Google adds some other security hurdles to make it difficult for Burp Suite to intercept traffic from mobile apps running on Android. However, as of the time of this writing, this works right up to Android 15.

I hope it helps if you are struggling to get Burp Suite to work with more modern versions of Android and supported emulated devices like the Pixel 8. 

From here, there are very few differences between hacking a web app that is connecting to an API and hacking a mobile app that is doing the same. You may find, though, that the endpoint payload data is different or that entirely different endpoints are used between the apps.

That’s the fun part. Give it a try and see. You may be surprised by what you find.   

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe at https://apihacker.blog.

The post Hacking Modern Android Mobile Apps & APIs with Burp Suite appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/hacking-modern-android-apps-with-burpsuite