Mobile Application Testing
The binary, the device, and the backend it talks to
A mobile app ships to devices you don't control, so anything embedded in the binary should be treated as public. We decompile it, look for hardcoded secrets and weak crypto, watch what it writes to disk, intercept its traffic, and test whether root/jailbreak detection and certificate pinning survive contact with someone who wants to bypass them. Then we test the backend, because that's usually where the real damage is.
What we cover.
- Both iOS and Android, on rooted/jailbroken and stock devices
- Binary analysis of .apk and .ipa packages
- Static analysis — decompilation, hardcoded secrets, weak cryptography
- Dynamic analysis — runtime behavior, local storage, traffic interception
- The backend APIs the app depends on
- OWASP Mobile Top 10 (2024) coverage
How the engagement runs.
Introduction
A mobile application penetration test identifies and exploits vulnerabilities in a mobile app, its backend APIs, and its interactions with the operating system it runs on. The goal is to find weaknesses leading to unauthorized access, data theft, or privilege escalation.
It is a hybrid assessment, guided throughout by the OWASP Mobile Top 10.
Application testing
Analysing the on-device application itself — the .apk or .ipa package as it ships to users.
Network and API testing
Analysing the communication between the app and the backend servers it depends on.
Platform testing
Analysing how the app interacts with the mobile operating system and its storage and permission model.
Test phases
Planning and scoping
- Define objectives — access another user's data, bypass in-app purchase, extract sensitive data from the device.
- Define scope.
- Platforms — iOS, Android, or both
- Application name and specific version under test
- Distribution — pulled from the public store (black box) or supplied as a binary (grey box)
- Backend — API endpoints, which are in scope almost without exception
- Credentials — test accounts for each distinct role
- Define test environment — testing runs on both stock and rooted/jailbroken devices, since bypassing OS-level protection is what lets us inspect the app's internal data. The lab combines emulators, physical handsets, and an interception proxy.
- Establish rules of engagement — written authorization, agreed testing window, handling procedure for any real user data encountered, and a named contact for critical findings.
Static analysis
Analysing the application binary without running it.
- Android — decompile the package into resources and smali, convert the dex classes, and read the recovered Java source.
- iOS — unpack the bundle; where the build is store-encrypted, decrypt it on a jailbroken device before disassembling the binary.
- Hardcoded secrets — search decompiled code and resources for API keys, passwords, encryption keys, and internal URLs.
- Manifest and property list analysis.
- Android — debuggable builds, exported activities, services and receivers that other apps could invoke, and over-broad permissions
- iOS — custom URL schemes, requested permissions, and insecure transport configuration
- Insecure code — weak cipher modes, sensitive values written to shared preferences, and logging that leaks data in production builds.
Dynamic analysis
Running the app on a device and interacting with it, with all traffic routed through an interception proxy. Testing follows the OWASP Mobile Top 10 (2024).
- M1 Improper credential usage — keys or tokens hardcoded into the binary, secure storage (Keychain, Keystore) not used, or credentials sent in clear.
- M2 Inadequate supply chain security — third-party libraries and SDKs that are vulnerable, outdated, or malicious. The app is only as secure as its weakest dependency.
- M3 Insecure authentication and authorization — identity not verified correctly, or an authenticated user able to exceed what they should be allowed to do.
- M4 Insufficient input/output validation — injection and cross-site scripting inside WebViews. Mobile apps must sanitise input just as web apps do.
- M5 Insecure communication — plain HTTP, unvalidated TLS certificates, or missing certificate pinning where the risk justifies it.
- M6 Inadequate privacy controls — excessive collection of personal data, sensor access without consent, or leakage to analytics and advertising partners.
- M7 Insufficient binary protection — no obfuscation, no root or jailbreak detection, no anti-tampering, making the app trivial to analyse and modify.
- M8 Security misconfiguration — insecure defaults, debug features left on in production, or misconfigured cloud storage the app reaches.
- M9 Insecure data storage — unencrypted data left in files, SQLite databases, or logs on the device filesystem.
- M10 Insufficient cryptography — deprecated or homegrown algorithms in place of current standards, or correct algorithms implemented wrongly.
Exploitation
Chaining findings to demonstrate maximum impact. Three representative chains:
- Data theft — bypass certificate pinning, intercept traffic, find an insecure direct object reference in the API, then script it to enumerate records.
- Account takeover — decompile the app, recover a hardcoded API key, use it against an administrative endpoint, and reset an arbitrary user's password.
- On-device theft — locate an auth token stored in clear on the device, then replay it to hijack that user's session.
Reporting
- Executive summary for management, framed around business risk.
- Technical report written for the mobile and backend developers.
- Per-finding detail — description mapped to the OWASP category, affected platform, evidence including code snippets and file paths, business impact, risk rating, and mobile-specific remediation.
Remediation and re-testing
- Debrief meeting to present the findings.
- Targeted re-test once the development team has shipped fixes.
What you get at the end.
Who it's for
Teams publishing consumer or enterprise mobile apps, particularly in finance, health, and commerce.
Need a scope for this engagement?
Tell us what's in your environment and we'll come back with a scoped plan.
More in Offensive Infrastructure
Red Teaming
Full-scope adversary simulation against people, process, and technology
Web Application Penetration Testing
Manual, OWASP-aligned testing for the flaws scanners consistently miss
API Penetration Testing
Testing the headless surface — broken object authorization, mass assignment, oversharing