Debugging Win32.Upatre - why does Ollydbg fail to analyze this?

Question

So I've been looking at this thread - Where can I, as an individual, get malware samples to analyze? And grabbed myself a binary sample of Win32.Upatre from Halvar Flake's blog.

I started analyzing the file in my VM (Win XP SP 3) and loaded up the malware in Olly. What I noticed is that the code looks encrypted - I searched for all the calls in the code and got this:

Which doesn't seem quite normal.

So I went ahead and started stepping from the EP hopefully landing on some decryption procedure -

I'll briefly explain what I concluded from debugging this code:

1 - Gets the arguments passed to this executable - I'm pretty sure any code before this is irrelevant, but I might be wrong.

2 - Calls GetStartupInfo - not quite sure why

3 - Call 00401C80 passing the EP as a parameter

So I went ahead jumping to 00401C80 to check what this is all about and found this code which kinda looks like junk code to me -

I suspect because there are some instructions that just don't seem logic to me like:

MOV EAX, 64
CMP EAX,3E8

But I might be wrong.

The problem is that after at the end of the function a value is copied into ECX and then CALL ECX is called which eventually ends in memory access violation:

No matter what I do or how I play with the flags inside this function I get an access violation or the code exits.

SOOOOOOOOO, my first thought was that I'm dealing with some kinda anti-debugging technique, so I tried to run the malware inside the VM and intercept some data from it -

And it seems like it's running alright and even created a UDP socket, no access violation or something like that.

I tried looking online for reports about this virus but I couldn't found any resources about how to bypass this obstacle.

Anyone got an idea how I should approach this? why is Olly failing? How does this code knows that it's being debugged? It doesn't seem like it uses some kind of API for that (like IsDebuggerPresent).

Thanks for everyone in advance.

Answer 1

About the "??3@YAXPAX" calls, it is called Name Mangling, take a look at this thread for more explanation.

"YAXPAX" calls are actually the delete C++ operator.

About the __set_app_type, __getmainargs, GetStartupInfo etc, those calls are generated by the compiler and usally called before the main function. They aren't part of the source code of the program you are willing to analyze, so you shouldn't have to analyze them.

Your main seems to be located at 00401C80, as it is usually right before a call to exit. This is where you start analyzing things seriously.

Concerning the anti-debug protection, there are few instructions that let me think there is something that catches the exception in the program :

cmp [0], 0 is supposed to crash, so maybe there is some custom exception handlers installed somewhere. I would say to check for TLS callback functions, but I may be wrong. You should be able to pass the exception by pressing Shift+F7, break on NtContinue, read the CONTEXT structure and continue the execution of the program.

Here is a listing of the most frequent anti debug tricks you may find - including the Thread Local Storage trick.

Answer 2

import base64
import zipfile
import os
import hashlib
infile = open("c:\\halvar\\halvfem.bin","rb")
outfile = open("c:\\halvar\\halvfem.zip","wb")
base64.decode(infile,outfile)
infile.close()
outfile.close()
if (zipfile.is_zipfile("c:\\halvar\\halvfem.zip")):
    myzip = zipfile.ZipFile("c:\\halvar\\halvfem.zip",'r')
    myzip.extractall('c:\\halvar\\',myzip.namelist(),'infected')
    os.rename(myzip.namelist()[0],"halvar_challenge.exe")
    print hashlib.md5(open('c:\\halvar\\halvar_challenge.exe','rb').read()).hexdigest()

is this the file you are talking about

C:\halvar>python decode.py
172aed81c4fde1cf23f1615acedfad65

C:\halvar>f:\odbg110\OLLYDBG.EXE halvar_challenge.exe

the exe is setting up a Structured Exception Handler prior to call ecx you should follow the Exception handler may be several times

hint check this function in msvcrt

77C2275C MSVCRT._JumpToContinuation    $  8BFF          MOV     EDI, EDI

if you followed them you should be able to see 0x89 imports being resolved with LoadLibrary and GetProcAddress

i followed till CreateEvent before posting this

0013FD90   0040F520  /CALL to CreateEventA from halvar_c.0040F51D
0013FD94   00000000  |pSecurity = NULL
0013FD98   00000001  |ManualReset = TRUE
0013FD9C   00000000  |InitiallySignaled = FALSE
0013FDA0   0013FDCC  \EventName = "{AB8D393B-9177-440d-B3F8-1C1FE0CF9692}"