Welcome to HBH! If you have tried to register and didn't get a verification email, please using the following link to resend the verification email.

Reverse Code Engineering Part One


Reverse Code Engineering Part One

By ghostghost | 4534 Reads |
0     0

-= Introduction to Reverse Code Engineering : Part One =-

by lucid_dream

Contents

01 - Why this guide? 02 - What is RCE? 03 - What should I already know? 04 - Getting Tooled Up

01: Why this guide?

The main reason for me creating this is that imo, there is a shortage of general reverse-engineering material on the web. A lot of what can be found are outdated cracking tutorials showing how to crack such-and-such a program. I'm hoping maybe with this series of articles I can help to shed light on the basics and help light the way forward for the beginner.

We will start in this part by going over some basic terminology and getting tooled up. In the next part we'll cover the general structure of a dead-listing, as well as some common windows code that makes it easy to find your bearings. From there onwards you can let me know via email/PM what you want to see covered. I will be going into more advanced topics eventually such as polymorphic/encrypted code and how to deal with it, and non-code methods such as using filemon/regmon and reversing protocols using a packet-sniffer. Seriously, if you have a topic you want me to cover, then let me know!

02: What is RCE?

Reverse Code Engineering (RCE) is taking a program that somebody else wrote and ripping it to pieces to see how it ticks. People practice this art/science in many different ways and for just as many reasons; Want to know how a program you have implements a certain feature? Want to add functionality but don't have the source code? Want to do some good for the community at large by figuring out how the latest malware works and writing a fix? Want to find a new vulnerability in windows based software? You get the idea ;)

03: What should I already know?

It goes without saying that to reverse code, you must know how to write it. You needn't necessarily be a master programmer (I'm certainly not) nor do you have to know assembly language inside out, although the more you do know the better.

You will pick up most of what you need of assembly from PRACTICAL APPLICATION. As long as you understand the flow of a typical program and can at least decipher the code when needed, you should be ok. At the end of the day, you will soon realise what you need for yourself, and can tackle that alone. Maybe you will come across an assembly routine you can't get your head round, or unfamiliar instructions. Thats what google is there for, the wonderful beast with an answer for everything; Google is your friend ;)

04: Getting Tooled Up

There are thousands of tools floating around out there on the net, some useful, some not. However, for our purposes in the beginning I am only going to suggest three of them. As we move on to more complex code in future articles I will mention more tools as the need for them arises, otherwise you will end up with a HDD full of tools you don't know what to do with :P

  • Disassembler:

The disassembler takes a program (raw opcodes) and outputs human readable assembly language for you to study, this is called a dead-listing. The two most popular disassemblers out there are W32DSM and IDA Pro. W32DSM is a small, fast, easy-to-use disassembler that's great for beginners and still reasonably useful for all else. IDA Pro is a big, complex disassembler that beginners typically struggle with, however, it's extremely powerful and if you need complete reversing functionality as opposed to quick-fix W32DSM then you should definitely look into it.

  • Debugger:

A debugger for studying a program while it's running (live). This enables you to see the variables and such as you play with the program. The debugger of choice these days seems to be OllyDbg, it's small and easy to use and has quite a lot of nice features, plus it's free! However, OllyDbg is a user-mode debugger, which means you can't break into the OS with it (not that I see many kernel hackers about these days). Another debugger that's extremely powerful (and kernel-mode) is SoftICE which now comes as part of DriverStudio. I prefer SoftICE but I think that's because I originally learnt with it, and the raw power it gives you over your PC is awesome. OllyDbg is a very good alternative however if you can't get/don't want SoftICE.

  • Hex Editor:

A hex editor enables you to open a file and see the contents, patch it, etc. My favourite still is HIEW (Hacker's View) simply because it's nice and intuitive and has 3 different modes at the touch of a key; Hex, Text or Decode. Other popular hex editors include Hex Workshop and XVI32. It's a matter of personal preference to be honest, find one you like and learn to use it properly, just like the other tools.

Once you have these you are all set to begin, and we will be doing so from the next article… see you then ;)

lucid_dream (lucid.dr34m@gmail.com)

Comments
ghost's avatar
ghost 19 years ago

Good read… I've been trying for ages how to Reverse engineer something. I hope you can teach me something ;). I most certainly am going to read your next article:)

ghost's avatar
ghost 19 years ago

Nice, but what i would like to see is different articles on reverse coding different languages, like: Reverse Code Engineering : What you need (this article) Reverse Code Engineering : Javascript Reverse Code Engineering : Basic Apps. etc.

ghost's avatar
ghost 19 years ago

Well I did say let me know what you want so… ;) I don't know about Javascript as it's not a compiled language, if you know javascript you can just read any script to know what it does, but after I finish the article I'm working on (Part Two: Win32 Basics) I'm open to suggestions :) I can definitely cover the peculiarities of VB apps compared to Win32 C++, stuff like that.