~/tutorials / mobile-app-testing-setup

Mobile App Testing Setup

Build an Android testing environment with an emulator, adb, and an intercepting proxy, then practice on intentionally vulnerable apps.

intermediate40 min readupdated
  • mobile
  • android
  • burp suite

Lab only. Practice these techniques on your own machines or on platforms that explicitly authorize testing. Informational and educational use only.

Mobile apps are mostly clients for APIs, and those APIs are often less hardened than the website. Setting up a mobile testing environment is the hard part. Once traffic flows through your proxy, the web testing skills you already have take over.

Test only apps you build, intentionally vulnerable training apps, or apps in a bug bounty program that lists mobile in scope. Read each program’s rules on reverse engineering before you start.

The environment

Use an Android emulator rather than your personal phone:

  • Android Studio’s emulator with a “Google APIs” system image (not “Google Play”) gives you root access through adb root.
  • Pick an API level that matches what your target apps support. API 30 to 34 is a good default.

Install the platform tools and confirm the device is visible:

adb devices
adb root
adb shell getprop ro.build.version.release

Useful adb commands

adb install app.apk                         # install an app
adb shell pm list packages | grep -i bank   # find a package name
adb logcat --pid=$(adb shell pidof -s com.example.app)   # one app's logs
adb pull /data/data/com.example.app/ ./app-data/         # app storage, requires root
adb shell am start -n com.example.app/.MainActivity      # launch an activity

logcat alone finds real bugs. Apps regularly log tokens, API responses, and personal data that any app with log access could once read.

Routing traffic through Burp

  1. In Burp, add a proxy listener on all interfaces, port 8080.
  2. Point the emulator’s proxy at your machine. The emulator reaches the host at 10.0.2.2.
  3. Export Burp’s CA certificate.

Since Android 7, apps ignore user-installed certificates by default. On a rooted emulator, you install Burp’s CA into the system store instead. The OWASP MASTG documents the current procedure for each Android version, including the changes in Android 14 where system certificates moved into an APEX module.

If an app still refuses to connect, it likely uses certificate pinning. Tools like Frida and objection can disable pinning at runtime for testing. Your own apps and training apps are the right place to learn this.

Static analysis first

Before running anything, look inside:

  • jadx decompiles an APK to readable Java.
  • MobSF automates static analysis and flags exported components, hardcoded secrets, and insecure settings.
  • Check AndroidManifest.xml for android:exported="true" activities and providers, android:debuggable, and android:allowBackup.

Hardcoded API keys, staging URLs, and feature flags in decompiled code are some of the most common mobile findings.

Practice apps

  • OWASP MASTG Crackmes (UnCrackable apps) teach reversing and anti-tampering bypass.
  • InsecureBankv2 and DIVA cover storage, IPC, and logging flaws.
  • InjuredAndroid is a CTF-style app with progressive flags.

What to test

The OWASP MASVS lists the requirements. In practice, start with:

Area Question
Storage Are tokens or personal data stored unencrypted in shared preferences or databases?
Network Is all traffic over TLS? Does the API enforce authorization server-side?
Components Can other apps launch exported activities or read content providers?
Logs Does logcat show secrets?
Authentication Does logout invalidate the session on the server?

Takeaway

Get traffic into your proxy and you’re testing an API. Most serious mobile bugs are server-side authorization issues that the app simply made easier to find.