/mobile-pentest

name: mobile-pentest
description: 'Mobile app pentest for bug bounty (Android APK + iOS IPA) — runtime-first workflow: install app, proxy through Burp/mitmproxy, drive the UI, capture packets, then test the API exactly like a web target; escalate to decompile (apktool/jadx) and Frida/objection only when traffic is SSL-pinned, encrypted, or absent. Covers APK/IPA decompile for hardcoded secrets + hidden API endpoints + base URLs the web app never exposes, exported-activity and deeplink intent injection, WebView addJavascriptInterface bridge abuse, SSL pinning bypass (objection patchapk / Frida CertificatePinner + checkServerTrusted hooks), OkHttp interceptor chain to recover request signing, JNI native-lib triage, and the quick apktool/grep secret + endpoint sweep. Use when the program scope includes a mobile app, when web recon dries up and you need a fresh attack surface, or when traffic is pinned and you must MitM it.'

MOBILE APP PENTEST (ANDROID / iOS)

Mobile apps talk to the same backend as the web app — but they ship a **different, less-hunted attack surface**: base URLs, API endpoints, header schemes, and hardcoded secrets that web recon never sees. Most hunters skip mobile. That's the edge.

> **The whole point:** the APK/IPA is a copy of the client. Decompile it once and you get every endpoint the web JS never references, every staging/internal base URL, and often a live API key sitting in `strings.xml`. Then you attack the backend like any web target.

---

RUNTIME-FIRST — THE ONE RULE THAT MATTERS

**Do NOT start by decompiling.** Decompiling first burns hours recovering crypto you may never need. Default order:

1. Install the app on a device/emulator (in scope confirmed via /scope)
2. Point it at Burp / mitmproxy
3. Drive the real business flows by hand (login, pay, edit profile, share)
4. After each action, check the proxy: are requests visible and replayable?
5. Traffic visible + replayable  → STOP. Test the API like a web target.
6. Traffic pinned / encrypted / absent → THEN escalate to apktool/jadx/Frida.

Most of your paid mobile bugs (IDOR, auth bypass, business logic) come from step 5 — plain HTTP traffic you replay in Burp. Reversing (apktool/jadx/Frida) is a **support step** to get traffic flowing or to recover a request signer, not the goal.

> If Burp already has a stable, replayable request, you are done reversing. Switch to server-side testing.

---

0. SCOPE CHECK FIRST

Mobile has its own scope traps. Before touching the binary:

• Is the **app itself** in scope, or only the web domains? Many programs list the app package (`com.target.app`) explicitly. If only `*.target.com` is listed, the **API endpoints** the app calls are usually in scope — but the app binary analysis may not be. Run `/scope`.
• Third-party SDKs (analytics, ads, crash reporters) bundled in the APK are **out of scope** — they belong to Firebase/Sentry/AppsFlyer, not the target.
• Don't report "app is debuggable" / "no root detection" / "no obfuscation" — these are N/A on almost every program (no real-world attacker impact). See the Never-Submit list below.

---

1. SETUP (one-time)

# Android device/emulator over adb
adb devices
adb install target.apk                     # or pull a live install: adb shell pm path com.target.app

# Proxy — route device traffic through Burp or mitmproxy
# Android: Settings > Wi-Fi > proxy = <laptop-ip>:8080, install Burp CA as a *system* cert
# (user certs are ignored by apps targeting API 24+ — push to /system/etc/security/cacerts on a rooted device,
#  or use objection patchapk to inject a network_security_config that trusts user certs)
mitmproxy --listen-port 8080               # CLI alternative to Burp; mitmweb for a UI

# Reversing toolchain
apktool d target.apk -o target_src         # smali + resources + manifest (recompilable)
jadx-gui target.apk                         # DEX -> readable Java (best for reading logic)
jadx -d target_jadx target.apk              # CLI batch decompile

# Runtime instrumentation
pip install frida-tools objection
# Pin a compatible gadget version — Frida 17 broke older flows; 16.7.x is the stable bug-bounty pick (2025)
frida --version

iOS needs a jailbroken device (Apple ships no emulator that defeats pinning). Same flow: install IPA, proxy, drive UI, escalate to `frida`/`objection` only if pinned.

---

2. STATIC SWEEP — SECRETS + ENDPOINTS WEB RECON MISSES 🔑

This is the highest-ROI 5 minutes in mobile hunting. Decompile, then grep. The quick check (no rooted device needed):

apktool d target.apk -o target_src

# Hardcoded secrets — strings.xml is where lazy devs stash keys
grep -rn "api_key\|secret\|password\|token\|Authorization\|Bearer\|client_secret\|private_key" \
  target_src/ --include="*.smali" --include="*.xml"

# Base URLs + endpoints — the gold. Strip framework noise:
grep -rn "https://" target_src/ | grep -v "schema\|xmlns\|android\|google\|w3.org\|apache" | sort -u | head -80

# Firebase / cloud creds frequently shipped in resources
grep -rniE "firebaseio\.com|amazonaws\.com|s3\.|googleapis|cloudfront|\.blob\.core" target_src/

# Use jadx output (Java) for readability when smali is unreadable
jadx -d target_jadx target.apk
grep -rnE "https?://[a-z0-9.-]+" target_jadx/sources/ | grep -viE "android|google|w3\.org" | sort -u

Automate it with `apkleaks` (regex pack for URIs + secrets) when installed:

apkleaks -f target.apk -o target_apkleaks.txt    # endpoints + secret patterns in one pass

What to do with each hit (impact-first — this is what makes it submittable vs N/A):

| Found in APK | Action — prove real impact RIGHT NOW | |---|---| | `internal-api.target.com` / `staging.target.com` base URL not in web recon | `httpx` it, crawl it, `/recon` it — fresh surface, often weak auth | | Live API key (Google Maps, AWS, Algolia, Mapbox, SendGrid) | **Call the API as the key.** Unkeyed billing = $$. See Credential Leaks rule — a key alone is Info