Mert SARICA
I agree that working at byte code level is sometimes a bit challenging. If the mission is analyzing a Java malware, decompiling the class files into Java source code is the first step most analysts would take. However, like I mentioned in my post on July (Java Byte Code Debugging), if you are up against a malware that takes advantage of an obfuscator tool (like Allatori) Java decompilers (like JD) can most of the time let you fail.
Around December, a Java malware called siparisler.rar (siparisler.jar) took my attention which downloads additional payload from a website that I think was hacked with different password each time.
When I looked at the class files inside the JAR package that was made with the help of Allatori obfuscator tools’ strongest features (long class and method names, reserved names like AUX e.t.c), I saw that file names were approximately 8000 digits long.
Because of the long file names, when I tried to extract the malware to the operating system with the use of tools like Winrar, 7zip, Unzip I realized that I got stuck at operating system limits and was not able to open the files. Also because of the long file and method names I noticed that most decompilers (except CFR) got an error during the decompilation process.
As a person who witnessed that this malicious file was crashing a commercial product that does sandbox analysis while it is analyzing, I can state again that corporations whom only invest in and rely upon devices are on a thin ice.
Of course, with Python a simple tool like Allatori Zip Shortener, making this zip file openable was easy enough.
To gain a more detailed information, I could have continued with a byte code level analysis, like in the article that I posted on July. If my purpose was to only find the type of this malware, I could have learned that it is a Jsocket RAT software by doing a quick search on the memory file without any trouble.
While I was analyzing this malware, I realized that most decompilers were not enough against Allatori thanks to a website (http://www.javadecompilers.com/).Most decompilers were either unsuccessful to decompile this malware into a source code or the source code they decompiled was in a condition that could not be reorganized. If I wanted to move on with a byte code level static analysis, I could have seen that Allatori is hiding the strings and to be able to solve it I would have needed to find the method of hiding which would have made my work longer at byte code level. Because of this, I decided to evaluate existing decompilers against Allatori and try to find out which decompiler can reveal the algorithm that was used for hiding those strings. The criterion for success was that the class file which got decompiled to source code was reorganizable and executable.
First of all, in Java I wrote a simple code which prints “Hello World” to the command line and compiled it into a JAR package. Then with the Allatori, I create an obfuscated HelloWorld package. Finally, I started to decompile all the JAR files into the source code and then compile and run them by using this site http://www.javadecompilers.com/
As a result of the evaluation I found out that JadX and Procyon decompilers were able to successfully decompile the codes that were hidden by Allatori v5.6 Demo version to their original form.
With the help of Procyon and JadX, the string obfuscation algorithm that is used by Allatori v5.6 came to light :)
Hope to see you on the next post, have a secure day.
Original Article: Java Kaynak Kodu Dönüştücüleri
Translated to English by: Hüseyin Fatih Akar | Twitter: @thehakar)
Mert SARICA
