Brief Intro and Advice to Fellow Noobs
Adam Pridgen (apridgen) <adampridgengmailcom> Sunday, March 18 2007 15:55.28 CDT


Meet Adam, ~H1  

I am currently a graduate student (once was a military grunt ;) if that tells you anything) finishing up my Master's in ECE.  I am involved in a self-study course focusing on RCE and code comprehension because I am both fascinated by the creation of code and astounded by how machines execute the code. The two projects I am involved with for the course are design-recovery/ binary auditing of a large closed source application and then some vapor-ware (until I get some more stuff done at least) for Pai-Mei in the malware arena.

So this initial post is more for my fellow reversing noobs.  Fear not noob friends, reversing is a liberating experience not to mention fun.  I would compare it to putting together a multi-dimensional puzzle, where pieces may degrade or enhance the clarity of the problem you are trying to solve and the actual solution to to that problem. It's like a good adventure game, where you are the adventurer and you have to un-solve the puzzles to unlock the various doors, nuggets of information, etc. to attain mastery of the level.  In fact, I bet someone could market a MMPOG, where there are good reversers and bad reversers trying to block each other out of the level...Oh wait that's malware ;).

Anyway, for my fellow inductee peer reversers or those who want to get started, I would like offer up some nuggets of advice that may or may not be helpful to you, so here you go:

- Obtain a copy of Eldad Eilam's Reversing: Secrets of Reverse Engineering
- You will NOT become an RCE expert over nights.
-- Some patience, concentration, discipline, and motivation are required to build your background
-- Expect to be invigorated, frustrated, challenged, humbled
-- Expect to become stubborn, adaptive, creative, vigilant, Experienced, Resourceful
- Just because a tool is free does not mean it is not effective
-- Olly Debug is great for Dynamic analysis.
-- For the small programs I have used, IDA Freeware was very effective
-- Starting out in RCE is an evolution, you don't need the hardcore tools to become an effective reverser
- Learn to use a few tools really well, Olly Debug is a priceless utility when used correctly
- Learn to document your thought process, progress, methodology, and functionality of your target in your sessions
- Learn the basics of assembly, then use Olly Debug to reverse some simple programs
-- Here is a good resource for labs aimed at beginners: http://certification.iitac.org/
- Learn the basics of the target operating system your are reversing on, this will help you better understand what is going on
- Find a target that you think might be fun and reverse it.
-- Use some discretion in your choice though, trying to reverse target that makes seasoned reversers balk is about as effective as trying to stop a speeding tractor-trailer with a small hatch-back; it probably won't happen under most conditions


Comments
cpanic Posted: Sunday, March 18 2007 16:24.43 CDT
Learn to document your thought process, progress, methodology, and functionality of your target in your sessions

This is what i fight with even now sometimes, like second day looking at some crazy chinese tea with various addresses/sequences, and thinking "what the hell i meant here" :)

Anyways, nice summary.

RolfRolles Posted: Sunday, March 18 2007 17:07.46 CDT
- Learn the basics of assembly
- Learn to document your thought process, progress, methodology, and functionality of your target in your sessions

These two are definitely the most important, although I'd go further on the first statement.

In the static arena (reading code in IDA), my advice for newbies would be to instruct your compiler to produce assembly-language output (-S option for gcc), and then compile some C code and compare the assembly-language output with the original source.  The goal is to let the compiler teach you what high-level statements in C/C++ look like in assembly language.  The compiler can also teach you about optimizations and different assembly languages in this way.

anonymouse Posted: Monday, March 19 2007 01:32.00 CDT
regarding the suggestion about comparing/analysing/ studying and reversing  your own programs disassembly

some one (i think he is registered  here or atleast one of his plugins is available for download iirc) started a wiki the initial few lessons are quiet good. if some one would like to contribute and expand the entries take a look:

http://scratchpad.wikia.com/wiki/Reverse_Engineering_Mentoring

chrisr Posted: Monday, March 19 2007 08:16.47 CDT
Make sure you know a language like C or C++ very well before diving into assembler, it will make your life a lot easier. It helped me a lot in the beginning.

