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 ...
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 ...
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 ...
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
Another method I commonly use is to reverse points of interests (eg SingleSignOne modules, other login methods, database connections (...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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'...
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. ...
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.
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. ...
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