everse engineering of software is a touchy subject. No one wants to be accused of writing a book that helps people steal software. But there's a lot of malicious software out there that's fair game. Eldad Eilam takes a cautious approach in this well-written survey of the tricks used by writers of worms and trojans, and the tricks used by software developers who want too much control over how end-users use what they legitimately paid for.

The vast majority of programs of both types are written for Windows. In the commercial Windows environment, some software providers spend enormous resources trying to find ways to force users to pay for the same functionality over and over again. Although Eilam reserves the term "malicious code" for viruses and trojans, some people would argue that commercial software that unfairly deprives people of their ability to use it, or software that spies on the end user to gather data for the vendor, fits in the same category. To prove that a particular program is spying on you, you need to reverse-engineer or "reverse" it. This book will get you started.

To benefit from this book, you need a familiarity with x86 assembly language and a willingness to use a debugger. The general process is to sift through assembly language listings of disassembled Windows or DOS executables. These files have almost always been stripped of their symbols, making such a task tedious. Eilam discusses some of the ways vendors obfuscate their code to make the task even more difficult. Unfortunately, decompiler technology is not yet up to the task, so the author recommends some good software and hardware debuggers, including WinDbg, OllyDbg, and SoftIce.

You also need a certain amount of common sense. Don't just jump in with a debugger. The first step in reversing a program should be to look at the string space. In some cases, this may provide many shortcuts and hints, or maybe even tell you you're looking at the wrong file.

Eilam has chapters on undocumented APIs, reversing malware, breaking copy protection, reversing ".NET", deciphering file formats, and decompilation. The chapter on file formats actually focuses on analyzing an example data encryption program, and provides few pointers on deciphering data or image files. We often run across data files that are compressed in some proprietary format, and the original program that created the file can no longer be found. Eilam's techniques would be of little use in these cases.

Here's a real-world example of a situation where reversing commercial software might be considered. Where I work we have an old piece of scientific equipment that cost us about US$ 40,000 in today's dollars. The instrument uses a DOS-based PC containing ISA cards made by the vendor, similar to standard data-acquisition cards. One day, upon trying to repair it, we discovered that the software has a serial number check. If you replace one of the cards, the software detects the change and quits. We found that the software had been obfuscated to make it difficult for the user to remove the check. In other words, a $40,000 scientific instrument had been deliberately designed so it was impossible to repair, in order to force users to buy a new one when the old one breaks. It proved impossible to get the vendor to send a repairman over to fix it. But they were delighted to send a salesman over to try to sell us a new one!

I hasten to add that most equipment vendors do not stoop to this sort of money-grubbing behavior. In this situation, would it be illegal to reverse-engineer their software to get our machine working again? I don't know. Did we do it? Naah.... All I can say is, I highly recommend this book.