Android reverse-engineering and HTTP API extraction skill (plugin)
A Claude Code skill that automates decompilation of Android packages and extracts Retrofit/OkHttp HTTP APIs, aimed at security audits, interoperability analysis, and incident response.
GitHub SimoneAvogadro/android-reverse-engineering-skill Updated 2026-04-17 Branch main Stars 5.5K Forks 621
Android reverse-engineering API extraction static decompilation security auditing

💡 Deep Analysis

7
What concrete problems does the project solve and what is its core value?

Core Analysis

Project Positioning: The project’s core value is automating the transformation of static decompilation artifacts (Java/Kotlin output, Manifest, resources) into structured HTTP API lists and call flows, enabling rapid identification, documentation, and reproduction of an app’s network interactions without source code.

Technical Features

  • Multi-engine decompilation: Uses jadx and Fernflower/Vineflower side-by-side to mitigate the limitations of any single decompiler when handling obfuscation or complex codegen.
  • Patterned extraction: Scripts detect Retrofit annotations, OkHttp usages, hardcoded URLs, and common auth header/token patterns.
  • Call-flow tracing: Performs static tracing from Activities/Fragments through ViewModels/Repositories down to HTTP call sites, aiding context-aware understanding.
  • Scripted workflow: Provides repeatable steps (dependency checks, decompile, API extraction) via decompile.sh and find-api-calls.sh.

Practical Recommendations

  1. Use as initial intelligence: Run it first to get candidate endpoints and auth clues when no source is available.
  2. Compare engines: Run --engine both or run decompilers separately to increase recovery coverage.
  3. Combine with dynamic validation: Feed static extraction results into packet capture or Frida validation to fill static gaps.

Important Notice: The tool is static-first — runtime-constructed endpoints, heavy native code (.so), or runtime obfuscation/encryption may not be captured; missing ProGuard/R8 mapping will reduce call-chain readability.

Summary: For rapid extraction and documentation of network APIs from binaries, this project provides a high-value automated starting point that significantly reduces manual triage and information assembly time.

90.0%
In which scenarios will static API extraction fail or be seriously incomplete, and how should one remediate?

Core Analysis

Core Question: Which situations cause static API extraction to fail or be seriously incomplete, and how should one remediate to obtain reliable interface information?

Technical Analysis

  • Common failure scenarios:
    1. Runtime assembly/encryption: URLs, paths, or auth tokens are decrypted/assembled at runtime, not visible statically;
    2. Reflection & dynamic proxies: Invocation targets are obscured via reflection, not resolvable statically;
    3. Native-network logic: Communications implemented inside .so (JNI), invisible from Java/Kotlin static view;
    4. Dynamic loading/modules: Functionality downloaded/loaded at runtime and absent from the static package;
    5. Severe obfuscation without mapping: Method/class names lack semantics, breaking readable call chains.

Remediation Recommendations

  1. Dynamic validation is essential: Use mitmproxy/Burp or Frida to capture and hook in a controlled environment to validate static candidates; for pinning, use hooks or test devices with appropriate certs (authorized contexts only).
  2. Recover symbols when possible: Obtain ProGuard/R8 mapping files or use pattern matching to infer meaning.
  3. Hybrid workflow: Use static extraction to get a candidate list, then dynamically trigger those code paths to confirm endpoints and auth flows, recording reproducible steps and evidence.
  4. Native-layer analysis: For suspected .so-based logic, perform native reverse engineering or packet-level capture to observe network behavior.

Important Notice: Dynamic interventions may alter app behavior and may be restricted by law or terms—operate within authorization and controlled environments.

Summary: Static extraction is an efficient reconnaissance step, but runtime-constructed endpoints, reflection, and native implementations require dynamic analysis and symbol recovery to reach completeness and verifiability.

88.0%
How to integrate this tool into an incident response or API reimplementation workflow? What are the recommended steps and output formats?

Core Analysis

Core Question: How to integrate this tool into incident response or API reimplementation workflows to ensure speed, reproducibility, and deliverable quality?

