Apktool for reverse engineering closed Android APK files

Apktool decodes third-party Android apk binaries back to nearly original resources and smali, then rebuilds them — a foundational utility for authorized app audits, debugging, and localization work.

Tool	iBotPeaches/Apktool — Java tool for reverse engineering third-party, closed, binary Android apps
Category	Android reverse engineering / resource decoding
Primary Use	Decoding apk resources and smali to a project-like file structure, then rebuilding modified apps for authorized analysis, localization, and debugging
Safe Use	Use only on apps you own or are explicitly authorized to assess, in research labs, internal app audits, or with written permission — the project explicitly prohibits piracy and non-legal uses
Telemetry Note	Purely local static tooling: it reads and writes files on the analyst workstation and emits no network traffic itself, so detection focuses on filesystem artifacts and rebuilt apk output rather than runtime indicators

Every Android security practitioner eventually needs to look inside an apk they did not build, and Apktool from iBotPeaches has been the default first stop for that job for over a decade. With roughly 25,500 stars and an Apache-2.0 license, it is one of the most established utilities in the mobile reverse-engineering ecosystem, written in Java and maintained on a main branch that carries the current 3.x generation alongside a 2.x maintenance branch. The README is refreshingly direct about scope: it decodes resources to nearly original form, supports rebuilding after modifications, and enables step-by-step debugging of smali code. That last capability — turning a closed binary back into something you can inspect and instrument — is the entire reason it occupies a permanent slot in authorized assessment workflows.

What Apktool does that a simple unzip of an apk cannot is reconstruct the semantic structure of the package. An apk is a zip archive containing compiled XML, packed resources in resources.arsc, a manifest encoded in Android binary XML, and Dalvik bytecode. Raw extraction gives you opaque binary blobs; Apktool translates all of it back into human-readable form — decoded AndroidManifest.xml, readable resource files, and disassembled smali representations of the Dalvik code. The README highlights the topics arsc, 9patch, and apk among its tags, which map neatly to the hardest parts of that translation: the resource table format and the stretchable-patch images Android uses for scalable UI elements.

The project-like file structure the tool produces is the architectural detail that matters most in practice. Instead of a flat dump, Apktool emits a directory tree resembling an Android source project, so an analyst can navigate resources, assets, and disassembled code in a familiar layout. That structure also makes round-tripping possible: you can decode, apply a change — a localization string, an instrumentation hook for debugging, a platform compatibility shim — and rebuild with apktool b. The README explicitly frames the automation of repetitive tasks like building the apk as a core value proposition, which tells you the tool was designed as a working environment rather than a one-shot dumper.

The smali debugging capability deserves its own paragraph because it is the feature that separates Apktool from resource-only tools. smali/baksmari is the assembler/disassembler syntax for Dalvik bytecode, and by emitting smali files in a rebuildable project, Apktool makes it possible to debug closed third-party apps step-by-step. In an authorized assessment context, this is how an auditor verifies a hypothesis formed during static review — placing the app under a debugger and watching execution rather than guessing from strings alone. It is documentary analysis of behavior, not weaponization, and that distinction is exactly how the tool is meant to be used.

The README is unusually explicit about ethics, and that matters for how the tool should be framed. It states plainly that Apktool is not intended for piracy and other non-legal uses, and enumerates legitimate purposes: localization, adding features, adding support for custom platforms, and other good-faith work with respect for app authors. This is not boilerplate hedging; it is a core part of the project identity, and any professional use should mirror it — only analyze apps you own, apps you have written authorization to test, or apps in a lab environment built for that purpose.

The branch structure signals an actively maintained project. main hosts Apktool 3.x, while 2.x continues as a maintenance branch, meaning the maintainer is supporting both current-generation Android packaging realities and long-lived legacy deployments where older tool versions are pinned. A CI badge on the README shows automated builds, and the project publishes a changelog and blog at apktool.org with documentation covering the basics through building from source. For teams, this maturity translates into low operational risk: the tool is unlikely to silently break on modern apk formats, and version pinning for reproducible analysis is straightforward.

Support infrastructure is solid for an open-source utility. The README points to a project page, hosted documentation, an issue tracker, and a real-time support channel — #apktool on libera.chat — plus a long-standing XDA forum thread dating back to 2020 in its linked form, evidence of the tool's deep roots in the Android modding and research community. Downloads are available from a Bitbucket mirror with a secondary mirror on the maintainer's own site, and build instructions live in the official docs. There is also a responsible-disclosure contact for security vulnerabilities in Apktool itself, a detail security-conscious teams should appreciate: parsing hostile apk files is attack surface, and the maintainer commits to promptly addressing reported flaws.

From a defensive perspective, Apktool is equally relevant in the other direction. Malware analysts triaging suspicious Android samples routinely decode them first with Apktool to inspect the AndroidManifest.xml for excessive permissions, examine embedded strings and resources, and map the smali for subsequent deeper analysis in a proper Dalvik decompiler. Threat-intelligence teams diffing successive versions of a malicious family's apk benefit directly from the rebuildable project structure, which makes version-to-version comparison tractable. Because the tool is entirely offline and local, it leaves no network trace of its own — defenders observing its use will see filesystem artifacts and analysis output rather than any telemetry.

Installation is deliberately simple, and the wrapper-script-plus-jar model is the standard approach documented across the project's resources. The essential pattern for a professional workstation is fetching the release jar and invoking it with java -jar apktool.jar, wrapped in a script so apktool d app.apk decodes a package into a project directory and apktool b project/ rebuilds it. Documentation at apktool.org covers platform-specific wrapper setup, build-from-source instructions, and the full option set. That two-verb simplicity — decode and build — is deceptive given how much format translation happens underneath.

Where Apktool sits in a modern workflow is worth stating precisely. It is the format-translation and project-structure layer, not a full decompiler to Java source; analysts typically pair it with tools like jadx for readable pseudo-source, using Apktool when fidelity to the original resource layout, 9patch images, and resources.arsc structure matters — or when a rebuildable output is required. Its sponsorship by firms like Sourcetoad and Emerge Tools, both mobile-development shops, reinforces that the tool's center of gravity is legitimate engineering: localization pipelines, platform support, and app-quality work that happens to require looking inside compiled packages.

For any authorized professional working on Android — pentester with a scoped mobile engagement, malware analyst triaging samples, or developer needing to localize a legacy closed binary — iBotPeaches/Apktool remains the dependable entry point. Its longevity, active maintenance across two release lines, transparent ethics stance, and clean separation of decode/rebuild capabilities make it a low-friction, high-trust component of the toolbox. Just honor the constraint the README itself sets: fair use with respect for app authors, analysis only where authorization exists, and the same disclosure discipline for tool vulnerabilities that the project models for its users.

Official project repository for iBotPeaches/Apktool.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.