Mobile App Penetration Testing: Android & iOS (OWASP MASVS / MASTG)

Quick Answer

Mobile application penetration testing assesses Android (APK) and iOS (IPA) apps against the OWASP MASVS standard using static and dynamic analysis to uncover security flaws. It covers local data storage, reverse engineering, certificate pinning, API security and IPC vulnerabilities. Frida, Objection and MobSF are core tools.

Why Mobile Testing Differs From Web Testing

A mobile app runs not on a server but on a device the user controls. That simple fact changes the threat model fundamentally. In a web app, the attacker typically gets only the HTTP traffic; on mobile, the attacker has access to the app binary (APK or IPA), the local file system, runtime memory and every IPC channel on the device.

This is why mobile penetration testing evaluates three attack surfaces at once:

  • Client side (app binary): Reverse engineering, weak obfuscation, embedded secrets, local data leakage.
  • Network side (API and traffic): Certificate pinning, weak TLS, broken authentication, API authorization flaws.
  • Device side (platform interaction): Keystore/Keychain usage, IPC, deep links, screenshot and clipboard leaks.

For the general penetration testing process, scope and pricing see our penetration testing process and pricing article, and for test types see penetration testing types and scope. This article focuses only on mobile specific topics.

The OWASP MASVS and MASTG Framework

The industry standard for mobile security is the OWASP Mobile Application Security project. It has two core components:

  • MASVS (Mobile Application Security Verification Standard): Answers the question what should be verified. It groups security requirements into categories.
  • MASTG (Mobile Application Security Testing Guide): Answers the question how to test. It provides step by step techniques for Android and iOS.

MASVS Control Groups

The current MASVS organizes requirements into seven main control groups:

  • MASVS-STORAGE: Secure storage of sensitive data and prevention of leakage.
  • MASVS-CRYPTO: Correct use of cryptography, no hardcoded keys.
  • MASVS-AUTH: Authentication and authorization mechanisms.
  • MASVS-NETWORK: Secure network communication, TLS and certificate pinning.
  • MASVS-PLATFORM: Secure use of platform APIs, IPC, WebView and deep links.
  • MASVS-CODE: Code quality, up to date libraries, disabled debug flags.
  • MASVS-RESILIENCE: Resistance to reverse engineering and tampering (root/jailbreak detection, obfuscation).

MASVS also defines maturity levels: L1 for basic security, L2 for high risk apps (banking, healthcare) and an R (resilience) profile for apps needing intellectual property protection.

OWASP Mobile Top 10 (2024)

The OWASP Mobile Top 10 ranks the most common mobile risk categories. The current 2024 list includes:

  1. M1 - Improper Credential Usage: Hardcoded API keys, passwords and insecure credential handling.
  2. M2 - Inadequate Supply Chain Security: Insecure third party SDKs and libraries.
  3. M3 - Insecure Authentication/Authorization: Weak session management, bypassable authorization.
  4. M4 - Insufficient Input/Output Validation: Injection, XSS through WebView.
  5. M5 - Insecure Communication: Weak TLS, missing certificate pinning.
  6. M6 - Inadequate Privacy Controls: Excessive collection and leakage of personal data.
  7. M7 - Insufficient Binary Protection: Easy reverse engineering, missing obfuscation.
  8. M8 - Security Misconfiguration: Open debugging, wrong permissions.
  9. M9 - Insecure Data Storage: Unencrypted local storage of sensitive data.
  10. M10 - Insufficient Cryptography: Weak algorithms, poor key management.

Static Analysis or Dynamic Analysis?

Mobile testing uses two complementary approaches. Both are required; each catches what the other misses.

