Becoming A Better Reverse Engineer

Question

I have been looking on the net and all I see when it comes to reverse engineering are a bunch of silly crackme tutorials. I want to be better at taking code from assembly to c or c++. I am getting the feeling that I am going to have to have to pick this all in time and or make a bunch of small programs and break them apart.I would like to build on what might be already out there. I am already some what proficient in what I am doing just I want to be better.

For example:

mov     eax, DDrawPtr
push    8
push    1E0h
push    280h
mov     ecx, [eax]
push    eax
call    dword ptr [ecx+54h]

Hex-rays translates this as

v1 = (*(**DDrawPtr + 0x54))(*DDrawPtr, 640, 480, 8)

which is ok.... It should be .

HANDLE v1 = DDrawPtr -> SetDisplayMode(640,480,8);

or sometimes IDA makes mistakes and will say

int __cdecl sub_41B869()

Where as this code doesn't return anything and is supposed to be a void....

I found a neat question and answer here Stackoverflow question/answer. I am wanting to learn more like this because I am realizing that IDA makes mistakes. I want to know how to recognize function types and more importantly do this by hand, because I am seeing IDA make mistakes and I feel that I should learn to recognize better these mistakes and see how I can manually if need bring it back.

Here is a book that does this somewhat but it goes from C to assembly not the other way around. reverse engineering pdf

Any suggestions?

Answer 1

These suggestions may help. One sure way of becoming a better reverse engineer is to become a better "forward engineer"! Here's what I would suggest:

1. Examine the assembly output of various compilers. Write test programs of increasing complexity and examine the assembly language output so that you get a sense of what the compiler does for any given high level construct.
2. Try running binaries through a decompiler. This will allow you to see how those same programs are interpreted by a tool and allow you to begin to see the kinds of errors that the tools make.
3. Try completely reverse engineering a small project. It's not hard to find source code for all kinds of things these days. Pick an open source project that you are not familiar with, compile it without peeking at the code and try to reverse engineer it entirely. Alternatively, try reverse engineering some particular routine or aspect (which is more usual).
4. Try to write code to fool the decompiler. Open source projects typically don't take any anti-disassembly measures but other kinds of software (e.g. malware) often does. Learn these techniques in the forward direction and then look at the results with your reverse engineering tools. You'll get a feel for which techniques are successful and why.

Hope that helps.