Obfuscation’s aim is to reduce the ability for a reverse engineer to perform static Analysis on the Binary/program. Obfuscation can be accomplish by modifying the programs layout, logic, data and the organization. Essentially Obfuscation transforms the code in such a way that it becomes less human readable, but still retains its functionality. Obfuscators often add irrelevant instructions that don’t really produce valuable data, its possible for others to make a DeObfuscator. A Deobfuscator will implement various data flow analysis algorithms on an obfuscated program which will enable it to seperate the good code from the chaff thrown in by the obfuscator, and auto magically remove the irrelevant instructions.
The reason we bring up code obfuscation and stray from Packing is because Monday evening Chris over at LSO released Crackme0×02. I went into the Crackme yesterday morning expecting it to be slightly harder than the first, but definitely not as difficult as it was. Honestly, The Crackme was made much more difficult by myself than it really was. I broke the first rule of Reverse Engineering. “Never Assume Anything.” As I first started poking around with the Binary I made assumptions which took me on a detour of where I should have been. So, Let’s begin our 3 Hour tour.
Standard practice we want to grab some information about the binary. We run my favorite pefile scripts accross the binary and everything looks normal except the imports. We notice that the imports section is looking a bit sluggish. We load up the binary in a Utilities called “Execinfo PE” and we don’t get much back. Exeinfo proclaims that the file is an unknown EXE and we should check it out with PEID. We open up the file with “DIE, Detect It Easy” to grab some more info, No hueristics on a packer are found. One last test with RDG Packer Detecter… Nothing. Hmm, So we have normal sections, only one import… Wtf? If we open it up in IDA the Code body is Tiny! This is definitely pointing to a packer! Just for the hell of it, let’s dump strings!
AHA! Something catches our eyes… Two things actually… First off a lot of the “strings” in the binary seem to be encrypted or something. Then towards the bottom of the dump we see “This software protected by 9rays.net Spices.Obfuscator.” Well, That would explain it. Renamed functions, small code body, Wierd jmp’s in the code, encrypted strings. When we start to google we don’t find too much information, and we certainly don’t find anything about deobfuscating the code. So we have some .Net code, that is Obfuscated using 9Rays Spices… Well, we notice that 9Rays utility Spices.Net is available for download. When we grab a copy and load up our binary theres a few things we can do, one being disassemble. Logic would have it, if it obfuscated it perhaps it can do the reverse on it’s own algorithm. It surely can…. If you pay that is! I found the evaluation copy will only give you a 50% decompilation. Which left code like this:
return ?.?.GetString ((byte[] ?.?), 188, ?);
Or:
internal static object ? ()
{
//Warning – Unlicensed copy will only decompile 50%
}
Although I got a few pieces of code out of it, there were many classes so ?.? Didn’t exactly help me out too much! Next on the block was a utility called DIS#. Dis# is similar to Spices.Net in every way, I did however like the flow of dis# a lot better, and it was able to decompile the code a lot better and even provide readable and logical names for variables. The Problem
public static void XsNksq(string[] A_0)
{
//trial
}
Same thing as Spices.Net! DAMN!
Next Utility. Lutz Roeder’s .Net Reflector. This utility is available free for download with just providing your email address, company and name information. I put in some crap info and hoped they didn’t email a trial key or anything. Fortunately they did not. .Net Reflector was able to decompile and DeObfuscate most of the code but had some confusion on a few things. One of the confusions was in the central Logic of the function Main. The class and function calls were somehow confused but it still gave you a fair idea of the program logic.
Link to ScreenShot
While browsing around in the almost completely decompiled code, as we use .Net Reflector to Analyze the code we see something that looks like an encoded array held within the cctor section.
It appears to be a Byte Array, with a bunch of data in it, then at the end it is encoded with Unicode. When we go back to the Main function we Notice a function String that is called a lot. This function turns out to be what .Net Reflector calls “GetString.” Looking up that function on MSDN, we find that GetString is a front for GetChars, which takes a Byte Array, and index, and a count. This is where I started assuming that the password was encoded in the byte array and began a long journey into discovering it wasn’t. When you start looking through, there are multiple declarations in E(): Object which call GetString, all with different indexs and count’s. While attempting to create a decoder using C# we stumbled upon two pieces of code that seemed out of the norm.
The first Uses WebClient, and the second is a function that accepts an object and a string, then calls DownloadData (part of webclient) wtih the argument of the text string passed to it…. Hmm.. MSDN! Webclient Provides common methods for sending data to and receiving data from a resource identified by a URI. DownloadData Downloads with the specified URI as a Byte array. Let’s go back and run a dynamic analysis on this binary real quick…
We execute the binary and it tells us we need to enter a password. That must be the code block in main that goes
if(TextArray1.length == 0)
{
Object.GetString(Object2.Method);
}
Apparently, its grabbing some text within that encoded byte array, decoding it and printing it up. Lets try giving the binary some cruff.
It repeats the password we entered, tell’s us its checking it, then tells us sorry. In main, we see numerous calls back to that byte array. Judging by our last discovery of Webclient.Download Data… Me thinks this is using the network! Firing up wireshark!
SCREENSHOT
Holy Crap, Its grabbing a text file
We try it out: And….
Boom!
Although the code was obfuscated pretty damn well, and the URL was encoded into a byte Array the password was in clear text. One way the author could have obfuscated the password transfer a little more would be to encode it with base64 or some type of encoding. Once wireshark picked it up it was apparent what the password was.
Overall though, it was a pretty good Crackme…would have taken a lot less time had I followed Rule #1… So let that be a lesson. NEVER ASSUME!
