Old and Lacking Entries
Some time ago, everyone’s decompiler of choice was jad. Currently, the project is dead (in addition, it wasn’t open source), but still you see a lot of people referring to it.
Also an older tool from fileoffset.com, but still works more or less. The interface is rather clunky to use for larger projects, but the ...
Inspect, understand and debug Java bytecode, no matter if you have the corresponding source.
JSwat is a graphical Java debugger front-end, written to use the Java Platform Debugger Architecture and based on the NetBeans Platform. Its features include sophisticated breakpoints; colorized source code display with code ...
There is no similar feature for Java byte code.
When you compile a C program, and statically link it to a standard library, the library code will be present, more or less unmodified, within the binary (except for addresses which will change), but there won't be any hint that a particular function had a particular name before being compiled (unless debugging ...
There're two broad ways in which you can declare JNI functions.
The first is the more obvious way in which the JNI function has to follow a specific naming convention like JNIEXPORT void JNICALL Java_com_app_foo_bar. You can easily identify such functions using readelf.
The other not so obvious way is to use RegisterNatives. Here your functions can have ...
The problem is that there is no notion of inner classes at the bytecode level. Each inner class is compiled to a separate class with no special privileges compared to any other class in the same package.
So in order to support the functionality of inner classes, the compiler has to add getter methods behind the scenes. Every time you access a field in the ...
I would recommend using a Java Agent to extract classes from the running JVM instance. An agent is a tool that provides instrumentation capability for an application. Speaking of agents, there are two broad ways they can be developed:
In pure java
In C/C++ in the form of native agents.
A native agent has more capability than a pure Java agent, but for ...
Stripping line numbers has a minimal impact on the difficulty of reverse engineering code. If it is causing you problems, I would recommend disabling it.
Col-E's answer is a red herring because it is fairly easy for a reverse engineer to insert synthetic line numbers into the bytecode to disambiguate stack traces (assuming they don't just rename the methods ...
Some tools you can use. However note that none of them has the ability to recompile classes, i.e you cannot decompile a single class to source, modify it, and then recompile back. It may be possible using Reflection API but then you need to do a lot of modification on the decompiled source itself. Other ways may be to decompile the entire bunch of classes ...
edit: This question overlaps with Dynamic java instrumentation?
Jeong Wook Oh did a presentation at Blackhat 2012 were he explained how to trace Java programs by modifying the bytecode to call hook methods, see the "Automation" section of the paper. There is no source or tool available as far as I know.
There is also a tool called Javasnoop ...
You want to look at the definitions of the methods being called. The definition of the decryptString method will contain the native access flag, similar to it's corresponding java declaration. e.g. Something like:
.method public native decryptString(Ljava/lang/String;)Ljava/lang/String
Additionally, you can look for calls to System.loadLibrary as an ...
The approach to finding security vulnerabilities in games is no different than the approach to finding security vulnerabilities in other applications.
As discussed here, "Most vulnerabilities in closed-source products are found via fuzzing and static reverse engineering... Typically you don't need to analyze the entire program, but only the entrypoints for ...
The reason it happens is because JD-Gui isn't encoding unicode properly. You can see that the thing inside the quotes is two bytes, and appears to be interpreted as nonstandard upper 128 characters. I.e. JD-Gui is emitting unicode, but the charset isn't declared correctly so your editor interprets it as two raw bytes in an 8bit charset instead of a single ...
Use JD-GUI to examine the jar file
Unpack the jar file
jar -xf yourapp.jar
Modify the .class file with a Java Bytecode Editor
Use Java Bytecode Editor (JBE)
Repack the modified classes into new archive file
jar -cvf yourapp_patched.jar *.*
Credits for this particular solution to Khai Tran @ NetSPI
If the control flow graph has not been obfuscated then you could use those to match methods. The biggest hurdle to this is building up the database of library signatures.
Control flow graphs are the structure that the basic blocks make when viewed as a directed graph.  These represent the possible paths of execution in a method. They are relatively easy ...
Krakatau is probably the decompiler most likely to produce code equivalent in behavior to the original (unless the code is using Java 8 lambdas, which Krakaau doesn't support). However, it is not possible to roundtrip decompile in general because compilation and decompilation are both lossy processes. And if the code has been obfuscated as Minecraft is, you'...
Lots of Java exploits revolve around bypassing the Java sandbox, the Security Manager in Java parlance. Sami Koivu published a lot of interesting work around Java security and exploits, notably his 3 parts introduction to Java security.
The ASEC file is a TwoFish encrypted container which in turn is a dm-crypt volume that gets mounted by Linux's device mapper at /mnt/asec/[app_id] (The AppID is based on the package name). The 128-bit key to the container can be found in /data/misc/systemkeys but this file requires root access for reading. You can read exactly how the encryption works here. ...
You can try using javasnoop (https://code.google.com/p/javasnoop/) to accomplish something similar.
Here's a tutorial for using it -
Proguard's "optimisation" stage results in deobfuscating junk as I wrote up here - http://www.surrendercontrol.com/2016/03/using-proguard-to-deobfuscate-code.html.
Also, Caleb Fention's Simplify engine has a bunch of very nice ideas and implements them for Dalvik code, if not straight for JVM - https://github.com/CalebFenton/simplify
You can dump bytecode at runtime using HotSpot tools, and use a decompiler to reverse the bytecode. I made a proof of concept, available here
It requires 3 dependencies:
JDK libraries (sa-jdi.jar, tools.jar) to dump bytecode
Fernflower to decompile bytecode into java code
RSyntaxTextArea to display java source code
You could also have a look at the HSDB ...
You are correct that the binary does not match the tagged source. It does, however, match the changes made in commit 6cfc6b4a403f8487d9fa96aa3d42db7848c8755a, which was made on February 25, one day after the most recent commit tagged 6.11 and before the most recent merge commit in 6.11.
I can only speculate, but it seems likely that their local version of ...
Stack maps were a feature added in Java 6 (corresponding to version 50), but were not made mandatory until Java 7 (version 51) in order to ease the transition. Stack maps make classloading slightly faster at the expense of making bytecode generation significantly more painful.
If you are manually editing bytecode, then it is a big hassle to write the stack ...
There's no technical limitation preventing software development in Java verses C. The only major advantage is execution speed. Moreover, as JEB is directed towards Java programs (android APKs) writing it in Java makes sense.
However, this question is not really about reverse engineering.
The issue is that constant pool entry 67 (the one for your List.get()) method has the type Method, rather than InterfaceMethod, even though you are trying to invoke it as an interface method. When using invokeinterface, the corresponding constant pool entries need to be InterfaceMethod.
Assuming you didn't specify the type itself, this is likely a bug in ...
In short, the difference is in the format into which Java and native code are compiled and executed. Compilation into native code formats eliminates from resulting executable a lot of information that Java code keeps by design, including, but not limited to the following list:
Properties names and types
Firstly, I would mention that instead of using a general purpose hex editor, a dedicated class editor would be much better. There are plenty of them.
You tried editing the class file and to your surprise the changes you made were not reflected. At that point you should be pretty much sure that there must be some other tricks such as generating the strings ...
The Krakatau decompiler will automatically rename the output files to valid filenames if the original class name doesn't correspond to a valid filename.
Note that the original names will still be preserved inside the generated files. As for renaming inside the actual source files, I wrote a script to do that (along with various other deobfuscation scripts) ...
First of all, there is a fix for Fernflower issue with missing classes here. You can say thank you to agaricusb for this.
For now Fernflower remains the best Java decompiler even It was not maintained for last few years. I've tried to reach the author recently, but still no luck.
As for AndroChef Java Decompiler, It's uses Fernflower as engine with author'...
I'm using https://github.com/JetBrains/intellij-community/tree/master/plugins/java-decompiler/engine
It's the decompiler from IntelliJ, it decompile codes where JD-GUI fail.
It's a unofficial mirror to download: