SimoneAvogadro/android-reverse-engineering-skill: a Claude Code skill for APK API extraction

What the skill extracts, and who it is actually for

The problem is a binary with no source. You have an APK, XAPK, JAR or AAR, and you need to know which HTTP endpoints it talks to, how it authenticates, and which classes call them. Reading obfuscated smali by hand does not scale. This skill wraps the decompilation and the search into scripts a Claude Code session can invoke, then hands the results back as structured findings: Retrofit interfaces, OkHttp call sites, hardcoded URLs, auth headers, tokens and HMAC request-signing schemes.

The audience is narrow and worth stating plainly. This is for an engineer already running Claude Code who has a legitimate reason to inspect an app's network layer, for example documenting a private API before a migration, auditing what a third-party SDK sends, or reproducing an integration whose vendor documentation is missing. It is not a general reverse engineering toolkit, and it is not a substitute for an Android IDE. Everything ships as shell scripts plus a skill definition, so the value depends on the assistant driving them.

The README is explicit about scope: APK, XAPK, JAR and AAR. A Flutter or React Native app is still triaged by the fingerprint phase, but the HTTP logic in those builds sits in Dart or JavaScript, not in the DEX the extraction scripts parse. That is a real boundary, not a footnote.

Phase 0 fingerprinting, then decompilation with jadx or Fernflower

The pipeline has a deliberate ordering. Before any decompile, fingerprint.sh triages the file and reports the framework (Flutter, React Native, Cordova, Xamarin or native Kotlin), the HTTP stack, the obfuscation level and the native libraries present. That is a cost decision: a full jadx pass on a large XAPK is slow, and knowing up front that the app is Cordova tells you the DEX will not contain the API calls you want.

Decompilation itself runs through decompile.sh, which defaults to jadx. Passing --engine fernflower switches to Fernflower or Vineflower, and --engine both runs the two side by side so you can compare output on the same class. Fernflower needs dex2jar to work on APK and DEX input, which is why dex2jar appears in the optional requirements rather than the required list. XAPK files are handled by auto-extracting and decompiling each APK inside the bundle.

Extraction is a separate step over the decompiled sources. find-api-calls.sh defaults to a full scan across every supported stack; --retrofit, --ktor and --apollo narrow it to one client, and --urls or --paths pull quoted literals instead of call sites. The --paths mode exists because R8 inlining destroys call structure but often leaves string literals intact, so path fragments survive even when the surrounding code does not.

Installing the plugin and running a first extraction

The README marks installation from GitHub as the recommended route, and it happens inside a Claude Code session rather than in a terminal. Two slash commands register the marketplace and install the skill:

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

After that the skill is available in future sessions. The alternative is a local clone, where the marketplace add points at the checkout path instead of the repository slug.

Before touching an APK, confirm the toolchain. check-deps.sh reports what is missing, and install-dep.sh auto-detects the OS and package manager to install a named dependency:

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

The required set is Java JDK 17 or newer and jadx on the CLI. Vineflower or Fernflower and dex2jar are optional but recommended. Once dependencies pass, a full run is one slash command, `/decompile path/to/app.apk`, which chains the dependency check, the decompilation and an initial structure analysis. If you prefer to drive the scripts yourself, the fingerprint step is the cheapest first look:

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/fingerprint.sh app.apk

What you should see is a framework, HTTP stack, obfuscation level and native library summary. If the framework comes back as Flutter or React Native, stop and reconsider whether the DEX is where your answer lives.

Kotlin name recovery is the part that distinguishes it

Most modern Android apps are Kotlin or Kotlin Multiplatform and ship through R8, so decompiled classes surface as `a.b.c`. The README states that the skill rebuilds original `*Repository`, `*ViewModel` and `*UseCase` class names from Kotlin metadata that R8 cannot strip. The mechanism is metadata recovery rather than guessing: Kotlin emits metadata into the class file, R8 renames the classes but does not remove that metadata, so the original names can be reconstructed from it.

This matters because the extraction step is only as good as the class names it searches. A Retrofit interface named `a.b.c` tells you nothing about which feature it serves. Recovering `UserRepository` or `CheckoutViewModel` turns a list of endpoints into a map of the application. The same logic extends to the newer stacks: Ktor clients, Apollo GraphQL operations and Koin dependency injection are all covered, which reflects where Kotlin apps have moved rather than where the classic Retrofit and OkHttp tutorials stopped.

