Mobile App Testing Notes: APK Analysis, Jailbreak Detection, and Traffic Interception#

Why this topic matters: the phone is where credentials, tokens, and payment flows live in plain sight of the app, so the app deserves the same review as the API.

Ethics and scope: test builds the vendor gave you, or your own build. Do not strip protections from apps you have no permission to analyze. API classes behind the app are covered in OWASP Top 10 notes.

Android: Start From the Package#

The APK is a zip of code, resources, and a manifest. Work in that order.

Static analysis#

1. Unzip the APK and look at AndroidManifest.xml.
2. Note exported activities and services.
3. Check permissions, especially the dangerous set: camera, location, SMS, contacts.
4. Look for hard-coded endpoints, debug flags, and test keys.

Dynamic analysis#

Run the app on an emulator or an instrumented device and watch it call home. Tools that help:

The first dynamic question#

Does the app validate the API's responses? Many apps render whatever the server returns, which just moves the finding to the web side. For that side, see the XSS delivery notes.

The Manifest Checklist#

iOS: Trust, Then Bypass, Then Read#

Getting a test device#

A jailbroken or instrumented device lets you inspect the filesystem and hook Objective-C methods. Use your own hardware and your own app builds.

Reading the binary#

1. Dump the decrypted IPA.
2. Class-dump to see the Objective-C interface.
3. Check for ATS settings, plist flags, and embedded keys.
4. Trace network setup in the delegate.

SSL Pinning: The Gate#

Most hardened apps pin the server certificate inside the app. Until you can see the traffic, every other check is guesswork.

Approaches#

Document which one you used, because the report's reproducibility depends on it.

Traffic Interception Setup#

1. Put the device on a test Wi-Fi you control.
2. Configure the device to use the proxy.
3. Install the proxy CA on the device.
4. Run the app and watch the history.
5. Disable pinning in a test build, not the release.

Copy code
# Device points at your laptop's proxy, e.g.
# adb shell settings put global http_proxy 192.168.1.10:8080
# Proxy: Burp or mitmproxy, with its CA trusted on the device.

Common Findings#

Proxy Side Notes#

Once the device talks to your proxy, the web-side skills transfer: Burp basics, ZAP notes, and the API-side checks in the BOLA matrix.

Storage Review#

• What lives in SharedPreferences, the keychain, or the app group?
• Are tokens rotated?
• Does anything write secrets to the filesystem?
• Does a backup export include the session?

Copy code
# Android: look at shared_prefs and cache
adb shell run-as com.example.app ls shared_prefs/
# iOS: dump the app container from a test device
# objection --gadget com.example.app explore --> ios keychain dump

What to Note in the Report#

• The build under test: version, signing state, source.
• The pinning state: on, off, or bypassed for this build.
• The exact proxy setup.
• One screenshot per finding, trimmed.

False Positives to Expect#

• Cleartext that only fires on a debug endpoint.
• Tokens in logs that are already rotated.
• Pinning that breaks the app on some devices but not others.
• A debuggable flag on a staging build, not the production one.

Walkthrough: One Session#

1. Install the test build on the instrumented device.
2. Configure the proxy and the CA.
3. Disable pinning in the test build.
4. Exercise the main flows for ten minutes.
5. Export the proxy history to JSONL.
6. Sort the requests: GET, POST, and mutating POSTs first.
7. Replay the mutating POSTs with changed fields.
8. Record the mutations that worked and the ones that were blocked.

Walkthrough: Storage Pass#

1. With the app open and logged in, snapshot the app container.
2. Log out and snapshot again.
3. Diff the two snapshots.
4. Note what survives logout: tokens, caches, keys.
5. Repeat the check after a failed login.

Walkthrough: Manifest Pass#

1. Decompile the APK with jadx.
2. Copy every exported activity and service into a table.
3. For each, note whether it requires a permission.
4. Check each deep link for input validation.
5. Record one line per entry point.

Limits of These Notes#

• Protections change with each app release.
• Pinning bypass methods differ per app.
• A finding on a test build may not reproduce on release.
• Traffic interception only works where the app cooperates.
• These notes cover the manual side; automated mobile scans exist but this note does not score them.

The Small Ethics Section#

