Mobile App Penetration Testing: iOS & Android Guide

Mobile applications are one of the most undertested components of an organisation’s attack surface. Most companies commission web application pentests annually but test their iOS and Android apps rarely — if ever. Our mobile app penetration testing service covers both platforms using the methodology described below. This is a significant gap: mobile apps handle authentication tokens, store sensitive data locally, communicate with backend APIs, and increasingly have privileged access to device features.

The mobile attack surface is distinct from web applications. Attackers interact with the app binary itself (not just HTTP traffic), analyse local storage on the device, intercept API traffic, and exploit platform-specific vulnerabilities. This guide covers the methodology, tools, and most impactful findings across iOS and Android.

The OWASP MASVS Framework

The OWASP Mobile Application Security Verification Standard (MASVS) is the reference framework for mobile security. It defines security requirements in categories:

Two verification levels:

• L1 (Standard Security): Basic security best practices applicable to all apps
• L2 (Defense-in-Depth): Advanced controls for high-risk apps (banking, healthcare, fintech)

OWASP MASTG (Mobile Application Security Testing Guide) provides the testing procedures for each MASVS requirement.

Android Penetration Testing

Setup and Prerequisites

Testing environment:

• Rooted Android device (Pixel recommended) or Android emulator (AVD)
• For emulator: emulator -avd <name> -writable-system -no-snapshot
• ADB (Android Debug Bridge) installed
• Install Burp Suite CA cert on device for traffic interception

Essential tools:

• jadx — decompile APK to Java source
• apktool — decode APK resources and smali bytecode
• MobSF (Mobile Security Framework) — static and dynamic analysis platform
• frida — dynamic instrumentation framework (hook functions at runtime)
• objection — frida-based runtime exploration toolkit
• apkleaks — find hardcoded secrets in APK
• drozer — Android security assessment framework

Phase 1: APK Acquisition and Static Analysis

Get the APK:

# From Google Play via adb (device connected, app installed)
adb shell pm list packages | grep appname
adb shell pm path com.example.app
adb pull /data/app/com.example.app-xxx/base.apk

# Extract from APKPure, APKMirror, or directly from Play via gplaycli
gplaycli -p com.example.app -f .

Decomile the APK:

# jadx — full Java source decompilation
jadx -d output_dir app.apk

# apktool — resources + smali (closer to compiled bytecode)
apktool d app.apk -o apktool_output

What to look for in source code:

# Hardcoded secrets
grep -r "api_key\|apikey\|secret\|password\|token\|AWS\|Bearer" output_dir/ --include="*.java"

# Firebase URLs
grep -r "firebaseio.com" output_dir/

# Hardcoded URLs and endpoints
grep -r "http://\|https://" output_dir/ --include="*.java" | grep -v "//comment"

# Cryptographic issues
grep -r "DES\|MD5\|RC4\|ECB\|AES.*ECB\|SecureRandom\|Math.random" output_dir/

# SQL queries (potential SQLi)
grep -r "rawQuery\|execSQL\|SELECT.*FROM" output_dir/

# WebView (potential XSS, JavaScript bridge)
grep -r "WebView\|addJavascriptInterface\|setJavaScriptEnabled" output_dir/

# Intent-based vulnerabilities
grep -r "getIntent()\|getStringExtra\|getParcelableExtra" output_dir/

MobSF automated static analysis:

docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
# Upload APK to http://localhost:8000
# Review findings: hardcoded secrets, insecure APIs, exported activities

AndroidManifest.xml review:

<!-- Check for dangerous exported components -->
<activity android:name=".AdminActivity"
          android:exported="true">  <!-- Exported without permission = accessible to any app -->

<!-- Check for debuggable app (never in production) -->
<application android:debuggable="true">  <!-- Should be false or absent -->

<!-- Check for cleartext traffic allowed -->
<application android:usesCleartextTraffic="true">  <!-- Should be false -->

<!-- Check for backup enabled (exposes app data) -->
<application android:allowBackup="true">  <!-- Consider false for sensitive apps -->

Phase 2: Dynamic Analysis and Traffic Interception

Set up Burp Suite proxy:

# Install Burp CA cert to Android trust store (requires root)
adb push BurpCA.der /sdcard/
# On device: Settings > Security > Install from SD card

# Set Android proxy to 192.168.x.x:8080 (Burp listener IP)
adb shell settings put global http_proxy 192.168.1.100:8080

Bypass SSL Pinning with Frida:

