Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →shuvonsec/mobile-pentest
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 addJavascriptInterf
Passed 18 of 22 test cases with the skill, and 14 of 22 without it.
and 2 more in the full report
5 fixed13 passed either way3 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
I just downloaded a target APK package for a bug bounty assessment and unpacked it onto my machine. Should I begin by running a full static analysis decompilation tool like JADX to analyze the crypto and network routines, or should I install and proxy the app first? Explain the recommended initial workflow step and why.
| Checked | Without skill | With skill |
|---|---|---|
| Recommends installing the app and proxying traffic to test server endpoints before initiating decompilation. | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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.
Mobile has its own scope traps. Before touching the binary:
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.test cases passed, vs 14 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.