The README does not explain the recovery algorithm in detail, and it does not state a success rate. Treat the recovered names as a strong hint rather than a guarantee, and expect partial recovery on builds with aggressive metadata stripping.

Where the skill fails, and when it is the wrong tool

The most concrete limitation is stated in the README itself: the PowerShell scripts are described as an experimental community contribution that is still being stabilised. If you are on Windows, you are on the less-travelled path, and the README asks that issues be filed on this repository rather than on upstream forks. That is a maintenance signal, not a defect report, but it should shape your expectations.

The second limitation is architectural. The extraction scripts parse decompiled DEX. A Flutter app's HTTP calls live in compiled Dart, a React Native app's in a JavaScript bundle, and a Cordova app's in web assets. The fingerprint phase will correctly identify those frameworks, and then the API extraction has nothing to bite on. The skill tells you this early rather than after a long decompile, which is the right design, but it does not solve the problem for you.

Third, obfuscation is mitigated, not defeated. The --paths mode targets string literals that survive R8 inlining, and the Kotlin recovery targets metadata R8 leaves alone. Neither handles a build where URLs are constructed at runtime from encrypted configuration or where the metadata has been stripped by an additional tool. If your target does that, the output will be sparse and you should not read the sparseness as absence of an API.

Finally, the skill is a Claude Code plugin. Without that environment, you are left invoking the scripts manually, and the natural-language entry points, the call-flow tracing, and the structuring of results all disappear.

How it compares to jadx-gui and MobSF

The honest comparison is with the tools this project wraps and with the established Android analysis platforms. jadx-gui gives you a decompiler with a searchable interface and a class browser. You can find a Retrofit interface in it, and you can follow a call by clicking through. What you cannot do is ask for the API surface across an entire application and get a consolidated answer, and you cannot recover original Kotlin class names from metadata as a separate pass. The skill is a workflow layer over jadx, not a replacement for it; the README lists jadx as a hard requirement.

MobSF takes a different approach again. It is a self-contained analysis platform that produces reports on an uploaded binary, including static and dynamic analysis, and it runs as its own service. The difference is where the intelligence sits. MobSF automates a fixed pipeline and gives you a report. This skill puts the analysis inside an assistant session, so the follow-up questions, the call-flow tracing from an Activity down to an HTTP call, and the narrowing of a search to one HTTP client are conversational. If you want a repeatable report artifact with no assistant in the loop, MobSF is the more direct answer. If you want to interrogate a specific app interactively and end up with documented endpoints, the skill's model fits better.

Licence, maintenance and the cost of upgrading

The project is Apache-2.0, and the README carries a disclaimer section alongside it. Apache-2.0 permits commercial use, modification and redistribution with the usual attribution and notice requirements. It also includes an explicit patent grant, which matters if you are embedding the scripts in an internal tool. None of that addresses whether you are permitted to reverse engineer a particular application in your jurisdiction or under its terms of service; the licence covers the code, not your use of it. Read the disclaimer in the README and get your own answer on the legal question.

The repository is not archived, and the last push was on 2026-09-08. The most recent release is v1.1.0 from 2026-04-27, so the commit activity is not mirrored by release tagging. Upgrading is cheap in the ordinary case: the plugin installs through the Claude Code marketplace, so a reinstall picks up the current state of the master branch, and the scripts have no build step. The real upgrade cost is dependency drift. jadx, Vineflower and dex2jar are external tools with their own release cycles, and decompiler output changes between versions, which can shift what the extraction scripts match against. Pin those versions if you are producing documentation that other people will rely on.

Editorial conclusion

Adopt this if you already work inside Claude Code and your task is to recover and document the HTTP surface of an Android binary: the fingerprint, decompile, find-api-calls and Kotlin name recovery scripts cover that path end to end, and the Apache-2.0 licence keeps redistribution straightforward. Do not adopt it if you need a GUI, if you are not a Claude Code user, or if your target is a Flutter or React Native build whose API layer lives in Dart or JavaScript rather than in DEX. Before relying on it, verify that jadx and JDK 17 are on PATH via check-deps.sh, confirm the Phase 0 fingerprint on your own APK, and read the disclaimer in the README about what you are permitted to do with the extracted endpoints.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. SimoneAvogadro/android-reverse-engineering-skill on GitHub