Apk Java Decompiler
Kizzy Burnworth
JD-Core is a JAVA decompiler written in JAVA. JD-Core is a standalone JAVA library containing the JAVA decompiler of "Java Decompiler project". It support Java 1.1.8 to Java 10.0, including Lambda expressions, method references and default methods. JD-Core is the engine of JD-GUI.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Can you recommend a Java decompiler for Eclipse? My other questions is what restrictions is there for using a decompiled code from an other Java program? Illegal or what? I dont know much about licenses. Thanks for reading.
The one which has worked absolutely flawlessly was Cavaj 1.11, the code produced by it contains no syntax errors and the applet compiled from the sources runs identically to the original. What I was missing on the UI side was: Ctrl-A/Ctrl-C keyboard shortcuts not working, and no batch conversion available.
For example, I had an example where the original case statement didn't have a 'break' on the last node (because naturally this is unnecessary), but because JD ended up re-ordering the nodes it meant the 'default' case was called unexpectedly. I also had an issue with character sets where I required some extra toString() calls on the end of things for it to log out as expected. Apart from that it was great!
I used another decompiler DJ to help me work out what was wrong with the code decompiled by JD. But there were other things that DJ couldn't handle, so I guess a mixture of both decompilers worked for me :)
I have the JD-eclipse-plugin installed. I want to decompile the classes within a jar-file. So I select the jar-file within Project-Explorer and click Decompiler in the Menu. However both decompilers (JAD and JD-core) are greyed out.
I also tried the steps shown in this blog on AVAJAVA Web Tutorials. I guess the blog is a bit outdated, however I can see within Windows-->Preferences-->Java-->Decompiler that Jad is correctly set up. But there is no JD-eclipse found within Preferences-->General-->Editors-->File Associations as you can see in the following image.. Now I right click the jar-file within Project-Explorer, but there is no such "Attach Source File".
Obviously I mixed the actual JD-eclipse-plugin an a plugin called JadClipse for Eclipse which is a slightly different plugin from eclipse marketplace. Thus when I followed the installation instructions of JD-eclipse, I could set the options for the screenshot posted within the question. So I set JD-eclipse as default for both *.class-files with and those without source-code.
Second mistake I did was a pretty silly and obvious one, namely that I wanted to browse the jar-files from within WEB-INF-folder of my Tomcat instead of from within Java Resources. Thus I could not dive into the jar-files at all hindering me to get to the class-level and thus to decompile those classes contained within the jar.
There are a few programs you can use. You will get the actual Java code, but sometimes the code will have been obfuscated so methods are named by one letter or number or a random mix of letters and numbers.
Most decompilers for Java are based on JAD. It's a great tool, but unfortunately hasn't been updated for a while and does not handle Java 1.5+ classes very well. I have not seen any tools that will properly handle 1.5+ classes.
If you want to see how the Java compiler does certain things, you don't want decompilation, you want disassembly. Decompilation involves transforming the bytecode into Java source, meaning that a lot of low level information is lost, and if you're wondering about compiler optimization, this is probably the very information you're interested in.
Anyway, I happen to have written an open source Java disassembler. Unlike Javap, this works even on highly pathological classes, so you can see what obfuscation tools are doing to your classes as well. It can also do decompilation, though I wouldn't recommend it.
On IntelliJ IDEA platform you can use Java Decompiler IntelliJ Plugin. It allows you to display all the Java sources during your debugging process, even if you do not have them all. It is based on the famous tools JD-GUI.
AndroChef supports Java language features like generics, enums and annotations. According to some studies, AndroChef Java Decompiler is able to decompile 98.04% of Java applications generated with traditional Java compilers - a very high recovery rate. It is simple but powerful tool that allows you to decompile Java and Dalvik bytecode (DEX, APK) into readable Java source.
To see the decompiler in action, right-click on a Java symbol for which you don't have the source code, and choose Go to Definition (or simply command/ctrl+click on the symbol). You will see the decompiled code.
As a developer who splits his time between the .NET and Java platforms, I have been surprised and dismayed by the lackluster selection of decompilers in the Java ecosystem. Jad (no longer maintained, closed source) and JD-GUI (GPL3) are pretty decent choices, but the former does not support Java 5+ language features, and the latter tends to barf on code emitted by my LINQ/DLR tree compiler.
While still incomplete, my own tests seem to indicate that the Procyon decompiler can generally hold its own against the other leading Java decompilers out there. There are, however, some known issues.
Java 7 is required to run. Unfortunately, I do not yet have a slick GUI front-end like JD-GUI (but third-party front-ends do exist--see below!). I do, however, offer color-coded output for consoles supporting ANSI/xterm-256. I also offer three output modes:
Note that color-coded output requires an ANSI-compatible console. Unfortunately, this rules out the Windows command prompt. To get color-coded output on Windows, I recommend using a terminal environment like MobaXterm. If ANSI detection fails for whatever reason (as it does with MobaXterm), you can force it on by running with -DAnsi=true.
The main class (entry point) is com.strobel.decompiler.DecompilerDriver. It's also the entry class for decompiler.jar (available under Downloads). You can pass in one or more types to be processed. At the moment, all output goes to System.out. I will probably add file-based output in the future. To call the public API externally, use the helper class com.strobel.decompiler.Decompiler.
The input types can be fully-qualified names in dotted or binary form (e.g., java.lang.String or java/lang/String) or relative/absolute file paths (path/to/MyClass.class or C:\src\path\to\MyClass.class) or even whole jar files. If you pass in a type name, it will attempt to load it out of the user or bootstrap classpath. If you have trouble getting it to locate classes from jars or directories in your CLASSPATH environment variable, try running the main class directly instead of running with -jar.
Bytecode Viewer is an open source Java decompilation, disassembly, and debugging suite by @Konloch. It can produce decompiled sources from several modern Java decompilers, including Procyon, CFR, and FernFlower.
In the past few days, I had some fun trying to understand the inner workings of an APK file.Previously, I had only used the legendary JD-GUI as a decompiler for some CTF challenges.But when dealing with more complex code, I found that looking at the output of different decompilers can help.Hence, I did a little research to find more decompilers that use different approaches.This post serves as a little reference on how to build and use these tools.
For the first approach, jadx is the way to go.If your target is an APK file, you should definitely give this tool a try.I saw that a lot of APK analyzers rely on it, which probably means that it does a good job.
The second approach requires some mechanism to translate .dex files into .class files.dex2jar is undoubtedly the most commonly known tool to do this.However, I stumbled upon Enjarify.It advertises to work better for several edge cases:
It [dex2jar] works reasonably well most of the time, but a lot of obscure features or edge cases will cause it to fail or even silently produce incorrect results. By contrast, Enjarify is designed to work in as many cases as possible, even for code where Dex2jar would fail.
When I saw the homepage of CFR the first time, the project quickly gained my sympathy.No fancy JavaScript-based interface, just a plain HTML site.The first sentence on the page immediately caught my eye:
Next up is Fernflower, which is part of IntelliJ IDEA.Everyone mentions that it is an analytical decompiler (as stated in their project description), but nobody points out what this actually means.I only found this Stackoverflow question, which unfortunately remains unanswered as of today.
Anyway, since there are no self-contained releases, you need to build it yourself.As a Gradle-based project, you can clone it and then run the following command given that Gradle is installed on your machine.
Next, make sure you have jars containing defintions (sic!) for any external classes (i.e. libraries) that might be referenced by the jar you are trying to decompile. This includes the standard library classes (i.e. JRT).
And according to the description, these standard library classes come with up to version 8 of Java in the form of the file rt.jar.For later versions, the author provides jrt-extractor, which can generate this file for us.
GUI tools like Bytecode Viewer also use multiple decompilers under the hood and allow you to see their output nicely side-by-side.But I prefer going the manual way to see what parameters I can adjust.You have more control over how you launch a decompiler, and you will probably learn new things.
One of the users of my Emacs java extensionse-mailed me with a question/suggestion about viewing .class files inEmacs. Emacs has automatic compression, encryption, and archive modeswhich allow certain non-text files to be viewed within Emacs in asensible text form. He wanted to do the same with Java byte-compiled.class files: when opening a .class file, Emacs should automaticallyand transparently decompile the bytecode into Java source.
c80f0f1006