[#2] Introduction To Reverse Engineering With OllyDBG

Introduction To Reverse Engineering With OllyDBG

Greetings everyone!

Welcome to the second part of my malware analysis series, if you’ve made it to this point you deserve a pat on the back! Malware analysis is just like I said before a journey, not an easy one but definitely a fun one!

In this part of the series, we’ll be picking where the first part of our series

[To see links please register here]

was left off. We’ll soon be on our way of exploring how static reverse engineering techniques can be used to understand what a piece of malware does. However, before we do that we need to understand how the reverse engineering tools work and understand the very basics of them in order to be able to perform some basic malware analysis.

What is exactly Reverse Engineering?
If we look up the definition of the term “Reverse engineering” it’ll be defined as:
"To disassemble and examine or analyze in detail (a product or device) to discover the concepts involved in manufacture usually in order to produce something similar".
However, it’s a bit different in our case since we’re not reverse engineering, physical products, but rather software which runs on the Windows platform. Thereby, we can define reverse engineering as the reproduction of another person’s source code following detailed examination of the executable machine code. In layman terms, it can be explained as, figuring out what a program does by examining the instructions the program "gives" to the CPU.

Assembly language is the language of reversing, there’s not a single action the program can make without it being translated in Assembly. In order to become a master in reverse engineering, one has to understand the Assembly language. I won’t be covering that because it’s a giant section and reading a book about it will be far better than anything you can find online. I hope you now understand the importance of knowing Assembly (particularly, the x86 assembly dialect) for the process of reverse engineering. Now that we know what reverse engineering means and that it’s based on the assembly language, it’s time to dive In to the world of reversing.

Prerequisites:

[To see links please register here]

A Windows Machine
The Will To Learn

OllyDBG
For reversers, OllyDbg is the best tool out there because it has been designed from the ground up as a reversing tool, and as such it has a very powerful built-in disassembler. However, it’s greatest strength lies in its disassembler, which provides incredibly powerful code-analysis features. OllyDbg’s code analyzer can identify everything from loops and switch blocks to running a program instruction by instruction, adding breakpoints and changing the assemble which is basically the code. Another wonderful feature is the built-in assembling and patching engine, which makes it every cracking enthusiast’s favorite. Analysing binaries with the tool is incredibly useful when the source code isn’t available in simpler words. Remember that OllyDbg is primarily seen as a debugger even tough it does have an amazingly integrated code disassembler.

Step 1: Starting OllyDbg
To start OllyDbg, locate the shortcut or the directory of the installation and start the software. Upon launching the program you’ll notice that it has the familiar dropdown list menu for navigating around the different functions.



Step 2: Loading a Executable into OllyDbg
In order to load a executable in OllyDbg you need to navigate to File > Open and load your executable from there.
Pro tip: You could also drag a executable directly into OllyDbg.

Once you’ve loaded the executable into OllyDbg, it will begin analysing the code and converting it to readable assembly language. In this case I picked a random executable laying around my SSD. In future tutorials, it’s important to know that I won’t be using OllyDbg because it’s very complex for beginners and requires a good understand of the Assembly language. I’ll most likely make a few reversing tutorials with IDA Pro since it has a better disassembler and is a bit easier to use. OllyDbg is within the malware field mostly for doing exactly what the program was made for, debugging.



If we take a look at the above image I’ve attached, you’ll see that OllyDbg takes the disassembled code and separates it into several windows. In the top left window you’ll be able to see thevirtual addresses of the instructions and in the top right window you’ll see the CPU registers. If we take a look at the bottom section we’ll be able to see what kind of data is residing in the memory and in the lower right window we can see the stack calls. Don’t forget the lower right corner which displays the status.

Step 3: The different code views
We can view our Assembly code in different ways by clicking on the View button of the top menu. You’ll see that each list view option will have a key bind associated with it, with the exception of "patches" which uses the Ctrl key.



If we select the Executable modules from the list of options we’ll see a list of all the file executables associated below. The Executable Modules Window shows the base virtual address to the far left, the virtual size of the binary in memory in the second column, the Entry Point’s virtual address in the third column, the name of the module in the fourth column, file version, and file path for each module loaded in the process. If the text appears in Red, that means the module was loaded dynamically.



From there you can right click in order to open up the context menu and do many different things, click “View names”. You’ll be granted with a list of all the functions used and imported by the program. It’s a great option to use when you’re analysing malware because you’ll be able to decipher the functionality of themalware on a much deeper level. The

[To see links please register here]

outlines what the different functions do which is essential in order to understand how the malware operates.



By right clicking on a function we can set a breakpoint (BP), alternatively pressing the shortcut key F2.



If we head over to View > Memory we’ll be taken to OllyDbg’s Memory Map window which shows the different virtual address, the virtual size, the owner module, section names, memory allocation type and memory protection for each allocated region of memory in the process.



OllyDbg’s Threads window can be found by going to View > Threads. You’ll see the thread ID, Entry Point virtual address, the Thread Environment Block (TEB) virtual address, the last-error value, status such as, active or suspended, the priority, and the timing information for each thread in the process.



The Windows window displays the Handle, Title, Parent Window, Window ID, Window Style, and Window Class Information for each window owned by the process.



The Handles window shows the object type, reference count, access flags, and the object name for each handle owned by the process.



The SEH (Structured Exception Handler) chain window shows the Structured Exception Handler functions for the current thread.



OllyDbg Frequently Used Shortcuts

Hidden Content

You must

[To see links please register here]

or

[To see links please register here]

to view this content.

I remember using this tool a long time ago. Although I never actually figured it out. I just used my basic knowledge on other tools like it. For reverse engineering anything binary file now, I just use ILSpy.

(07-28-2019, 11:25 PM)Drako Wrote:

[To see links please register here]

I remember using this tool a long time ago. Although I never actually figured it out. I just used my basic knowledge on other tools like it. For reverse engineering anything binary file now, I just use ILSpy.

It's very rare that you have to use a native disassembler these days, but it's essential in the malware world. I used to be a very faithful user of ILSpy, but eventually switched to DnSpy. The switch was mainly that DnSpy had an integrated Debugger, basically being able to attach a running process and debug it without having the source code, even though it feels like it. Being able to edit the disassembled C# code directly and later on simply recompile it and save a new version of the software, was just marvelous.

(07-28-2019, 11:34 PM)Tracefl0w Wrote:

[To see links please register here]

(07-28-2019, 11:25 PM)Drako Wrote:

[To see links please register here]

I remember using this tool a long time ago. Although I never actually figured it out. I just used my basic knowledge on other tools like it. For reverse engineering anything binary file now, I just use ILSpy.

It's very rare that you have to use a native disassembler these days, but it's essential in the malware world. I used to be a very faithful user of ILSpy, but eventually switched to DnSpy. The switch was mainly that DnSpy had an integrated Debugger, basically being able to attach a running process and debug it without having the source code, even though it feels like it. Being able to edit the disassembled C# code directly and later on simply recompile it and save a new version of the software, was just marvelous.

Oh I did mean DnSpy. I just remembered that ILSpy was close to DnSpy, and I didn't feel like digging for its name. I also thought that DnSpy was way better than the latter option, ILSpy.

Along with Import Rec, PEiD, W32DASM and a few others, I haven't used OllyDBG In years. I still have almost every plugin.

That aside, an excellent tutorial Indeed.

(07-29-2019, 04:15 AM)mothered Wrote:

[To see links please register here]

Along with Import Rec, PEiD, W32DASM and a few others, I haven't used OllyDBG In years. I still have almost every plugin.

That aside, an excellent tutorial Indeed.

Jesus, that's been a longtime ago. Certainly brings back many memories from 2002.

(07-29-2019, 09:06 AM)Tracefl0w Wrote:

[To see links please register here]

(07-29-2019, 04:15 AM)mothered Wrote:

[To see links please register here]

Along with Import Rec, PEiD, W32DASM and a few others, I haven't used OllyDBG In years. I still have almost every plugin.

That aside, an excellent tutorial Indeed.

Jesus, that's been a longtime ago. Certainly brings back many memories from 2002.

It certainly dates back quite a while. In fact, probably around the same time you've mentioned.

Once my computing tasks are under control, I'm planning to get back Into the scene.