Diobfuscator runs Java obfuscator transformers against a jar, from the IDE

What the repository actually is

The README calls the project Diobfuscator and describes it as a deobfuscator for java. The repository is a Maven project with a pom.xml at the root and five substantive directories: deobfuscator-api, deobfuscator-impl, deobfuscator-transformers, reverse-engineering and testData. The api module holds the public surface, the impl module holds the machinery, and the transformers module holds the individual transforms, which the README points you at for the list of what you can run. There is also a CONTRIBUTING.md that doubles as a project introduction and a primer on the basics of java bytecode. The previous version of the tool lives in a v1 branch of a different repository, narumii/Deobfuscator, and the README links it for anyone who wants that one. The primary language is Java, the licence is GPL-3.0, the default branch is master, the homepage is a Discord invite, and the last push was on 2026-06-18 with no GitHub releases.

The transformer list is the catalogue of obfuscators it targets

The repository topics are the clearest description of the scope. They include deobf, deobfuscate, deobfuscation, deobfuscator, java-deobfuscator and javadeobfuscator alongside names of specific obfuscators and their ecosystems: binsecure, bozar, caesium, jobf, mosey, paramorphism, qprotect, sb27 and sb27-deobf, scuti, and superblaubeere27. Two of those, sb27 and superblaubeere27, name a well-known family of Java obfuscators whose protections are exactly the kind of thing a transformer module exists to unwind. The Transformers module path given in the README, deobfuscator-transformers/src/main/java/uwu/narumi/deobfuscator/core/other, is where you find the implementations, and the choice of transformers is a configuration value rather than a command line flag, so the set you can apply is whatever that module contains. This is the practical shape of the tool: not a general binary analysis environment, but a catalogue of specific unwrappers that you select individually for a given sample.

Two JDKs, and why the sandbox needs the old one

The prerequisites are the first thing that trips people up, and the README is emphatic that you need two different Java installations. Java 17 from Adoptium is required for the project to compile and run. Java 8 is required for the sandbox, referred to as the SSVM, to work properly. The reason appears in the FAQ, which covers the case where the sandbox does not work and the error rt.jar is required for sandbox to run. The sandbox requires rt.jar from a Java 8 installation. The deobfuscator tries to auto-detect it, and if that fails there are two ways to point it at the right file. You can set it via the system property -DrtJarPath="path/to/rt.jar", or specify it in the Bootstrap configuration with .rtJarPath(Path.of("path/to/rt.jar")). The README also lists common rt.jar locations, noting they may vary by installation, with examples for Oracle JDK 8 and Eclipse Adoptium JDK 8 under a jre/lib path. The design rationale is that the sandbox emulates the obfuscated code, and that emulation expects the class library of the runtime the obfuscator targeted.

Two ways to point the sandbox at the right file, taken from the README's FAQ, are a system property and a configuration call.

-DrtJarPath="path/to/rt.jar"

.rtJarPath(Path.of("path/to/rt.jar"))

The workflow is seven steps inside IntelliJ

The README is explicit that if you want to use the deobfuscator you need to start it from your IDE manually, so there is no packaged entry point. The steps are as follows. Clone the repository and open it in IntelliJ. Make sure Java 17 is selected under Project Structure and SDK. Install Java 8 if you do not already have it. Place your obfuscated jar inside the root project directory, with the example given as work/obf-test.jar. Navigate to the Bootstrap class, located at deobfuscator-impl/src/test/java/Bootstrap.java. In that class, edit the deobfuscator configuration, where inputJar is your obfuscated jar file from the previous step and transformers is the list of transformers you want to run, which you find in the deobfuscator-transformers module. Finally, run the class manually from your IDE, and the README notes you can use the pre-configured IntelliJ task named Bootstrap. The .run directory at the repository root holds those run configurations, which is where the pre-set task lives. The repository also includes an assets directory with a run-deobfuscator.gif showing the process.

Where the configuration actually lives

Two fields carry the whole configuration. The inputJar points at the obfuscated archive and is set in the Bootstrap class inside the implementation module's test sources, which is a slightly unusual place for it but keeps the sample next to the code it exercises. The transformers field takes the list of transforms to apply, and each one comes from the core/other package in the transformers module. The rtJarPath option belongs to the same configuration object when auto-detection of the Java 8 runtime library fails. That gives you three inputs total: which jar, which transformers, and where the sandbox finds rt.jar. What you do not get is any command line interface, any configuration file, and any documented pipeline mode, since the repository layout shows only .run IntelliJ configurations, an .onedev-buildspec.yml for continuous integration, and the Maven modules. A build server can presumably invoke the same entry point, but the README describes the IDE path only.

Where Diobfuscator is the wrong tool

The obvious limit is the workflow itself. A tool you must start by hand from IntelliJ, against a jar you copy into the source tree, is a research instrument for a person at a desk, not something you can put in an automated pipeline that processes a queue of samples. If your requirement is reproducible batch analysis, you will be writing the surrounding automation yourself around a manual step. The second limit is the sandbox dependency on Java 8. rt.jar no longer exists in a modern JDK, so the tool needs a legacy runtime installed alongside your current one, and if that runtime is not present the sandbox fails with an error message rather than a wrong answer, at least. The third is scope. The transformer set covers named Java obfuscators, and a sample protected with something else gets no help from this repository. The fourth is the legal and ethical line, which the README does not discuss at all. Deobfuscating a jar means defeating protections someone put around their code, so the tool is appropriate for malware analysis, for software you own, or for research, and the responsibility for that use sits with the operator.

Editorial conclusion

Adopt Diobfuscator if you analyse obfuscated Java jars regularly and are comfortable running a research tool from source in IntelliJ, since the transformer catalogue covers a long list of named Java obfuscators. Skip it if you need a packaged CLI or a reproducible pipeline, because the README states the tool must be started manually from the IDE. Before you run it, install both Java 17 and Java 8, confirm the sandbox can find rt.jar, and only transform jars you are authorised to analyse.

Frequently asked questions

Official sources

1. Diobf/Deobfuscator on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README