---
name: android-app-reverse-engineering
description: Reverse-engineer Android apps — static analysis (apktool, jadx), local storage exploration, Frida dynamic hooking, and API interception. Covers the full recon → extract → replay pipeline.
category: android
---

# Android App Reverse Engineering

Class-level skill for reverse engineering any Android app: decompile the APK, explore local storage, hook runtime behaviour, intercept API calls, and replay authenticated requests.

## Triggers

- User asks to "破解", "逆向", "decompile", or "reverse engineer" an Android app
- User wants to read app data, extract API endpoints, or post via an app's API
- User wants to understand how an app stores data locally

## Phase 0: Clarify the Real Goal

When a user says "破解" (crack), they almost never mean bypassing license checks or removing ads. Common actual goals:

| What they say | What they usually mean |
|---|---|
| "破解 X 拿数据" | Extract/capture app data — cached responses, feeds, user content |
| "破解 X 发消息" | Replay the app's private API with auth tokens |
| "破解 X 看源码" | Read decompiled Java to understand business logic |
| "破解 X 去广告" | Modify smali to skip ad loading (hardest, rarely the real goal) |

Ask clarifying questions BEFORE picking tools. Don't install jadx when they just want API tokens.

## Phase 1: Reconnaissance

### 1a. Confirm app and get APK path

```bash
# Is it installed?
pm list packages | grep -i <keyword>

# APK location (need root for base.apk path on modern Android)
pm path <package.name>
# → /data/app/~~XXXX==/<pkg>-YYYY==/base.apk
```

### 1b. Explore local storage (requires root)

The data directory reveals the app's architecture:

```bash
su -c 'ls -la /data/data/<pkg>/'

# Key directories to check:

# databases/    → SQLite DBs (content likely here)
# shared_prefs/ → XML prefs (tokens, config, device IDs)
# files/        → App-private files (caches, MMKV, keys)
# cache/        → Transient caches
```

**Red flag — server-driven apps:** If `databases/` contains only SDK databases (ads, push, analytics) and no main content DB, the app is server-driven. All content comes from API responses; local storage is only images/config/tokens. Don't waste time looking for a content database that doesn't exist.

### 1c. Quick file-type sampling

```bash
# Check file types to understand cache format
su -c 'file /data/data/<pkg>/files/cache_dir/*' | head

# Sample first few bytes
su -c 'xxd /data/data/<pkg>/files/cache_dir/<file> | head -5'
```

Common cache formats:
- `8950 4e47` (PNG magic) → cached images
- `7b 22` or `7b 0a` → JSON responses
- `1f 8b` → gzip compressed
- Binary/non-printable → likely protobuf or encrypted

## Phase 2: Static Analysis (if source code needed)

### apktool — resource/smali extraction

apktool is NOT the right tool for reading application logic. It produces smali (Dalvik bytecode), not Java. Use it ONLY for:
- Extracting resources (AndroidManifest.xml, layout XMLs, assets)
- Quick manifest inspection (permissions, Activities, Services)
- Modifying resources before recompiling

Install on Termux (not in pkg repo — download jar directly):

```bash
# Download latest apktool jar
curl -sL https://github.com/iBotPeaches/Apktool/releases/download/v2.11.0/apktool_2.11.0.jar -o ~/apktool.jar

# Create wrapper
mkdir -p ~/bin
cat > ~/bin/apktool << 'EOF'
#!/data/data/com.termux/files/usr/bin/bash
exec java -jar /data/data/com.termux/files/home/apktool.jar "$@"
EOF
chmod +x ~/bin/apktool

# Decompile
apktool d base.apk -o output_dir/
```

**Limitations on hardened apps:**
- 加固 (360, Tencent, Bangcle) — apktool extracts the shell's smali, not the real app
- ProGuard/R8 obfuscation — classes named a, b, c; unreadable
- Multi-dex — large apps split across classes.dex, classes2.dex, etc.

### jadx — readable Java decompilation

For actual source code reading, use jadx instead:

```bash
pkg install jadx -y
jadx base.apk -d output_dir/
```

**Pitfall:** 164MB APK with 4+ dex files → jadx may OOM on a phone. Consider running on a desktop instead.

## Phase 3: Dynamic Analysis (API interception)

Frida is the primary tool for runtime analysis. See `frida-android-setup` skill for installation.

### Key hook targets by app type

