Garlic decompiles dex, apk and class files to Java source in C

From dex and apk back to readable Java source

Garlic takes the binary artefacts of the Java world and turns them back into source you can read. The README lists decompiling apk, dex, class, jar and war files, and the tool description calls it an apk and Java open source decompiler written in C.

The audience is Android reverse engineers and anyone who needs to read code they do not have the source for: security researchers checking what an application really does, analysts auditing a suspicious package, developers recovering behaviour from an old build. It is a developer tool in the plain sense, a command line binary you point at a file.

The C implementation is the reason for the interest. A decompiler in C can be compiled to a native binary for a target platform without a Java runtime in the loop, which is what makes the cross-compilation story in this project possible at all. The homepage points at apppipeline.online, and the project also documents a Garlic and Rosemary pipeline, with Rosemary being the ELF analysis side that Garlic can be paired with.

The top level of the repository also holds MCP-SERVER.md and its Chinese counterpart, so the tool is being exposed to model context protocol clients as well.

Rosemary covers the aarch64 ELF side

Decompiling Java bytecode and analysing a native library are different problems, and the project covers the second one under the name of the ELF analyzer library it links, referred to in the README as rosemarylib. The feature list names analysis of aarch64 ELF files and then breaks that down: control flow, IR, imports, exports, strings, and a function call graph.

Control flow and the IR are what you use to reason about a stripped binary without source, imports and exports tell you what the library exposes, strings give you constants and format strings, and the call graph gives you the shape of the program. This is the standard triage set for a native library.

The limit is explicit in the README: the aarch64 support is the one described. There is no mention of x86 or other architectures for the ELF side, so a native library in a different architecture is outside what is documented here.

On Android the analyzer is switched off entirely. The build notes state that no prebuilt librosemarylib is shipped for Android, so that platform is built with the ELF analysis feature disabled, while all other decompilation features work unchanged.

Three build paths: CMake, Zig and the Android NDK

The primary build is CMake, and the README requires cmake 3.26 or newer on Linux and macOS:

git clone https://github.com/neocanable/garlic.git
cd garlic
cmake -B build
cmake --build build
./build/garlic

The Zig route is the interesting one for distribution. With zig 0.16.0 or newer you build for your host, or pass a target, and the README explains that Zig bundles its own cross-linkers and libc so no cross-toolchain has to be installed:

zig build --release=fast -Dtarget=x86_64-linux-musl

The same -Dtarget switch is shown for Linux glibc, Linux aarch64, Linux i686, Windows x86_64 and 32-bit Windows, macOS x86_64 and macOS aarch64. The output lands in zig-out/bin.

Android has its own route. The environment is an Android NDK of r21 or newer, verified on r28, located through the ANDROID_NDK_HOME and ANDROID_NDK_ROOT variables or the ANDROID_HOME and ANDROID_SDK_ROOT paths, with the default Android Studio install path auto-detected as a fallback. A helper script wraps it:

./build.sh android-arm64-v8a

The result is build/garlic-android-arm64-v8a for arm64-v8a with minSdkVersion 23. Windows users are pointed to two documents in the docs folder, one about building and one about performance tips and known issues.

The command line surface is four flags

Usage is short and readable. Decompiling an apk with default settings writes the source next to the input:

garlic /path/to/android.apk

Two options adjust that. The -o option sets the source code output path, and -t sets the thread count, which defaults to 4:

garlic /path/to/android.apk -o /path/to/save
garlic /path/to/android.apk -t 5

The same flags work for dex files and for jar files. There is one asymmetry worth knowing: for a .class file the default output is stdout, while for a jar the default output is the same level directory as the input file.

Two modes mirror tools you already know. The -p flag gives a javap style listing with the LineNumber and StackMapTable attributes disabled, and the README describes a separate dexdump mode for a dalvik.dex file. The -f flag searches strings inside the file, and it accepts a regular expression as well as a literal:

garlic ~/demo/demo.jar -f "[W|w]indow"

