We all know software piracy causes huge financial losses. It has been estimated that the world’s software companies are now losing $40 billion in revenue in unlicensed installations. Yet, with all the security technology at our disposal, why isn’t piracy going away? While some areas have been able to squelch a certain percentage of software theft, the problem is here to stay. The huge influx of new PC users, the ubiquitous nature of piracy tools over peer-to-peer networks, and the near-impossibility of enforcement across the globe stand in the way of significant progress. Moreover, the outsourcing of development work opens up new worries for those dealing with countries with weak intellectual property (IP) enforcement laws.
Under these conditions, tackling piracy may seem like an insurmountable task. And piracy is just one example of the risk to IP. Reverse engineering of software not only opens the door to piracy, but to malicious tampering and the theft of source code itself. The economic impacts are simply too great to ignore. The detriment goes even beyond the cost of software stolen. Some companies are put out of business by competitors offering pirated software from overseas, not to mention lost tax revenues and jobs. The Fourth Annual BSA and IDC Global Software Piracy Study revealed that 35 percent of the software installed in 2006 on personal computers (PCs) worldwide was obtained illegally, amounting to nearly $40 billion in global losses due to software piracy.
Organizations can protect software on multiple fronts: legislative action, legal agreements, code segregation, and source code review.
Legislative Action: Businesses around the globe must band together to strengthen laws and enforcement to combat software theft. The World Intellectual Property Organization (WIPO) adopted new copyright laws that enable more effective enforcement against online piracy. Countries need to update their national copyright laws to implement these WIPO obligations. This prevents copyrighted materials from being shared online without the author’s permission and helps prevent copyright protection tools from being hacked. Likewise, governments need to adopt laws that meet international guidelines for intellectual rights protection and enforcement under the World Trade Organization’s Trade Related Aspects of Intellectual Property Rights Agreement.
Legal Agreements: Before any code or API is allowed to be shared, organizations normally insist on a non-disclosure agreement (NDA). This agreement outlines what is confidential and provides terms for sharing sensitive IP. However, this will do little good in countries were IP enforcement laws have been weak. If the partnering scenario involves outsourcing of application development, then legal agreements will include provisions for auditing a vendor’s site and mandating of hiring requirements.
Code Segregation: This term refers to technologies and techniques such as secure file transfer, network segregation and password protection for source code repositories used to control access to sensitive software. Code segregation is most important for those dealing with third-party development firms that may be working with competitors in their market.
Source Code Review: Any organization embarking in application development offshore should undertake a careful review of the resulting source code to ensure legal use of open-source software and GNU General Public License, and assurances that no malware or back doors were been injected during development.
These approaches are necessary first steps, but few focus on the direct threats to the code itself. This requires leveraging software protection technology that enables safe sharing of code for collaborative development environments. Ironically, despite the massive financial losses businesses experience from software theft, the majority of companies say that software license compliance programs account for just two percent or less of software revenues, according to a 2007 study by KPMG. To curb this burgeoning problem, this mindset has to change.
Software protection technology is designed to deter reverse-engineering (RE) of applications by making this expensive and time-consuming to achieve. Normally these solutions are deployed to prevent piracy, protect sensitive algorithms from competitors, and prevent tampering of software. This is achieved either by modifying the source code or via injecting into the binary themselves (i.e., embedded code within the compiled object code). Countermeasures employed by anti-RE features include:
Code Obfuscation: Obfuscation techniques make deployed software difficult to decipher by removing symbols, encrypting strings, or altering code control flow. This technique is used most often in Java and Microsoft .NET computing environments because of the greater threat to accessing source code when using these frameworks.
Encryption: One effective way to stave off hackers is to apply encryption at the function level, decrypt it at run time, and then re-encrypt it after the function is called. This prevents hackers from simply dumping the decrypted code in memory. While it is a useful defense, it is difficult to apply in intermediate language environments, so it must be combined with other run-time countermeasures that verify the environment is safe to execute code.
Anti-tampering: Anti-tampering features are critical to ensure the safe execution of software. Software protection technology normally deploys its own cryptographic-based means to detect and prevent tampering of software modules. Unlike existing code signing (or Strong Name in the Microsoft .NET world), which can be easily stripped out by manipulating the intermediate language, anti-tampering prevents hacker from creating a binary patch that manipulates machine code to bypass licensing routines.
Anti-debugging: Because tools such as Microsoft Windbg, SoftIce, and dissemblers such as DataRescue’s IDA Pro are so effective in analyzing deployed application code, it’s important to use software protection solutions that prevent these tools from attaching to an application. While there is no absolute way to prevent these tools from being used to reverse engineer an application, employing multiple anti-debugging countermeasures make the process far more difficult for hackers. Usually these techniques are kept at the user (“Ring 3”) level, but some solutions have attempted to monitor and block threats at the kernel (“Ring 0”) level and introduced even greater security vulnerabilities.
Execution Monitoring: Organizations can go a step further by conducting additional monitoring of the execution environment to further deter reverse engineering. For example, anti-debugging alone would offer little protection if the protected application could run within a virtual machine (i.e., ReactOS, Bochs, Xen, etc.) where the user would have complete control of memory.
More Features Equals Greater Protection
It’s crucial to employ a multi-tiered approach to securing code, particularly when software is being shared in a risky or unknown environment. To that end, organizations should make sure software protection tools combine the features mentioned above instead of relying on a single approach. Moreover, these protection tools must be able to be deployed in a collaborative software development environment. However, many of the features mentioned above would also break many of the development processes needed. This is because applying software protection systems is normally a binary proposition. If the code needs to be protected, then once the protection technology is applied, its purpose is to prevent all debuggers and development aids from attaching the protected application.
To resolve this security dilemma, organizations often adjust their anti-RE features to allow authorized partners, firms, and users to develop around protected software. However, if not controlled, this approach would negate the value of applying software protection in the first place. Therefore, organizations wishing to leverage this technology should look for capabilities that enable authorized end users to develop and debug their extensions around the application code without exposing sensitive code within the primary protected application.
Conclusion
As peer-to-peer networks and weak regulatory enforcement make it all too easy for people to pilfer someone else’s intellectual property, businesses must take a firm stand to protect their software. Existing laws offer little deterrent to theft, and are only minimally successful in environments where IP laws are enforced. By layering software protection solutions with development partners, organizations can directly govern access to their software IP without disrupting development processes. This transforms software protections from rigid anti-reserve engineering techniques to controlled access within a distributed software environment.