Module 1 · Mobile App Security Threat Model 🔒

Mobile application security is a different discipline from web application security. The client-side code runs on a device you do not control, the communication channel can be inspected by the user, and the platform itself (Android or iOS) imposes a security model that testers must understand before they can meaningfully assess an app. This module builds the mental model you need before touching any mobile-specific tool.

How mobile apps differ from web apps

• Client trust is zero. The APK/IPA is shipped to the user. They can decompile, modify, and re-sign it. Any security decision made client-side is advisory at best
• Transport is inspectable. A user with root/jailbreak can proxy the app’s traffic, even if the app pins certificates — bypasses exist
• Local storage is exposed. SharedPreferences, SQLite databases, keychain items — all reachable by an attacker who owns the device
• Inter-process communication is an attack surface — Android Intents, iOS URL schemes, deep links, custom content providers
• Platform APIs provide security primitives (Keystore, Secure Enclave) that apps may or may not use correctly

The Android security model (brief)

Each Android app runs as a separate Linux user ID in its own process. The OS isolates apps from each other via standard Unix permissions plus the Android permission system (INTERNET, CAMERA, READ_CONTACTS, etc.). App components (Activities, Services, Broadcast Receivers, Content Providers) declared in the manifest can be exported — callable from other apps. Exported components without permission checks are a classic vulnerability class.

The iOS security model (brief)

iOS sandboxes each app to its own filesystem container. IPC is tightly restricted — XPC services, URL schemes, shared keychains with entitlements, and App Groups for sibling apps from the same developer. Code signing is mandatory; unsigned or resigned apps only run on jailbroken devices (or developer profiles). The Secure Enclave holds cryptographic keys that never leave the chip.

The OWASP Mobile Top 10 (2024 revision)

1. M1: Improper Credential Usage — hardcoded secrets, insecure storage of tokens
2. M2: Inadequate Supply Chain Security — unvetted SDKs, compromised dependencies
3. M3: Insecure Authentication/Authorization — broken session handling, weak server-side checks
4. M4: Insufficient Input/Output Validation — injection, data leaks in logs
5. M5: Insecure Communication — missing TLS, weak pinning, cleartext traffic
6. M6: Inadequate Privacy Controls — excessive data collection, leakage
7. M7: Insufficient Binary Protections — no obfuscation, no integrity checks
8. M8: Security Misconfiguration — debug flags, exported components
9. M9: Insecure Data Storage — plaintext databases, unprotected files
10. M10: Insufficient Cryptography — weak algorithms, ECB mode, reused IVs

What a mobile pentest actually assesses

Four testing surfaces, all covered in a proper engagement:

1. Static analysis of the binary — decompile APK/IPA, read manifest, inspect strings, check for hardcoded secrets and insecure patterns
2. Dynamic analysis on the device — run the app in a controlled environment (emulator or rooted/jailbroken device), hook functions, inspect behaviour at runtime
3. Local storage inspection — what the app writes to disk, whether it’s encrypted, whether keys are stored in the platform keystore
4. Network traffic — proxy all requests, understand the API surface, feed it back into web API testing (this is usually where the biggest findings come from)

The last one is important: most mobile app vulnerabilities are actually backend API vulnerabilities, exposed by the fact that the mobile app is a different client than the web app and may call different endpoints with different parameters. The mobile client is often an auth bypass waiting to happen because developers assumed it is harder to inspect.

Setting up your lab

A minimum viable mobile pentest lab:

• Android: Genymotion or Android Studio emulator with Google APIs image + Magisk root. Or a physical rooted test device
• iOS: jailbroken iPhone on a supported iOS version (getting harder each year; palera1n works on A9–A11 devices on iOS 15/16 as of 2026). Or use Corellium as a virtual iOS service
• Proxy: Burp Suite or mitmproxy with the CA certificate installed on the test device
• Static tools: JADX-GUI, apktool, MobSF, Ghidra (for native libraries), otool/class-dump (iOS)
• Dynamic: Frida (function hooking, cross-platform), Objection (Frida wrapper with pre-built scripts)
• Test environment: do not test against production without written authorization. Request a staging/test build with anti-tamper relaxed if possible

Scoping questions before engagement

Ask the customer before you start:

• What platforms (Android, iOS, both)?
• Production build or debug build for testing?
• Backend API in scope? (Usually yes — mobile without API is half a test)
• Target user role(s) — unauthenticated, standard user, admin?
• Is anti-tamper/root-detection in scope or will they provide a relaxed build?
• Jailbreak/root allowed on test devices?
• Business-logic flows they want specifically verified?

Reporting mobile findings

Two things mobile reports often get wrong:

1. Severity inflation. “App stores API endpoint in a decompiled class file” is low — the API is in the HTTP traffic anyway. Calibrate severity against real-world exploitability, not the existence of the artifact
2. Platform-specific remediation. Android and iOS have different fix patterns. A report that says “use secure storage” without specifying Keystore (Android) or Keychain (iOS) is not actionable

What the next modules cover

Module 2 walks through a real Android pentest with Objection and Frida — runtime hooking, bypassing SSL pinning, inspecting shared preferences. Module 3 does the same for iOS. Module 4 dives into the mobile backend API surface (where most real vulnerabilities live). Module 5 is the harder side — bypassing root/jailbreak detection and chaining mobile findings into an end-to-end exploit.