Mobile Application Penetration Testing: Android and iOS Guide

Mobile apps live in a strange middle ground for security testing — part client-side reverse engineering, part API testing, part traditional network analysis. A lot of beginners coming from web app testing assume the skills transfer directly, and while some do, mobile introduces an entirely new layer: the compiled application binary itself, sitting on a device the attacker fully controls. Mobile application penetration testing requires understanding both Android and iOS platform-specific security models, plus the backend APIs nearly every app depends on.

What Is Mobile Application Penetration Testing?

Mobile application penetration testing evaluates the security of Android and iOS apps across three layers: the client-side binary and local data storage, the network communication between app and backend, and the backend API itself. Because the attacker controls the device, mobile testing includes techniques rarely relevant in traditional web testing — binary decompilation, runtime instrumentation, and local storage analysis.

Why Mobile Security Testing Matters

Mobile apps frequently store or process sensitive data locally — authentication tokens, cached personal data, even hardcoded API keys — and many developers underestimate how easily a compiled app can be reverse-engineered. Combine that with a backend API that’s often tested less rigorously than a company’s main web application, and mobile apps become a genuinely attractive, under-scrutinized attack surface.

The OWASP Mobile Top 10

1. Improper Credential Usage — hardcoded credentials or poor token handling
2. Inadequate Supply Chain Security — vulnerable third-party SDKs and libraries
3. Insecure Authentication/Authorization — weak session and permission handling
4. Insufficient Input/Output Validation — injection risks in local and remote data handling
5. Insecure Communication — missing or misconfigured TLS, certificate validation bypass
6. Inadequate Privacy Controls — excessive data collection or insecure storage of PII
7. Insufficient Binary Protections — lack of obfuscation, easily reversible logic
8. Security Misconfiguration — debug flags left enabled, excessive permissions requested
9. Insecure Data Storage — sensitive data cached in plaintext, logs, or backups
10. Insufficient Cryptography — weak algorithms or improper key management

Setting Up Your Testing Environment

Android Lab Setup

• Android Studio with an emulator (AVD) — ideally a rooted emulator image for full filesystem access
• Genymotion — an alternative emulator with easier rooting support
• A physical rooted device is preferable for realistic testing when available

iOS Lab Setup

• A jailbroken iOS device — required for full filesystem access and runtime manipulation; the iOS simulator lacks the sandboxing realism needed for genuine security testing
• Corellium — a virtual iOS device platform increasingly used as a jailbreak alternative for professional testing

Practice Applications

• OWASP MASTG Crackmes / UnCrackable Apps — deliberately vulnerable Android and iOS apps built for the Mobile Security Testing Guide
• DIVA (Damn Insecure and Vulnerable App) — Android-focused vulnerable app
• iGoat — iOS-focused vulnerable app for hands-on practice

Step-by-Step Methodology

Step 1: Static Analysis

Static analysis examines the app without running it — decompiling the binary to review source code, hardcoded secrets, and configuration.

Android APK extraction and decompilation:

apktool d target-app.apk -o decompiled_app

• d decodes the APK into readable resources and smali code
• -o specifies the output directory for the decompiled project

jadx -d jadx_output target-app.apk

• jadx decompiles the APK further into readable Java source, making manual code review significantly easier than reading raw smali

iOS IPA extraction (on a jailbroken device or via decrypted binary):

class-dump target-app-binary

• class-dump extracts Objective-C class, method, and protocol declarations from a compiled iOS binary, revealing app structure without full decompilation

During static analysis, look for:

• Hardcoded API keys, credentials, or encryption keys
• Insecure use of WebView components (JavaScript injection risk)
• Overly permissive AndroidManifest.xml permissions or exported components
• Weak or missing certificate pinning implementation

Step 2: Dynamic Analysis

Dynamic analysis observes the app’s actual behavior at runtime.

Setting up traffic interception with Burp Suite:

1. Configure the device or emulator’s Wi-Fi proxy to point to your Burp Suite listener
2. Install Burp’s CA certificate on the device to intercept HTTPS traffic
3. Navigate the app and observe API calls captured in Burp Suite’s Proxy history

Bypassing certificate pinning (Android, using Frida):

frida -U -f com.target.app -l pinning-bypass.js --no-pause

• -U targets a USB-connected device
• -f launches the specified app fresh under Frida’s instrumentation
• -l loads a script (in this case, a certificate pinning bypass script) to hook and neutralize the app’s pinning checks at runtime
• --no-pause allows the app to run immediately rather than waiting for a manual resume

Certificate pinning bypass is essential for intercepting traffic in apps that implement pinning correctly — without it, Burp Suite’s traffic capture will simply fail with connection errors.

Step 3: Local Data Storage Analysis

• Inspect app data directories (/data/data/com.target.app/ on rooted Android) for plaintext credentials, tokens, or cached sensitive data
• Check SQLite databases stored locally for unencrypted PII
• Review shared preferences (Android) or plist files (iOS) for insecurely stored secrets
• Check device backups for sensitive data leakage if backup flags aren’t properly restricted

