Android Reverse Engineering

Decompile Android APK, XAPK, AAB, DEX, JAR, and AAR files using jadx and Fernflower/Vineflower, trace call flows through application code and libraries, analyze security patterns, produce structured documentation of extracted APIs, and perform adaptive dynamic analysis with Frida — generating custom bypass scripts based on what the static analysis finds, iterating through crash logs to refine hooks until protections are bypassed. Two decompiler engines are supported — jadx for broad Android coverage and Fernflower for higher-quality output on complex Java code — and can be used together for comparison.

Prerequisites

This skill requires Java JDK 17+ and jadx to be installed. Fernflower/Vineflower and dex2jar are optional but recommended for better decompilation quality. bundletool is required for AAB (App Bundle) files. For dynamic analysis (Phase 7), Python 3.8+, adb, and a device/emulator with frida-server are needed — the setup-frida.sh script handles the full setup. Run the dependency checker to verify:

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.sh

If anything is missing, follow the installation instructions in ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/setup-guide.md.

Workflow

Phase 1: Verify and Install Dependencies

Before decompiling, confirm that the required tools are available — and install any that are missing.

Action: Run the dependency check script.

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.sh

The output contains machine-readable lines:

• INSTALL_REQUIRED:<dep> — must be installed before proceeding
• INSTALL_OPTIONAL:<dep> — recommended but not blocking

If required dependencies are missing (exit code 1), install them automatically:

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/install-dep.sh <dep>

The install script detects the OS and package manager, then:

• Installs without sudo when possible (downloads to ~/.local/share/, symlinks in ~/.local/bin/)
• Uses sudo and the system package manager when necessary (apt, dnf, pacman)
• If sudo is needed but unavailable or the user declines, it prints the exact manual command and exits with code 2 — show these instructions to the user

For optional dependencies, ask the user if they want to install them. Vineflower and dex2jar are recommended for best results.

After installation, re-run check-deps.sh to confirm everything is in place. Do not proceed to Phase 2 until all required dependencies are OK.

Phase 2: Decompile

Use the decompile wrapper script to process the target file. The script supports three engines: jadx, fernflower, and both.

Action: Choose the engine and run the decompile script. The script handles APK, XAPK, AAB, DEX, JAR, and AAR files.

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/decompile.sh [OPTIONS] <file>

For XAPK files (ZIP bundles containing multiple APKs, used by APKPure and similar stores): the script automatically extracts the archive, identifies all APK files inside (base + split APKs), and decompiles each one into a separate subdirectory. The XAPK manifest is copied to the output for reference.

For AAB files (Android App Bundles): the script uses bundletool to generate a universal APK from the bundle, then decompiles it. bundletool must be installed (run install-dep.sh bundletool).

For DEX files: jadx handles them natively. For Fernflower, dex2jar is used as an intermediate step (same as APK files).

Options:

• -o <dir> — Custom output directory (default: <filename>-decompiled)
• --deobf — Enable deobfuscation (recommended for obfuscated apps)
• --no-res — Skip resources, decompile code only (faster)
• --engine ENGINE — jadx (default), fernflower, or both

Engine selection strategy:

When using --engine both, the outputs go into <output>/jadx/ and <output>/fernflower/ respectively, with a comparison summary at the end showing file counts and jadx warning counts. Review classes with jadx warnings in the Fernflower output for better code.

For APK files with Fernflower, the script automatically uses dex2jar as an intermediate step. dex2jar must be installed for this to work.

See ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/jadx-usage.md and ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/fernflower-usage.md for the full CLI references.

Phase 3: Analyze Structure

Navigate the decompiled output to understand the app's architecture.

Actions:

1. Read AndroidManifest.xml from <output>/resources/AndroidManifest.xml:

   • Identify the main launcher Activity
   • List all Activities, Services, BroadcastReceivers, ContentProviders
   • Note permissions (especially INTERNET, ACCESS_NETWORK_STATE)
   • Find the application class (android:name on <application>)

2. Survey the package structure under <output>/sources/:

   • Identify the main app package and sub-packages
   • Distinguish app code from third-party libraries
   • Look for packages named api, network, data, repository, service, retrofit, http — these are where API calls live

3. Identify the architecture pattern:

   • MVP: look for Presenter classes
   • MVVM: look for ViewModel classes and LiveData/StateFlow
   • Clean Architecture: look for domain, data, presentation packages
   • This informs where to look for network calls in the next phases

Phase 4: Trace Call Flows

Follow execution paths from user-facing entry points down to network calls.

Actions:

1. Start from entry points: Read the main Activity or Application class identified in Phase 3.

2. Follow the initialization chain: Application.onCreate() often sets up the HTTP client, base URL, and DI framework. Read this first.

3. Trace user actions: From an Activity, follow:

   • onCreate() → view setup → click listeners
   • Click handler → ViewModel/Presenter method
   • ViewModel → Repository → API service interface
   • API service → actual HTTP call

4. Map DI bindings (if Dagger/Hilt is used): Find @Module classes to understand which implementations are provided for which interfaces.

5. Handle obfuscated code: When class names are mangled, use string literals and library API calls as anchors. Retrofit annotations and URL strings are never obfuscated.

See ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/call-flow-analysis.md for detailed techniques and grep commands.

Phase 5: Extract and Document APIs

Find all API endpoints and produce structured documentation.

Action: Run the API search script for a broad sweep.

bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/

Additional options:

• --context N — Show N lines of context around each match (recommended: --context 3)
• --report FILE — Export results as a structured Markdown report
• --dedup — Deduplicate results by endpoint/URL

Targeted searches:

# Only Retrofit
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/ --retrofit

# Only hardcoded URLs
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/ --urls

# Only auth patterns
bash ${CLAUDE_PLUGIN_R