Android Reverse Engineering Maps an APK's APIs and Call Chains

Use this skill when a user wants to find out which APIs an Android app calls and how its code is organized. It is built on the open-source android-reverse-engineering-skill (Apache-2.0): it decompiles APK, XAPK, JAR, and AAR files and extracts HTTP endpoints from them, without needing the original source code.

Triggers

Users say things like "decompile this APK", "see which APIs this app calls", "extract the API endpoints", "trace the call chain from LoginActivity", or "analyze this AAR library".

Hard Rules

1. Only analyze your own targets or targets you have explicit authorization for. If the scope of authorization is unclear, stop and ask the user before doing anything.
2. Do not scan, attack, bypass payment or access controls, or perform denial of service against live systems. Prioritize read-only and local analysis.
3. Tell the user before installing anything or changing configuration, and proceed only after they agree.
4. Sort conclusions into three categories: what you directly observed (with file and location), what you inferred, and what you did not find (write "unknown", not "does not exist").
5. Do not output or log the full contents of any keys or tokens you find, only report where they are.
6. Only analyze apps you are authorized to analyze. Reverse engineering software you have no rights to may violate intellectual property rights and terms of service. Extracted endpoint information is for documentation, interoperability, and security research. Do not use extracted tokens or keys to access someone else's service.
7. Fingerprint first, then decide whether a full decompilation is necessary.

Installation

You need Java JDK 17 or later and jadx (command line). Optional: Vineflower or Fernflower (better output for complex Java code), and dex2jar (for feeding APKs to Fernflower).

In Claude Code:

/plugin marketplace add SimoneAvogadro/android-reverse-engineering-skill
/plugin install android-reverse-engineering@android-reverse-engineering-skill

Check dependencies first, and install anything missing only after getting consent:

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/check-deps.sh

Workflow

1. Fingerprinting (Phase 0): Before a full decompilation, identify within seconds the framework (Flutter, React Native, Cordova, Xamarin, native Kotlin), the HTTP library, the degree of obfuscation, and any native libraries.

bash .../scripts/fingerprint.sh app.apk

2. Decompile:

bash .../scripts/decompile.sh app.apk                    # uses jadx by default
bash .../scripts/decompile.sh app-bundle.xapk            # automatically unpacks XAPK
bash .../scripts/decompile.sh --engine both --deobf app.apk   # compare two engines side by side

3. Find APIs: Scan everything by default, or narrow down by tech stack.

bash .../scripts/find-api-calls.sh output/sources/            # everything
bash .../scripts/find-api-calls.sh output/sources/ --retrofit
bash .../scripts/find-api-calls.sh output/sources/ --ktor     # Ktor
bash .../scripts/find-api-calls.sh output/sources/ --apollo   # GraphQL
bash .../scripts/find-api-calls.sh output/sources/ --paths    # path literals that survive R8 inlining

4. Recover Kotlin class names: After R8 obfuscation, class names become a.b.c, but Kotlin metadata is not obfuscated away, so you can use it to rebuild original names such as *Repository, *ViewModel, and *UseCase.
5. Trace call chains: Follow the path from Activities and Fragments through ViewModels and the repository layer all the way to the HTTP call.

In Claude Code you can also run the full workflow directly with /decompile path/app.apk. The Windows PowerShell scripts are still experimental.

Output Format

1. The app's framework, HTTP library, and degree of obfuscation.
2. The endpoint inventory: method, path, and authentication method (for hardcoded keys, give only the location).
3. Key call chains and a description of the code structure.
4. Parts that were not analyzed, such as logic inside native libraries, stated explicitly.