Debugging child processes - Olly 2.01h

A lot of malware creates new processes and injects the actual malicious code into the memory of that process and then runs it from there. Meaning..you could start debugging malware.exe...but then find out that it has called CreateProcess() and created a new child process boo.exe. Then it called VirtualAlloc() and allocated memory into some part of boo.exe.

The point being... malware.exe has nothing and you now need to debug boo.exe. There's a few different ways I have tried, all to varying degrees of success.

- Get PID of the Child process from Process Explorer. Then go to Olly and Attach to process.
- Set Olly as JIT debugger. Windows Task Manager. Right click - Debug
- Set Olly as JIT debugger. Set the entry point of the process to CC (a breakpoint) and run the process.
- Try and attach Immunity to the process while debugging the parent in Olly.

But none of that, for multiple reasons worked at all... or worked very sporadically. That sucked.

Luckily OllyDbg 2.01h has this new (well for me ;)) option to debug child processes created by Olly. Meaning, if I'm debugging malware.exe and it creates a new process..and you have this option checked, it'll automatically open a new window and load boo.exe into it :). Perfect.

You can find this option in Olly 2.01 (latest version) in Options - Events. Tick the box that says 'Debug child processes' and save yourself a lot of pain :).

View PE header - Olly 2.01

Many times we want to view the PE header to study certain fields. Its easy enough to do this with a million PE editors out there. You could even do it programatically - I use the pefile module in Python to do it. There's almost certainly others. But the point is... that I love Olly :). How can we do it in Olly?

Well, in Olly 1.10 you could go to the PE header location in the Dump section, right click and select Special - PE header. And this would perfectly parse the PE header and display it in the Dump. Or just go to View - Memory Map, right click and select Dumo.

But Olly 2.01 doesn't have this. The option seems to have changed. I had trouble finding it but finally managed. There is no Special -> PE header menu but a 'Decode as structure' menu.  Here are steps on how to view the PE header in Olly 2.01:

• View - Memory Map. Locate PE header for the exe. Get the address from here.
• Go to the Dump section of Olly. Ctrl+G - enter address.
• So you can right click on the start of the PE header (MZ)  - Decode as structure and in the Drop down box there select IMAGE_DOS_HEADER. Now you see just 1 section decoded.
• Scroll down a bit till you come to the PE header. Right click on the PE header (anywhere...but make sure its inside the PE header, not the DOS header - Decode as structure - IMAGE_FILE_HEADER.

And so on.. use all the different IMAGE_ structures to decode the entire header. Its a bit of a pain really, and I preferred the old way :( or maybe just use another tool - just not Olly 2.01 for this. Its good for other structures though..probably, as you might have guessed.

OllyDbg - Running DLLs

So this isn't something new really. There's plenty of articles that talk about running DLLs. You usually either write a small EXE that uses LoadLibrary to load the DLL or use rundll32.exe with the arguments set to calling DllMain(). That'll work.

But that'll work only if all the functions are eventually called. I mean... if a DLL has 4 functions A, B, C and D. And the program flow is something like:

DLLMain(){
   a()
}

a() {
  b()
  c()
}

c(){
  d()
}

... it'll work and you'll end up being able to reverse the entire DLL.

But if you have a 5th function e() that isn't directly called... and is called only on some specific case... you won't directly ever end up there.

A quick tip on how to analyze this in Olly is to identify the function() to reverse using IDA or any other disassembler and go to that address. Now right click on that address and click "Set new origin here". This will allow you to run that function :)

Of course...this will work out of the box only if the function takes no arguments at all. If it does you will have to set up the registers EAX, EBX, ECX and anything else...with the correct arguments. This you can do..by finding out where it was called from... or by studying how the arguments are processed inside the function by running it and seeing why it crashes.

For example: A function may need 2 arguments and takes these from EBX and ECX. So you might fill in EBX="A" and ECX="d" and try and run the function. But you might find out later that there was code which was dividing EBX and ECX... (EBX/ECX). This means that they both had to be numbers... integers maybe. So you fill up EBX=4 and ECX=2 and see what happens. It might crash again but for some different reason...and you then go back .. and so on :)

