SKILL.md 8.35 KB

Edit Raw Blame History Permalink



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
# 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:
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
# 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):
# 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:
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):
// 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:
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）。