re-apktool

MCP server for Android APK triage. Two backends are supported on the same MCP surface:

• apktool (Java) — the canonical APK disassembler. Produces a Smali representation of every DEX class plus a decoded AndroidManifest.xml. Install: apt-get install apktool or download the jar from https://github.com/iBotPeaches/Apktool/releases.

• androguard (Python) — pure-Python APK / DEX / manifest parser. Always installed (the server's hard dep). Faster to import, easier to script; less Smali-friendly than apktool.

The MCP wrappers call whichever backend is available; the check_apktool tool reports the active backend so the analyst knows which one fired.

Tools

Related MCP server: Apktool MCP Server

Why both backends?

apktool is the gold standard for Smali and manifest decoding, but it's a Java tool the user has to install. The parse_apk + list_dex_classes + decode_manifest surface area is small enough that androguard covers ~90% of the analyst's needs (header + classes + manifest) without requiring a JRE. The MCP layer prefers apktool when present and falls back to androguard cleanly.

Install

pip install -e ./servers/re-apktool        # androguard (required)
apt-get install apktool                    # apktool (optional, java)

Run

re-apktool                                 # stdio transport (default for MCP)
python -m re_apktool                       # equivalent

Deferred to a future run

The original Explore findings called for an APK parser; this scaffolding lands it so the future Android target run has the toolchain. The Live Fire Windows-target run uses re-leak-scan + re-winedbg for the three named products; re-apktool becomes the workhorse when an Android binary is in the input.