.h3mf85n:004041FF pop ebx
.h3mf85n:00404200 leave
.h3mf85n:00404201 retnListing 11.7 (continued)This function starts out in what appears to be a familiar sequence, but at
some point something very strange happens. Observe the code at address
004034DD, after the JMP EBX. It appears that IDA has determined that it is
data, and not code. This data goes on and on until address 4041FD(I’ve elim-
inated most of the data from the listing just to preserve space). Why is there
data in the middle of the function? This is a fairly common picture in copy pro-
tection code—routines are stored encrypted in the binaries and are decrypted
in runtime. It is likely that this unrecognized data is just encrypted code that
gets decrypted during runtime.
Let’s perform a quick analysis of the initial, unencrypted code in the begin-
ning of this function. One thing that’s quickly evident is that the “readable”
code area is roughly divided into two large sections, probably by an ifstate-
ment. The conditional jump at 00403405 is where the program decides where
to go, but notice that the CMPinstruction at 00403401 is comparing [ebp-8]
against 0 even though it is set to 1 one line before. You would usually see this
kind of a sequence in a loop, where the variable is modified and then the code
is executed again, in some kind of a loop. According to IDA, there are no such
jumps in this function.
Since you have no reason to believe that the code at 40346Dis ever executed
(because the variable at [ebp-8]is hard-coded to 1), you can just focus on the
first case for now. Briefly, you’re looking at a loop that iterates through a chunk
of data and XORs it with a constant (2BCA6179h). Going back to where the
pointer is first initialized, you get to 004033E3, where [ebp-20h]is initial-
ized to 4034DDthrough the stack. [ebp-20h]is later used as the initial
address from where to start the XORing. If you look at the listing, you can see
that 4034DDis an address in the middle of the function—right where the code
stops and the data starts.
So, it appears that this code implements some kind of a decryption algo-
rithm. The encrypted data is sitting right there in the middle of the function, at
4034DD. At this point, it is usually worthwhile to switch to a live view of the
code in a debugger to see what comes out of that decryption process. For that
you can run the program in OllyDbg and place a breakpoint right at the end of
the decryption process, at 0040346B. When OllyDbg reaches this address, at
first it looks as if the data at 4034DDis still unrecognized data, because Olly
outputs something like this:386 Chapter 11