Step 4: Network Communication Testing

• Confirm TLS is enforced for all traffic, not just login screens
• Test for certificate validation bypass susceptibility beyond just pinning
• Once traffic is intercepted, apply standard web application penetration testing and API penetration testing methodology against the backend endpoints the app communicates with — this is often where the most impactful findings surface

Step 5: Platform-Specific Runtime Testing

• Android — test exported activities, services, broadcast receivers, and content providers for unauthorized access via adb:

adb shell am start -n com.target.app/.ExportedActivity

• This attempts to directly launch an exported activity, bypassing the app’s normal navigation flow and any access controls that were only enforced at the UI level
• iOS — test URL scheme handling and universal links for injection or unauthorized deep-link triggering

Step 6: Reporting

Document each finding with the exact static or dynamic evidence (decompiled code snippet, intercepted request, or storage location), the OWASP Mobile Top 10 category, and platform-specific remediation guidance.

Essential Tools

• MobSF (Mobile Security Framework) — automated static and dynamic analysis for both Android and iOS, an excellent starting point before manual deep-dives
• Frida — dynamic instrumentation toolkit for runtime hooking, pinning bypass, and function tracing
• Objection — a Frida-based runtime exploration toolkit simplifying common mobile testing tasks
• apktool / jadx — Android decompilation and resource extraction
• class-dump / Hopper — iOS binary analysis
• Burp Suite — network traffic interception for both platforms

Common Mistakes and Troubleshooting Tips

• Testing only the client without touching the backend API — many of the highest-severity findings live in the API the app talks to, not the client binary itself
• Assuming certificate pinning means traffic can’t be intercepted — Frida-based bypasses handle nearly all pinning implementations with the right script
• Skipping static analysis entirely — dynamic-only testing misses hardcoded secrets and logic only reachable under specific, hard-to-trigger conditions
• Ignoring local storage after login — many apps cache far more sensitive data locally post-authentication than testers initially check for
• Using the iOS Simulator for security testing — it lacks proper sandboxing and code-signing enforcement, making findings unreliable; use a jailbroken device or Corellium instead

Security Risks and Defensive Recommendations

• Never hardcode secrets in the client binary — any embedded key can be extracted via static analysis regardless of obfuscation
• Implement proper certificate pinning alongside standard TLS, and pair it with root/jailbreak detection to raise the bar against runtime tampering
• Encrypt all locally stored sensitive data, and avoid storing sensitive tokens in plaintext shared preferences or plist files
• Restrict exported components (Android) to only what’s genuinely needed by other apps
• Enforce backend-side authorization — never assume the mobile client enforces access control correctly, since the client is fully attacker-controlled

Frequently Asked Questions

Do I need a jailbroken iPhone to test iOS apps properly? Ideally yes — jailbreaking provides the filesystem access and runtime control needed for thorough testing. Platforms like Corellium offer a virtual alternative increasingly used in professional engagements.

Is mobile app testing just web app testing with extra steps? Not quite — while the backend API testing overlaps significantly with web application penetration testing, the client-side binary analysis and platform-specific runtime testing are unique skill sets requiring different tools entirely.

What’s the easiest way to start learning mobile pentesting? Start with MobSF for automated baseline analysis, then work through OWASP’s MASTG Crackmes and UnCrackable Apps to build manual static and dynamic analysis skills hands-on.

Do most mobile app vulnerabilities live in the client or the backend? Both matter, but backend API vulnerabilities (broken authorization, weak session handling) are often more severe and more common than purely client-side issues.

Is Frida legal to use? Yes, Frida itself is a legitimate open-source instrumentation tool. Use it only against apps you own or have explicit written authorization to test.

What certification focuses specifically on mobile security? The Mobile Application Penetration Testing (MAPT) and various GIAC/eLearnSecurity mobile-focused certifications cover this specialization, though it remains a smaller certification landscape than web or network testing.

Can I test a mobile app without decompiling it? Partially — dynamic analysis and traffic interception don’t strictly require decompilation, but you’ll miss hardcoded secrets, logic flaws, and vulnerabilities only visible through static code review.

Conclusion

Mobile application penetration testing blends binary reverse engineering, runtime instrumentation, and backend API testing into a single methodology that differs meaningfully from both traditional network and pure web app testing. Master static analysis with apktool/jadx and class-dump, dynamic analysis with Frida and Burp Suite, and never neglect the backend API the app ultimately depends on. As always, confine every technique here to authorized lab environments or signed, scoped engagements — the same authorization boundaries that apply across every other pentesting discipline apply just as strictly to mobile.

References

• OWASP Mobile Application Security Testing Guide (MASTG) — owasp.org/www-project-mobile-app-security
• OWASP Mobile Top 10 — owasp.org
• Frida Documentation — frida.re
• MobSF Documentation — github.com/MobSF