All articles
BLOG · 8 min read

How I Run a Mobile App Pentest (iOS & Android)

A mobile pentest is really three assessments: the client binary, the data it stores on the device, and the API behind it. Here's how I run all three, with a representative findings box at the end.

Share

1. Static analysis of the binary

Pull the APK/IPA and decompile. MobSF for the fast pass, then jadx / Hopper by hand for anything interesting.

  • Hunt for hardcoded secrets: API keys, cloud credentials, signing keys, backend URLs
  • Check `AndroidManifest.xml` / `Info.plist` for exported components, debuggable flags, weak `android:networkSecurityConfig`
  • Note third-party SDKs and their versions for known issues

2. Dynamic instrumentation

Run on a rooted/jailbroken device or emulator with Frida + Objection. Hook crypto calls to see what's really being encrypted, trace file and network APIs, and dump runtime secrets that never appear in the static strings.

3. Traffic interception and pinning bypass

Route through Burp. If certificate pinning blocks it, bypass with an Objection script or a custom Frida hook, then test the full API exactly as in an API pentest — the mobile client is just another consumer of the same endpoints.

4. Local storage and platform keystores

Inspect SQLite DBs, shared preferences / plists, cache and log files for sensitive data at rest. Verify the Keychain / Keystore is actually used for tokens, and that data is cleared on logout.

5. Deep links, IPC and the backend

Fuzz custom URL schemes and intents for unauthenticated actions, then fold every backend finding into one report so the client sees the mobile and API risk together.

⟩ sample findings — sanitized

What this kind of project turns up

Representative findings from real engagements. Details are altered and unlinked from any client — the pattern and severity are what matter.

SKR-MOB-01Hardcoded cloud storage credentials in the APK
Critical

Access key + secret in a resource file, granting read/write to a production bucket with customer documents. Extracted in the first 20 minutes of static analysis.

SKR-MOB-02Certificate pinning bypassable, full API MITM
High

Single Frida hook disabled pinning; from there every API auth and BOLA issue in the backend was reachable.

SKR-MOB-03Exported activity allows auth-bypass to internal screens
High

A non-exported-by-intent screen was reachable via a crafted intent, skipping the login gate on Android.

SKR-MOB-04Session token and PII stored in plaintext SQLite
Medium

Recoverable from a device backup or with physical access; not held in the Keystore.

SKR-MOB-05Production build shipped with debuggable=true
Medium

Allowed runtime debugging and memory inspection on non-rooted devices.

SKR-MOB-06No root / jailbreak detection
Low

Not a vulnerability by itself; raised as defence-in-depth given the sensitivity of the app.

Tools mentioned

MobSFFridaObjectionjadxapktoolBurp Suite ProRadare2
⟩ takeaway

Treat a mobile pentest as binary + on-device data + backend. The highest-impact findings are usually a hardcoded secret from static analysis or a pinning bypass that unlocks the whole API.

⟩ keep reading

Related articles

Let's Connect

connect

For VAPT engagements, SOC consulting, AI/LLM security assessments, cloud reviews, incident response retainers or training collaborations — let's build a defensible stack together.

Available worldwide · Remote & on-site