SSL pinning prevents traffic interception. Most apps implement it — and most implementations can be bypassed:

# Install Frida server on device
adb push frida-server-16.x.x-android-arm64 /data/local/tmp/frida-server
adb shell chmod 755 /data/local/tmp/frida-server
adb shell /data/local/tmp/frida-server &

# On your machine
pip install frida-tools objection

# Use objection to auto-patch SSL pinning
objection --gadget com.example.app explore --startup-command "android sslpinning disable"

# Or use the Universal SSL Unpinner script
frida -U -f com.example.app --no-pause -l universal-ssl-unpinner.js

Runtime exploration with objection:

objection --gadget com.example.app explore

# List activities, services, receivers
android hooking list activities
android hooking list services

# List SQLite databases
sqlite connect
sqlite execute query "SELECT * FROM users LIMIT 5"

# Dump SharedPreferences
android clipboard monitor
android sharedpreferences list

# Monitor file system access
android filesystem list /data/data/com.example.app/

# Hook specific methods
android hooking watch class_method com.example.app.auth.TokenManager.getToken --dump-args --dump-return

Phase 3: Local Storage Testing

Sensitive data should never be stored in plaintext on the device:

# Access app's local storage (requires root)
adb shell
su
cd /data/data/com.example.app/

# SharedPreferences (XML files — check for credentials, tokens)
cat shared_prefs/*.xml

# SQLite databases
sqlite3 databases/main.db
.tables
SELECT * FROM accounts;
SELECT * FROM sessions;

# Files directory
ls -la files/
cat files/user_data.json

# Check for files in external storage (world-readable)
ls /sdcard/Android/data/com.example.app/

MASVS-STORAGE failures (most common findings):

• Access tokens stored in SharedPreferences
• Passwords stored in SQLite
• Sensitive user data in plaintext files
• Credentials in application logs (Log.d(), Log.v())

Phase 4: Intent and IPC Testing

Android apps communicate via Intents. Exported components without permission requirements can be called by any app on the device:

# drozer — Android IPC testing
drozer console connect

# List exported activities
run app.activity.info -a com.example.app

# Launch exported activity directly
run app.activity.start --component com.example.app com.example.app.DeepLinkActivity --data-uri "example://admin"

# List exported content providers
run app.provider.info -a com.example.app

# Query content provider (may expose data)
run app.provider.query content://com.example.app.provider/users

# Test for SQL injection in content provider
run app.provider.query content://com.example.app.provider/users --selection "1=1 OR '1'='1'"

iOS Penetration Testing

Setup and Prerequisites

Testing environment:

• Jailbroken iPhone or iPad (iOS version matching your target)
• macOS machine with Xcode installed
• Install Burp CA cert to iOS trusted root certificates

Essential tools:

• Frida on jailbroken device
• Objection for runtime exploration
• class-dump — dump Objective-C class headers from app binary
• Hopper / Ghidra / IDA Pro — disassemble app binary
• ipatool — download IPA from App Store
• libimobiledevice — iOS device management

Phase 1: IPA Extraction and Static Analysis

Get the IPA:

# From a jailbroken device
# Using Frida (Fridump)
python3 fridump.py -u -s AppName

# Using clutch on jailbroken device
clutch -b com.example.app

# Using ipatool
ipatool download -b com.example.app --purchase

Analyse the binary:

# Check security flags on binary
otool -lv AppName | grep -A 4 "MAIN_COMMAND"
otool -hv AppName | grep PIE  # Position Independent Executable

# Dump class information
class-dump -s -S -H AppName -o ./headers/

# Look for hardcoded strings
strings AppName | grep -iE "password|secret|api_key|token|http"

What to look for in IPA:

unzip app.ipa -d app_contents
cd app_contents/Payload/AppName.app

# Info.plist — check ATS (App Transport Security)
cat Info.plist | grep -A 5 "NSAppTransportSecurity"
# NSAllowsArbitraryLoads: true = cleartext HTTP allowed = bad

# Check for embedded secrets in resource files
grep -r "apikey\|secret\|password\|aws" . --include="*.plist" --include="*.json" --include="*.strings"

# Check for bundled certificates (may indicate pinning implementation)
find . -name "*.cer" -o -name "*.der" -o -name "*.p12" -o -name "*.pfx"

Phase 2: Traffic Interception and SSL Pinning Bypass

Install Burp CA on iOS:

1. Transfer cacert.der from Burp to device
2. Settings > General > VPN & Device Management > Install Certificate
3. Settings > General > About > Certificate Trust Settings > Enable full trust

SSL Pinning bypass with Frida:

# Start Frida server on jailbroken device
scp frida-server root@<device-ip>:/usr/sbin/
ssh root@<device-ip> "chmod 755 /usr/sbin/frida-server && frida-server &"

# iOS SSL kill switch
frida -U -f com.example.app --no-pause -l SSL-Kill-Switch2.js

# Objection (covers most common implementations)
objection --gadget com.example.app explore --startup-command "ios sslpinning disable"

Phase 3: Data Storage Testing

# Via objection or SSH on jailbroken device
ssh root@<device-ip>
cd /var/mobile/Containers/Data/Application/<UUID>/

# Keychain — most secure, but check for misconfigurations
# Items stored with kSecAttrAccessibleAlways = accessible when device locked = bad

# NSUserDefaults (UserDefaults)
cat Library/Preferences/com.example.app.plist

# SQLite databases
find . -name "*.sqlite" -o -name "*.db"
sqlite3 Library/Application\ Support/app.db
.tables
SELECT * FROM accounts;

# CoreData
find . -name "*.sqlite" -o -name "*.momd"

# Check for sensitive data in screenshots (iOS auto-screenshots app for task switcher)
ls Library/SplashBoard/

MASVS-STORAGE failures on iOS:

• Sensitive data in NSUserDefaults
• Keychain items with kSecAttrAccessibleAlways or kSecAttrAccessibleAlwaysThisDeviceOnly
• Passwords in SQLite/CoreData
• App captures sensitive screens (no blurring in app switcher)

Phase 4: Runtime Analysis

# Objection commands for iOS
objection --gadget com.example.app explore

# List classes
ios hooking list classes | grep -i auth

# Hook a method
ios hooking watch method "-[AuthManager validatePin:]" --dump-args --dump-return

# Dump NSUserDefaults
ios nsuserdefaults get

# List keychain items
ios keychain dump

# File system
ios file ls /var/mobile/Containers/Data/Application/<UUID>/Documents/

Common Mobile Security Findings

Both Platforms

Android-Specific

• Exported activities without permission requirements (malicious apps can invoke them)
• Intent sniffing (implicit intents readable by any app)
• Content provider SQL injection
• Exposed Logcat data (sensitive logs visible to other apps)
• Backup allowed — sensitive data exposed via ADB backup

iOS-Specific

• Keychain items accessible after device restart (wrong accessibility attribute)
• App screenshots captured by iOS and stored on disk
• Pasteboard data exposure (sensitive data copied to clipboard, accessible to all apps)
• UIWebView XSS (if app uses legacy UIWebView)
• Binary without PIE (makes exploitation easier)

Reporting Mobile Security Findings

Effective mobile pen test reports include:

Technical evidence:

• Screenshots showing data in plaintext storage
• Network captures showing unencrypted traffic
• Proof-of-concept code for exploitable vulnerabilities
• Frida scripts used and output

Device and app version:

• Test device model and iOS/Android version
• App version tested (version number from app store listing)
• Testing approach (static, dynamic, or both)

Remediation specifics:

For iOS:

• Keychain storage with kSecAttrAccessibleWhenUnlockedThisDeviceOnly
• Implement TrustKit or NSURLSession with custom trust evaluation for pinning
• Set UIApplicationExitsOnSuspend for apps handling very sensitive data

For Android:

• Use Android Keystore for cryptographic operations
• Use EncryptedSharedPreferences instead of plain SharedPreferences
• Set android:exported="false" on internal activities, services, receivers
• Disable log output in production builds

Mobile Pen Test Scope Considerations

When scoping a mobile pen test, clarify:

• Which platforms (iOS, Android, or both)?
• Which versions of each platform?
• Is source code available (white box) or binary only?
• Are backend APIs also in scope?
• Is jailbreak/root testing in scope (tests some additional attack vectors)?
• Is the App Store version or development build provided?

White box testing (with source code) provides deeper coverage and is significantly more efficient. For regulated industries (fintech, healthcare), include MASVS L2 verification as the baseline. Consider combining this with a web application penetration test for full application coverage.

CyberneticsPlus conducts mobile application penetration testing for iOS and Android, covering OWASP MASVS L1 and L2 requirements. Our penetration testing services cover web, API, mobile, cloud, and network — often combined for comprehensive coverage. Contact us to scope your mobile app assessment.