Criterion Static Analysis (SAST) Dynamic Analysis (DAST)
How it works Binary/source inspected without running the app Behavior monitored while app runs on device
Issues found Hardcoded secrets, weak crypto, permissions, obfuscation Runtime data leakage, pinning bypass, IPC abuse
Typical tools jadx, apktool, MobSF, Ghidra, class-dump Frida, Objection, Burp Suite, Wireshark
Root/JB needed No Usually yes (or repackaging)
Advantage Fast, broad coverage, source visible Proves real behavior, low false positives
Limitation Cannot see runtime behavior Only sees triggered code paths

In practice the flow is: first map the target with static analysis (entry points, endpoints, suspicious functions), then validate those findings at runtime with dynamic analysis.

Android Penetration Testing

Static Analysis: APK Decompile and Inspection

The first step is taking the APK apart. An APK is essentially a ZIP archive containing compiled DEX bytecode, resources and the manifest.

# Pull APK from the device
adb shell pm path com.target.app
adb pull /data/app/com.target.app-1/base.apk

# Decode resources and manifest (apktool)
apktool d base.apk -o output_folder

# Convert DEX to readable Java (jadx)
jadx -d jadx_output base.apk
# or with GUI:
jadx-gui base.apk

In the manifest, the priorities are:

  • android:debuggable="true" (is debugging enabled)
  • android:allowBackup="true" (data leakage via backup)
  • Components with android:exported="true" Activities, Services, BroadcastReceivers and ContentProviders (IPC attack surface)
  • usesCleartextTraffic and network_security_config (cleartext traffic allowed)
  • Dangerous permissions and custom intent-filters (deep links)

Search the source for hardcoded secrets:

# API key, password, token patterns
grep -rEi "api_key|secret|password|token|aws_|firebase" jadx_output/

# Embedded values in strings.xml and BuildConfig
grep -rn "https://" jadx_output/resources/

Automated Static Scanning With MobSF

MobSF (Mobile Security Framework) combines static and dynamic analysis in one interface. For a static scan:

# Run MobSF with Docker
docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf
# Upload the APK/IPA at http://localhost:8000

MobSF automatically produces manifest analysis, certificate checks, hardcoded secrets, permission assessment and MASVS mapping. Its output is the starting point for manual review, not the end of it.

Local Data Storage Testing

How the app stores sensitive data is one of the most critical topics. Inspect the running app's data directory:

# Access the app data directory (root required)
adb shell
su
cd /data/data/com.target.app/

