I saw a tweet from MalwareCrusaders earlier today about another obfuscated Java applet so I thought I would have a look. Details about where the applet came from is rather slim. Something important may be needed along the way (e.g. applet parameters) so I prefer getting PCAPs but I’ll give it a try nonetheless.
MalwareCrusaders will be posting more details on this soon so I won’t go too deep here. I’ll just focus on the embedded binary file which turns out to be an executable.
Downloading the JAR from the website gives a different one each time but here’s the MD5 hash I’m working off of: 01B9B996144834146B4109719ED84AA5
Opening the file with JD-GUI shows us an object in the JAR:
The embedded file does look encrypted:
We can tackle this two ways. One way is to bruteforce the file. The other is to reverse the applet and find the decryption routine. Let’s go through both starting with the bruteforce method.
Using Converter’s Key Search/Convert feature, you can import the first 1KB of the file so you can test your assumptions on a small data set. Just by looking at it, you can see diagonal waves formed by cetain characters which tells us there’s a pattern. If you don’t see any pattern then the file may be encrypted using the AES or RC4 algorithm.
Just select a bunch of characters and look for repeating strings:
55493564413855774F6A386265516455493564413855774F6A386265516455493564413855774F6A3862655
16455493564413855774F6A386265516455493564413855774F6A386265516455493564413855774F6A3862
65516455493564413855774F6A386265516455493564413855774F6A386265516455493564413855774F6A3
86265516455493564413855774F6A386265516455493564413855774F6A386265516455493564413855774F
6A386265516455493564413855774F6A386265516455493564413855774F6A3862655164554935644138557
74F6A386265516455493564413855774F6A3862655164554935647216
Then put them one on each line:
4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356
4413855774F6A38626551645549356
So this looks like a 15-byte XOR key but which byte goes first? Going back to Converter, just leave the first two characters in the input box, set the input format to “hex”, then do a key search match of “M”. It will tell you what the XOR key is…77.
So 77 is the first byte:
774F6A386265516455493564413855
Now enter the hex string above separated by commas into Converter. Be sure you choose Hex format for the key and select the Consecutive action. Looks like it works!
If you want to write it out to a binary file, you need to make sure that you import the *entire* file (not just the first KB) and the output format must be changed to hex.
The second way is to reverse engineer the applet. You will have to go through each of the applet’s class files and read though the code. There’s a lot of deadends, fake data, and decoys but you will eventually end up on the last class called “U”. In it, is a string of positive and negative integers. The variable is called “encoded” and it just so happens that a few lines down, it says that the “encoded” value is passed to an “XorDecrypt” function along with a string, “wOj8beQdUI5dA8U”.
Further down, we can see the function with useless content except for the code that indicates that each byte is XORed with the string from above. This string is the decryption key.
Let’s copy the strings over to Converter. Make sure the input format is dec(imal), the key format is text, the key itself is separated by commas, and the action is consecutive. Looks like it’s another class file.
To write this out, choose hex output, convert it again then write to binary file.
Change the file name to whatever.class then open it up with JD-GUI. This routine takes the inputStream (which is the encrypted file) along with a decryption string which is the same string as the one above, “wOj8beQdUI5dA8U”.
MD5: 6943787043e7a946c840f9d82f8088f6
VT: 4/46
This entry was posted in Malscript and tagged java applet, java deobfuscation. Bookmark the permalink.
沒有留言:
張貼留言