Automation of Reversing Through Scripting

Today's Deals

Automation of Reversing Through Scripting | www.SecurityXploded.com

Automation of Reversing Through Scripting

Author: Amit Malik

Contents

Introduction
Ollydbg - Playing with OllyScript
Immunity Debugger
PyDbg
Windbg
Conclusion
References

Introduction

This article teaches you how to become smart reverser by automating your reverse engineering tasks through Scripting.

It is the part of our free "Reverse Engineering & Malware Analysis Course" [Reference 1]. It is primarily written to act as additional learning material for our session on 'Part 5 - Reverse Engineering Tools' where in we are going to demonstrate important reversing tools.

You can visit our training page here [Reference 1] and all the presentations of previous sessions here [Reference 2]

Reverse engineering is a sophisticated task especially when we analyse large applications or packed files like malware or normal applications for vulnerabilities.

Some of the common tasks include

Tracking memory allocation
Tracking specific API calls
Unpacking a family of malwares
Intelligent decision making based on some specific events

These are just some simple examples where automation will help in a great way. For example, lets say that we want to monitor HeapAlloc calls in an application and application may call HeapAlloc for hundreds of times but we want to log the call for some specific values like if allocation request is greater than 1024 bytes etc.

A simple script will give us all the information virtually on the spot while in manual task we have to manually create breakpoints on HeapAlloc and have to check if the allocation size is greater than 1024 bytes or not which eventually increase the analysis time for such a simple task.

In this article, I will show you how to automate some of these common tasks through Scripting for main reversing debuggers i.e Ollydbg, Immunity Debugger, Pydbg & Windbg with practical code samples.

Ollydbg - Playing with OllyScript

Ollydbg [Reference 3] is one of the best ring 3 (user-land) debugger. It has a very nice gui interface. It is one of the most popular debugger on the planet and has very mature community support. Ollydbg is my all time favourite debugger :)

But ollydbg doesn't support scripting natively instead ollydbg support plugins. So people written scripting plugins for ollydbg, the one that i will use in this article is Ollyscript by ShaG.

You can download Ollyscript from here [Reference 4].

Ollyscript comes with a nice help file. It has similar syntax like assembly programming and very easy to understand. It supports almost all functionalities like dumping memory, decision making etc.

But when you compare it with other debuggers scripting environment then it will seems to be a rigid type of scripting environment, I will discuss more about it later in this article.

So let's understand Ollydbg scripting environment i.e Ollyscript with the help of a simple example.

Problem Statement:

Let say we are analysing an application for a simple bug and we want to identify the function that is actually causing the problem. But the function is deep inside the application and manually it will take hours of analysis time.

So here we want to track the execution flow after a specific point up to the function that is causing the problem, more precisely I want to log the return address of each function.

Solution:

The above problem can be solved by multiple methods but to demonstrate it in a very simple way I will use the following steps,

From current EIP, search for calls and create breakpoint on that call
Step into the call
Log the value at ESP (i.e return address) and search for calls at return address and
Breakpoint on the call
Repeat step 1, 2, 3 inside the call
Run

Below is the tiny script to accomplish this task. Please note that the script is just to demonstrate the concept, it may fail when call used after decision instructions. :)

/*
Author: Amit Malik
http://www.securityxploded.com
*/

EOB breakprocess
var return
var infunction
var x
var y
mov infunction,EIP
mov return,EIP

start:
findop return,#E8#
mov x,$RESULT
findop infunction,#E8#
mov y,$RESULT
cmp x,0
ja breaksetx
backx:
cmp y,0
ja breaksety
backy:
run

breakprocess:
sti
mov return,[esp]
msg return
sti
mov infunction,EIP
jmp start

breaksetx:
bp x
jmp backx

breaksety:
bp y
jmp backy

Please refer to the Ollyscript help file [Reference 4] for more details. Here I will explain only important keywords and terms.

The script start with EOB (Execute over breakpoint), as name states it will execute the code inside the label that is specified with EOB when a breakpoint hit. In this code it will execute the breakprocess label code.

var - declares a variable.
mov - is similar to assembly
findop - search for opcode from the specified address & stores the results into a $RESULT variable
run - is similar to F9 in ollydbg
sti - step into - similar to F7 in ollydbg
msg - will show a messagebox - (log should be used but I used msg just for visual pleasure :))

As you can see that scripting is similar to assembly language. Most of the time people use ollyscripting for unpacking malwares. I have never seen anyone using it for vulnerability analysis. It is not very much flexible and also limited in its functionality. But it can be used for some stuff that we want to automate through ollydbg.

Immunity Debugger

Immunity debugger [Reference 3] is a pure python debugger with similar GUI interface as Ollydbg. It is developed by Immunity Inc. and according to immunity it is the only debugger designed specifically for vulnerability research.

It has some very powerful pycommands like heap, lookasidelist etc. one of the major advantage of this debugger is that it provides plethora of APIs for various reversing tasks and supports python which makes it one of the best debugger for reversing.

In the reference section [Reference 6] you can find some good tutorials and projects based on Immunity debuggers and also it comes with a nice help file so don't forget to check that as well.

Problem statement:

We want to search all "jmp esp" instruction addresses.

Solution Script:

You can use the below script directly on Immunity debugger python shell

data = "jmp esp"
asm = imm.assemble(data)   # imm is object of immlib class
results = imm.search(asm)

