Solving the hacking problem

As software hackers adopt new and sophisticated methods of breaking code and stealing software, Independent Software Companies (ISVs) are scrambling to stay one step ahead of thieves in order to protect their intellectual property. Today, that is getting harder to do.

It is certainly more complex as traditional anti-hacking defenses are becoming largely ineffective against more sophisticated tampering tactics. In fact, hackers have become so good at what they do that Nintendo recently reportedly lost $975 million due to piracy. Microsoft also estimated that it lost $900 million in five years when a Taiwan company started to pirate 21 titles, selling them in 22 countries.

Yet despite these significant losses, current anti-tamper products just aren't up to the task of protecting sophisticated software applications. Rather than protecting the application anti-tamper products today easily succumb to hacker efforts in a matter of minutes or hours. Or, they are often huge drains on application performance and can result in unpredictable performance spikes.

Two specific examples where traditional protection easily fails are:

Hardware Breakpoint Attacks
Many modern processors have a fixed number of hardware breakpoints (also known as debug registers) that can be used by applications and debuggers. These breakpoints are provided in the processor as a way to easily debug applications. Developers configure the breakpoints so they can interrupt the program to verify proper operation. But once an application is released to end-users, hackers use these breakpoints in order to subvert the proper execution of the application. The result is that breakpoints become a powerful hacker tool used to change the behavior of a program without changing the code.

The traditional solution to this is to detect the use of hardware breakpoints and respond accordingly. However this just moves the problem back one level - the hacker will simply use a hardware breakpoint to circumvent the detection/overwriting mechanism and continue with his hack. Incredibly, this kind of attack can take around 2-3 hours to remove the protection from an average application.

Patch-Execute-Unpatch Attacks
Another common hacking tactic involves patch-execute-unpatch attacks. With this approach it is possible to modify a program, execute some arbitrary code and then remove the modification so that the hack cannot be detected. This Patch-Execute-Unpatch attack takes advantage of ‘gaps' in protection to operate. If a protection scheme does not verify the integrity of all the running code dynamically at run-time frequently, then it is likely to be susceptible to a Patch-Execute-Unpatch attack. The attack works by taking advantage of delays between checking and execution. If hackers can find unchecked code, or code that is checked but has a delay before being executed, then they can modify (patch) it and have their code run (execute).

Afterwards, again before it is re-checked, a hacker can replace the original code (unpatch) to create an undetectable hack. Patch-Execute-Unpatch attacks can take one to five hours to implement, although some attacks can take as little as five minutes. The quickness that this hack can be initiated has a dramatic effect on the time that an application remains protected.

What's a software vendor to do against attacks like these?
To avoid hacking and malicious alteration of the application, software companies are turning to new anti-tamper solutions that will protect the entire application, as well as maintain code integrity. One emerging approach is to arm the application with a self-defense system that injects thousands of checks into the source code of a target application, transforming the application into its own robust security system. Resistant to detection and removal techniques, this type of approach slows a hacker down because he must manually remove each check in order to render the security around the application ineffective.