Lab summary questions

1. Considering malware analysis as a whole, how important is it to a general aspiring analyst to complete this chapter’s exercises?

2. What did doing the lab exercises teach that was not gained from reading the chapter?

Challenges encountered in the labs

Lab Walkthrough (includes answers!)

9.1

Analyze the malware found in Lab09-01.exe using OllyDbg and IDA Pro to answer the following questions. Note that this malware was initially analyzed in the Chapter 3 labs using basic static and dynamic techniques. (Uh oh…)

Questions to answer

1. How can you get this malware to install itself?

   One way (of at least two) is to call it as such: ./Lab09-01.exe -in abcd (90% confidence)

2. What are the command-line options for the program? What is the password requirement?

   The last command-line argument of the program is the password. The password must be ‘abcd’.

3. How can you use OllyDbg to permanently patch this malware, so it doesn’t require the special command-line password?

   Simply overwrite the function call to the password checking program with NOPs.

4. What are the host-based indicators of this program?

   • A service called “ Manager Service”.

5. What are the different actions this malware can be instructed to take via the network?

6. Are there any useful network-based signatures for this malware?

Walkthrough process

NOTE: Before running this program or beginning to analyze it with Ida or OllyDbg, I recommend making a couple copies of it for backup purposes.

First, I opened the assets/images/posts in OllyDbg and Ida. I looked through main() on Ida to see what sorts of things we could expect to see, and did a little bit of initial commenting.

I opened up sub_402510 to discover a big mess of movs and some repne scasbs and other things. After putting about 5 minutes of effort into trying to understand how all this worked, I realized it would be a lot brighter to, you know, use the tool I just learned about. I migrated over to Olly with the mindset that I wanted to watch how sub_402510 works, since I believe this function is what determines if the malware will install, or delete itself.

Upon first looking at this new tool’s interface, I noticed OllyDbg broke at _start, while Ida starts up at main(). So, I stepped through code in Olly until I hit where main was called. As I walked through code and matched where Olly was vs. where we were in Ida, I discovered/confirmed:

• ctrl + g is how you do goto address in OllyDbg
• Return back after going somewhere by using -. It doesn’t necessarily go “back” mind you… but that hasn’t gotten in the way enough for me to put time into it, yet.
• Place a breakpoint by hitting F2.
• To change the contents of some registers, you just right click it and choose the appropriate option. EIP doesn’t follow this convention. To change EIP, you must goto the location you want EIP to execute next, right click it, and choose New Origin Here.
• To rename a memory label in Olly (such as for a call instruction), goto that address and then right click the first instruction at that address and type “:” or right-click the address and click label, and type the new name. This will have all references to that address propogate with the new name. In this way, I made the functions I named in Ida have the same names in Olly, which is very helpful when I’m switching between both programs so much.
• Double clicking an address will make all addresses around it appear with numbers relative to the one you clicked. This can be helpful for finding out how far away two instructions or bits of data in memory are.

In the first run of this program where there are no command line arguments, the argument passed to sub_402510 is the program’s path.

Let’s look into the function that processes the last command line argument.

Is this the password checking function?

It contains a repne scasb instruction. This instruction is not something I know off the top of my head, so I checked out a post on the reverse engineering stackexchange that explains how the command breaks down.

• repne: repeat while not equal.
• scas: SCan A String. It compares values in a string (the one pointed to by the ES:[EDI] register) to the value in the accumulator register (EAX) until it finds a match.
  • ES: a segment register. These are used to derive memory addresses. How? I’m not sure, and I am not sure it matters for purposes of this assignment yet. WEEDS
  • EDI: contains a pointer to the string. Why yes, OllyDbg is indeed reporting that the string is in EDI!

Overall, it scans the string until it finds an element in it equal to the element in the accumulator. So, in this case, since EAX is 0, it’s looking for the null terminator.

Hitting F7 (i.e. step into) shows how the string in EDI shrinks one by one from the left side, and each time that happens, ECX is decremented. (ECX was 0xFFFFFFFF at the beginning). (Just to be clear, it’s not that the string is “shrinking”… We are just changing the pointer in EDI to look one character ahead, and that is what gives the illusion that the string is shrinking.)

ECX is manipulated to contain the string length!

Moving on, we see that a comparison of the string length to 4 happens. Since the string length is not 4, it leaves the function. Clearly, it’s looking for something that is a 4 character argument. I reran the program with the argument “asdf” by clicking Olly’s black X in the top left corner, opening a file, and putting “asdf” in the arguments field, and then I stepped through until at the same block of code discussed right above.

