Okay before we actually begin dissecting malware and tracing where it originated from we need to cover some of these subjects first or you won’t know what the hell you are doing. The last thing I want to do is make a series of tutorials where you don’t learn anything except me showing you exactly what to do because in cracking everything that you did before to crack something you got get creative on the next crack because not ever crack is the same. If you feel like this is too much work then feel free to leave now. – ro0ted
If you haven’t created your white hat lab yet, you missed the first step go here:
Subjects we are going to cover:
(Not in order)
ASM Programming +
Ollydbg Introduction +
Ollydbg different cracking methods — Next Tutorial
IDA Pro Introduction — Next Tutorial
ASM Programming – Best place to start.
Question: Why do I need to learn this?
Because when you are running your virtual machine most likely you will be using Ollydbg quite a lot for debugging malware and you will be using IDA Pro along with many other dissemblers which use ASM Programming.
Now if you are thinking I tried programming once, I sucked at it, ASM Programming isn’t really a language like that. Basically ASM Programming is a language to interpret as humanly as possible what the program does when it executes. It shows you the strings, functions, structures, what memory is being used, what .dll files are being used as dependencies, lots more, etc. So I never really taught anyone ASM Programming but it shouldn’t be that hard. Let’s begin.
Before we begin learning about ASM Programming you MUST read this:
After you read that proceed to these tutorials:
After those tutorials you must read these two links:
Introduction to Ollydbg
Olly opens with the default window, CPU, open. This is where most of the “big-picture” data is. If you ever close this window, just click the “C” icon in the toolbar. It is separated into 4 main fields; Disassembly, Registers, Stack, and Dump. Here is a description of each section.
This window contains the main disassembly of the code for the binary. This is where Olly displays information in the binary, including the opcodes and translated assembly language. The first column is the address (in memory) of the instruction. The second column is what’s called the opcodes- in assembly language, every instruction has at least one code associated with it (many have multiple). This is the code that the CPU really wants and the only code it can read. These opcodes make up ‘machine language’, the language of the computer. If you were to view the raw data in a binary (using a hex editor) you would see a string of these opcodes, and nothing more. One of Olly’s main jobs is to ‘disassemble’ this ‘machine language’ into more human readable assembly language. The third column is this assembly language. Granted, to someone who does not know assembly, it doesn’t look much better than the opcodes, but as you learn more, the assembly offers FAR more insight into what the code is doing.
Every CPU has in it a collection of registers. These are temporary holders for values, much like a variable in any high-level programming language. Here is a more detailed (and labeled) view of the registers window:
On the top is the actual CPU Registers. The registers will change color if they have been changed from black to red (makes it really easy to watch for changes). You can also double click on any of the registers to change their contents. These registers are used for many things, and we will have much to say about them later.
The middle section are flags, used by the CPU to flag the code that something has happened (two numbers are equal, one number is greater than another, etc). Double clicking one of the flags changes it.
The bottom section are the FPU, or Floating Point Unit registers. These are used whenever the CPU performs any arithmetic involving decimal points. These are rarely used by reversers, mostly when we get into encryption.
The stack is a section of memory reserved for the binary as a ‘temporary’ list of data. This data includes pointers to addresses in memory, strings, markers, and most importantly, return addresses for the code to return to when calling a function. When a method in a program calls another method, control needs to be shifted to this new method so that it can retun. The CPU must keep track of where this new method was called from so that when this new method is done, the CPU can return to where it was called and continue executing the code after the call. The stack is where the CPU will hold this return address.
The dump window is a built-in hex viewer that lets you see the raw binary data, only in memory as opposed to on disk. Usually it shows two views of the same data; hexadecimal and ASCII. These are represented in the two right-hand columns in the previous picture (the first column is the address in memory that the data resides.) Olly does allow these representations of data to be changed,
These are your main controls to run code. Keep in mind that, especially as you start using Olly, all of these buttons are also accessible from the “Debug” drop down menu, so if you don’t know what something is, you can look in there.
I will make a couple of remarks about some of the icons. “Re-load” is basically to restart the app and pause it at the entry point. All patches (see later) will be removed, some breakpoints will be disabled, and the app will not have run any code yet, well, most of the time anyway. “Run” and “Pause” do just that. “Step In” means run one line of code and then pause again, calling into a function call if there was one. “Step Over” does the same thing, but jumps over a call to another function. “Animate” is just like Step In and Over except it does it slowly enough that you can watch it. You won’t use this much, but sometimes it’s fun to watch code run, especially if it’s a polymorphic binary and you can watch the code change.
Next is the (even more cryptic) windows icons:
Each of these icons opens a window, some of which you will use often, some rarely. Seeing as they are not the most intuitive letters, you can also do like I did and just start clicking them all until you find what you want. Each of these are also accessible in the “View” menu, so you can get some help when first starting out.I will go over some of the more common windows right now:
The memory window displays all of the memory blocks that the program has allocated. It includes the main sections of the running app (in this case, the “Showstr ” items in the Owner column. You can also see a lot of other sections down the list; these are DLL’s that the program has loaded into memory and plans on using. If you double-click on any of these lines, a window will open showing a disassembly (or hex dump) of that section. This window also shows the type of block, the access rights, the size and the memory address where the section is loaded.
This window displays any “patches” you have made, ie. any changes to the original code. Notice that the state is set as Active; if you re-load the app (by clicking the re-load icon) these patches will become disabled. In order to re-enable them (or disable them) simply click on the desired patch and hit the spacebar. This toggles the patch on/off. Also notice that in the “Old” and “New” columns it shows the original instructions as well as the changed instructions.
This window shows where all of the current breakpoints are set. This window will be your friend
This window is different from the “Stack” shown earlier. It shows a lot more info about calls being made in the code, the values sent to those functions, and more.
The Context Menu
Right-clicking anywhere in the disassembly section brings it up:
Next tutorial we will cover cracking with ollydbg and IDA Pro. It will be released later today. – ro0ted
- You can follow any responses to this entry through the RSS 2.0 feed.
- Both comments and pings are currently closed.