Mobile Security

Mobile Security

Scope

End-to-end mobile application VAPT for Android (APK/AAB) and iOS (IPA), aligned to the OWASP MASVS v2.x control groups and the MASTG testing process. Four complementary tiers:

1. Static reverse engineering of compiled artifacts — Dart AOT snapshots, Unity IL2CPP, React Native/Hermes bytecode, native ARM64 .so/Mach-O, smali. Recover secrets, endpoints, and the crypto contract without a device.
2. SAST — manifest / Info.plist, exported-component & IPC surface, WebView, local storage, cryptographic-primitive weakness, code-signing, and automated baseline (MobSF/apkid/apkleaks) → then manual deep-dive.
3. Dynamic analysis (DAST) — Frida/objection instrumentation, traffic interception, TLS-pinning bypass across stacks, Keychain/Keystore runtime dumps, IPC probing, and root/jailbreak/anti-tamper defeat for MAS-L2 / MASA scope.
4. Privacy — data-collection inventory, tracker/SDK enumeration, PII leakage, declared-vs-actual (Play Data Safety / Apple Privacy Manifest).

Static dump first (faster, no device); dynamic is a first-class phase whenever a control can only be proven at runtime (enforced pinning, Keystore-backed keys, root reaction, IPC guards). Cross-asset stitching, scoring, and reporting are owned by sibling skills — this skill produces MASVS/MASTG-tagged findings and hands them off.

Coverage contract

In a coverage-mode engagement (pentest-engagement mobile mode) completion is code-enforced, not narrative. Two surfaces are gated, and both are mandatory:

The second row is where the material risk has historically been. A decompiled bundle hands you the full server contract, and that surface is not browser-reachable — so it is systematically under-tested by everyone, including the app's own developers. Recovering the endpoint inventory and driving it through the API classes is not an optional extra; a bundle that yields zero endpoints is treated as a failed acquisition.

Per-class detail: reference/masvs-class-map.md. Two rules worth internalising before you write a negative:

• proof_mode: runtime cannot be closed statically. Pinning and root detection are the classic traps: static analysis can prove a control is inert (a CertificatePinner built and never attached, a RootBeer that no DEX references) — raise that as a positive. It can never prove the control is effective; that needs a bypass attempt that failed, and a failed bypass is a legitimate, reportable result.
• proof_mode: static can never be device-deferred. No device does not excuse the manifest, the signature, the bundled dependencies, or the secrets in the artifact.

When to use

• Target ships an Android APK/AAB or iOS IPA — extract and inspect before any runtime testing.
• Built with Flutter (lib/arm64-v8a/libapp.so / iOS App.framework), Unity (libil2cpp.so + global-metadata.dat), or React Native + Hermes (libhermes.so + index.android.bundle) — needs a runtime-aware decompiler, not just jadx.
• Stock Android/iOS app — you need the manifest/IPC/storage/crypto/signing attack surface (SAST) and, where a control is runtime-only, dynamic confirmation.
• App uses encrypted API envelopes (KEY/IV/SALT/SIGNATURE headers) and you need to reverse the crypto contract, then replay against the live API.
• TLS pinning / root / jailbreak detection blocks testing — bypass it dynamically (or defeat it statically) and demonstrate the protected flow.
• You suspect IDOR / mass assignment / business-logic flaws easier to find in the dumped client, then confirmed server-side.
• You need a MASVS-PRIVACY pass (trackers, over-collection, PII leakage, declared-vs-actual).

Methodology