34
My apologies for the belated reply.
I have been working on a new, open source Java decompiler. Feel free to check it out.I have not tested it against any obfuscated code, but I have seen it decompile many methods that JD-GUI failed to handle. Note that it's a work in progress, and I'm sure you will find plenty of code that it will fail to decompile.
16
Old and Lacking Entries
JAD
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.
Java DeObfuscator
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 ...
14
Maybe radare2 is what you're looking for. See this screenshot:
13
Bytecode Visualizer
Inspect, understand and debug Java bytecode, no matter if you have the corresponding source.
JSwat Debugger
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 ...
12
It largely depends on what kind of vulnerability.
This particular one you mentione is in SecurityManager, and you could have found it relatively easily by analyzing the Java source code.
To get some idea of how that process is done, take a look at this and this articles by Esteban Guillardoy of Immunity.
Jduck has also published some research on memory ...
11
Java compiles to bytecode that is run in the JVM, and stored in the .class files. This bytecode is not a 1:1 representation of the original code, and includes several compiler-implemented optimizations. Information is lost when these optimizations are performed, and due to that lost information decompilers can't reconstruct the code back into exactly what it ...
10
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 ...
9
If you just need to find the bytes you need to change in the original file, IDA shows the original file offset in the status bar. You can also check the opcodes in the Hex View.
9
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 ...
8
Well I myself am an exploit developer. The methods of attack/research are:
Reversing the input values. Files, network protocols etc etc.
Building a Fuzzer with this information
Fuzz till crash
Analyse the crash
Build exploit
Another method I commonly use is to reverse points of interests (eg SingleSignOne modules, other login methods, database connections (...
7
The only real protection is to not deliver the resources!
As long as you give the resources out of your hand they can be extracted. It may be difficult but it is possible to extract them.
The most secure way would be to store the resources on a server and access them in a remote way. But also then if the resource is on the client computer it is possible to ...
7
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 ...
7
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 ...
6
To add on to what Ditmar said, the big problem is probably your obfuscation. Normal Java bytecode is actually surprisingly close to the original source, at least from the perspective of C or C++ (or even Scala). You'll always lose some information, but unobfuscated Java can be decompiled to something close to the original, especially if you compile with ...
6
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.
Paper
Video
There is also a tool called Javasnoop ...
6
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 ...
6
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 ...
6
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 ...
5
Try taking a look at Bytecode Viewer https://github.com/Konloch/bytecode-viewer It has the option to decompile using 5 different decompilers:
FernFlower
Procyon
CFR
Krakatau
JD-GUI
5
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 ...
5
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 ...
5
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
5
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. [1] These represent the possible paths of execution in a method. They are relatively easy ...
5
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'...
4
Your choice of decompiler can greatly affect the outcome. You should try either JODE, or Fernflower (which I believe goes by Androchef).
Before decompiling, it might be a good idea to do some simple deobfuscation yourself. For example, you could try
Remapping of Java keywords that have been used as class/method/variable names to legal Java identifiers. ...
4
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.
http://slightlyrandombrokenthoughts.blogspot.ca/2009/02/java-se-security-part-i_25.html
http://...
4
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. ...
4
You can try using javasnoop (https://code.google.com/p/javasnoop/) to accomplish something similar.
Here's a tutorial for using it -
http://resources.infosecinstitute.com/hacking-java-applications-using-javasnoop/
4
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
4
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
