iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

Mobile Pentesting Basics

By · Reviewed & last updated · Part of Ethical Hacking Tutorial

Defensive view: mobile app security. Authorised engagements only. Focus on what blue teams should harden in iOS and Android apps.

Defender-first overview

EXAMPLE
# Mobile app security - defender perspective

> Lab and authorised engagements only. This page describes mobile app
> security patterns so defenders can build controls. Live testing
> against production apps requires owner consent, scoped Rules of
> Engagement (RoE), and app-store policy compliance. We do not
> publish step-by-step app cracking, store policy circumvention, or
> any technique aimed at user-installed apps without owner authorisation.

## Common weaknesses (defender lens)

- Hard-coded API keys, tokens, or AWS access keys in shipped binaries
- Insecure local storage: secrets in SharedPreferences / NSUserDefaults
- WebViews with debug enabled or arbitrary URL loading
- Certificate pinning missing or trivially bypassed
- Deep links not validated - intent / universal link redirects
- Old protocols (Smb1, TLS 1.0) negotiated for telemetry endpoints
- Misuse of platform crypto APIs (ECB, static IV, custom math)

## Controls that move the needle

- Secrets handled server-side; mobile receives short-lived tokens only
- Keychain (iOS) / Keystore (Android) for sensitive data; biometric prompt for unlock
- Certificate pinning with rotation strategy; backup pin so you can rotate without bricking
- Verify deep link sources - intent filters + Android App Links + iOS Universal Links
- Disable JS interface, debug, and file access on WebViews unless explicitly needed
- Code obfuscation for native code where it raises the bar (R8/ProGuard for Android, bitcode/symbol stripping)
- Re-sign and re-fingerprint with each release; ship build attestations

## Server-side mitigations

- Short-lived tokens; refresh-token rotation; revoke server-side
- Device-bound credentials (DPoP, attestation-backed sessions)
- Anomaly detection on backend (impossible travel, rooted/jailbroken signals from attestation)
- Server is the source of truth for entitlements; client cannot self-grant

## Detection signals

- Mass downloads of a beta build from a single IP
- Spike in API errors for older versions (indicator of replay/repackaging)
- New devices presenting old attestation tokens
- Unusual binary hashes in your crash reporter

## Engagement reporting

- Categorise findings by client-side hardening vs server-side controls
- Recommend short-term fixes (token TTL, pinning) and long-term (attestation, server-of-record)
- Never include user data in reports; redact at the source

Why it matters

Mobile security is mostly server-side: short-lived tokens, server-of-record for entitlements, attestation-backed sessions. Client hardening (pinning, keychain, WebView discipline) raises the bar but does not stop the determined attacker - that is what the server does.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
# Mobile basics:
#   - Use a rooted/jailbroken DEVICE you own.
#   - Static analysis with MobSF.
#   - Dynamic with Frida + Burp.
# Common findings: hard-coded API keys, missing cert pinning, insecure logs.
Try it Yourself »

Discussion

Loading…