I've been spending a lot of time going deep on mobile application security, specifically around how Android and iOS apps get attacked and defended at every layer. This post covers the full picture: platform architecture, attack tooling, reverse engineering workflows, runtime protection, and the ongoing cat-and-mouse game between offense and defense.

1. Threat Landscape

Before getting into specifics, here's the high-level map of what mobile apps are up against:

Apps that handle authentication, transaction integrity, and sensitive data -- PII, tokens, session keys -- are the highest-value targets. A compromised app directly enables fraud at scale.

2. Platform Architecture

Understanding what you're defending against starts with understanding what the platforms actually guarantee.

Android

Android is built on a modified Linux kernel:

• UID Isolation: Every app gets a unique Linux UID and its own ART VM instance. The kernel enforces process separation.
• SELinux: Enforcing mode since Android 5.0. Apps are confined to SELinux domains restricting system calls and file paths.
• Permissions: Post-6.0, runtime permissions require individual user grants. Weakness: users routinely grant everything.
• Sideloading: APKs installable by toggling "Install from unknown sources." Major attack surface.
• APK Structure: ZIP archive containing DEX bytecode. Decompiles cleanly to near-original Java/Kotlin via JADX.
• Dynamic Code Loading: DexClassLoader allows loading new DEX files from disk or network at runtime.

iOS

iOS is built on the XNU kernel (Mach + BSD hybrid):