Nothing new but a quick little thing that I learnt last week or so...while working on that Fireeye challenge.

Reverse Engineering DLLs

A DLL is usually imported by an EXE. A DLL usually has a number of functions that the EXE can usually directly use. If you want to debug an EXE in OllyDbg, all you need to do is load it in Olly and set a breakpoint on the entry point of the Exe. If you want to debug a specific DLL though, it's not that straightforward.

There's 2 ways of doing this:

a) Open the DLL in Olly. If you also have an EXE called LoadDLL.exe in the Olly directory on your hard disk, LoadDLL.exe will automatically pick up the DLL you want to analyze, load it and stop at the entry point for the DLL. This though seems to work only for Olly 1.10.

b) The other way of doing this is to tell Olly to break each time a new DLL is loaded. You can do this by going to Olly's (2.01) Options - Debugging - Events and tick the box which says 'Pause on New DLL' and OK your way out.

The next time you load an Exe which in turn loads up DLLs at runtime, Olly will break each time a new DLL is loaded. So you can keep hitting F9 (Run program) until you reach the DLL you want to debug.

Now you can debug the DLL as you would debug an EXE :)

Olly - Hit trace..finding code flow

Many a time we come across malware which is extremely confusing and has lots of JMP and CALL statements. It becomes very difficult to find out what exactly the malware is doing; if you use a purely manual technique..and you start seeing stars after a while. At least I did :)

So to help you understand the control flow better you can use something called a Hit Trace in Olly. Here is how you can best use a Hit Trace:-

a) Load the executable into Olly. You'll have to use 2.01; I couldn't find this in Olly 1.10.

b) Till what point in the code, do you want to understand code flow? Identify that point and set a breakpoint there using F2.

c) Once you've set the breakpoint, navigate to Trace - Run hit trace. This will automatically run the malware until the breakpoint that you had set earlier.

d) If there's some anti debug measures or the process simply exits before your breakpoint...you won't be able to see the Hit Trace at all. However, if the program is still active, you should see a little red dot to the left of each assembly instruction. This just says....'This instruction has been run at least once'.

You will notice a lot of gaps in between the 'red dot' lines. That is because those instructions were never triggered at all. You'll see this specially in cases of JMP instructions.

There's another feature called 'Run Trace' in Olly and the way to use that to identify code flow is to Log to File and then study the log.

Or lastly (as far as I know) you can set breakpoints and then use the 'Trace Over/Into and Animate over/Into) to step into and over code interactively using the '+' and '-' keys to go forward or back.

But the Hit Trace is quite neat and it offers a very nice option to identify control flow. Until next time ...bye :)

EXE dependencies - Read from PEB

I was trying to understand where executables load all their dependencies from. So for example: When I load up minesweeper (winmine.exe) there are a host of additional DLLs that are loaded up as well. That's fine as there are functions inside each of those DLLs that winmine uses. What was interesting to find out though, was how the list of those DLLs was built in the first place. Where did the OS loader look...into the process..to find out 'what else to load'?

So I loaded up winmine.exe in Olly, Dep Walker and a few other tools to get an understanding of 'what all' was loaded. Once that was done I read up a little about the PE header to understand where dependencies are accessed from. In PE terminology, these are called imports. It turned out there was a Data Directory for the Import Table. So i thought; lets read the import table; that should give me a list.

So I wrote a little bit of Python code [after learning Python from Google's Python class ;)] to read the IMPORT TABLE from the PE header. This did give me quite a few DLLs but it still did not tally with what Olly was displaying.

The next thing I did was to modify my code to be recursive. So...

--- Load EXE. Get dependent DLLs from import table.
--- Load 1st DLL from previous list. Get its dependent DLLs. Add to list.
--- Load 2nd DLL from previous list. Get its dependent DLLs. Add to list.

And so on... until all dependencies were resolved.This was doubtlessly an improvement as I was closer to what was displayed in Olly [Alt+E]. It still wasn't complete though.

Then I read some more, read how Dependency Walker works, asked on Woodmann and re-read a few sections from Xeno Kovah's Life Of Binaries class. Turns out there are somethings called Delayed Imports. These aren't loaded statically at load time; like the Import table but only when a particular function needs to be called..later on...at runtime.

So I modified the code a little to recursively get all the DELAYED IMPORTS too. This would have been enough but it gave me a huge huge list which contained much much more than what Olly ever showed me :). So obviously this wasn't efficient either and it was something else.

