Mobile Pentesting Fundamentals

Why Mobile Is Different

Web pentesting gives you a server you can poke from anywhere. Mobile pentesting gives you a binary that runs on a device you control, talking to a backend that may or may not be in scope. The interesting bugs live in three places:

1. The client itself, secrets, logic, and storage
2. The traffic between client and backend
3. The exported surfaces the OS gives the app, intents, providers, deep links, IPC

Most teams ship the client first and treat the backend like a known-trusted partner. That assumption is usually wrong, and that is where the easy findings come from.

Environment Setup

Android

I prefer a physical device when I can, an emulator when I cannot. Pixel devices with GrapheneOS or stock plus Magisk give the cleanest experience.

# Verify adb is talking to the device
adb devices

# Pull an installed APK off the device
adb shell pm list packages | grep target
adb shell pm path com.target.app
adb pull /data/app/.../base.apk

For an emulator, I use Android Studio's AVD with a Google APIs image (not Play Store), which gives root via adb root out of the box.

# Start an emulator with a writable system partition
emulator -avd Pixel_API_33 -writable-system
adb root
adb remount

iOS

iOS is harder. Options, in order of preference:

1. A jailbroken iPhone running checkra1n, palera1n, or unc0ver, depending on iOS version
2. A Corellium virtual device, paid but worth it
3. A non-jailbroken device with a re-signed IPA from Frida-gadget injection

Once you have a jailbroken device, install:

# From Cydia, Sileo, or similar
- OpenSSH
- Frida (via the frida.re repo)
- Filza or another file manager
- Cycript or Objection

# Then connect from your laptop
ssh root@<device-ip>
# default password is 'alpine', change it immediately

Proxy Setup

Both platforms need a CA certificate installed and trusted before you can intercept HTTPS.

Android

Modern Android (7+) ignores user-installed CAs unless the app opts in via network_security_config.xml. For pentesting, push the cert to the system store:

# Convert Burp's cert to the format Android expects
openssl x509 -inform DER -in cacert.der -out cacert.pem
hash=$(openssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1)
mv cacert.pem ${hash}.0

# Push to system store (requires root)
adb root
adb remount
adb push ${hash}.0 /system/etc/security/cacerts/
adb shell chmod 644 /system/etc/security/cacerts/${hash}.0
adb reboot

iOS

Visit http://burp from Safari on the device, download the cert, then:

Settings > General > VPN & Device Management > Profile > Install

Then enable trust under Settings > General > About > Certificate Trust Settings.

Methodology

I work through the same checklist on every engagement, adjusted for whatever the app actually does.

1. Recon

• Pull the binary, decompile, look at the manifest or Info.plist
• Identify the framework, native, Flutter, React Native, Xamarin, Cordova
• Map the backend endpoints from strings, config files, and decompiled code
• List exported components, deep links, custom schemes, file handlers

2. Static Analysis

• Search for hardcoded secrets, API keys, tokens, signing material
• Review crypto usage, look for ECB, hardcoded IVs, weak hashes
• Check for debug flags, backup flags, exported components without permissions
• Look at obfuscation, root or jailbreak checks, anti-debugging

3. Dynamic Analysis

• Intercept traffic with Burp or mitmproxy
• Inspect local storage, shared preferences, NSUserDefaults, keychain, SQLite
• Hook sensitive functions with Frida
• Test auth and session handling, especially refresh and rotation

4. Bypass

• Defeat SSL pinning if present
• Bypass root or jailbreak detection
• Patch the binary or hook the checks at runtime

5. Exploit

• Test backend findings with intercepted requests
• Probe IPC, content providers, intents, URL schemes
• Test for client-side authorization decisions that should be server-side

Common Pitfalls

• Trusting that an app is "secure" because it has obfuscation. Obfuscation slows you down, it does not stop you
• Skipping the backend because the client looks complex. The backend is usually where the real bugs are
• Forgetting to check the app's behavior when offline or with a manipulated response
• Not checking what the app logs to logcat or Console.app, tokens leak there constantly

Related Notes

• Frida
• Objection
• Android App Analysis
• iOS App Analysis
• SSL Pinning Bypass