NOTES
The Android stack is a chain rather than one tool: acquire the exact app build, understand the manifest and resources, observe traffic, inspect storage and logs, and use runtime instrumentation only when static and behavioral evidence require it.
I keep production accounts and personal devices out of the lab. Test identities, emulator snapshots, proxy certificates, and captured application data are all part of the evidence boundary.
WORKFLOW
- Record package name, version, signing information, architecture, SDK levels, and split APKs.
- Inspect the manifest, exported components, permissions, deep links, backup behavior, and network security configuration.
- Run through the normal user flows before modifying the app or runtime.
- Proxy traffic and determine whether the app trusts user, system, or pinned certificates.
- Review application storage, logs, WebViews, intents, and inter-process boundaries.
- Use Frida or Objection to validate a specific hypothesis, not to bypass every control automatically.
COMMANDS
adb devices -ladb shell pm path PACKAGEadb shell dumpsys package PACKAGEadb logcat --pid=$(adb shell pidof PACKAGE)adb shell run-as PACKAGE ls -laGOTCHAS
- Install every required split APK for the same release.
- An emulator root or userdebug build changes the threat model; say so in the report.
- A proxying failure may be certificate trust, pinning, QUIC, native networking, or an unproxied process.
- Clear test data and restore snapshots between account-bound authorization tests.
- Capture the in-app impact in addition to proxy or console output.