for addr in results:
	print "%s  %0.8x" % (data,addr)

The above 5 lines of code will give you all the "jmp esp" addresses. This is the beauty of scripting :)

Pydbg

Pydbg [Reference 3] is also a pure python based debugger. Pydbg is my favourite debugger, I use it in various automation tasks and it is extremely flexible and powerful.

Problem Statement:

We want to track VirtualAlloc API whenever VirtualAlloc is called, our script should display its arguments and the returned pointer.

VirtualAlloc:

LPVOID WINAPI VirtualAlloc(
__in_opt LPVOID lpAddress,
__in SIZE_T dwSize,
__in DWORD flAllocationType,
__in DWORD flProtect
);

Solution:

Put breakpoint on VirtualAlloc
Extract parameters from stack
Extract return address from stack and put breakpoint on that
Get the value from EAX register.

# Author: Amit Malik
# http://www.securityxploded.com


import sys
import pefile
import struct
from pydbg import *
from pydbg.defines import *


def ret_addr_handler(dbg):
	
	lpAddress = dbg.context.Eax                      # Get value returned by VirtualAlloc
	print " Returned Pointer: ",hex(int(lpAddress))
	
	return DBG_CONTINUE

def virtual_handler(dbg):
	
	print "****************"
	pdwSize = dbg.context.Esp + 8                   # 2nd argument to VirtualAlloc
	rdwSize = dbg.read_process_memory(pdwSize,4)
	dwSize  = struct.unpack("L",rdwSize)[0]
	dwSize  = int(dwSize)
	print "Allocation Size: ",hex(dwSize)
	
	pflAllocationType = dbg.context.Esp + 12          # 3rd argument to VirtualAlloc	
	rflAllocationType = dbg.read_process_memory(pflAllocationType,4)
	flAllocationType  = struct.unpack("L",rflAllocationType)[0]	
	flAllocationType  = int(flAllocationType)
	print "Allocation Type: ",hex(flAllocationType)
	
	pflProtect = dbg.context.Esp + 16                  # 4th Argument to VirtualAlloc	
	rflProtect = dbg.read_process_memory(pflProtect,4)
	flProtect  = struct.unpack("L",rflProtect)[0]	
	flProtect  = int(flProtect)
	print "Protection Type: ",hex(flProtect)

	pret_addr = dbg.context.Esp                        # Get return Address
	rret_addr = dbg.read_process_memory(pret_addr,4)
	ret_addr  = struct.unpack("L",rret_addr)[0]
	ret_addr  = int(ret_addr)
	dbg.bp_set(ret_addr,description="ret_addr breakpoint",restore = True,handler = ret_addr_handler)
	
	return DBG_CONTINUE

def entry_handler(dbg):
	
	virtual_addr = dbg.func_resolve("kernel32.dll","VirtualAlloc")   # Get VirtualAlloc address
	if virtual_addr:	
		dbg.bp_set(virtual_addr,description="Virtualalloc breakpoint",restore = True,handler = virtual_handler)
		
	return DBG_CONTINUE

def main():
	
	file = sys.argv[1]
	pe = pefile.PE(file)
	# get entry point 
	entry_addr = pe.OPTIONAL_HEADER.AddressOfEntryPoint + pe.OPTIONAL_HEADER.ImageBase 
	dbg = pydbg()          # get pydbg object
	dbg.load(file)
	dbg.bp_set(entry_addr,description="Entry point breakpoint",restore = True,handler = entry_handler)
	dbg.run()

if __name__ == '__main__':
	main()

Notice that in this script first i am setting breakpoint on entry point and then on VirtualAlloc not directly to VirtualAlloc because pydbg does not support deferred breakpoints. I am also ignoring 1st argument to VirtualAlloc i.e lpAddress, see VirtualAlloc specification in problem statement.

This script uses two modules PEFile and Pydbg, PEFile is used to get the entry point.

Windbg

Windbg [Reference 3] is the official Microsoft debugger. It is the most powerful debugger available for reversing on windows platform (mainly Kernel side of it) and it also supports symbols.

Windbg provides its own scripting language which is similar to C language, it also comes with a great help file. I highly recommend reading help file before we start with Windbg.

Problem Statement:

We want to track malloc, whenever malloc is called, our script should display requested size for allocation and returned pointer.

Solution:

On the same lines as previous example.

Breakpoint on malloc
Extract parameter from stack
Extract return address from stack and put breakpoint on it
Get value from EAX register

bp msvcrt!malloc ".printf \"Size: %x\n\",poi(esp+4);gu;.printf \"Returned Pointer: %x\n\",eax;g"

When we use multiple commands in a single line then we have to separate them using semicolon (;)

bp - sets breakpoint
msvcrt!malloc - this is DLL!Method (here DLL name & function name are separated by ! )

These are known as conditional breakpoints and in conditional breakpoints we want to perform something when breakpoint hit. In our case we want extract the size of allocation from stack.
So simple syntax is:

bp address or dll!method or dll!method+offset "block that should be executed when breakpoint hits"

poi - is similar to pointer in c
gu - go up - execute until return
g - go or execute

For more interesting commands please check out the Windbg help file.

Conclusion

This article is an additional learning material to our next session on 'Part 5 - Reverse Engineering Tools' - part of our FREE Reversing/Malware Analysis course [Reference 1]

References