Skip to main content
Glama

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

Tool

What it does

check_apktool

Health check — return apktool / androguard / java availability

parse_apk

Open the APK, return header info (package, version, min/target SDK, per-file entry list, signature block presence)

list_dex_classes

Enumerate classes across every classes*.dex in the APK

decode_manifest

Return the decoded AndroidManifest.xml (text) plus the parsed activity / service / receiver / provider / permission lists

Related MCP server: APK Security Guard MCP Suite

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.

Available Tools

5 tools
check_apktoolA

Return apktool / androguard / java availability.

Active backend is one of "apktool" (apktool jar on PATH and a JRE), "androguard" (pure-Python fallback), or "none" (server can't analyse anything).

The MCP layer prefers apktool when both are present because apktool's Smali output is closer to the canonical AOSP form. androguard is the always-on fallback for the header

  • class enumeration + manifest-decoding tools.

Inputs: no named parameters.

classify_apk_protectionA

Walk the APK + every classes*.dex for known protection patterns.

Uses the vendored data/apkid-signatures.json catalog. Returns a list of {category, evidence, evidence_offset, evidence_file} records with category-only labels ("apk_packager", "dex_obfuscator", "ssl_pinning", etc.). The category names describe observable patterns; no specific commercial product is named.

Args: path: path to the APK max_per_category: per-category match cap (default 50)

Returns::

{
  "path": "...",
  "matches": [{"category": "...", "evidence": "...",
               "evidence_offset": N, "evidence_file": "...",
               "match_pattern": "...", "id": "..."}, ...],
  "by_category": {"dex-obfuscator": 12, "ssl_pinning": 2, ...},
  "truncated": {"per_category": bool}
}

The signature table is matched against:

  • classes.dex string table (DEX class names + method signatures + string literals);

  • every lib/*.so for the native-section + string-literal categories;

  • the manifest's application / meta-data elements.

The implementation lives in servers/re-apktool/src/re_apktool/classify.py.

Inputs: path (required), max_per_category.

decode_manifestA

Decode the APK's AndroidManifest.xml.

Returns the manifest as text (androguard's AXMLPrinter output) plus the parsed activity / service / receiver / provider / permission lists.

When the manifest is binary-only (some closed-source protectors encrypt it) androguard fails — the analyst falls back to apktool d directly. The MCP layer surfaces the error in the response rather than silently returning a half-decoded manifest.

Inputs: path (required).

list_dex_classesA

Enumerate every class in every classes*.dex in the APK.

Returns one record per class::

{
  "fqn": "com.foo.Bar",
  "access": "public",
  "method_count": N
}

plus a per-dex summary. Use this for the "what's actually compiled into this APK" view — class names are the structural fact, not the implementation. Apktool would give a Smali dump; the MCP surface sticks to the typed class graph so the analyst can ask Claude "what classes are in this APK" without dragging the full bytecode into context.

Inputs: path (required).

parse_apkA

Return a structural summary of the APK at path.

Output includes:

  • package / version / min+target SDK

  • activities, services, receivers, providers

  • permissions list

  • signature scheme (v1 / v2 / v3)

  • debuggable + allowBackup flags

  • per-file entry inventory + DEX / native lib / asset counts

Uses androguard for the manifest-backed fields, falls back to a zipfile-only walk for the entry list when androguard is missing.

Inputs: path (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.1/5.0

    Scored across 5 tools

    Disambiguation4/5

    Tools are mostly distinct: check_apktool checks tool availability, classify_apk_protection identifies protection patterns, decode_manifest outputs manifest XML, list_dex_classes enumerates classes, and parse_apk provides a structural summary. Some overlap exists between decode_manifest and parse_apk (both output activity/service lists), but descriptions clarify the different outputs (raw manifest vs. summary).

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern with snake_case (check_apktool, classify_apk_protection, decode_manifest, list_dex_classes, parse_apk). No mixed conventions or irregular naming.

    Tool Count5/5

    Five tools is well-scoped for an APK analysis server: checking the backend, classifying protection, decoding the manifest, listing classes, and parsing the overall structure. Each tool earns its place without being redundant or overwhelming.

    Completeness4/5

    The set covers core APK analysis tasks (structure, manifest, classes, protection), including signature scheme and entry inventory. Minor gaps exist: no Smali decompilation or resource extraction tools, but the provided tools allow thorough structural and security analysis.

    Related MCP Connectors

    Related MCP Servers

    Appeared in Searches