Technical Analysis

  • Tool fits a staged workflow: With check-deps.sh, decompile.sh, and find-api-calls.sh, the tool easily automates the static analysis stage and plugs into larger response pipelines.
  • Recommended outputs: Structured JSON (machine-readable), CSV (quick review), and Markdown reports (human-friendly). Each entry should include endpoint URL/path, library identification (Retrofit/OkHttp), source file/line snippets, call-chain context, auth clues, confidence score, and validation recommendations.
  1. Dependency check: Run check-deps.sh and install missing tools via install-dep.sh.
  2. Parallel decompilation: decompile.sh app.apk --engine both --deobf, keep outputs separate.
  3. Static extraction: find-api-calls.sh output/sources/ --retrofit --urls to produce structured JSON/CSV.
  4. Prioritize candidates: Rank by confidence, presence of auth, or sensitive domains.
  5. Dynamic validation: In an isolated environment, use mitmproxy/Frida automation to verify high-priority endpoints and capture request/response samples.
  6. Deliverables: Produce a combined Markdown report with JSON attachments, including reproducible steps, captured evidence, and recommended remediation or reimplementation notes.

Important Notice: Operate within authorized and controlled environments during incident response; dynamic testing may require device configuration and must preserve a clear evidence chain.

Summary: Use the tool as an automated static triage step that emits structured candidates; combine with automated dynamic validation and standardized report formats to build a reproducible, auditable workflow for incident response or API reimplementation.

88.0%
To what extent can call-flow tracing reach? What are the feasibility and limits of static tracing?

Core Analysis

Core Question: The tool claims tracing from UI to HTTP. What can static tracing achieve and where does it fail?

Technical Analysis

  • High-feasibility scenarios: When an app follows standard architecture (Activity/Fragment → ViewModel/Repository → network) and uses explicit libraries (Retrofit, OkHttp), static rules can:
  • Detect Retrofit interfaces and annotations (@GET, @POST);
  • Locate OkHttp construction/execution sites;
  • Perform static call-path analysis to assemble UI-to-network flow maps.
  • Primary limitations:
  • Reflection and dynamic proxies: Targets invoked via reflection are not statically resolvable.
  • Runtime string assembly/encryption: URLs or headers assembled/decrypted at runtime will be missed (false negatives).
  • Native code & dynamic loading: Communications initiated via .so or dynamically loaded dex/modules are outside static reach.
  • Obfuscation without mapping: Loss of semantic names reduces call-chain readability and confidence.

Practical Recommendations

  1. Use static output as a roadmap: Feed extracted endpoints into dynamic testing tools (mitmproxy / Frida) for validation.
  2. Flag uncertainties: Mark endpoints likely produced by reflection/string assembly and prioritize them for dynamic verification.
  3. Obtain mapping or apply symbol recovery: If available, use ProGuard/R8 mapping to improve chain clarity.

Important Notice: Static tracing is not definitive evidence; in legal or incident response contexts, corroborate findings with dynamic captures.

Summary: Static call-flow tracing is valuable for most conventional Android architectures, but blind spots require complementary dynamic techniques for completeness and accuracy.

87.0%
What is the learning curve and typical pain points for this tool? What best practices lower the adoption barrier?

Core Analysis

Core Question: How steep is the learning curve? What are common pain points and how to get started with minimal friction?

Technical Analysis

  • Sources of the learning curve: Users should understand Android app structure, how to read decompiled Java/Kotlin output, command-line tooling, and dependencies (JDK 17+, jadx, optionally vineflower/dex2jar).
  • Typical pain points:
  • Environment/dependency mismatches causing decompilation failures;
  • Obfuscation without mapping reduces readability;
  • Static rules produce false positives/negatives, especially for runtime-constructed endpoints;
  • Treating static output as definitive evidence without dynamic validation.
  • Built-in mitigations: The project includes check-deps.sh / install-dep.sh and example scripts (decompile.sh, find-api-calls.sh) to automate setup and provide repeatable workflows.

Practical Recommendations (Best Practices)

  1. Run dependency checks first: Use check-deps.sh to ensure JDK 17+, jadx, etc.
  2. Follow a staged workflow:
  3. decompile.sh (use --engine both if unsure);
  4. find-api-calls.sh --retrofit/--urls to extract candidates;
  5. Validate high-value endpoints with mitmproxy/Frida.
  6. Compare outputs in parallel: Use both engines’ outputs to fill gaps and reduce blind spots.
  7. Annotate uncertainty: Mark endpoints likely produced by reflection/string assembly and validate them first.

Important Notice: Proficiency requires reverse engineering basics; ensure legal authorization when analyzing closed-source targets.

Summary: The tool has a moderate-to-high learning curve, but scripted checks, staged workflows, and integrating dynamic verification significantly reduce onboarding friction and improve analysis reliability.

