This chapter is from the book
This chapter is from the book
This chapter is from the book
1.9 Discussion
There are plenty of reasons to use the techniques you will read about in this book to protect your code, and plenty of reasons not to. In the end, you must weigh the pros and cons to see if using them makes sense in your particular case.
1.9.1 Reasons to Use Software Protection . . .
On the plus side, there are situations where even a short delay in cracking your code will be beneficial. For example, these days computer games often escape into the wild within days or a few weeks of release. Sometimes, as the result of insider attacks, they even escape before they’re released! Since gamers are interested in playing the latest and greatest, the revenue from a new game is typically collected within the first few weeks of its release. Game manufacturers have therefore traditionally been eager to adopt software protection techniques, even those that are sure to be cracked within a very short time.
In situations where you’re selling a particularly high-value program, software protection might also make sense. If every year you sell only a few tens of copies of a software system that costs $100,000 per seat, the loss of even one sale due to piracy could be devastating to your bottom line. In these situations, it’s common to use a combination of hardware techniques (such as dongles) to prevent illegal copying and software techniques (such as obfuscation) to protect the interface between the hardware and the application.
In some situations, you may want to use software protection to prevent individuals from cracking your program, individuals you are unlikely to catch (because they’re far off in another country) or who are legally untouchable (because they have no assets to forfeit). In other cases, you may want to use software protection as an aid in criminal prosecution. It is said that more money is lost to piracy performed by corporations than by individuals. The reason is that corporations often will buy, say, 10 licenses to use a program but will let 50 of their employees use it. These corporations have huge assets, and if you can prove license infringement, you may actually have a chance to use the legal system to force them to abide by the license agreement. Individuals, on the other hand, often crack a program or download a pirated program that they would never have bought legally anyway. The amount of revenue lost to this type of piracy may therefore not be as high as often reported, and going after these types of adversaries is less likely to be profitable.
1.9.2 . . . and Reasons Not To
On the downside, adding software protection to your program can cause problems in terms of cost, performance, a more complex software development cycle, and last but not least, annoyance to your legitimate users.
Costs can increase both during development and distribution. During development, you have the option of purchasing a protection tool, developing one yourself, or applying the protection techniques by hand. Regardless, you will be adding a step and complexity to the development cycle. In several techniques you’ll see in this book (such as fingerprinting and code encryption), every distributed copy of your program will be unique. This means additional headaches during distribution, quality assurance, and when fielding bug reports.
Many of the techniques you’ll see come with significant performance overhead. And when we say “significant” we mean significant. Whether higher levels of protection necessarily incur a more severe performance hit is unknown, but it seems not an unreasonable possibility. In the end, this may require you to make difficult trade-offs: using techniques with low overhead and a low level of protection, using powerful techniques with high overhead but only for the security-sensitive parts of your program, or accepting the high overhead of a powerful protection technique but only selling to users with sufficiently powerful computers.
Many software protection techniques have been cracked not because the attacker necessarily wanted to pirate or reverse engineer the program, but because he wanted to perform what to him seemed like reasonable operations on it. Maybe he wanted to run the program on his laptop as well as his desktop computer, maybe he wanted to make a backup copy of it, maybe he wanted to transfer it from his old machine to his newly bought one, maybe he wanted to run the program without the annoyance of having to enter a password or insert a CD or USB token every time, and so on. Whether or not you, as the software developer, think these are legitimate concerns, and whether or not the software license agreement allows it, the user may well get ticked off enough to feel no qualms about cracking the program.
And that’s not to mention bugs. Many of the techniques you will see in this book are based on code transformations. As such, they’re very similar to the optimizing code transformations you’ll find in sophisticated compilers. And as such, they’re susceptible to the usual menagerie of bugs. As a result, your program that was perfectly functional before protection was added may exhibit erratic behavior afterward, either as a result of a bug in the protection tool itself, or because its code transformations revealed a latent bug in your own code.
1.9.3 So Which Algorithms Should I Use?
So you’ve written your fantastic new program and for whatever reasons you’ve decided that it makes sense to add some sort of software protection to it. You’ve bought this book5 and read it cover to cover in search of the One True Algorithm to implement. Unfortunately, if this was your attitude, you will have been sorely disappointed.
The problems facing software protection research are multitudinous, but it boils down to one central issue: How do you evaluate the effectiveness of an algorithm? Unfortunately, the state of the art is sorely lacking. Ideally, this book would end with a single large table over all the algorithms that lists for each one effort to implement, effort to defeat, parallelizability of attacks, and performance overhead.6 As you may have already guessed, there’s no such table.
Without knowing how many more hours/days/weeks/months your program will remain uncracked if you protect it with the algorithms in this book, how can you know if software protection will make sense in your particular case? And without being able to compare two algorithms to say that one is better than another, how can you pick the right algorithm to use? And how does the field progress when a paper purporting to present a new, improved algorithm can’t substantiate its claims?
Disturbing questions, indeed. In practice, software protection takes a belt-and-suspenders approach to security. You layer protection algorithms until you’ve convinced yourself that your program is secure “enough” while at the same time remaining within performance bounds. If you can afford to, maybe you employ a professional red-team to try to break through the defenses and give you some feel for how long the protection will survive in the wild. But in the end, you have to accept the fact that you’re engaged in a cat-and-mouse game: If crackers deem your program sufficiently crack-worthy, eventually they’ll succeed. This situation may seem depressing, but it is not much different from other areas of life. In the end, all it means is that you will have to monitor the efforts of your adversaries and be prepared to continuously update your defenses.