Problem - Kevin Tafuro

When planning to implement a protection, keep these three costs in mind:
Development time
Designing and writing an effective software protection is quite difficult. The programmer
must have knowledge of assembly language and operating system
internals and some experience with protection cracking techniques. Writing and
testing a protection takes valuable resources away from application development.
As a result, it is tempting to use a third-party software protection rather
than to develop one from scratch. This is often a mistake, however, because
most commercial software protections are well known to protection crackers
and can be bypassed quite easily. If you are using a third-party software protection,
be sure to supplement it with additional in-house protection mechanisms.
Debugging difficulty
Any software protection worth using is going to make the application difficult to
debug; after all, this is what a protection is designed to prevent. Protections that
rely on CPU-specific instructions or data structures internal to the operating system
may very well introduce bugs into an otherwise working application. Supporting
such applications on a wide variety of hardware and operating systems
can be a nightmare, especially with a large number of users actively reporting
problems. Once again, these factors may seem to favor the use of third-party
software protections; however, as mentioned above, the gain from such protections
is often minimal.
Maintainability
Incorporating a software protection into an application often comes at the price
of code understandability. Months or years after the protection has been developed,
the programmers maintaining the application may no longer be able to
understand the protection or the code it protects. This can result in modifications
to the application that result in the protection’s failing.
The techniques of software protection are often at odds with the goals of code reusability
and maintainability. Most methods entail the obfuscation of code and data
within the binary, while some attempt to foil the use of standard analysis tools such
as debuggers and disassemblers. Because the obfuscation must take place at a binary
level rather than a source-code level, and because binary analysis tools work with an
assembly language representation of the binary rather than with the original source
code, many of the anti-tampering techniques presented are implemented at the
assembly-language level.
Anti-tampering techniques
This chapter is concerned with preventing software tampering: detecting changes in
a compiled application, combating the use of common cracking tools, and preventing
the understanding of code and data. There are four main approaches to anti-tampering
covered here:
652 | Chapter 12: Anti-Tampering
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.