Post cover image

July 12, 2026

Android Pentesting in 2026: The Only Guide You’ll Need to Go From Emulator to Exploit

A field-tested runbook — Android Studio, ADB, Frida, Objection, and Burp Suite — mapped to the OWASP MASTG. Not another “install these five…

By Makishima_ShogO

7 min read

A field-tested runbook — Android Studio, ADB, Frida, Objection, and Burp Suite — mapped to the OWASP MASTG. Not another "install these five tools" post.

Part 1 — Build the lab (Android Studio in 15 minutes)

None

You need a device you fully control. You have three realistic options; here's the honest comparison:

OptionRootSpeedBest forAndroid Studio AVD (Google APIs image)adb root worksFast (HAXV/hypervisor)Everyone starting out — recommendedGenymotionRooted by defaultFastPeople who want zero root frictionPhysical rooted device (Magisk)FullNativeApps with strong emulator detection

Start with the Android Studio emulator. It's free, reproducible, and gives you a root shell.

Install Android Studio from developer.android.com. It bundles the two things you actually need: the SDK Platform Tools (which include adb) and the AVD Manager.

Create the device: Device Manager → Create Device → Pixel 6 → pick a system image.

The one mistake beginners make:_ choose a Google APIs image,_ not a Google Play image. Play Store images are production-locked — no root shell, ever. Google APIs images let you run adb root. API level 30–33 (Android 11–13) hits the sweet spot for tooling compatibility.

