Mobile App Pentesting: Android and iOS from Zero

Mobile applications are among the most attacked surfaces in 2026. Billions of people carry their most sensitive data — banking credentials, health records, private messages — on devices running apps that were often rushed to market with minimal security testing. Mobile pentesting is a high-demand skill that combines traffic interception, static analysis, dynamic debugging, and API testing. This guide covers the complete methodology for both Android and iOS.

Setting Up Your Mobile Pentesting Lab

Android Testing Environment

# Option 1: Rooted Android device or Android emulator
# Install Android Studio and create an emulator (x86_64, API 30+)
# OR use a physical device with Magisk for root access

# Key tools to install:
# Frida — dynamic instrumentation framework (hooks functions at runtime)
pip install frida-tools
# Push frida-server to device:
adb push frida-server-16.x.x-android-x86_64 /data/local/tmp/frida-server
adb shell "chmod 755 /data/local/tmp/frida-server && /data/local/tmp/frida-server &"

# MobSF — automated mobile app security scanning
docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf
# Upload APK at http://localhost:8000 — get instant vulnerability report

Traffic Interception with Burp Suite

# Set up Burp as proxy for your device:
# 1. In Burp: Proxy → Options → Add listener on 0.0.0.0:8080
# 2. On Android: WiFi settings → Manual proxy → Your PC IP:8080
# 3. Install Burp CA cert on device (download from http://burpsuite/cert)

# For Android 7+, apps ignore user certs by default
# Fix: add network_security_config.xml to the APK
# OR use objection to bypass cert pinning at runtime:
objection --gadget "com.target.app" explore
> android sslpinning disable

Android Static Analysis

Decompiling APKs

# Download APK from device:
adb pull /data/app/com.target.app-1/base.apk

# Decompile with JADX (produces readable Java/Kotlin source):
jadx -d output_folder/ base.apk
# Now browse the source code in output_folder/

# Decompile with apktool (gets smali bytecode + resources):
apktool d base.apk -o unpacked/

# Search for hardcoded secrets in decompiled code:
grep -r "api_key|password|secret|token|AWS|Bearer" output_folder/
grep -r "http://" output_folder/  # HTTP endpoints (not HTTPS!)

Common Android Vulnerabilities to Check

# 1. Exported Activities (accessible without authentication)
# Check AndroidManifest.xml:
grep 'exported="true"' unpacked/AndroidManifest.xml
# If an activity is exported and handles sensitive data, it can be invoked by other apps
adb shell am start -n com.target.app/.AdminActivity

# 2. Insecure data storage
adb shell
run-as com.target.app
cat /data/data/com.target.app/shared_prefs/UserPrefs.xml
# Check: are passwords, tokens stored in cleartext here?

# 3. Insecure logging (sensitive data in logcat)
adb logcat | grep -i "password|token|credit|card"

# 4. Hardcoded API keys in strings.xml
cat unpacked/res/values/strings.xml | grep -i "key|secret|token"

Android Dynamic Analysis with Frida

# Hook a Java method at runtime to intercept its arguments and return value
# Example: hook the login function to capture credentials
frida -U -n com.target.app -l hook_login.js

# hook_login.js content:
Java.perform(function() {
    var AuthManager = Java.use('com.target.app.AuthManager');
    AuthManager.login.overload('java.lang.String', 'java.lang.String').implementation = function(user, pass) {
        console.log('[*] Login called: user=' + user + ' pass=' + pass);
        return this.login(user, pass);  // call original function
    };
});

# Bypass root detection:
frida -U -n com.target.app --codeshare dzonerzy/fridantiroot

iOS Pentesting Basics

# Requirements: Jailbroken iOS device (Checkra1n or Palera1n for supported models)
# OR: Corellium virtual iOS (commercial, expensive)

# On jailbroken device, install via Cydia/Sileo:
# - Frida (via https://build.frida.re)
# - SSL Kill Switch 2 (bypasses certificate pinning)
# - Filza (file manager for browsing app data)

# Static analysis of IPA:
# Extract IPA, rename to .zip, unzip
# Find the main binary in Payload/*.app/
# Strings dump:
strings TargetApp | grep -E "http|key|secret|token|password"

# Class dump (shows Objective-C class structure):
class-dump -H TargetApp -o headers/

# For Swift: use Hopper Disassembler or Ghidra

API Testing — The Real Attack Surface

Most mobile apps are just frontends to APIs. Once you capture the API traffic with Burp Suite, you are essentially doing web application pentesting. Key checks:

# IDOR — change your user ID in API calls to access others' data
GET /api/v1/users/12345/profile → try /api/v1/users/12346/profile

# Missing authorization — call authenticated endpoints without token
# Remove the Authorization header — does the server still respond?

# Mass assignment — send extra fields in POST body
POST /api/v1/users/update
{"name":"attacker","email":"attacker@evil.com","role":"admin"}
# Does setting "role" work? It should be server-side only.

# Broken object level auth — access other users' resources
GET /api/v1/orders/ORD-98765  # (order belonging to another user)

The OWASP Mobile Top 10 Checklist

  • M1: Improper Credential Usage — Hardcoded credentials, insecure credential storage
  • M2: Inadequate Supply Chain Security — Malicious third-party SDKs, unverified dependencies
  • M3: Insecure Authentication/Authorization — Broken login flows, IDOR in APIs
  • M4: Insufficient Input/Output Validation — SQLi, XSS, injection in API parameters
  • M5: Insecure Communication — HTTP instead of HTTPS, no cert pinning, weak TLS
  • M6: Inadequate Privacy Controls — Excessive permissions, PII in logs
  • M7: Insufficient Binary Protections — No obfuscation, no root detection, no anti-tamper
  • M8: Security Misconfiguration — Debug mode on, exported components, cleartext data
  • M9: Insecure Data Storage — Sensitive data in SharedPrefs, SQLite, or external storage
  • M10: Insufficient Cryptography — Hardcoded keys, weak algorithms (MD5, DES)