My continuing saga tackling the ESET 2013 challenge

In part one and part two, we unpacked and coaxed the ESET CrackMe 1 puzzle into revealing its hidden messages, which led us to a second puzzle called crack_me_2.zip.

crack_me_2.zip is an actual executable because you can see the ‘MZ’ header in a hex editor.  If we examine the sample using the strings command:

We can see it is packed.  Claims to be UPX but is it?  According to PEiD, it claims “Nothing Found” but there is some overlay.

Using PEiD’s extra information plug-in, we can examine the EP and the Entropy of the code section.  Entropy is pretty high, indicating that this sample is packed with something.  It turns out, that you can use the same unpacking technique that we did in part one.  However, I needed to use LordPE to rebuild the unpacked and repaired crack_me_2 sample to get it to run.  When the unpacking process was done and we run our unpacked sample we get:

Note that the text boxes for Stage 1 and Stage 2 are greyed out.  I can not enter any text in them, nor can I click on any of the “check” buttons.  The only thing I can click on is the red X button in the upper right hand corner of the CrackMe dialog box.

This perplexed me for a while.  I wasn’t sure if I unpacked this sample correctly so I executed the packed crack_me_2.zip and got the same dialog box as above with the inactive text boxes and check buttons.  Perhaps examining the code in OllyDbg will yeild insights into how I might activate the text boxes:

I couldn’t find any sign of how to activate the text boxes but I did find clues as to what to put in the text boxes.  In the above screen shot, you will observe that we should enter the text: “Pigs are filthy animals”.  When we hit the check button, it compares our entry with String2 and if they match, it activates the next text box.

As you can see above, the second text box clue is obsured.  That ASCII string “SSBkaWQgaXQh” looks like a base64 encoding.  We can test this by entering that string in a tool called base64 encoder/decoder (my version is older so it looks different than the one at the link):

Lucky guess.  I wasn’t sure it was base64 because this encoding did not have the tell tale ‘==’ at the end of the string.  We know what to enter in the text boxes but I still haven’t found any clues as to how to enable these text boxes.

I was still stumped after a few hours.  I decided to try the crack_me_2 sample on my old Windows XP laptop and you know something?  It worked!  The first text box was enabled and I could enter text.  Next I tried the sample on a Windows 7 machine and that, too worked.   Stage 1’s text box was enabled.  I suddenly realized that the difference between those machines and my analysis machine, was that my analysis platform was running inside VMWare.  This sample wouldn’t be VM aware would it and try some anti-VM tricks?  So I found this white paper from SANS on Thwarting VM analysis.  Then I set to searching for OP Codes in Olly that looked for a VM presence.

For example, I thought I would start with a simple anti-VM trick outlined in that SANS paper:

MOV EAX,564D5868 <--"VMXh"
MOV EBX,0
MOV ECX,0A
MOV EDX,5658 <-- "VX"
IN EAX,DX <-- Check for VMWare
CMP EBX,564D5868

I used Olly’s search trying the first MOV instruction.  No hits.  Then I tried the second instruction.  No hits.  It wasn’t until the last instruction, the CMP instruction that I got a hit:

By the way, the hexidecimal 0x564D5868 in ASCII is: “VMXh”.  You can see the CMP instruction but not the others.  But you do notice the CHARs VX and VMXh just above the CMP instruction.  It appears that this sample has some anti-disassemble techniques that fool Olly’s ability, in selected parts of the code, to distinguish between data bytes and actual OP codes.  To be sure and avoid the anti-debugging tricks, I activated the Advanced Olly plug in to hide itself from these anti-debugging techniques.

We can highlight these so called data bytes and then right-click, select Analyze, and then Remove Analysis from Selection:

By removing Olly’s analysis, the code is revealed and it looks just like one of the tricks mentioned in the SANS white paper.  If we highlight the top instruction and hit F4 (Run to here), then single step past the MOV EAX, 564D5868, we can simply change EAX to something else — like 0.  When we do that:

It works!  Well almost.  After entering the correct text we get a “Nope you didn’t” notice.  If you click the OK button, the program just sits there until you hit the red X button and terminate the program.  Argh!  All that work… well, that is the life of a malware analyst.  We will often go after something interesting only to discover that it may lead us astray.  We are going to have to search the code and look for something else of interest.

When you first load crack_me_2 into Olly, it stops at this starting point:

This program calls CreateFileW and looks for a named pipe called Vincent_Vega.  Since there is no pipe server by that name running, CreateFileW will return a -1.  So I set a break point on CreateFileW and hit F9 to run the program.  When the execution stopped at CreateFileW, I noticed in the stack trace something about a 990.tmp file.

Looks like this thing will create a .tmp file in my Local Settings\Temp directory.  By the way, each run of crack_me_2 will create a different named .tmp file.  Usually, the names are simple like 2C.tmp, 4C.tmp, etc.  Upon this running, it is calling mine 990.tmp:

This program is going to create a 990.tmp file.  Earlier in the code, I noticed some function calls for getting resources.  If we examine crack_me_2 in PExplorer:

We can see that crack_me_2 has two bitmap resources.  What do you bet that these resources are something MORE than bitmap files?

At 0x404983, we see this function is going to take the resource bitmap ID 0x83 = 131 in decimal, and decrypt it with the key: “T2ggbWFuLEkgc2hvdCBNYXJ2aW4gaW4gdGhlIGZhY2U=”
That looks like base64 encoding:

And yes it is!  By the way, I am starting to detect a theme here.  The named pipe is “Vincent Vega” a character played by John Travolta in the film “Pulp Fiction“.  The phrase we put in the Stage 1 text box: “Pigs are filthy animals” is a quote from one of the scenes when Vince asked Jules (played by Samuel L Jackson) if he wanted some bacon.  The key to decrypt our 990.tmp file is another quote from the movie.

If we continue to let this run and let it drop the 990.tmp file, then open it in a hex editor we see that it is supposedly an executable (has an MZ header).  Next, I renamed 990.tmp to 990.exe and double click on it, I discovered that it is a .NET executable because I was told to install .NET Framework 4 in order to run it.  Once that was done:

How cute.  Ok, maybe it was a bitmap resource.  However, the picture of a bunny rabbit and a little Easter egg icon in the upper left corner suggests its time to go on an Easter egg hunt.  This .NET file may do more than just display a cute picture.  There is just one small challenge ahead for me: I am pretty weak with reversing .NET executable files in that I have, until today, zero experience.  I am going to have to do some research.

But first, I tried disassembling the Easter egg in IDA Pro and it can handle .NET files, however, it looked gibberish.  No strings to examine and weird function names.  Soon, I discovered that there are open source .NET decompilers like ILSpy.

I am not sure how to make heads or tails of the above.  Class names of a, A, b, B, c, etc.  Variable names were not much help either.  However, just by happen chance, I decompiled the class a() and the result is in the left panel above.  This looks like something that sets up a pipe server named Vincent Vega.  My guess is that if we run this .NET Easter egg, it creates the named pipe that our crack_me_2 file was looking for.  The next step, then, is to run this Easter egg and re-run crack_me_2 to see what messages may be passed through this pipe.  I will also need to analyze this Easter egg .NET file further for clues as to where to take my analysis.  I am unsure yet so I have some studying to do.  The challenge continues…