The README notes that a thread count below 2 disables multi-threading entirely, which is worth remembering on a machine where you want to cap CPU use.

What the output does not give you, and where it is quiet

Several documented behaviours are absences rather than features, and they matter if you plan to feed the output to another tool.

The javap style mode disables LineNumber and StackMapTable attributes. That is a deliberate speed choice, and it means the listing is less complete than the JDK tool of the same name. Line numbers in particular are what you use to map a stack trace back to source, so if that is your workflow, this mode is not a substitute.

The class file mode prints to stdout by default, which makes it convenient in a pipeline and inconvenient for a large file. The jar mode writes to a directory beside the input, which means a read-only input directory is a problem and a repeated run can collide with a previous output.

On Android the ELF analysis is compiled out, so a pipeline that starts with a native library inside an APK cannot use Garlic for that step on the device.

One more gap: the README has a Debug section that points at src/jvm.c and asks you to change the main function to call jar_file_analyse directly. That is a statement about how thin the wrapper around the library is, and it is also the only documented route to embedding the analyser in your own program.

The speed claim comes from one large apk

The README reports a single measurement: a recent WeChat apk, more than 200 megabytes with more than 190,000 classes, decompiled in 12 seconds. The console output it shows is short:

garlic ~/wechat/wechat.apk
[Garlic] APK file analysis
File     : ~/wechat/wechat.apk
Save to  : ~/wechat/wechat_apk
Thread   : 4
Progress : 192538 (192538)
[Done]

Treat this as one data point from the project's own documentation rather than a benchmark. It does not say which CPU, how much memory, or whether the resulting source is equivalent to the original, which is the question that matters more than speed for a decompiler.

The speed claim is also the reason the tool is interesting next to the tools it resembles. Garlic's javap style mode is described as faster than javap, and it decompiles rather than disassembles, producing Java source from class, jar, dex and apk input where the JDK's javap and the Android SDK's dexdump print bytecode-level listings. The trade is depth for speed: you get a higher level view of the code, and you give up the line number and stack map attributes that the lower level view carries.

That difference is the honest comparison to make. If your task is to read the logic of an application, Garlic's output is the more useful artifact. If your task is to map a stack trace or verify a class file attribute by attribute, the platform tools are the correct instrument.

Releases named after herbs, and an Apache 2.0 licence

The version tags read like a menu. Version 1.7-release was published on 2026-07-10, v1.8-release with rosemary on 2026-08-17, and v1.8-release-thyme on 2026-10-05. The last push to the default branch was on 2026-10-19 and the repository is not archived, so work is still landing on the main branch between tags.

Two different build systems sit side by side in the repository: CMakeLists.txt with a cmake folder and toolchains for the Android builds, and build.zig with build.zig.zon for the Zig path. The sources live in src, with a libs folder for bundled dependencies and a shell folder that holds the images used in the README. release.sh sits at the top level next to build.sh.

The licence is Apache 2.0, stated in the README and in the licence badge. For a tool you may compile and redistribute inside your own analysis pipeline, that licence is permissive, but two points are worth checking in the text yourself: the patent grant and the requirement to keep the licence text with the source. That is a licensing fact rather than legal advice, and it also matters for the libraries under libs, whose terms are separate from the tool's own.

For a researcher who wants to extend the analyser rather than only run it, the Debug section and the Rosemary pairing are the two entry points into the code.

Editorial conclusion

Adopt Garlic when you reverse engineer Android artefacts, want Java source rather than disassembly, and prefer a tool you can cross-compile from one checkout, including to Android with the NDK. Do not adopt it when your pipeline needs line number tables, StackMapTable data, a guaranteed output layout for jar input, or ELF analysis on Android, because the ELF side is disabled there and no prebuilt librosemarylib is shipped. Before you build on it, check the thread count behaviour for a single-thread run, confirm the output directory for the input type you care about, and read the Apache 2.0 licence text, since the project publishes releases under herb themed names such as v1.8-release-thyme and v1.8-release with rosemary.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. neocanable/garlic on GitHub
3. Project website
4. README
5. Releases