Mobile Pentest
Mobile app pentest for bug bounty (Android APK + iOS IPA), runtime-first workflow...
Install
npx skills add awarexone/Agentic-Bug-Hunter --skill mobile-pentest -g -a claude-code -y- Repository
- awarexone/Agentic-Bug-Hunter5.5k
- Category
- Design
- Updated
- 7d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
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:
