android-reverse-engineering-skill: a Codex-ready Android reverse engineering toolkit

What the skill actually packages

The project is a skill for Codex, and it is built on top of an earlier one by SimoneAvogadro with substantial extension. The README describes it as a full Android reverse engineering toolkit covering the chain from APK decompilation to Frida instrumentation, from HTTP interface extraction to JNI and native library reverse engineering, and it states that it suits authorised security research and penetration testing work.

The functional core is a set of shell and PowerShell scripts plus a body of reference documentation, and the repository layout shows the structure. Inside android-reverse-engineering/ there are the commands/ directory with decompile.md, and skills/android-reverse-engineering/ containing SKILL.md, a references/ folder with setup-guide.md, jadx-usage.md, fernflower-usage.md, api-extraction-patterns.md, call-flow-analysis.md, dynamic-analysis.md and native-analysis.md, plus a scripts/ directory with check-deps.sh and check-deps.ps1 and the other tools. Plugin manifests exist for both platforms, with .claude-plugin/ and marketplace.json at the root and .codex-plugin/plugin.json inside.

The primary language is JavaScript, the licence is Apache-2.0, the default branch is master, and the last push was on 2026-05-07. There are no GitHub releases, which fits a repository whose unit of delivery is a skill directory rather than a binary.

The framing matters for how you read the feature list. This is a workflow description in prose and scripts, not a program with an API, and its value is that it encodes a workflow an agent can follow rather than a capability you call.

Two decompilers, compared rather than chosen

The static analysis side is the part with the clearest design decision. The tooling supports three engines, jadx, Fernflower and Vineflower, and the decompile script takes an engine selection that includes a both mode.

SKILL_DIR="android-reverse-engineering/skills/android-reverse-engineering/scripts"

bash $SKILL_DIR/check-deps.sh
bash $SKILL_DIR/install-dep.sh jadx

The both mode runs the engines and compares their output, which is the interesting part. jadx is a decompiler and dex to jar converter with its own opinions about how to render control flow, and Fernflower and Vineflower are Java decompilers with a different history and a different output style. Running both and preferring the better result per file is a reasonable way to work around the fact that neither is right everywhere, and it is a strategy a human analyst would otherwise have to apply by hand for every class.

The script arguments are worth reading closely. The decompile script takes an app.apk for the default jadx path, a --engine fernflower flag for the Java library case, --engine both for the comparison, and an app-bundle.xapk for the XAPK case.

The static analysis also covers the manifest and the package structure, the architectural pattern detection for MVP, MVVM and Clean Architecture, and a strategy for locating string anchors in ProGuard or R8 obfuscated code, which is the part of reverse engineering that a language model is genuinely bad at without being told where to look.

The deobfuscation option has an explicit default: on the first decompilation do not add --deobf, because class names stay closer to the real names in the dex runtime, which suits later FindClass, Class.forName, Frida hooks and unidbg emulation. The --deobf flag is for heavily obfuscated code where readability matters more, for pure static analysis, and as a second output to compare against the original.

API extraction and call chain walking

The network layer tooling is the part aimed at analysts who need to answer what an application talks to and how it authenticates.

bash $SKILL_DIR/find-api-calls.sh output/sources/
bash $SKILL_DIR/find-api-calls.sh output/sources/ --retrofit
bash $SKILL_DIR/find-api-calls.sh output/sources/ --urls
bash $SKILL_DIR/find-api-calls.sh output/sources/ --auth

The flags are separate passes over the decompiled sources: the default pass, then a Retrofit pass, a URL pass and an auth pass. The output it aims to produce is a complete documentation of the request and response structure, the base URL, the path, the headers and the body, along with the location of signature parameters and encryption entry points.

Call chain tracing works the other way, from a UI entry point downwards. The documented chain runs from Activity or Fragment to ViewModel or Presenter to Repository to an API service to the HTTP call, and the tooling maps Dagger and Hilt dependency injection bindings so you can follow the object graph rather than grep for class names. In obfuscated code the navigation relies on Retrofit annotations as anchors, since an annotated interface method survives obfuscation even when the class name does not.

The combination is what gives the skill its shape. A language model asked to find an authentication header in a decompiled APK will get a confident wrong answer, but asked to find the Retrofit interface and then follow the interceptor that sets the header will get a useful one, and that is the sequence the skill encodes.

Nine Frida scripts, and the ones that detect you

The dynamic analysis half is a set of nine scripts that are described as ready to use, and they are worth going through in groups because the intent differs sharply between them.

The observation scripts record rather than alter. ssl_log.js exports TLS keys so HTTPS traffic can be decrypted, alongside tools like Wireshark. dump_dex.js dumps DEX from memory, which is the technique for packed or dynamically loaded code. dump_so.js does the same for a native library while preserving the full ELF structure. jni_method_trace.js traces JNI calls and can target a specific shared library. hook_artmethod_register.js hooks ART method registration to follow the binding from native into Java. hook_encryption_algo.js intercepts calls to encryption and hashing algorithms. keystore_dump.js exports a client certificate as p12 in mutual TLS situations.

The last two are different in kind. bypass_root_detect.js is a general root detection bypass including Magisk detection, and bypass_frida_svc_detect.js is a bypass for Frida detection at the SVC instruction level on ARM32 and ARM64.

frida -U -f com.example.app -l ssl_log.js --no-pause
frida -U -f com.example.app -l dump_dex.js --no-pause
frida -U -f com.example.app -l hook_encryption_algo.js --no-pause

The pattern in every invocation is the same: -U to attach over USB to a connected device, -f to spawn the package by its application id, -l to load the script and --no-pause to keep the process running after the script attaches.

The two bypass scripts are standard instrumentation-detection countermeasures and they exist in every serious reverse engineering toolkit, but they are the part of this repository that most obviously requires an authorisation context to justify. They are also the part most likely to be blocked by the next version of the target application, which is the maintenance cost of carrying them.

Native libraries, and a fallback when rizin is missing

The native layer analysis starts from a signal in the Java code. When static analysis shows a native method declaration, a System.loadLibrary call or RegisterNatives, the tooling follows the chain through JNI_OnLoad and the dynamic registration, and then analyses the shared object with rizin, readelf, nm and objdump.

rz-bin -I libfoo.so && rz-bin -s libfoo.so && rz-bin -i libfoo.so
rizin -qc "aaa; pdf @ sym.JNI_OnLoad; q" libfoo.so
readelf -Ws libfoo.so && nm -D libfoo.so | rg 'JNI_OnLoad|Java_'
objdump -d libfoo.so > libfoo.asm

The three rizin invocations are the ELF header, the symbol table and the imports, and the analysis command disassembles the JNI_OnLoad function. The readelf and nm pair is the documented fallback when rizin is unavailable, and objdump produces a disassembly listing you can read in any editor.

What the tool is really for is a decision. The native analysis section is about locating the boundary between layers: is the signature or the encryption generated in Java or in the native layer? That is the question an API extraction pass cannot answer, because the code that produces the value is not in the decompiled sources at all. Once you know which layer it is, you know whether a Frida hook on the Java side will ever fire.

The tooling is also positioned for the step before dynamic analysis, providing the static reconnaissance you do before unidbg emulation, so you know which classes and which library functions to model rather than guessing at them.

Cross platform scripts, dependency handling, and a wrinkle in the install steps

Two structural choices are worth calling out. The first is that the whole toolkit ships as two script stacks, Bash and PowerShell, so macOS, Linux and Windows are all covered rather than Windows being an afterthought. The Windows path mirrors the Bash one, with check-deps.ps1, install-dep.ps1, decompile.ps1 and find-api-calls.ps1 and the same -Retrofit style argument.

The second is the dependency handling. The project has a check script and an install script per tool, and the claimed behaviour is one-click checking and automatic installation of missing tools, falling back to manual guidance when sudo is not available.

$SKILL_DIR="android-reverse-engineering/skills/android-reverse-engineering/scripts"

& "$SKILL_DIR/check-deps.ps1"
& "$SKILL_DIR/install-dep.ps1" jadx
& "$SKILL_DIR/decompile.ps1" app.apk
& "$SKILL_DIR/find-api-calls.ps1" output/sources/ -Retrofit

The required dependencies are Java JDK 17 or newer and the jadx command line tool. The optional but recommended ones are Vineflower or Fernflower for better output on complex Java code, dex2jar to pair an APK or DEX with Fernflower, Rizin for native symbols and disassembly, Frida for runtime instrumentation, and adb for device connection and script pushing.

There is one inconsistency in the installation section that an adopter will hit immediately. The documented clone command points at the upstream repository, SimoneAvogadro/android-reverse-engineering-skill, and the symlink paths are written relative to that checkout, so the instructions as written install the original project rather than this one. The fork exists precisely because of the differences listed in its comparison table, and the clone URL in the install section was not updated to match.

Where this skill does not help

There are three limits, and the first is a scope one that the project itself is honest about.

The first is that this is an analysis toolkit, not an exploitation toolkit. It decompiles, extracts, traces and dumps. It does not find and use a vulnerability in a target application, and it does not produce a working exploit. The native layer work stops at the boundary question of which layer generates a signature, not at defeating a verification scheme.

The second is the authorisation constraint, and it is not decorative. The presence of root detection bypass and Frida detection bypass means the tool set is built for work on applications you have permission to test, and a security review of a deployment of this skill should treat the bundled bypass scripts as the sensitive part. Whether those scripts are legitimate depends entirely on the relationship between you and the application owner.

The third is that the skill is written for agents, and that is both its value and its constraint. The reference documents encode a workflow that a language model can follow, and the natural-language trigger examples in the README are ordinary requests such as decompiling an APK, extracting an application's interfaces and signature, or finding whether a sign is generated in the Java or native layer. That works because the workflow is fixed and the tools are external.

The comparison table against the original project also tells you where the work went. The platform support widened to both Claude Code and Codex, the decompiler became two engines compared against each other, the dynamic analysis went from a mention to nine working scripts, native analysis was added along with rizin command references, Windows got a full PowerShell stack, XAPK and packed APK handling became automatic recursive unpacking with split detection, dependency management went from manual to automatic, and the documentation language changed from English to Chinese. The last point is a practical detail for anyone who cannot read Chinese and is relying on the reference material inside the skill.

Editorial conclusion

Adopt android-reverse-engineering-skill if you do authorised Android application analysis and want a scripted static-to-dynamic workflow that a coding agent can drive, since the dependency checks and the two-engine decompilation comparison remove the most repetitive parts of that work. Do not adopt it for work on applications you are not authorised to test, and note that several of the bundled scripts exist specifically to bypass root and instrumentation detection. Before you install it, note that the documented install steps clone a different repository than this one, and the last push was on 2026-05-07 with no GitHub releases.

Frequently asked questions

Official sources

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