It's not only possible but has been done already, and not just once. Here's three I know about, and there may be more.
Kivlad by Cody Brocious
DAD by Zost (Androguard project):
JEB by Nicolas Falliere (commercial)
Then there ...
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.
I did a quick test with JSmooth and it simply places the whole .jar file in a resource. You can easily see this by opening a JSmooth executable with Resource Hacker as the following screen shot shows (I used sun's deploy.jar from the java lib folder):
For other utilities it might be different but you could use a tool like binwalk to look for the jar/zip ...
Oracle Java Virtual Machine
Tracing the execution of a Java program can be done through the Java Platform Debugger Architecture (JPDA). This framework allow you to get a full control of an execution within the JVM (without having to modify the original code). See this tutorial for a more in depth view of this framework.
If you want to implement it by ...
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 ...
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 ...
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 ...
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 ...
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 ...
I can't speak to which one of these is the best, but there are a few java decompilers out there as indicated by this SO question. None of these decompilers appear to attempt to actively handle obfuscation though and many of those projects are abandoned.
I have not tried Krakatau, but it sounds like it may help with what you are looking for.
From the readme:...
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 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 ...
You can instrument Java by using an agent, that will manipulate the bytecode of the loaded file (using Asm is recommented for bytecode manipulation).
You might want to use Eclipse's Bytecode Outline plugin to debug execution.
This is a good tutorial on the topic.
I think it should be possible even with current Java decompilers, by patching their code. They have at least one big difference - while JVM is stack-based, Dalvik is register-based. This difference could be handled with not so much code. Second difference - bytecode format. So you need use code, which is able to disassemble Dalvik bytecode format.
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 ...
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 ...
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 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 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 ...