Skip to content
Pwnversity

Mobile Pentest Methodology

Mobile pentesting covers the app (the APK/IPA binary), its communication with the backend, and how it stores data on the device. Unlike the web, here the code runs on a device the user (and the attacker) controls physically, so anything the app stores or decides locally can be inspected and manipulated. The reference is OWASP MASVS/MASTG, which structures the whole process.

The three surfaces

Section titled “The three surfaces”
1. The app (static analysis): the binary, its code, secrets, configuration
2. The running app (dynamic analysis): behavior, storage, memory
3. Communication: traffic with the backend (API) -> the Web section attacks apply

Static vs dynamic analysis

Section titled “Static vs dynamic analysis”
  • Static (SAST): decompile the APK/IPA and review the code, resources, permissions, and secrets without running the app. Fast for finding hardcoded keys, endpoints, insecure configuration.
  • Dynamic (DAST): run the app (on device/emulator) and instrument it (Frida, see Frida and Dynamic Analysis) to observe and modify its behavior live: storage, encryption, authentication, SSL pinning.

OWASP MASVS: the categories

Section titled “OWASP MASVS: the categories”
MASVS-STORAGE     data storage (see mob-storage)
MASVS-CRYPTO      use of cryptography
MASVS-AUTH        authentication and authorization
MASVS-NETWORK     communication (TLS, pinning -> mob-ssl)
MASVS-PLATFORM    platform interaction (IPC, deeplinks -> mob-deeplinks)
MASVS-CODE        code quality and protections
MASVS-RESILIENCE  anti-tampering, anti-debugging, obfuscation

Workflow

Section titled “Workflow”
1. Obtain the binary (Android APK, iOS IPA)
2. Static analysis: decompile, review manifest/Info.plist, permissions, secrets, endpoints
3. Prepare the environment: rooted/jailbroken device or emulator; proxy (Burp)
4. Dynamic analysis: run + instrument (Frida)
5. Storage: inspect what it stores and how (mob-storage)
6. Network: intercept traffic; bypass SSL pinning if present (mob-ssl)
7. Logic/platform: deeplinks, IPC, exported components (mob-deeplinks)
8. Backend: test the API like a webapp (Web section)
9. Document per MASVS

Testing environment

Section titled “Testing environment”
Android:  emulator (AVD/Genymotion) or rooted device; adb; Burp as proxy
iOS:      jailbroken device (more restrictive); or no-jailbreak techniques
Cross-cutting tools: Frida/Objection, MobSF (automated analysis), Burp

What’s almost always found

Section titled “What’s almost always found”
  • Hardcoded secrets: API keys, credentials, internal URLs in the code/resources.
  • Insecure storage: sensitive data in cleartext in SharedPreferences/plist/SQLite (Insecure Storage).
  • Unencrypted traffic or missing/bypassable pinning (SSL Pinning and Bypass).
  • Exported components / deeplinks allowing unauthorized access (Deeplinks and IPC).
  • Broken authentication/authorization in the backend (the API is the real target).

For the defense

Section titled “For the defense”
  • Follow MASVS: don’t trust the client, encrypt sensitive data, TLS + pinning, validate in the backend.
  • Don’t hardcode secrets in the app (the binary is inspectable); use backend/secret management.
  • Anti-tampering/anti-debugging/obfuscation (MASVS-RESILIENCE) raise the attacker’s cost, don’t prevent them.
  • Treat the API as the primary surface: all real security must be in the backend.

Testing checklist

Section titled “Testing checklist”
  • Obtain the binary (APK/IPA)
  • Static analysis: manifest/permissions/secrets/endpoints (MobSF)
  • Environment: rooted/jailbroken device or emulator + proxy
  • Dynamic analysis with Frida/Objection
  • Insecure storage (Insecure Storage)
  • Network: intercept + bypass SSL pinning (SSL Pinning and Bypass)
  • Deeplinks/IPC/exported components (Deeplinks and IPC)
  • Backend/API tested as a webapp (Web section)

References

Section titled “References”