So as usual when I'm stuck I bug the nice guys on Woodmann and I'm rarely disappointed. This time was no exception and I was pointed in the direction of something called a PEB.

The PEB or the Process Environment Block is apparently the only "part" (very loosely used) of a process that is in User Mode. Everything else is in Kernel mode. So if you want to find out every DLL that an EXE depends upon; its best to query the PEB instead of doing all that stuff I did earlier :)

I want to quickly touch upon the structure of the PEB before I finish this post. To look at the entire structure of the PEB you can visit this link. You need to query the PEB_LDR_DATA structure to get the list of Loaded DLLs. Here is an article that I found quite useful while I was learning stuff about all this.

And lastly..here is the complete thread of my discussion on Woodmann, if at all you are interested :).

Reverse Engineering - Know your tools...

I've talked quite a bit about what tools to use and when in general. While all that is correct in principle, I recently, after a lot of painful 'research' [mostly already out there somewhere] , came up with a process for myself to use the right tools at the right time. Here is a short summary of the same:

1) Do your dynamic analysis and document what you found.

2) To learn more you have to now do static analysis; don't start off with IDA Pro; it overwhelms you very quickly... specially if you are new.

3) Put the EXE through Olly or Immunity and start identifying what each function does, step by step. I'm just saying... don't be worried initially about understanding everything about the malware. If you can even confirm what you found in dynamic analysis, via static analysis and say that...I know what these 5 functions do...that's good enough for a start.

4) Now once you know what these 5 functions do, open the EXE up in IDA Pro and rename the 'known' functions from sub_4012345 to something meaningful, like sub_malware_connect_irc. Repeat for each function you know. Go back to Olly now.

5) Now take each function(known); say sub_malware_connect_irc and identify all of its system function calls.. connect() send() getcommandline() etc etc.

6) Look at MSDN and understand the arguments that are passed to each. See where these arguments are stored in the disassembly you have. Is it stored on the stack or in a variable?

7) If its in a variable go to IDA and give that variable a meaningful name. So for e.g rename something like dword_ptr_401324 to malware_irc_host-name. This will result in every single place where that variable is accessed, getting renamed to the new variable. So dword_ptr_401234 will no longer exist; it will be referred to as malware_irc_host-name. Repeat this process for all known functions and all known variables.

8) Once you have a few functions and all corresponding variables renamed, use the GroupNodes feature in IDA (Right click on any block, select GroupNodes) to collapse blocks you have already analysed. Give each block a name that you will recognize instantly, without having to look at the disassembly again. Repeat this for all blocks that you have analyzed. So this will reduce the disassembly that you have to look at, in other parts of the program you have not yet analyzed.

9) So now, to summarize, for all known functions you have renamed the functions, renamed the variables, and grouped blocks of code that you have already analyzed and named the block. This should give you a nice 'pseudo codish' flowchart in IDA for quite a few functions :)

10)  Now use the 'Functions' submenu in IDA and sort by the first column to see how many functions are pending; you can get this by seeing how many start with sub_.

11) Go to each function and see where it is called from. You can do this first in Olly 1.10 by highlighting the first line (usually PUSH EBP) of the function and looking in the middle pane on where all it is called from. Visit each of the calls in the middle pane and see where they were called .. and so on. Do this till you get to the root of the call.. see if you can now understand 'when' it was triggered.. 'What' behavior triggered it? Do the renaming and grouping as before. If you can't understand.. at least give the function a name.. some name.. like dummy_notunderstood_1, dummy_notunderstood_2 and so on. That still is better than sub 401237.

12) At the end of all of this you should have a .IDB file fully named (as much as possible) and fully grouped. Now ..only now should you start drilling down into HOW exactly each function works...the exact algorithm behind each function and so on. Repeat this for as many interesting functions that you want.

13) Once this also is done, if you WANT , try rewriting this in a high level language, at least pseudo code so you can quickly refer back to it when you want.

