Problem - Kevin Tafuro

The threat of protection crackers
Software is rarely cracked for profit. It is cracked because the protection is trivial
(“Why crack it? Because I can”), because the software itself is in demand (“crack
requests” and “zero-day warez”), or because the protection is interesting, often
sheerly because it is difficult (this is “reverse engineering” for sport). Protecting
against every type of attacker is impossible. Instead, we recommend that you determine
which type of attacker poses the greatest threat.
If your software is popular and has a high demand, you will want to defend against
the “zero-day” cracker by making the crack itself take a long time to produce. The
goal here is to sell more copies of the application in the time between when the software
is released and when the crack is produced. The crack can be made to take
longer in a variety of ways. Distributing validation checks requires that more locations
be patched and thereby increases the complexity of the crack. Delaying the
effects of a failed validation increases the probability that incomplete cracks will be
produced. Performing supplemental validation checks in areas of the program that
are used only by the “power user” of your software can also be effective because
most crackers know little or nothing about the software they crack and use only the
basic feature set when testing their crack. The rule of thumb for this type of software
is to hide the protection itself and provide “red herring” protections, which are
slightly difficult to defeat, and which appear to be responsible for the security of the
application. Anti-debugger code, hardware validation, and network validation all fail
here as they only serve to draw attention to the protection itself.
If your software is released frequently and/or has a low cost or a relatively small user
base, you will want to defend against the “because I can” cracker by increasing the
skill needed to crack your program. This way, users of your software will find it more
reasonable to purchase your software than to crack it. Encrypting or packing the
software can do this by including anti-debugger code and by making the code of the
protection itself tedious to debug and disassemble (e.g., by incorporating a lot of
irrelevant mathematical transformations, breaking the protection up into numerous
small subroutines, and repeatedly moving variables around on the stack and in memory).
In this situation, there is little need for outwitting the cracker with this type of
software, as heavy-duty protection would come at too great a software development
cost. Instead, focus your protection efforts on frustrating the casual or inexperienced
cracker.
If your software is genuinely valuable and is more likely to be reverse-engineered for
its algorithms than cracked for purposes of redistribution, you will want to protect
against the “for sport” cracker. In this case, you assume that the value of your software
is in its originality, and therefore that it’s worth spending large amounts of time
and money to protect the software. In such cases, the attacker is usually a professional:
the application is run in a sandboxed environment, the system state is backed
up to recover from hostile code, and replacement hardware is available in case of fail-
650 | Chapter 12: Anti-Tampering
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.