First of all, you will ask yourself what the heck "Reverse-Engineering" means... Well, when you develop a program you are "engineering", that means you write the source-code, build the object files, link the executable etc. Thus, when you reverse-engineer you do it exactly the other way round. You want to modify a program, but you just have the final product of the developing/engineering process which is the .exe file (including any other data files, online-manuals etc. that belong to the final program version). So in order to be able to modify the existing program without the source-code, you have to "reverse-engineer" it, which means that you have to generate your source-code from the executable (in contrary to generating an executable from a source-code). You can do this either with disassembling the exe-file, modifying the source-code and then recompile it - or, for less complex reverse-engineering tasks, using a debugger like soft-ice to analyze the desired code-part and patching the exe-file afterwards.

Getting the source-code

Now the problem with generating source-code from an executable is that every compiler for a high-level language has its own way of translating its specific commands into machine-language. This would require a different high-level language "disassembler" for every different compiler, and since these kind of disassemblers are quite difficult to program this is seldomly used as a solution. But as you should remember from the second chapter, ASM is just a readable form of machine language. This implies that its quite easy to convert an executable (machine-language) into an ASM source-code, and thus several disassemblers for machine-language to ASM source-code conversion exist. Of course it is a lot more difficult to edit programs in ASM language than in a high-level language like C, but on the other hand you can reverse-engineer ANY program with this disassembling methods (which is quite a deal i think). As always, since there are quite a few of these disassemblers you have to choose the right one for your task. The right choice depends mainly on the environment the target program is run under, so the best choice for windows programs would be i.m.h.o. WDASM (iam currently using version 8.xx) which detects calls to Win-APIs, string references and a whole lot more ... For DOS programs i would use the latest versions of SOURCER or IDA.

Debug & Patch

Like i said before, this method is only useful for small modifications to the target program (like ... ehm ... cracking ?). And even then it┤s sometimes useful or even necessary to have a disassembled listing of the source-code in reach, in order not to get lost in the masses of gloomy ASM-Code for example. If you are an ASM-buff, know your way around debugging and don't mind spending nights in front of a dark screen (and maybe want to get rid of your girlfriend ?) then this is JUST THE THING for you ! But hell, it┤s a lot of fun, a big challenge and a fair one as well (sometimes at least). A great debugger for this task is Soft-Ice from NuMega, i wrote a small basic tutorial (MEEP ! MEEP ! self-promotion detected !) for this precious tool which is also available on the MiB-HP. Go find Soft-Ice on Caligo┤s Page (take a look at the Links on our MiB-Homepage), you find everything you need (along with tons of other topic-related tuts) there. After you found the desired routine in the target program spending hours in front of your debugger, you have to figure out a proper modification to fix the bug (or whatever you wanted to do to the target) in ASM and add this modification to the exe-file. This is done by translating the new commands into machine-language, which should be no problem for you if you are familiar with ASM (just take the opcodes), and inserting this at the correct location in the exe-file (here you often need a disassembled listing). Note that this may cause trouble if the target checks for a certain file length (checksum), and you have to be careful not to mess up the program flow with wrong addressing too. A much more safer method of patching is to overwrite the unwanted code parts with new code, the major disadvantage being in having to match the exact length of the code you want to overwrite with the new code you want to insert.