OllyDbg Reverse Engineering Series — Part 1 of 60
This article is part of a structured beginner-to-advanced reverse engineering series using OllyDbg.
| # | Title | Link |
|---|---|---|
| Part 1 - You are here | What is Reverse Engineering? Why OllyDbg? | What is Reverse Engineering? And Why Am I Using OllyDbg? |
| Part 2 | OllyDbg Interface Tour Every Window Explained | How to Read Disassembly in OllyDbg: A Beginner’s Guide |
| Part 3 | Number Systems- Hex, Decimal, Binary with Real Examples | Hex vs Binary vs Decimal: Explained for Programmers and Reverse Engineers |
| Part 4 | CPU Registers –What They Are and Why They Matter | CPU Registers Explained: What They Are and Why They Matter in Reverse Engineering |
| Part 5 | Your First Look at Assembly Reading Code Like a Reverser | How to Read Assembly Code for Reverse Engineering |
Okay so I want to be honest with you before we start.
When I first heard the words “reverse engineering,” I thought it was some advanced hacker thing only genius people do. Like something from a movie. I almost didn’t even try.
But then I actually learned what it means. And I was like wait, that’s it?
So let me explain it the way I wish someone had explained it to me. From absolute zero. No assumptions. No shortcuts.
What Even Is Reverse Engineering?
Let me give you an analogy first because that’s the only way this clicked for me.
Imagine someone baked the most perfect chocolate cake you’ve ever tasted. And they hand you a slice. No recipe. Just the cake.
You eat it. You think about it. You taste it again carefully. You go okay, there’s definitely cocoa here. Some vanilla I think. Probably butter. The texture feels like it has eggs.
You’re basically working backward from the final result to figure out how it was made.
That is reverse engineering. Exactly that.
Now replace “cake” with a software program.
Someone wrote code in C or Python or whatever. Then they compiled it which means they converted that human-readable code into machine instructions that a computer can run. The output is an .exe file on Windows.
You open that .exe file. You don’t have the original source code. You just have the compiled binary the “cake.”
Reverse engineering is the process of taking that compiled binary and working backward to understand what it does, how it works, what logic is inside it.
Wait, But Why Would Anyone Do This?
This is the question I had. Like okay cool concept, but why?
Turns out there are a lot of legitimate reasons:
Security research. You find a suspicious program on someone’s computer. You don’t have the source code. You need to understand if it’s malware, what it does, how it communicates. Reverse engineering is how you figure that out.
Malware analysis. This is a big one for me personally. When researchers analyze viruses or ransomware, they’re doing reverse engineering. They take the malicious binary and work through it to understand exactly how it infects, spreads, and does damage.
Vulnerability research. Sometimes you want to find security flaws in software. If you don’t have the source code, you reverse engineer the binary to look for weaknesses.
Understanding how things work. Sometimes you just want to learn. How does this protection work? How does this software check for a valid license? How does this game handle its save files?
I want to be clear we’re not doing this to pirate software or do anything illegal. We’re doing this to understand how software works from the inside. That’s a core skill in security research.
The Problem: .exe Files Look Like Gibberish
Here’s where it gets interesting.
If you open a .exe file in a normal text editor, you’ll see something like this:
MZÿÿ¸@€º´ Í!¸LÍ!This program cannot be run in DOS mode.
$ùèÔ=½=½=½5%¼½5%»½=¼½nÎ ...
Just noise. You can’t read it. You can’t understand it.
But here’s the thing that gibberish is not random. It’s machine code. Binary instructions that the CPU reads and executes. It has structure. It has logic. We just need the right tools to read it.
What Is a Debugger?
Okay this is the tool that changes everything.
Think of it like this. Imagine you’re watching a movie, but you have a magic remote control. You can:
- Pause the movie at any exact frame
- Look at every pixel on screen while it’s paused
- Go forward one frame at a time
- Inspect anything you want while time is frozen
A debugger is that magic remote but for a running program.
With a debugger, you can:
- Load a
.exeand start running it - Pause it at any instruction
- Look at memory, CPU registers, and the stack at that exact moment
- Move forward one instruction at a time and watch what changes
Without a debugger, you just see the program run and finish. You see the output. You have no idea what happened inside.
With a debugger, you freeze time and look inside. You see everything.
This is what I was missing when I first opened Ghidra and saw assembly code. I could see the code statically like reading a frozen snapshot. But I couldn’t watch it run. That’s the difference between a disassembler (like Ghidra) and a debugger (like OllyDbg).
So What’s the Difference Ghidra vs OllyDbg?
You might have heard of Ghidra. NSA made it. It’s free. It’s powerful.
Both Ghidra and OllyDbg are reverse engineering tools. But they work differently.
Ghidra = Static Analysis
You open the .exe in Ghidra. It reads the binary and tries to reconstruct something close to the original code. You can read through it, search functions, understand the structure all without running the program.
Think of it like reading a recipe someone tried to reconstruct from tasting the cake.
OllyDbg = Dynamic Analysis
You actually run the .exe inside OllyDbg. The program executes for real. But you can pause it, step through it, and watch everything happening live.
Think of it like watching the baker actually bake the cake, one step at a time, and pausing them at any moment to ask “what are you doing right now?”
For security research, especially for understanding how software protections work, dynamic analysis is incredibly powerful. You’re not guessing what the code does you’re watching it do it.
Why OllyDbg Specifically?
Okay fair question. There are other debuggers out there. x64dbg, WinDbg, IDA Pro.
I chose OllyDbg to start this series because:
- It’s free
- It’s designed specifically for Windows
.exefiles - The interface is beginner-friendly compared to alternatives
- There are thousands of tutorials and resources for it
- It has a huge community and plugin ecosystem
- For 32-bit Windows binaries, it’s still the classic go-to tool
Is it the newest tool? No. But for learning the fundamentals of reverse engineering, it’s perfect. Once you understand OllyDbg, moving to x64dbg or other tools is easy because the concepts are the same.
What You’ll See Inside OllyDbg
When you open a .exe in OllyDbg and pause execution, you’ll see four main windows:
+---------------------------+------------------+
|Part | Title | Status|
|--- | --- | ---|
|**1 - You are here** | **What is Reverse Engineering? And Why Am I Using OllyDbg?** | ✅|
|2 | OllyDbg Interface Tour - Every Window Explained(https://iotsec.in/t/what-is-reverse-engineering-and-why-am-i-using-ollydbg/33) | 🔜|
|3 | Number Systems - Hex, Decimal, Binary with Real Examples | 🔜|
|4 | CPU Registers - What They Are and Why They Matter | 🔜|
|5 | Your First Look at Assembly - Reading Code Like a Reverser | 🔜|
|6–60 | More parts coming... | 🔜|
+---------------------------+------------------+
| MEMORY DUMP | STACK |
| (raw hex bytes) | (temp data |
| 45 6E 74 65 72... | in/out) |
+---------------------------+------------------+
Disassembler - this is the assembly code of the program. The actual CPU instructions.
Registers - these are tiny storage locations inside your CPU. EAX, EBX, ECX — you’ll learn all of these. They hold values the CPU is currently working with.
Memory Dump - the raw bytes stored in memory, shown as hexadecimal numbers.
Stack - a temporary storage area the program uses to remember things.
Don’t worry if these words don’t make complete sense yet. Each one gets its own full blog post in this series. I just want you to know what you’re looking at before we open OllyDbg together.
What We’re Building Toward
Here’s the full picture of what this series covers:
Phase 1 (Parts 1–5): The foundations. Number systems, registers, basic assembly. This is where we are now.
Phase 2 (Parts 6–15): Assembly instructions that actually matter. MOV, PUSH, CALL, JMP what each one does.
Phase 3 onwards: Tracing how programs actually work. Cracking serial number checks. Understanding how protections are built. Unpacking compressed executables. Real reverse engineering.
By the time you finish Phase 1, you’ll be able to open OllyDbg, load a program, and read what’s happening without feeling completely lost.
That’s the goal for now. Just getting comfortable.
What I Found Confusing (And Now Don’t)
I kept mixing up “reverse engineering” with “hacking.” Like I thought it meant breaking into systems.
It doesn’t. Reverse engineering is about understanding. You’re analyzing software to understand how it works. What you do with that understanding is up to you and in security research, the goal is always to find vulnerabilities, study malware, or understand protections. Not to harm systems.
I also confused static analysis and dynamic analysis for a long time. Static = reading without running. Dynamic = watching it run live. OllyDbg is dynamic. That distinction matters a lot.
What We Learned
| Term | What It Means |
|---|---|
| Reverse Engineering | Taking a compiled binary and working backward to understand its logic |
| Compiled Binary / .exe | Human code translated into machine instructions no source code visible |
| Debugger | Tool that lets you pause a running program and inspect memory, registers, and instructions |
| Static Analysis | Reading code without running it (Ghidra style) |
| Dynamic Analysis | Watching code while it actually runs (OllyDbg style) |
| Disassembler | Converts machine code back into readable assembly instructions |
| Assembly Language | The low-level language the CPU actually reads and executes |
Coming Up Next
In Part 2, we’ll take a full tour of the OllyDbg interface. Every window. Every panel. What each one shows and why it matters.
By the end of Part 2 you’ll stop feeling lost when you open OllyDbg for the first time.
Part 2: OllyDbg Interface Tour - Every Window Explained (coming soon)