When starting a reverse engineering class I usually ask: 
- How many of you have ever done any reverse engineering?
And usually, all the hands in the room are raised, so I continue and ask: 
-
 So, if I give you a simple binary you’ll be able to tell me which 
compiler I used within ten minutes just by looking at the disassembly, 
not using any tools?
As
 an answer, nine out of ten hands drop. When I ask the remaining hand 
whether or not he will be able to take a simple binary and give me back a
 C file that, when compiled, matches the original binary bit for bit, 
he’ll retreat too.
I
 have been thinking about why this happens. Thinking back to myself, I 
started learning reverse engineering by reading the Lena151 tutorials. I
 thought they were awesome until Daeken told me that was an awful approach to learn reverse engineering.
At
 first I didn’t understand why they were so bad. After all, Lena’s 
tutorials had taught me how to crack my first software. But since Daeken
 is such an experienced reverse engineer, I took his advice without 
question and started writing C programs that I reverse-engineered 
statically instead.
A
 while back, a friend of mine who wants to get going on reverse 
engineering told me he had downloaded the Lena151 tutorials and was 
about to get started. I told him he shouldn’t and gave him the exact 
same advice I got from Daeken some years back, because I really agree 
with him. But I couldn’t explain to my friend why he should do as I 
said.
I’ve
 come up with an analogy that I think anyone getting into reverse 
engineering should read and understand. If you do this and follow the 
advice, you won’t be one of those raised hands who will drop immediately
 when the follow-up question is asked. Your hand will stay raised.
The analogy
Pretend
 I give you a car without a brand and tell you to reverse engineer it 
for me. One way you could do this is by sitting in the car and press 
different buttons while documenting what happens. You could take a ride 
with it, maybe tank it full and document how far you get, how fast it 
can go and how good the brakes are. You open the front or the back and 
examine changes while you press buttons or pedals. You crawl under it 
and repeat what you’ve done to document and examine it from another 
angle. 
I
 bet, in the end of the day, you’ll have a pretty good grasp of the 
limits of that car. You could probably even write a specification for 
somebody that would like to build a car with the same limits and 
benefits.
So, have you reverse engineered it? Hell no! 
-
 Let’s dig deeper, you tell yourself. You find a manual for the car and 
read it. Then you google for the engine model and learn some basic 
electronics. Great, you now know how to hot-wire the car. Finally you 
google the lock type and find out how to break it. Voila, you know 
exactly how to steal the car. 
And
 yet, you still haven’t reverse engineered anything. You’ve done simple 
behavior analysis and behavior modification at most. This is what the 
Lena151 tutorials are all about, behavior analysis and behavior 
modifying, or as we hackers call it “cracking”. 
What
 actually needs to be done to reverse engineer the car is that you need 
to be able to tell me how the electronics in it work and how they are 
put together. You need to be able to tell me why they are put together 
the way they are and how a change on the system will impact the entire 
system. You need to be able to tell me which fabric or brand the engine 
is from by analyzing the electronic in it. When you have enough 
information to tell me how to build a fabric that will squeeze out cars 
like that, with the exact same engine and the exact same electronics, 
you’ve actually reverse engineered the car.
Translated to the world of software, this means you need to understand the following:
x86 assembly (electronics and wires in the car analogy)
How operating systems work and how they manage memory (the engine of the car)
The compiling process from C-code to assembly (this is equivalent to knowing how a car-fabric is assembling a car)
The life of a binary (equivalent to everything that happens in the car from the key-switch to the off-switch)
Then
 you’ll need to know the file format of binaries in your targeted 
system, but that is minor knowledge that you’ll be able to pick up 
quickly once you know the rest.
See
 the difference between reversing and cracking? While one of them is 
about understanding the features of the target the other one is about 
re-creating the process that created the target. 
This
 is why Daeken’s advice works. When compiling your own C-code and 
examining it in IDA Pro you take your first steps to learn how compilers
 create binaries and why. The Lena151 tutorials have not a single line 
about compiler technology or how operating systems manage memory. 
Most
 people, whether they learned “reverse engineering” from Lena’s 
tutorials or by their own, are confusing reverse engineering with 
behavior analysis and behavior modification. The later ones are great 
skills to have and very essential for software professionals. They just 
are not the same as reverse engineering. I think that is the reason why 
so many raised hands drop when asked to reverse engineer a simple 
binary.