Also like Rolf said up there using gcc with the -S flag and comparing your C and ASM is invaluable when you first dive into RE. I still use this to learn what different code looks like in assembler all the time.

nico Posted: Monday, March 19 2007 11:36.40 CDT
You don't need to be too good in C/C++ before diving into assembly.

C/C++ knowledge is only good when you are reversing programs made in such languages, as Rolf said, you can check out output from compilers.

Programming in Assembly for a while is helpful to read disassembly. Obviously, avoid the use of all the macros crap in your assembler, if you want to write code that looks like your IDA output..

Piotr Posted: Monday, March 19 2007 13:21.58 CDT
I must agree with the nico's comment. I didnt know much C when i was starting with assembly. What's more funny i was even too poor to buy a computer that times so i was trying to code using my copybook. If you need a good pure asm compiler i can suggest you TASM5, even though it's really outdated and not supported anymore i still love it :)

have fun!

chrisr Posted: Monday, March 19 2007 19:23.52 CDT
Knowing C first helped me a lot cause thats what I was reversing. I guess I made  a bad assumption in thinking thats what others would start with  :]

MohammadHosein Posted: Tuesday, March 20 2007 10:34.43 CDT
meanwhile its a good idea to learn one of today well known VHLL dynamic languages , to write your own tools without a lot of pain and to have an understanding of others . there are alot of exciting news and projects regarding to Python and Ruby nowadays , and they have become very famous in hacking and RCE community . Metasploit3 is written in Ruby and PaiMei is written in Python , also to play with IDA there are IDAPython and IdaRub . after a while you certainly need to code your own plugins and scripts to get things done , and one of these will help you a lot .

PSUJobu Posted: Wednesday, March 21 2007 09:50.35 CDT
I would say that (depending on what you are trying to reverse), general comp-sci principals are at least as important as knowledge of the HLL (e.g., C or C++) used to generate the binary. For example, if you don't know about typical data structures (e.g., linked lists), you will struggle with the meaning of the code, even once you understand the assembly language instructions. The more data structures and algorithms you know, the more you will "recognize" while reversing.

The same goes for the comments about knowing C++. If you have never programmed in C++ and you attempt to reverse a C++ program, you may spend a lot of time puzzling over the "tables of function pointers" rather than seeing them as vtables and understanding the significance of them.

Of course, I am somewhat biased, since I programmed in C, C++, etc., for many years before learning RCE...

frankboldewin Posted: Wednesday, March 21 2007 11:58.19 CDT
my first computer language i've learned was assembler and it took me 4 different architectures (6502, z80, 68000, x86) before i've started learning c and c++. in former times i've just coded native assembler programms, but when i began reversing other peoples high-level language code, i saw the big difference between human coded assembly and machine compiled code.

for me, a good reverser should have the following skills:

- a good assembly knowledge including a good understanding how the cpu works (registers, mnems, realmode, pmode, MSRs and so forth)

- debugging knowledge and usual tools (softice, windbg, ollydbg+ollyscripting, ida+automationplugins)

- OS architecture (processes, threads, mutexes, namedpipes, semaphores, most important file formats like PE or ELF etc) and systemprogramming skills (usual APIs like win32, native APIs etc)

- high level programming language skills (c, c++, delphi, vb)

- knowledge how compiler work

and depending what should be reversed:

security researcher:
- known bug classes and how they can be identified in compiled code

malware analyst:
- unpacking knowledge (unpacking and reparing, vm-detection tricks, antidebugging tricks, polymorph and metamorph code usual rootkit hiding techniques, etc)

sohlow Posted: Thursday, March 22 2007 11:21.27 CDT
some advice besides the obvious learning/understanding
the architecture you're examining as well as asm constructs
generated by the compiler the application is written in, is as you're reading code...think like a coder.

when developing under a deadline, most coders tend to
implement portions of programs the same way. it'll save you time as you start thinking how you'd implement something
and discovering the application you're reading matches
how you'd accomplish it. if it's completely different from
the way you'd implement, then that's when you'll probably
want to analyze the code in detail as the developer was
probably having fun with an interesting/different way to implement something.

next, it always falls back to clever breakpointing.
good breakpoints will give you a point-of-reference
to begin debugging/analyzing the application. i find
that more important to anything.