I guess, this is all very intuitive for most reversers who have learnt this on their own or been reversing for a long time. It took me a long time though, to reach this level and hope it is helpful to any relative newbie reading this blog post and feeling lost. I know I was one a few months ago ;).

p.s.... Make sure you back the .IDB file up ;)

Here are 2 sample screen-shots:

Sample Graph of Grouped Functions

 

 

Renamed functions - A sample list

Debugging threads - Olly

Recently I was debugging a piece of malware which launched numerous threads inside, after it ran. Now, after the thread spawned, I could no longer F7 or F8 my way through the malware and understand things. This was because it was the thread which was doing all the work. So somehow I needed to get into the thread.

The first thing I did was 'Right click' and then select a thread from the Threads sub menu. That though just seemed to take me to system space, which was kind of useless. I wanted to see what the Thread did in User Space.

I looked at the CreateThread API then, which was what was being used. The 3rd argument to the function was a start address for the thread. I did a Ctrl+G, went to that address in Olly and put a breakpoint there, and then restarted the program. Went on as normal till CreateThread and then F9'd to run till next breakpoint. The main thread still "hung" but I did break inside UserMode for the Thread and could debug it.. yay :)

If you want to break even before UserMode and want to track it the moment the thread is launched, you can set debugging options in Olly to break each time a new thread is started or stopped. There's simple check boxes under the Options menu. Go search :)

The last bit is when  the Thread itself exits..it just says Thread Terminated and you again cannot F7 or F8 because there is nothing left to F7 or F8 into. You need to get back to the main thread, where the CreateThread API was called. Makes sense ..rt? Main.. created a thread...I debugged thread...now I come back to main...once I finish debugging the thread.

To do so, pause the program(F12) after the thread terminates and hit Alt+F9 to return to user mode. This will bring you right to the spot after CreateThread was first called.


Hope this helps someone newish to reversing :). Have fun!!

10 - OllyDbg hints

Before moving forward into actually reversing something, its a good idea to quickly step through some basic debugging terminology, which you will hear all the time. We'll use OllyDBG as a reference; download both OllyDBG 1.10 and OllyDBG 2.0. There are some features that are available only in the older version. I'll mention the older version whenever needed; otherwise just assume I'm talking about the newer Olly.

1. You can either 'Open' a new executable or 'Attach' to a running executable.

2. Midway through a debugging session, you will want to return to the start many times to understand things better. Use Ctrl+F2 to restart the session.

3. After opening an executable in Olly you will want to run it. Use F9 to run it

4. To analyze the executable you will almost certainly want to break execution midway so you can study it part by part. Move cursor to highlight that line and hit F2 to set a breakpoint. Once you set a breakpoint and then hit F9, your program will run till the breakpoint and wait for user input. If you hit F9 again it will start running again.

5.Programs have functions that are called from within the main program. These functions might be user defined functions or actual system calls. At any time you might want to see how the program is behaving, at ay point in any function. If you want to explore the behavior of a specific function, you must "Step Into" the function using the F7 key. If you know what the function is doing and are interested only in what happens AFTER the function is called, you must use the F8 key to "Step Over" the function.

6. Once you've got to a certain point in the program and want to see where you came from; you can use the '-' key to move the cursor backward and the '+' key to move it forward. This won't actually "re-run" the program; it'll help you understand where you jumped from or the exact path through the code that your program has chosen.

7. If the program that you are debugging is a command line program and needs arguments to even start; you can use the File - Set new arguments menu option to supply those

8. If you want to search for Strings you can right click in the main window and go to "Search for" - All referenced strings

9. To go to a particular memory address you can right click and select Go to -> Expression and type the exact memory address you want to visit

10. You can right click on most values and choose to "Follow in Dump" (bottom left) to understand their content

11. You can hit Ctrl+N to find out all the functions useed by the program and Ctrl+M to find specific sections in memory

12. You can Pause a program by hitting F12

There are plenty of other options as well and they're all explorable yourself or by reading documentation for Olly which is available online. However if you are fully clear about at least all of these options, you should be good to go. We'll explore a few other options as we go along reversing various types of executables along the way.

Next time we will look at a malicious executable and dynamically as well as statically analyze the same. Until then..have fun :)