badfile.exe – Part 3 – Behavioral/Static Analysis

So far, we have discovered that interacting with the web server hosted at will reveal a bunch of random bytes, which actually represent a Windows executable file.  It would be reasonable to assume that the communication with this web server was initiated by a malware downloader (not to be confused with a dropper).

In order to further examine the file, we need to get it back into binary form.  There are several utilities that can help with this, such as hex2bin.

Once we have it in a form that can be executed, we can attempt to execute the file in an isolated VM with host only networking.  We don’t want this malware to interact with the internet or any other local devices.

It should be pretty obvious that this file isn’t really suspicious (surprise!).  The source code for this program can be found here, but try to figure out what the secret (or secrets) on your own first.

There are two unknowns that we will need to work out:

  1. What is the password?
  2. What does the password reveal?

One of the first steps that you might take in the initial analysis would be to run the executable through something that can determine what ASCII/Unicode can be found, using a tool like strings.  PEStudio is a tool that can provide some really helpful information, such as libraries/imports/hashes/etc.

We find that the first part of the secret is “Electric”, which suggests that there might be second as well.  None of the strings seem to indicate what the password is either.

The fact that we can actually see the imported libraries, as well as strings found within the executable indicates that the executable hasn’t been packed.  It should be relatively easy to continue with some static/dynamic analysis.

Onto IDA Pro!

Within IDA Pro, we can determine what the structure of this program might be by pivoting off of the APIs/strings that we know are present.  For example, we know that one of the first strings presented to the user is “What is the password?”.   Finding where this string is stored, and then checking the cross references (xrefs) will point you to the main function, found at 0x4015C3.  Alternatively, we know that within the program, a call to “puts” and “gets” will be made prior to any comparisons.  Both of those function calls will point you to the main function.

Based on the structure of the program above, we can conclude that there are two possible outcome.  One possibility will lead execution to function “loc_401605” (highlighted).  The other to “sub_4014AB”.   This all depends on whether or not the zero flag is set at the end of “sub_4015C3”.

So, if the zero flag is set, we know that the program has identified a bad password, as we print “Incorrect!” via the printf in loc_401605… So what if we just change the zero flag?

Furthermore, its reasonable to assume that a string comparison is being made somewhere within the program, since we are comparing the user’s input with something.  It might be helpful to find which instructions are responsible for calling “strcmp”.

xrefs to strcmp:

We can see that strcmp is being called at 0x004015BC.  If we could pause execution at this point, I wonder what we’d see on the stack…



Stay tuned for some dynamic analysis with Ollydbg in Part 4…

Leave a Reply

Your email address will not be published. Required fields are marked *