**Standard apps (OkHttp/Retrofit):**
```javascript
// Hook OkHttp to capture all HTTP traffic
Java.perform(function() {
    var RealCall = Java.use("okhttp3.RealCall");
    RealCall.execute.implementation = function() {
        var response = this.execute();
        console.log("[OkHttp] " + this.request().url().toString());
        return response;
    };
});
```

**Apps with custom networking:**
- Search for HTTP client class names in jadx output first
- Common patterns: `*HttpClient`, `*NetworkManager`, `*ApiService`

**Auth token extraction:**
- Check shared_prefs for `token`, `auth`, `session`, `cookie`
- Hook MMKV: `Java.use("com.tencent.mmkv.MMKV").decodeString`
- Hook SharedPreferences: `Java.use("android.app.SharedPreferencesImpl").getString`

### Authentication & signature challenges

Chinese apps (小红书, 抖音, etc.) often have:
- **Custom signature algorithm** — `x-mini-sig`, `x-s`, `x-sign` headers computed natively
- **Timestamp-based tokens** — expire quickly, must be extracted at runtime
- **Device fingerprint** — tied to IMEI/AndroidID, hard to replay from a different device
- **Anti-debugging** — ptrace checks, Frida detection

For these, static API replay may fail. Fall back to UI automation + Frida co-piloting: use the real app for auth, intercept the signed request + response through Frida.

## Phase 4: API Replay

Once you have:
- API endpoint URLs
- Auth token(s)
- Request/response format (JSON schema)
- Signature algorithm (or Frida to sign in real-time)

Replay with:
```bash
curl -X POST "https://api.example.com/v1/endpoint" \
  -H "Authorization: Bearer $TOKEN" \
  -H "x-sign: $(python3 sign.py $PAYLOAD)" \
  -d '{"key":"value"}'
```

## App-Specific Attack Surface Analyses

When targeting message-sending APIs of specific apps, first load the relevant reference for the app's known architecture:

| App | Reference | Key Finding |
|-----|-----------|-------------|
| 小红书 (XHS) | `xiaohongshu-reverse-engineering-v2` → `references/im-bcim-architecture.md` | BCIM → Custom Java Longlink TCP. JSON payload. OkHttp blind spot. |
| 微信 (WeChat) | `references/wechat-messaging-attack-surface.md` | mars C++ native → Protobuf → ECDH+AES. DB injection most promising vector. |

**Common pattern**: Chinese super-apps (微信, 小红书) use custom long-connection protocols for IM, NOT REST APIs. OkHttp hooks won't capture messaging. Start with the app-specific reference before choosing tools.

## Pitfalls

- **"破解" is a loaded word.** Always clarify before acting. 90% of the time the user means "read data" or "call API", not "remove license check".
- **Don't assume a local DB exists.** Modern Chinese apps are aggressively server-driven. If `databases/` has only SDK tables, stop looking and switch to Frida.
- **apktool ≠ Java source.** Don't let the user believe smali is readable code. Set expectations before decompiling.
- **加固 (app hardening) blocks static analysis.** If the APK is from a major Chinese company, assume it's hardened. Test with `apktool d` and check if the smali code looks like a shell (class names like `com.stub.StubApp`) or the real app.
- **API replay may fail without the real device context.** Signature algorithms often incorporate device fingerprints. Plan for Frida co-piloting as the fallback.
- **164MB+ APKs with 4+ dex files** will cause Termux jadx to OOM. Plan for desktop-based decompilation.
- **raw_swift_data is an image cache** (noted for 小红书 specifically, but check file headers for any `raw_*_data` directory).

## References

- `references/xiaohongshu-reconnaissance.md` — 小红书 v8.x reconnaissance (app structure, local storage, MMKV, API endpoints)
- `references/wechat-messaging-attack-surface.md` — 微信消息发送攻击面分析 (mars 架构, 5 条攻击路径, DB 注入优先)

## Related Tools

- `mcp/reverse-engineer-anything-mcp` — REA（morluto/rea）：跨平台逆向 MCP server + CLI（原生二进制 / JS·Electron / .NET / WASM / APK / 固件 / 抓包），结论带 Evidence + limitations/unknowns。**本机 android/arm64 只可跑 JS·Electron 静态分析，APK/原生分析被宿主门控 ⇒ 需 x64 主机**（实测门控矩阵见该 skill）。