86.0%
When binaries are ProGuard/R8 obfuscated without mapping files, how can you improve readability and reconstruct call chains?

Core Analysis

Core Question: Without ProGuard/R8 mapping files, how can you improve decompiled readability and reconstruct useful call chains?

Technical Analysis

  • Inherent limit: Missing mapping means original class/method names are irreversibly replaced—perfect recovery is impossible. However, several heuristic and engineering approaches can recover meaningful context.
  • Feasible techniques:
    1. Multi-engine comparison: jadx and Fernflower may each yield locally clearer fragments; comparing outputs uncovers the best readable pieces.
    2. Constant/annotation anchors: URLs, annotations, resource strings, and log messages are usually unchanged and can be used to label obfuscated symbols.
    3. Signature/type inference: Method signatures and parameter/return types (e.g., Call<>, Response<>) hint at network-related functions.
    4. Runtime mapping: Run in a controlled environment and collect stack traces/logs or use Frida to map runtime names back to obfuscated symbols.
    5. Pattern recognition: Use library-specific detection rules (Retrofit/OkHttp) to auto-tag likely interface methods.

Practical Recommendations

  1. Run both engines and merge clues: Use --engine both and construct a candidate table with confidence scores.
  2. Anchor on constants and annotations: Hardcoded URLs, Retrofit annotations, and Manifest fields are reliable anchors for semantic recovery.
  3. Correlate with runtime evidence: Use packet capture or instrumentation to map observed behavior to obfuscated code.
  4. Document uncertainty: Record evidence sources and confidence per inferred call chain for auditing and reproducibility.

Important Notice: Any renaming inference without mapping carries uncertainty—use dynamic validation to confirm critical findings.

Summary: Full symbol recovery is impossible without mapping, but multi-engine comparison, constant/annotation anchors, signature inference, and runtime mapping can greatly improve readability and produce actionable call chains when systematized.

86.0%
Why choose `jadx` and `Fernflower/Vineflower`, and what architectural advantages does the project have?

Core Analysis

Core Question: Why use jadx and Fernflower/Vineflower, and what practical advantages does the architecture provide?

Technical Analysis

  • Engine complementarity: jadx parses DEX directly and usually preserves Kotlin/Android semantics (lambdas, resource refs) well; Fernflower/Vineflower, when used on dex2jar-produced JARs, often produces more Java-readable output for plain Java code paths. Side-by-side comparison leverages strengths of both and reduces risk when one engine fails.
  • Modular architecture: The project’s separation into plugins/skills/commands/references/scripts makes it easy to swap decompilers, add detection rules, or plug in additional analysis stages (e.g., AST processing or symbol recovery).
  • Scripted workflow: decompile.sh, find-api-calls.sh, etc., ensure repeatable, automatable steps that can be integrated into CI/pipelines.

Practical Recommendations

  1. Run engines in parallel by default: For complex/obfuscated APKs, use --engine both to compare outputs and maximize recovery.
  2. Use dex2jar when Java readability matters: Convert DEX to JAR for Fernflower if Java-style output is preferred.
  3. Add custom post-processing rules: Tailor detection rules for known libraries (Retrofit/OkHttp) to reduce false positives.

Important Notice: External decompiler versions and a correct local environment (JDK 17+) directly affect results—use check-deps.sh and keep toolchain updated.

Summary: The multi-engine + modular + scripted architecture raises decompilation recovery rates and maintainability, making the tool robust and extensible for varied APKs.

85.0%

✨ Highlights

  • Supports side-by-side comparison of jadx and Fernflower
  • Automatically extracts Retrofit/OkHttp calls and hardcoded URLs
  • Includes installation guides and scriptable one‑command workflows
  • Depends on external tools and environment configuration
  • Unauthorized reverse engineering carries legal/compliance risks

🔧 Engineering

  • Decompiles APK/XAPK/JAR/AAR and extracts HTTP API endpoints
  • Traces call flows from Activities/Fragments down to HTTP calls
  • Provides automated scripts to find API calls and compare engines

⚠️ Risks

  • Repository metadata appears incomplete: no contributors or releases recorded
  • Results on heavily obfuscated code may require manual verification
  • Unauthorized reverse engineering may violate law; users bear compliance responsibility
  • Depends on JDK17, jadx, dex2jar and other external tools; integration cost exists

👥 For who?

  • Security researchers, application pentesters and mobile security auditors
  • Reverse engineers, malware analysts and incident response teams
  • Developers needing to recover APIs from binaries or perform interoperability analysis