• App Sandbox (Seatbelt): Each app gets its own container directory. Kernel-level enforcement prevents cross-app data access.
• Mandatory Code Signing: Every binary, dylib, and executable memory page must be signed. Enforced by AMFI at kernel level.
• No Sideloading: App Store only (or TestFlight). Enterprise cert workarounds exist but are actively revoked.
• Entitlements: Capabilities baked into code signature. Cannot modify without re-signing.
• Mach-O Binaries: Compiled native ARM64. Harder to reverse engineer than DEX. Symbols stripped in release.
• No Dynamic Code Loading: JIT blocked (except Safari's JSC). Code signing enforced on all executable pages.

From an Attacker's Perspective

3. Rooting and Jailbreaking

Android Rooting

Stock Android has no su binary -- no process can escalate to UID 0. Rooting installs su plus a management app.

Magisk (Systemless Root): Patches boot.img rather than /system. System stays untouched, bypassing some integrity checks. Provides Zygisk + DenyList to hide root from target apps.

KernelSU: Operates entirely within the kernel. No su binary on the filesystem. Grants root via a kernel mechanism. Significantly harder to detect from userspace.

What root enables:

• Read any app's /data/data/<package>/ -- preferences, databases, tokens
• Modify app APKs or runtime memory
• Install Xposed/LSPosed for system-wide hooking
• Disable SELinux (setenforce 0)
• Intercept and modify network traffic at the OS level

iOS Jailbreaking

A jailbreak exploits vulnerabilities to disable three mechanisms:

1. AMFI -- code signing enforcement bypassed, unsigned code executes
2. Sandbox -- apps access files outside their container
3. Root filesystem -- remounted read-write

The types matter because detection strategies differ:

• Untethered: persists across reboots (very rare now)
• Semi-tethered: requires a computer to re-jailbreak after reboot
• Semi-untethered: on-device app re-jailbreaks (unc0ver, Dopamine)
• Rootless (Dopamine 2.0): operates within /var and preboot. Does not remount root filesystem. Evades traditional filesystem-based detection entirely.

What Becomes Possible on a Compromised Device

4. Reverse Engineering Android APKs

Obtaining the APK

adb shell pm path com.target.app
adb pull <path>

For App Bundles (AAB): use bundletool to merge split APKs first.

Static Analysis

apktool d target.apk -o output_dir       # Extract manifest, resources
apksigner verify --print-certs target.apk # Signing certificate
unzip -l target.apk | grep "\.so"         # Native libraries (need Ghidra, not JADX)

AndroidManifest.xml reveals the real attack surface:

• Exported components (exported=true = attack surface)
• debuggable=true in production -- critical vulnerability
• allowBackup=true -- adb backup extracts data without root
• Deep link intent filters -- potential hijacking
• networkSecurityConfig -- pinning configuration

Decompilation with JADX

jadx target.apk -d jadx_output

What to look for:

Dynamic Analysis with Frida

objection -g com.target.app explore
> android sslpinning disable

// Hook a function at runtime
Java.perform(function() {
    var cls = Java.use("com.target.app.TransactionManager");
    cls.transferMoney.implementation = function(amount, recipient) {
        console.log("transferMoney: " + amount + " to " + recipient);
        return this.transferMoney(amount, recipient);
    };
});

Protections and Bypasses

5. Reverse Engineering iOS IPAs

Why iOS Is Harder

• Native ARM64 Mach-O vs. DEX bytecode. Ghidra/IDA output pseudocode, not original source.
• Stripped symbols: TransactionManager.transferMoney() becomes sub_100004A3C(). Exception: ObjC selectors survive because objc_msgSend dispatch requires them.
• FairPlay DRM: App Store binaries are encrypted. Must decrypt on a jailbroken device (frida-ios-dump, CrackerXI, bfdecrypt) before analysis.

Tool Mapping

Workflow

python dump.py com.target.app          # Decrypt IPA (frida-ios-dump)
unzip target.ipa -d output
plutil -p Payload/App.app/Info.plist   # URL schemes, ATS exceptions
otool -L Payload/App.app/App           # Linked libraries
jtool2 --objc Payload/App.app/App      # ObjC class/method dump

Frida on iOS uses the ObjC runtime directly:

var handler = ObjC.classes.PaymentHandler;
Interceptor.attach(handler['- processPayment:'].implementation, {
    onEnter: function(args) { console.log("payment: " + ObjC.Object(args[2])); }
});

6. Frida: Dynamic Instrumentation

Architecture

1. frida-server -- root daemon on target device
2. frida-client -- runs on your machine, sends commands via USB/network
3. frida-agent -- .so/.dylib injected into target process, runs V8 JavaScript engine

How Injection Works

Android (rooted): frida-server uses ptrace() to attach to the target process, forces it to dlopen() frida-agent.so, then the agent starts a V8 runtime inside the target's address space.

Gadget mode (no root): Repackage the APK with frida-gadget.so included. Loads on launch. Requires re-signing.

iOS: Uses task_for_pid() mach trap instead of ptrace(). The jailbreak patches the kernel to allow this.

Interceptor.attach() overwrites the first bytes of a target function with a trampoline (a jump to Frida's handler). Original bytes are saved for calling through. The function's machine code is modified in process memory.

Detection Techniques

7. Xposed/LSPosed: System-Wide Hooking

Xposed is more dangerous than Frida for a specific reason: it hooks before your app code runs at all.

How It Works

Android's Zygote process is the parent of all apps. It preloads framework classes, then fork()s for each app launch. Xposed modifies Zygote itself:

1. Replaces /system/bin/app_process with a modified version
2. Loads XposedBridge.jar into Zygote before any app launches
3. Provides findAndHookMethod() for intercepting any Java method
4. Hooks are inherited by every app process forked from Zygote

LSPosed: Uses Magisk's Zygisk for injection (systemless). Modules scoped per-app. DenyList covers hiding.

Why This Is a Different Problem Than Frida

Detection

• Class check: Class.forName("de.robv.android.xposed.XposedBridge") -- bypass: hook Class.forName()
• Stack trace: Check for Xposed frames -- bypass: hook getStackTrace()
• Native maps scan: /proc/self/maps for XposedBridge/lspd -- bypass: Zygisk manipulates layout
• ART internals: Check entry_point_from_quick_compiled_code_ in method metadata. Most robust, requires per-version ART knowledge.
• Behavioral (most resilient): Call functions that should fail and verify they fail. Perform crypto and verify server-side. If "should fail" succeeds, something is hooking.

8. SSL/TLS Pinning and Bypass

Why Pinning Exists

Devices trust 150+ root CAs. Any compromised or attacker-installed CA can issue valid certificates for any domain, enabling MITM. Pinning restricts trust to a specific certificate or public key regardless of the device's CA store.

Public key pinning (recommended) survives certificate rotation. Certificate pinning breaks when the cert renews.

Android Implementations

Network Security Config (platform-level, Android 7+):

<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">api.target.com</domain>
        <pin-set><pin digest="SHA-256">hash=</pin></pin-set>
    </domain-config>
</network-security-config>

OkHttp CertificatePinner (app-level): Only applies to connections through that specific client instance.

Custom TrustManager: Full control. Common vulnerability: empty checkServerTrusted() that accepts everything.

iOS Implementations

URLSession delegate: Implement didReceive challenge, extract server public key, compare against pinned hash.

TrustKit: Swizzles NSURLSession delegates. Can be un-swizzled by an attacker.

Bypass per Implementation

Defense Beyond Pinning

Pinning alone is insufficient on compromised devices. Stack these:

• Mutual TLS (mTLS): Client cert required. Private key in Keystore/Keychain.
• Request signing: HMAC/signature on each request. Intercepted requests unforgeable without the key.
• Proxy detection: Check system proxy settings.
• Server-side anomaly detection: Flag proxy-like traffic patterns.

9. Screen Overlay Attacks

Android's SYSTEM_ALERT_WINDOW permission allows floating windows on top of all apps.

Tapjacking: Transparent overlay intercepts or redirects taps on confirm buttons.

Credential harvesting: Malicious app monitors foreground via UsageStatsManager/AccessibilityService, draws fake login screen over target app when launched.

Partial overlay: Covers specific fields (recipient account number, for example) with different values.

Platform Mitigations Over Time

In-App Defenses

<Button android:filterTouchesWhenObscured="true" />

window.setHideOverlayWindows(true)        // Hide all overlays (API 31+)
window.setFlags(FLAG_SECURE, FLAG_SECURE) // Block screenshots/recording

10. OTP and SMS Interception

Mitigations

11. Root and Jailbreak Detection

Every individual check has a known bypass. That's the key insight. The only real approach is combining multiple methods, running them at unpredictable intervals, obfuscating detection code, and verifying results server-side.

Android

iOS

12. RASP Architecture

RASP (Runtime Application Self-Protection) is code shipped inside the app binary that continuously collects signals, computes risk, and enforces security decisions.

Signal Collectors

Risk Engine

risk_score = w1*root + w2*hook + w3*emulator + w4*debugger + w5*integrity + w6*behavioral

• 0-30: normal, log telemetry
• 31-60: block transactions, require step-up auth
• 61-85: block sensitive ops, alert backend
• 86-100: kill app, wipe tokens, server-side lock

The enforcement actions span a spectrum: silent telemetry, feature gating, step-up auth, token invalidation, app termination, server-side lockout. Proportional response matters -- hard-killing the app on any anomaly creates a bad user experience and gets bypassed the same way.

Self-Protection

RASP code is itself an attack target. Mitigations:

• Obfuscated via R8/LLVM
• Self-checksumming
• Critical logic in native C/C++
• Detection code scattered across the codebase (not one SecurityChecker class)
• Decoy functions waste the reverser's time

The server side makes final decisions using device fingerprint, behavioral analytics, attestation, and historical risk data. Never trust the client.

Commercial vs. Custom

13. Code Obfuscation, Hardening, and Integrity

Three distinct disciplines: obfuscation hides what code does, hardening makes code fight back, and integrity checking verifies code hasn't been modified.

Obfuscation

iOS: symbol stripping (Xcode default), O-LLVM/Hikari, iXGuard (renames ObjC selectors).

Hardening

Anti-debugging:

// Android native
if (ptrace(PTRACE_TRACEME, 0, 0, 0) == -1) { exit(1); }

// Android Java
if (Debug.isDebuggerConnected() || (applicationInfo.flags and FLAG_DEBUGGABLE != 0)) { /* kill */ }

// iOS
ptrace(PT_DENY_ATTACH, 0, 0, 0);

Anti-emulator: Check Build.FINGERPRINT for "generic", Build.HARDWARE for "goldfish"/"ranchu", sensor availability, OpenGL renderer, telephony data.

Anti-hooking: Verify function prologue bytes match compile-time expected values.

Environment binding: Bind keys to APK signature hash. Bind to installer (com.android.vending). Bind to device ID.

Integrity

• Signature verification: Compare runtime signing cert hash against expected value
• DEX checksumming: Hash classes.dex at runtime, store expected hash in native code
• Resource integrity: Hash assets, .so files, manifest
• Continuous verification: Periodic re-checks, guards guarding guards
• Server-side: Send hashes + Play Integrity attestation to backend

14. Cryptographic Key Storage

Android Keystore

Three backing tiers:

KeyGenParameterSpec.Builder("key", PURPOSE_SIGN)
    .setIsStrongBoxBacked(true)
    .setUserAuthenticationRequired(true)
    .setUserAuthenticationParameters(0, AUTH_BIOMETRIC_STRONG)
    .setInvalidatedByBiometricEnrollment(true)
    .build()

Key Attestation: Device generates a certificate chain proving hardware backing. Server verifies against Google root cert. Contains hardware type, OS version, boot state.

iOS Keychain

Encrypted database. Key derived from device UID (hardware-fused) + user passcode.

Secure Enclave

Dedicated coprocessor since A7 (iPhone 5S). Own boot ROM, encrypted memory, AES engine. No access from the application processor even at the kernel level. NIST P-256 EC keys only.

Attack Scenarios

15. Secure Data Storage

Android (Least to Most Secure)

iOS (Least to Most Secure)

What Goes Where

Common Mistakes

16. Device Fingerprinting and Risk Scoring

Fingerprinting

Combine multiple signals into a composite hash for persistent device identification:

Hardware (stable): CPU info, GPU renderer, display metrics, RAM, sensor list (model strings, ranges, vendor), camera config.

Software (less stable): Android ID / iOS IDFA, OS version, build number, fonts. Wi-Fi/BT MAC addresses are randomized since Android 10/iOS 14 -- unusable for identification now.

Behavioral (hardest to spoof): Typing cadence, touch pressure, accelerometer patterns, usage patterns, network/location history.

Risk Scoring

Signals evaluated in real-time:

• Environment: root, emulator, dev options, bootloader, SELinux, attestation
• Runtime: debugger, hooks, prologue tampering, unexpected libraries, thread count
• App integrity: signature, checksum, resource hashes, install source
• Network: VPN, proxy, TOR, IP-GPS mismatch, IP reputation
• Temporal: time since install, device first seen, attestation age, signal change frequency

Backend Intelligence

Context matters a lot. A device that's been clean for 6 months then suddenly shows root + Frida is a different risk profile than a device that's always been rooted (power user, lower risk).

• Cross-device: Same account on a new device from a different country = high risk
• Binding anomalies: 50+ accounts on one device = fraud farm. 10+ devices for one account in 24h = credential compromise.
• Velocity: Transaction/OTP request spikes vs. baseline
• ML models: Trained on labeled data learning complex signal correlations

Signal Integrity

17. OWASP MASVS and MASTG

MASVS is the standard framework for mobile security requirements. If you're doing security work on a mobile app, this is the checklist.

Categories

Verification Profiles

• MAS-L1: Baseline for all apps
• MAS-L2: Defense-in-depth for apps handling sensitive data
• MAS-R: Resilience against reverse engineering

High-security apps target L2 + R.

Assessment Phases

1. Static: Decompile, review manifest, map crypto/storage/auth issues, identify API surface
2. Dynamic: MITM testing, session analysis, storage inspection on rooted device
3. Resilience: Test each detection (root, Frida, Xposed, emulator, debugger, integrity) with known bypasses. Verify active response, not just logging.
4. Backend: Replay modified requests, expired tokens, stripped attestation headers, rate limit testing
5. Report: Each finding mapped to MASVS requirement + severity + reproduction + remediation

The throughline across all of this: every client-side control is a speed bump, not a wall. The goal isn't to build an impenetrable client -- that's not achievable. The goal is to raise the cost of attack, generate signals, and make the server-side trust decisions. Defense in depth across all these layers is what makes the economics of attacking a specific app unattractive.