# Android Authorized App Pentest SOP

Use this file as the default entrypoint when the task is to test an authorized Android app and you need one stable operating sequence instead of choosing between multiple Android branches manually.

## Front Rule

Do not start with APK-first reverse analysis.

For an authorized Android app pentest, the default opening order is:

1. confirm the target app is installed on the connected device
2. get `burp` or `charles` ready for traffic visibility
3. open the app with `scrcpy_vision`
4. simulate real business clicks, navigation, text input, and feature use
5. after each important action, check whether `burp` or `charles` already sees HTTP/HTTPS requests or WebSocket messages
6. if traffic is visible and replayable, move directly into `03-web-security-integrated.md`
7. only escalate into `jadx`, `frida_mcp`, or `ida_pro_mcp` when traffic is absent, encrypted, opaque, unreplayable, or runtime evidence points to a client-side blocker

Reverse engineering is a blocker-resolution step, not the default entrypoint.

## Operating Goal

The first goal is not "understand the APK."
The first goal is "obtain a usable request or message and prove which UI action triggered it."

The standard loop is:

`app presence -> UI action -> screenshot/log check -> packet visibility -> replay -> Web/API/WebSocket testing`

## Default Read Order

1. `01-unified-methodology.md`
2. `02-client-api-reverse-and-burp.md`
3. `android-external-url-runtime-first-workflow.md`
4. `android-ui-driven-observation-and-packet-loop.md`
5. `03-web-security-integrated.md`
6. `05-tools-and-operations-integrated.md`

Read `android-signing-and-crypto-workflow.md` only when runtime-first testing proves that Java, hook, or native recovery is actually needed.

## Default MCP Chain

1. `scrcpy_vision`
2. `burp` or `charles`
3. `adb_mcp`
4. `jadx` only after runtime packet visibility fails
5. `frida_mcp`
6. `ida_pro_mcp` only for dumped `.so` analysis or native blocker resolution

## Step 1: Confirm device and app presence

Before any testing move:

- confirm the correct Android device `serial`
- confirm the target package is installed
- confirm whether the app is already foregrounded or must be launched

Typical helpers:

- `android_devices_list`
- `android_apps_list`
- `android_activity_current`
- `android_app_start`

If the app is not present, do not start reverse work as a substitute for environment validation.

## Step 2: Prepare packet visibility first

Before driving the feature:

- ensure Burp or Charles is the active capture path
- confirm proxy and certificate assumptions are already in place
- decide whether HTTP/HTTPS, WebSocket, or both are expected

The app should be exercised only after packet visibility is ready.

## Step 3: Drive the real business flow

Use `scrcpy_vision` to:

- wake or unlock the device
- open the app
- navigate to the target feature
- input required text or credentials
- tap, swipe, back, or confirm dialogs

If coordinate-based input is required, confirm the current screen resolution first.

## Step 4: After each important action, inspect runtime evidence

Do not jump straight from UI action to reverse.

After each important action:

1. inspect the current screenshot
2. review logs with `adb_mcp`
3. check `burp` or `charles` for HTTP/HTTPS requests or WebSocket messages

Look for:

- visible error dialogs, auth blockers, certificate warnings, blank states, or redirects
- TLS, parsing, auth, WebView, okhttp, retrofit, or JNI errors in logs
- newly appeared packets, missing packets, encrypted payloads, or replayable plaintext requests

## Step 5: Branch by packet result

### Case A: Packet is visible and replayable

- do not reverse first
- move directly into `03-web-security-integrated.md`
- test the API, Web, or WebSocket surface from the captured request
- preserve which screen state and action produced the packet
- repeat the loop for the next business feature

### Case B: Packet is visible but encrypted or opaque

- reverse Java first with `jadx`
- locate builder, interceptor, signer, encryptor, serializer, or JNI boundary
- use `frida_mcp` when hook-based plaintext recovery is faster than deeper static work

### Case C: Packet is missing

- re-check screenshot state
- re-check logs
- verify proxy and certificate assumptions
- if runtime setup is correct and traffic is still missing, escalate into Java recovery first

## Escalation Order

When runtime-first testing is not enough:

1. `jadx`
2. `frida_mcp`
3. dump the relevant `.so`
4. `ida_pro_mcp`

Do not dump native code first when Java or hooks can answer the blocker faster.

## Exit Criteria Before Payload Testing

Do not begin mutation or exploitation work until you can explain:

- which UI action triggered the request
- whether the request is HTTP/HTTPS or WebSocket
- whether login state, cookies, tokens, nonces, timestamps, or device values matter
- whether replay works outside the app
- which fields are safe to modify

## Evidence To Keep

Keep:

- app package name and device identity
- the screen state that triggered the packet
- the triggering UI action
- relevant screenshot and log anomalies
- the captured request or message
- the reason reverse escalation was or was not necessary
- the recovery notes if `jadx`, `frida_mcp`, or `ida_pro_mcp` became necessary

## Related Files

- `02-client-api-reverse-and-burp.md`
- `android-external-url-runtime-first-workflow.md`
- `android-ui-driven-observation-and-packet-loop.md`
- `android-signing-and-crypto-workflow.md`
- `03-web-security-integrated.md`