Put adb on your PATH (it lives in the SDK's platform-tools/), boot the emulator, and confirm:

bash

adb devices
# emulator-5554   device

Lab's alive.

Part 2 — ADB: your window into the device

adb (Android Debug Bridge) is the tool you'll touch most. Root the emulator and drop a shell:

None

bash

adb root
adb shell

Find the target's package name and where it lives:

bash

adb shell pm list packages | grep -i target
adb shell pm path com.target.app        # location of base.apk

Inspect private storage — the single richest source of quick wins:

bash

adb shell
cd /data/data/com.target.app
ls -la
# shared_prefs/  → XML; devs stash tokens & flags here
# databases/     → SQLite, often unencrypted
# files/ cache/  → arbitrary app data

Pull artifacts to your machine:

bash

adb pull /data/data/com.target.app/shared_prefs/prefs.xml .
adb pull /data/data/com.target.app/databases/app.db .
adb pull /data/app/.../base.apk ./target.apk

Watch logs live while you use the app — apps leak an embarrassing amount here:

bash

adb logcat | grep -i com.target.app

Every one of those commands maps to a MASTG storage test (MASVS-STORAGE). You're already doing methodology, not just running commands.

Part 3 — Static analysis: take the APK apart

None

An APK is a ZIP with structure. Two complementary tools:

apktool — decode manifest & resources, disassemble to Smali:

bash

apktool d target.apk -o target_decoded

Open AndroidManifest.xml and hunt for:

  • android:debuggable="true" — shouldn't ship in prod
  • android:allowBackup="true" — lets you back up app data over ADB
  • android:exported="true" on activities/services/receivers/providers — entry points other apps can invoke (a classic IPC bug source)
  • usesCleartextTraffic="true" — permits plain HTTP

JADX — decompile back to readable Java:

bash

jadx-gui target.apk

Then grep the decompiled source for the usual suspects:

password  secret  api_key  api_secret  token  Bearer
http://   amazonaws  firebaseio  BEGIN PRIVATE KEY
AES  DES  ECB   // weak crypto smells

Hardcoded credentials in strings.xml or constant pools are one of the most common real-world findings. If you find a cloud key here, you may already have your headline bug — verify it, don't just report the string.

Part 4 — Intercept HTTPS with Burp Suite

None

Now read what the app says to its backend. Burp Suite Community Edition is free and enough to start.

1. Open a proxy listener in Burp: Proxy → Proxy settings → Add → bind to All interfaces, port 8080.

2. Point the device at Burp. Find your host LAN IP (ifconfig/ipconfig). On the emulator: Settings → Wi-Fi → gear → Proxy → Manual, host IP + port 8080. (The emulator's extended controls have a proxy field too.)

You'll now see HTTP. HTTPS throws TLS errors because the app doesn't trust Burp's CA. Fix that next.

3. Install Burp's CA as a system certificate. Since Android 7, apps ignore user-added CAs by default, so a user-store install often isn't enough. Export Burp's CA (Proxy settings → Import/export CA certificate → DER), convert to PEM, rename it to its subject hash (<hash>.0), remount /system writable, and push it into /system/etc/security/cacerts/:

bash

openssl x509 -inform DER -in burp.der -out burp.pem
# compute the hash name Android expects
openssl x509 -inform PEM -subject_hash_old -in burp.pem | head -1
mv burp.pem <hash>.0
adb root && adb remount
adb push <hash>.0 /system/etc/security/cacerts/
adb shell chmod 644 /system/etc/security/cacerts/<hash>.0
adb reboot

HTTPS now decrypts cleanly. Send interesting requests to Repeater and start tampering: change user IDs, roles, prices, quantities. Most real Android bugs aren't in the app — they're in a backend that trusts whatever the client sends. That's IDOR and broken access control, and it's where the money is in bug bounty.

Part 5 — Frida & Objection: rewrite the app at runtime

Many apps use certificate pinning — they hardcode which certificate to trust, so even a system-trusted Burp CA is rejected and your traffic goes dark. Others refuse to run on rooted devices. Frida injects JavaScript into the live process so you can rewrite that behavior on the fly.

None

Set up Frida (match server version to client, and architecture to your device — usually x86_64 for an emulator):

bash

pip install frida-tools
# download frida-server matching your frida version + arch
adb push frida-server /data/local/tmp/
adb shell "chmod 755 /data/local/tmp/frida-server"
adb shell "/data/local/tmp/frida-server &"
frida-ps -U        # lists processes → confirms it's working

Server vs Gadget: the frida-server binary needs root and is the norm for lab work. If you can't root, you repackage the APK with the Frida Gadget library instead — same power, no root, more setup.

The fast path: Objection

Objection wraps Frida in an interactive console so you get results without writing JavaScript. It's the default choice for quick assessments (actively maintained — v1.12.x shipped in 2026 with reconnect support for long sessions):

bash

pip install objection
objection -g com.target.app explore
# inside the objection console:
android sslpinning disable          # kills most pinning implementations
android root disable                # defeats common root detection
android hooking watch class com.target.app.AuthManager
android heap search instances com.target.app.SessionManager

android sslpinning disable + Burp = your HTTPS traffic reappears. That combo is the bread-and-butter of mobile pentesting.

The precise path: a custom Frida hook

Writing your own hook is what makes you a practitioner instead of a tool-runner. Force a client-side auth check to always pass:

javascript

Java.perform(function () {
  var Auth = Java.use("com.target.app.AuthManager");
  Auth.isValidUser.implementation = function (user, pass) {
    console.log("[+] isValidUser(" + user + ", " + pass + ")");
    return true;                    // bypass the check entirely
  };
});

bash

frida -U -f com.target.app -l hook.js

You just proved the finding: never trust the client. The same pattern defeats root detection (hook it, return false) and unlocks client-gated premium features.

If Objection's one-liner fails against a stubborn app, drop to the community Universal Android SSL Pinning Bypass on Frida CodeShare, or write a targeted hook against the specific pinning class you found in JADX. There's always a layer below the automation.

Part 6 — The findings mindset (what nobody teaches)

None

Tools don't find bugs; a checklist and a suspicious mind do. On every app, ask:

  • Storage: Are tokens, PII, or keys sitting in shared_prefs/SQLite in plaintext?
  • Secrets: Any live cloud/API keys in the decompiled code? Do they actually work?
  • Transport: Cleartext anywhere? Does pinning fall to Objection (i.e., it's not real defense-in-depth)?
  • Authorization: In Repeater, can you access another user's object by changing an ID? (IDOR)
  • Business logic: Does the server re-check prices/roles/limits, or trust the client?
  • Platform: Any exported component you can invoke from a malicious app? Any WebView loading attacker-controllable URLs or exposing a JS bridge?
  • Resilience: Do root/Frida detection actually stop you, or just slow you down?

A finding is only worth reporting if you can show impact. "The app doesn't pin certificates" is weak. "By disabling pinning I intercepted the session token and replayed it to read another user's private messages" is a report that gets paid.

Part 7 — The one-page runbook

None

Every new target, in order:

  1. Install it, use it normally, learn the features.
  2. jadx-gui the APK; grep for secrets and URLs; read the manifest for exported components and insecure flags.
  3. adb shell into /data/data/<pkg>; inspect shared_prefs and databases.
  4. Tail adb logcat while you exercise the app.
  5. Proxy through Burp; install the system CA; map every endpoint.
  6. Pinning blocking you? objection ... android sslpinning disable, re-capture.
  7. Hammer authorization and business logic in Repeater (IDOR, price/role tampering).
  8. Frida-hook root detection and client-side checks; re-test what unlocks.
  9. Write findings with reproduction steps and demonstrated impact, mapped to MASVS categories.

Troubleshooting (the stuff that actually wastes your day)

  • frida-ps -U hangs or errors: version mismatch. frida --version on host must match the frida-server binary exactly. Re-download the matching server.
  • HTTPS still fails after installing the CA: it's pinning, not the cert. Go to Objection/Frida. Or you installed to the user store, not the system store.
  • App crashes on launch under Frida: it's detecting Frida. Try Objection's spawn/reconnect, use a non-default frida-server name/port, or move to a physical device.
  • Emulator shows no traffic at all: proxy set on the wrong network, or the app uses non-HTTP protocols (gRPC/WebSocket) — check Burp's event log and the emulator's Wi-Fi proxy field.
  • adb remount fails: you're on a Play image (can't root) or need adb disable-verity && adb reboot first.

Where to go next

  • OWASP MASTG & MASVS — the definitive methodology; MASTG v2 reached its first stable release in 2026. Structure your entire learning path around it.
  • Deliberately vulnerable apps — DIVA, InsecureBankv2, OWASP MAS crackmes. Break these end-to-end before touching production.
  • objection deep-dive — memory search, method watching, and class enumeration go far beyond pinning.
  • Bug bounty with mobile scope — the only way to build real reps legally against production apps.

The tooling is free, the emulator runs on any laptop, and the fastest way to learn is to take one vulnerable app and run the full loop until something breaks. Set up the lab today, decrypt your first request, write your first Frida hook — that loop, repeated, is the entire craft.

If this saved you a weekend of trial and error, follow for Part 2, where we write custom Frida hooks against real pinning implementations and automate the whole runbook with Objection scripts