Do not apply this workflow to apps you have not been given permission to test. A bypassed pinning check is not a bypassed consent. Pair this testing with a scope document that names the bundle IDs, the builds, and the devices.

Related Reading#

• The API behind the app: API access control test plan.
• The hidden-field problem on APIs: shadow API inventory.
• Server action analogs for mobile: server actions authorization.
• Class context: web hacking 101.
• Delivery of the web views: XSS types compared.
• Cloud backend behind the app: AWS testing notes.
• Web-side recon that feeds this: automating dead link detection.
• The tool that watches the network: Wireshark guide.
• The roadmap: reading order.
• The triage mindset: denied request alert triage.

Glossary#

Closing Notes#

The phone app is a client with better networking than the web. Treat it as one. The checks that matter are the same ones the web runs: does the API trust the client, does the client trust the server, and does the client trust what it renders.

Packets You Will See#

False Friends on Mobile#

• A finding on an emulator that does not reproduce on the hardware build.
• Pinning that fails only when the device clock is wrong.
• Trace logs that only appear on debug devices.
• A storage snapshot taken after the app was backgrounded and re-logged.

Small Rules#

• Pin state is a fact about the build, record it.
• Proxy history is evidence, export it.
• Cleartext is a finding only when the request carries real data.
• A token in a log is one fact; a token that works twice is another.

Where These Notes End#

They end where the interesting logic moves to the server, which is why every mobile session should be paired with the web-side notes: OWASP Top 10 notes for the class map, API access control test plan for the authz shape, and shadow API inventory for endpoints the mobile app did not advertise.

What to Avoid#

• Shipping a report without the build identifier.
• Calling cleartext a finding when the request carried a public asset.
• Claiming a pinning bypass you cannot reproduce on the release build.
• Treating a web view renderer as a mobile-only bug.

A Cross-Check List#

• Pin state recorded?
• Build identifier recorded?
• Proxy history exported?
• Exported components enumerated?
• Storage snapshot diffed across logout?
• One scanner pass, one manual pass, one writeup?

A Short Example Session#

Copy code
09:12  app started, debug logcat captured
09:14  login POST captured, token refresh noted
09:19  storage snapshot taken
09:23  logout, snapshot taken, diff shows token remains
09:31  exported component list written to notes
09:40  history exported to JSONL

Six timestamps; enough to reconstruct what was tested and what was found.

A Note on Builds#

Test the build you ship notes about. Internal builds often differ from release builds in pinning, debuggability, and cleartext settings. The build identifier belongs in the report header.

Per-Permission Triage#

One More Loop#

Dump, intercept, replay, compare, record. Same loop as web, different tooling. The discipline transfers; the class does not change.

Proxy History Hygiene#

Save the session, trim the history, keep the POST bodies that matter, and export one JSONL before closing. The next run can diff against it, and the finding travels with the session instead of the memory.

Final Shape#

One build, one proxy session, one writeup. Mobile adds two facts to the web discipline: the pinning state and the storage snapshot. Record both, and the note stands on its own.

Ties to the Web Side#

The mobile session usually hands you an API map. Hand that map back to the web-side notes: API access control test plan for authz, BOLA test matrix for object access, and shadow API inventory for endpoints the app never names.

Wrapping Up#

The loop is short on purpose. Dump, intercept, replay, compare, record. Everything else in this note is a way to keep that loop honest against a mobile target.

One Screen, One Rule#

Treat every screen as a renderer, every field as a payload candidate, and every request as a record. The phone shows you more of the app's logic than any single page does; write it down while it is open.

Traffic Interception Checklist#

1. Install the CA on the device trust store; on iOS this means Settings -> General -> About -> Certificate Trust Settings, then enabling full trust for the proxy CA.
2. On Android 7+, user CAs are ignored by default. Use an emulator with a writable system partition or Frida's objection android sslpinning disable.
3. Point the proxy at the app's traffic and watch for the first TLS error. That error names the pinning code path.
4. If the app uses certificate transparency enforcement, expect pinning to be layered; one bypass rarely suffices.

Manifest Triage#

Start with aapt dump badging app.apk and aapt dump permissions app.apk. Exported activities without permission guards show up as android:exported=true with no android:permission attribute. Deep links registered through <intent-filter> deserve the same scrutiny as any public endpoint.