CL, the lower byte of ECX, had moved into it the first letter of the argument being processed by this function. That was then moved into var_4. So, what Ida labeled as var_4 is actually the first character of the command line parameter. We can tell by reading the assembly in Ida that a comparison of 61 (hex) happens shortly after, and the code leaves if it detects the comparison is not equal. 61 is an ‘a’ in ascii. How convenient. The first guess takes us to step 2 of the checking process.

Step two (starting at memory location 402563) threw me off for a little, until I just ran it in Olly and observed what happened.

It did a bunch of pointer math, and compared to 1 shortly after. Instead of spending too much time trying to know exactly what the assembly was doing, I just ran the code up to 0x40255A, and discovered that with “asdf”, the value resulting in ECX after the pointer math occurs was 0x12. I also noticed that 0x12 is just about the value that results if you subtract the second character of my current password from the first– s - a = 12. So, this step checks to see if the second character is one more than the first– i.e. ‘b’. So I reran the code with the password ‘abcd’.

Step three employs more strange pointer math. We’ll notice that, however, at 0x402566, 63h (i.e. ‘c’) is moved into dl. After skipping past all but one of the movs, we see an [ecx + 2] is part of the final mov. This is probably somehow referencing the third char of our string (the second, if we refer to the characters in a zero-indexed fashion). Either way, 0x63 is compared to 0x63 with my password of ‘abcd’, and the code moves on to check four.

Step 4 takes the current char ‘c’ and adds 1 to it. That makes a ‘d’! Stepping through yields a comparison of ‘d’ to ‘d’, and we know that the password is now ‘abcd’ as a 1 is put into eax and we return.

We have the password, but how can we patch the program to not require one at all (question 3)?

If the password checking function runs successfully, it puts the value ‘1’ into EAX. Otherwise, it zeroes EAX. The test instruction combined with a jnz instruction effectively tests to see if what’s in EAX is zero. If we just … didn’t call that function, EAX would contain a nonzero value from the mov at address 0x402B2A, and the jnz jump would be taken. All we need to do is nop out the call, and the code will always take the jnz branch to the next phase of the malware.

The book specifically has a section on how to do this (see the patching section in my previous notes post). I right clicked the call instruction of the password checking function in Olly, and selected Binary -> Edit. Now Olly displays the updated code in the disassembler. I then saved this patched version of the program.

HA. Sick. It works.

Getting the malware to install itself

To answer this question, I took a shot in the dark and assumed installing itself involved creating a service. I looked through the strings within Ida and found one, “ Manager Service”. Cross-referencing that leads to one use: within sub_402600. This function also does stuff with the registry. If we cross-reference this, we find that it’s used in two places.

My next observation came from this block of code here.

We see that it’s doing a string comparison after it passes the password check function. OllyDbg tells us that the comparison is done with the “-in” hardcoded string, and we can observe it’s comparing one of the command line arguments. Furthermore, if strcmp finds that two strings are the same, it returns 0. So, the jnz will NOT be taken if the comparison results in finding a “-in” argument.

The red branch checks to see if there are a total of three arguments (say, perhaps, the program name, -in, and the password). If there are, the jnz is again not taken due to the nature of how cmp works. If we follow that red path, we arrive at…

…a block of code that much closer to the install function. At this point, I think it’s safe to say one way to get this malware to install itself is by calling it as such:

./lab09-01.exe -in asdf

Realizations made after reading the book answers:

• here

9.2

Analyze the malware using OllyDbg.

1. What strings do you see statically in the binary?

   Answer here

2. What happens when you run the binary?

3. How can you get this sample to run its malicious payload?

4. What’s happening at 0x401133?

5. What arguments are being passed to subroutine 0x401089?

6. What domain name does this malware use?

7. What encoding routine is being used to obfuscate the domain name?

8. What is the significance of the CreateProcessA call at 0x40106E?

Realizations made after reading the book answers:

• here

9.3

Analyze the malware found in Lab09-03.exe using OllyDbg and Ida. The malware loads three included DLLs that are built to request the same memory load location, which means Ida will show differing memory addresses than Olly when loaded in each. This is done by design to give you experience going from Ida to Olly and back, when the addresses differ.

1. What DLLs are imported by Lab09-03.exe?

2. What is the base address requested by DLL1.dll, DLL2.dll, and DLL3.dll?

3. When you use OllyDbg to debug Lab09-03.exe, what is the assigned base address for all three DLL assets/images/posts?

4. When Lab09-03.exe calls an import function from DLL1.dll, what does this import function do?

5. When the exe calls WriteFile, what is the filename it writes to?

6. When the exe creates a job using NetScheduleJobAdd, where does it get the data for the second parameter?

7. While running or debugging th eprogram, you’ll see it prints out three piees of mystery data, one of each corresponding to each DLL. What are these pieces of mystery data?

8. How can you load DLL2.dll into Ida so that it matches the load address used by OllyDbg?