# SharedPreferences (often holds cleartext passwords/tokens)
cat shared_prefs/*.xml

# SQLite databases
find . -name "*.db"
sqlite3 databases/app.db ".tables"

# Cache and external storage
ls -la cache/ files/

Vulnerabilities sought: cleartext stored credentials, unencrypted databases, sensitive data written to external storage (SD card) and tokens leaking into logs.

Dynamic Analysis: Frida and Objection

Frida injects code into the running app, letting you trace and modify functions at runtime. Objection is built on Frida and offers ready made commands.

# Install and run frida-server on the device (root)
adb push frida-server /data/local/tmp/
adb shell "chmod 755 /data/local/tmp/frida-server && /data/local/tmp/frida-server &"

# List running apps
frida-ps -Ua

# Attach to the app with Objection
objection -g com.target.app explore

Common commands in an Objection session:

# Dump Keystore contents
android keystore list

# Watch local storage at runtime
android hooking watch class_method com.target.app.LoginManager.checkAuth

# List all loaded classes
android hooking list classes

Bypassing Root Detection

High security apps detect root and refuse to run on rooted devices. To test, this check is bypassed:

# Disable root detection with one Objection command
android root disable

For more complex detection a custom Frida script is written. For example hooking the methods of the RootBeer library to return false:

Java.perform(function() {
  var RootBeer = Java.use("com.scottyab.rootbeer.RootBeer");
  RootBeer.isRooted.implementation = function() {
    console.log("[+] isRooted() bypassed");
    return false;
  };
});

Certificate Pinning Bypass

Certificate pinning makes the app trust only a specific certificate, blocking man in the middle (MITM) inspection of API traffic. For testing it must be bypassed:

# Universal pinning bypass with Objection
android sslpinning disable

This targets OkHttp CertificatePinner, TrustManager and common pinning libraries. After bypass, all HTTPS API traffic becomes readable through a Burp Suite proxy and API security can be tested.

IPC and Component Testing

Components with exported=true can be triggered by other apps. If authorization is weak, authentication can be bypassed:

# Start an exported Activity
adb shell am start -n com.target.app/.AdminActivity

# Trigger an exported Service
adb shell am startservice -n com.target.app/.SyncService

# Query data from a ContentProvider
adb shell content query --uri content://com.target.app.provider/users

iOS Penetration Testing

iOS testing requires a physical jailbroken device or a suitable test environment; the simulator is insufficient for most checks.

Static Analysis: IPA Inspection

An IPA is also a ZIP archive. It contains a Payload/App.app directory, the main binary (Mach-O), Info.plist and resources.

# Unpack the IPA
unzip App.ipa -d ipa_output

# Inspect Info.plist (URL schemes, permissions, ATS settings)
plutil -p ipa_output/Payload/App.app/Info.plist

# Extract class and method names
class-dump ipa_output/Payload/App.app/App

# Embedded strings and secrets in the binary
strings -a App | grep -Ei "key|secret|token|https"

In Info.plist, pay attention to NSAppTransportSecurity (ATS); NSAllowsArbitraryLoads = true indicates cleartext or weak TLS connections are allowed.

Binaries downloaded from the App Store are encrypted (FairPlay DRM). For static analysis they are decrypted first:

# Decrypt the running app on a jailbroken device
frida-ios-dump -u com.target.app
# or use dumpdecrypted/bagbak

Local Data Storage Testing (iOS)

Inspect the app's data directory. For sensitive data check these locations:

  • Library/Preferences/*.plist (NSUserDefaults, often cleartext)
  • SQLite databases under Documents/ and Library/Caches/
  • Keychain (the correct place for passwords and tokens, but risky if the access class is wrong)
# Dump the iOS Keychain with Objection
ios keychain dump

# View NSUserDefaults contents
ios nsuserdefaults get

The Keychain access class is critical: instead of kSecAttrAccessibleAlways or ...AfterFirstUnlock, use ...WhenUnlockedThisDeviceOnly; otherwise data can leak from backups or while locked.

Dynamic Analysis: Frida and Objection (iOS)

# Attach to the app on the device
objection -g com.target.app explore

# Search loaded classes
ios hooking list classes

# Watch a specific method
ios hooking watch method "-[LoginViewController validatePassword:]" --dump-args --dump-return

Jailbreak Detection Bypass

# Disable jailbreak detection with Objection
ios jailbreak disable

For manual bypass, typical checks are targeted: presence of /Applications/Cydia.app, success of the fork() call, writable system directories. With Frida the functions returning these checks are hooked.

Certificate Pinning Bypass (iOS)

# Pinning bypass with Objection
ios sslpinning disable

This command targets TrustKit, AFNetworking and NSURLSession based pinning. Afterwards API traffic is inspected with Burp Suite or mitmproxy.

Android vs iOS Testing Differences

The two platforms share the same MASVS goals but the technical details differ.

Topic Android iOS
Package format APK (ZIP + DEX) IPA (ZIP + Mach-O)
Decompile tool jadx, apktool class-dump, Hopper, Ghidra
Secure storage Keystore + EncryptedSharedPreferences Keychain + Data Protection
IPC mechanism Intent, ContentProvider, Service URL scheme, Universal Link, XPC
Root/JB testing adb + frida-server easy Jailbroken device required, more limited
Binary encryption None (DEX open) FairPlay DRM (decrypt first)
Device access adb open and flexible More closed, restricted access
Sideloading Easy (apk install) Requires certificate/profile

General rule: Android testing is more accessible thanks to tool diversity and an open ecosystem; iOS testing requires more preparation due to device, jailbreak and signing constraints.

API Security: The Heart of Mobile Testing

The vast majority of mobile apps talk to a backend API where the real business logic lives. After pinning is bypassed, inspecting the traffic lets you test for:

  • Broken Object Level Authorization (BOLA/IDOR): Changing a userId parameter to access another user's data.
  • Weak authentication: Predictable tokens, sessions that never expire, refresh token abuse.
  • Excessive data exposure: The API returning more fields to the client than needed.
  • Missing rate limiting: Openness to brute force and enumeration.
  • Business logic bypass: A client side check not repeated on the server.

Remember: every check done on the client can be bypassed. Security decisions must always be validated server side.

Automating Mobile Security Testing With KAOS

DSET's AI powered offensive security agent KAOS AI security engine accelerates manual work in authorized mobile tests. On the mobile side KAOS automates:

  • APK/IPA static analysis: Automatic decompilation of the binary, mapping hardcoded secrets, weak crypto usage and risky permissions to MASVS controls.
  • API traffic inspection: Detection of authorization and authentication flaws in traffic captured after a pinning bypass.
  • Exploit generation and validation: Validating detected flaws with proof (PoC); demonstrating real exploitability without producing false positives.
  • Continuous regression testing: Automatic checks for whether the same vulnerabilities reappear in each new release.

Key principle: KAOS operates only within authorized tests, with customer approval and a defined scope. Its goal is not to replace the expert analyst but to automate repetitive work so the expert can focus on deep manual review. Our methodology aligns with the PTES methodology.

Mobile Penetration Testing Flow (Summary)

  1. Scope and authorization: Target app versions, backend endpoints and test accounts are defined.
  2. Static analysis: APK/IPA decompiled, MobSF scanned, manifest/Info.plist and hardcoded secrets inspected.
  3. Environment setup: Rooted/jailbroken device, frida-server, proxy and certificate installed.
  4. Dynamic analysis: Root/JB and pinning bypass performed, runtime traced with Frida.
  5. Data and IPC testing: Local storage, Keystore/Keychain and exported components tested.
  6. API testing: Authorization, authentication and business logic checked in captured traffic.
  7. Reporting: Findings mapped to MASVS/Mobile Top 10, presented with PoC and remediation advice.

Frequently Asked Questions

Does the device need to be rooted or jailbroken for mobile pentesting?

Not for static analysis; the APK/IPA file is inspected on a computer. However, for dynamic analysis (runtime tracing with Frida, local storage access, pinning bypass) a rooted Android or jailbroken iOS device is practically required. As an alternative, repackaging and Frida Gadget injection can be used, but this is more limited.

Is certificate pinning bypass legal?

It is legitimate when done for testing within a defined scope on your own app or one you have written authorization for. Attempting a pinning bypass against an unauthorized app or interfering with its traffic is illegal. DSET conducts all tests with customer approval and a contracted scope.

Is MobSF enough on its own?

No. MobSF is an excellent starting point and quickly produces automated static findings, but it cannot catch business logic flaws, runtime data leaks or API authorization errors. Automated tools scan; real vulnerabilities are confirmed by expert manual analysis and dynamic testing.

Which is more important, static or dynamic analysis?

Both are required and complement each other. Static analysis surfaces hardcoded secrets, weak crypto and code structure; dynamic analysis proves what the app actually does, how it stores data and how it talks to the API. Relying on only one causes important findings to be missed.

How often should mobile apps be tested?

Testing is recommended on every major release and significant architectural change. For high risk apps such as banking, healthcare and payments, at least one comprehensive test per year plus continuous regression testing is ideal. Automation tools like KAOS speed up this cycle by repeating baseline checks on every release.

Sources

DSET Information and Cyber Security (established 2003). For corporate mobile application security testing and KAOS support: +90 536 662 38 09.