Label: reverse engineering
Reverse Engineering: how people actually read and understand binary code
What reverse engineering really is
Reverse engineering is not about “hacking” in the cinematic sense. In practice, it’s much simpler and much more technical: you have a program, you don’t have the source code, and you need to understand what it does and how it does it.
You are essentially walking the path backwards. Instead of writing code and compiling it, you start with the compiled binary and try to reconstruct the logic behind it. And an important point right away — you never fully recover the original source. What you get is an understanding of behavior.
That distinction matters.
You are not trying to recreate the developer’s code. You are trying to answer concrete questions:
why does it behave this way, where is the decision made, what needs to be changed.
How it starts in real life
In practice, it rarely begins with assembly. It starts with a question.
Something behaves incorrectly. Or unexpectedly. Or just interestingly.
You open the binary and first look at it as a structure. On Windows, for example, you immediately recognize a PE file. That already tells you a lot: how it is loaded, what libraries it depends on, whether it talks to the network, where execution begins.
Only after that do you go deeper — into the code itself.
Disassembly: not convenient, but honest
When you look at disassembled code, you are seeing exactly what the CPU executes. No abstractions, no names, no intent — just instructions and control flow.
mov eax, 1
cmp eax, 0
jne short loc_continueIt’s harder to read, but there is no interpretation layer. Nothing is being “guessed” for you.
That’s why experienced developers often trust disassembly more than decompilation. Because it cannot lie — it only shows what is there.
Why decompilation is both useful and dangerous
Decompilers try to reconstruct higher-level code, usually something that looks like C or C++. That makes navigation easier, but it comes at a cost: everything you see is an approximation.
The tool does not know what the original code looked like. It infers structure from patterns.
Sometimes that works well. Sometimes it doesn’t — especially when:
- the compiler heavily optimized the code
- control flow is non-trivial
- pointer logic is complex
So decompiled output is helpful for orientation, but it should never be treated as ground truth.
What you actually do during analysis
A common misconception is that reverse engineering means understanding the entire program. In reality, it’s almost always targeted.
You are looking for something specific:
a validation check, a transformation, a network handler.
So the real work is:
finding where that logic lives, understanding how execution reaches it, and figuring out what conditions control it.
At that point it starts to feel less like “analysis” and more like investigation.
Why architecture knowledge is not optional
Very quickly you run into a wall if you don’t understand how the machine executes code.
Things like:
- calling conventions
- stack layout
- register usage
- instruction encoding
are not theoretical — they are the only way to interpret what you see.
On architectures like x86, with variable-length instructions and complex control flow, guessing is not an option. You either understand what happens, or you don’t.
Reverse engineering is rarely the end goal
In most real scenarios, analysis is just a step.
The actual goal is to change something.
Once you understand where the decision is made, you can:
- modify a condition
- redirect execution
- intercept a call
Without analysis, that becomes trial and error. With analysis, it becomes precise.
Why it is hard
The main difficulty is not the tools. It’s the missing context.
A binary has:
- no variable names
- no types
- no structure
Only the result of compilation.
And the compiler is not trying to preserve readability. It is trying to generate efficient machine code. It inlines, removes, merges, and reorders.
What you see is optimized behavior, not original intent.
If obfuscation is involved, the gap becomes even larger.
Final thoughts
Reverse engineering is not a separate discipline from programming. It is the same domain, just viewed from the opposite direction.
You are still dealing with:
- the same CPU
- the same memory model
- the same execution rules
just without the convenience of source code.
And over time it becomes clear:
the better you understand how code actually executes, the less you depend on tools
Everything else is practice.
Self-modifying programs – applying patch
