Preface

Overview

Modifying somebody else's code is unethical and even may be illegal. Long ago, when MS-DOS was the prevailing operating system, I wrote a small resident printer driver. At that time, the problem of localizing code or reencoding printers was urgent. One year later, I located my driver in use by some other company. This driver was installed by a Mister X. However, Mister X didn't limit himself to installing the driver. That person also modified the copyright information, specifying that the driver's author was himself. I do not feel angry about that occasion anymore, although a feeling of resentment still remains. Thus, I understand very well the feelings of software developers whose programs have been illegally reverse-engineered and modified.

However, ignoring reality is not the right behavior. To efficiently protect their programs, developers must know the cracker's toolset. Furthermore, in addition to negative effects, attacks on protection systems, worms, and computer viruses have some positive effect, because their existence makes software developers pay more attention to security and develop protection mechanisms more carefully. To a certain extent, attacks on software and computer systems play the role of stimulators for the software's "immune system," although indisputably on a large scale they can result in a virus epidemic harming many users or even ruining their computer systems. This book provides some examples of reverse engineering and of patching executable code. Note that all of these examples are intended for educational purposes only.

There are other reasons for investigating executable code. Understanding the internal mechanisms of executable code operation, and the way in which individual structures of high-level programming languages are converted into Assembly commands, is important for writing more efficient and highly-optimized programs. Often, low-level debugging is required for understanding the causes of random errors that occur at run time. Finally, every professional programmer must be curious and willing to understand how his or her programs operate. Isn't it interesting to discover how the source code of a program written in C++ or Delphi is transformed after it is processed with a compiler? Thus, all examples provided in this book are aimed at achieving positive goals and in no case at performing illegal actions.

When planning this book, I didn't intend to write an official textbook (although such textbooks are few and the time has come for them to be written). Rather, I tried to provide materials that I have accumulated during my long years of professional activity. In the future, I hope to write a textbook on the basis of this book. I'll do this with pleasure.

This book pays the most attention to such powerful tools of executable code investigation as the IDA Pro disassembler and the SoftIce debugger. These tools are characterized by practically unlimited capabilities, and hopefully you'll add them to your armory.

This book contains lots of reference materials. This is possibly a typical programming style that manifests itself in attempts to write a universal, all-sufficient program (which, by the way, remains an unattainable dream). I support the opinion that only few books do not force the reader to undertake, every ten pages, a long search in other books and on the Internet.

When writing this book, I oriented it toward operating systems from the Windows NT/2000/XP/2003 family. Nevertheless, lots of materials provided here will be applicable for the Windows 9x operating systems, although I didn't test my materials on this platform.

Most examples considered in this book relate to the C++ programming language and the Microsoft Visual C++ compiler, although there are some examples related to Borland C++ 5.0. The Pascal language and the Delphi compiler are paid less attention. You might ask why I use such a limitation. The answer is that I chose the classical language and the most powerful and popular compiler.