A standalone Java Decompiler GUI. Nonetheless, java-decompiler / jd-gui HackingDecompilersAndroid SecurityReverse Engineering. Decompilers are usually unable to perfectly reconstruct the original source code, thus frequently would produce obfuscated code. It is therefore the opposite of a compiler, which translates a source file in to an executable. A decompiler is a computer program translates an executable file in to a high-level source file which can be recompiled successfully.It supports most features of Java, but the shortcoming is that it can't do batch processing.JD-GUI- Standalong GUI which displays the source code of the class files. I found JAD, but it didn't support some new features of Java, and the benefit of this program is that it can execute from command line and generate a. Kaspersky Internet Security for AndroidI'm looking for a program to batch decompile Java classes.In this case there was no manifest, but we could see this in the applet call from the html:< param value = “ The third parameter was the. Usually the Manifest states the entry point (main class) of the applet. Jar file:The class names are weird, but nothing unusual.I had read a McAfee report () about a similar campaign using the same Exploit kit. Jar file exploits.At this point I should say that I was biased. However the point here was to analyze the vulnerability that this. There was no real need to explore any more deeply just to get an overview of what the applet does.
Step 2: Different strategySeeing that the code was not decompiled properly I remembered that to check which vulnerability is being exploited you don’t really need a fully decompiled code. Now I could decompile all the strings, but I still didn’t have a clear idea of what was happening in this. We can confirm that the ZqnpOsRRk class is implementing the Applet:Not exactly rocket science. But now I had all of them!Now this was much more clear and familiar to me. But there was no big clue.I decided also to try a few other decompilers, but still got no results.However when taking a second look at the results of running a now-obsolete JAD I saw that the decompiled code was quite different from the one of JD-GUI, even though it was still incomplete and unreadable.But there were different calls with obfuscated strings to the deobfuscation function.The applet uses a class loader with the obfuscated strings to avoid detection, making it difficult to know what it is loading without the properly decompiled strings. All of them were easily decompiled and I saw some ways to implement this vulnerability. Oracle was having a bad time just then, and shortly afterwards a few other Java vulnerabilities were exposed.I downloaded a few samples from VirusTotal with this CVE. At this point I thought that it might be CVE-2013-0422, so I decided to get more information about this vulnerability and see if I could find something in the code to confirm this.This CVE was discovered in January 2013. We will need this:1 : invokespecial # 1 //Method java/applet/Applet.””:()VAnd the decompiled code with the corresponding instruction numbers:So we can see how a method which just provides returns leaves a lot of garbage in the middle. We can easily get it like this:Javap -c -classpath LOCAL_PATH ZqnpOsRRk > ZqnpOsRRk.bytecodeLet’s take a look to the code we get and what it means, with an eye on the decompiled code. Let’s take a look at the decompiled bytecode manually. If you want to go this way I recommend reading this for the setup:However, I couldn’t stop thinking about why all the decompilers failed with this code. Step 3: Why didn’t the Java Decompiler work?In these cases it is always possible to take another approach and do some dynamic analysis debugging the code. Driver dell precision m4600Now I understood what was happening and what was wrong with the original code I could safely delete the dead code and introduce readable names for classes and methods.But there was still one unanswered question: why was the first decompiler unable to deobfuscate all the strings, and why did I have to use JAD to get everything?JD-GUI returns the bytecode of the methods that it cannot decompile but for instructions such as ldc (that puts a constant onto the stack) it does not include the constant along with the instruction in the output code. It’s up to the decompiler to get rid of this dead code.After a couple of hours manually cleaning the code and reconstructing it from the bytecodes, I could finally read the result and compare it with the original decompiled one. Here a few examples:There are also a lot of nonsense jumps, such as push NULL then jump if null, gotos and nops.Basically it’s difficult to delete these constructors from the bytecode because the parameters are different and don’t always throw up the same opcodes. We can safely delete all this.There are TONS of these artifacts in the bytecode. It just adds a lot of extra noise to the final results.
0 Comments
Leave a Reply. |
Details
AuthorMichael ArchivesCategories |