ShepherdTech.info

An analysis of software protection schemes

The BTO (”better than original”) problem posed by software protection mechanisms

ASICs (application specific integrated circuits) and their shortcomings

Software protections schemes based on media copying hardware and the shortcomings of these schemes

Application server model as a software protection scheme

Server-based electronic licence management

Software activation schemes based on hardware fingerprinting

Code tamperproofing

Lexical and control obfuscation of code

Generally, when one suggests current hardware based methods for the protection of software, he or she is referring to “dongles”. Dongles act as a physical key to open locked software programs, so that during install and/or during subsequent program runs, a piece of hardware external to the system is polled and its presence is verified. These dongles have come in pocket size units that connect to a system’s hardware ports: parallel, serial, and USB units. In the past, some poorer implementations have also utilized rewritable media: CD’s, floppies, or secured digital memory cards[1]. Various schemes are employed in the query that verifies the presence of the hardware unit on the system, including algorithms stored and/or hardwired within the dongle unit that can generate responses to multiple queries from the software. ASIC’s (application specific integrated circuits) employed in dongle design are preferable to the use of more generalized integrated circuits, which more easily succumb to physical analysis by attackers and brute force hacking[2].

Dongle-type protection systems suffer from the BTO vulnerability, in which cracked versions of the software are seen by customers as “Better than Original.[3]” Requiring a separate component to be added to the computer may cause system lock-ups, lead to computer system configuration conflicts, or require system rebooting. Although such problems are less common with more recent Linux and Windows operating systems³, the BTO vulnerability also surfaces when we consider that a user must “plan ahead” for use of the software product. Namely: that a software user must keep track of and have access to the hardware piece when wishing to use the software. Requiring the dongle to be carried around is a drawback to consumers such as mobile business professionals and the like. Due to these drawbacks, as well as high cost of production, hardware dongles have generally been used only for low-volume, high-end software products[1].

A protective system such as dongles is only as strong as its weakest link, and the vulnerability of hardware dongles lies with its hardware/software interface[1] [4]. When the protected program queries the key and receives a response, such query/response pairs can be intercepted and analyzed by an attacker. For this reason, it has been said by one dongle manufacturer that “the software interrogating the dongle may be the weakest part of the system… Any dongle manufacturer who claims that their system is unbeatable is lying.”³ The security of a dongle-type system must rest upon obfuscation of the communication carried on between the software and hardware key. In some cases, encryption is employed, and in these cases, it is generally a proprietary encryption algorithm utilized, presumably to further hinder analysis by an attacker. To counter replay-type attacks, in which the attacker could replay known correct responses to software queries, a common technique of dongle products is to provide a large number of valid query/response pairs2, thus making the attackers attempt at analysis more time consuming. An attacker would need to analyze a larger amount of query/response pairs in order to reverse engineer such a protective system.

It is important that in the manufacture of the hardware device, an ASIC (application specific integrated circuit) is devised for the specific software product2. If a more generalized IC is utilized in its design, the unit is susceptible to analysis and circumvention by engineers having less comprehensive knowledge of circuit design. This fact lends to a higher cost of production for a more secure dongle-unit, and has limited hardware key protection mostly to high-end, low-volume software products¹. Hardware production costs continue to fall, though, so that production of key copies by a pirate is not entirely unfeasible. Complexity can be added to these protective systems by employing periodic random (meaningless) queries sent from the software to the hardware unit (which should contain no meaningful response to such a query). Upon a random query, the program should ensure that a meaningful response (a valid response to a legitimate query) is not sent back from the hardware unit, but the dongle should produce SOME response that corresponds to no meaningful query. In this manner, replay attacks are more difficult to mount².

Software pirates in general have a greater knowledge of software and are trained in programming, but they have less of an understanding of hardware, and the strength of dongle-type systems somewhat relies on this fact, as well as the fact that hardware production can only be carried out by those with adequate resources. Similarly, copy protection schemes have utilized the software producer’s precise knowledge of hardware workings and production techniques to foil copying of software products by home users with limited technical and hardware resources. Early Commodore and Apple II developers used obscure knowledge of how disc drives of home systems read and copied discs: a typical scheme was to write necessary information to a disc is such a way that home hardware could not duplicate. Current copy protection schemes have carried on similarly. Essentially, all CD copy protection schemes rely upon differences between the way that the CD master is used in the production facility to produce authentic discs and the way that a home CD writer burns copies. Precise knowledge of how such home CD writing equipment operates will reveal that a home CD writer cannot always produce an exact 1:1 correspondence between the original disc (written in a certain way) and the copy produced. Modern CD copy prevention systems use this knowledge: most CD-ROM copy protective systems encrypt the main executable on the disc, and include a loader module on the disc which decrypts the main software using a key contained on the disc. The key is written (in the production facility) to the disc using a method which makes it hard to duplicate the key on home equipment[5]. In the end, such protective measures become outdated once the developers of CD writing software and producers of CD burning hardware become wise to these schemes. Software pirates employ burning software such as ClonyXXL and BlindRead, both of which are constantly updated to circumvent protective mechanisms in common use.

A particularly debilitating drawback to copy protection schemes is (once again) the BTO vulnerability. A product which can be backed up is of more value to the end user than a product which may produce corrupt copies upon attempted backup. In addition, requiring a user to insert a CD-ROM each time in order to use a software product is ultimately inconvenient to even legitimate users, who may end up resorting to the same “no-CD patches” that non-licensed customers employ.

A more recent trend in software piracy prevention has utilized the widespread availability of the internet. Two approaches, in general, have utilized network availability: application server models, and the much more widespread product activation schemes.

A radical departure from conventional software delivery methods and piracy prevention methods is the application server approach, in which software is not delivered as a stand-alone product, but instead a trusted server is employed to perform computations, while the client machine receives dynamically generated content (in the form of HTML or XML documents, for example). Similar network based solutions to piracy deliver program components on demand to users during the application’s usage, so that a client machine never has access to the entire software package at once. Such a system was deployed by Autodesk recently when the company used an application streaming model to deliver its AutoCAD software to trial users. The application server model has the capability of severely hampering any reverse engineering attempts by software pirates because the entire application never resides on a client computer entirely at any time[6], but these approaches are limited at present by inherent scalability and performance problems¹. Requiring access to high speed networks and server technologies for developers, this approach is not practical for many customers and developers alike.

A much simpler use of network servers in software piracy prevention is in the area of electronic license management, or ELM. In these schemes, a full software product is distributed to customers through conventional media (CD-ROMs, full downloads, etc), and servers are employed to in a way that encourages a particular software copy to be used by only a single user or machine.

In a simple ELM scheme, during install and during subsequent program runs, an application checks for a license file upon the computer system. Typically, the license information is hidden in the registry or in a file somehow hidden on the machine, such as the Windows system directory. If the license file is not found, the user is prompted to connect to the internet so that a kind of enforced registration may take place. Typically the user is prompted for his or her email address, name, address, etc, and this information is sent to the server, whereupon license information is returned (either directly to the program or to the email address provided) and then this license information is hidden upon the system[7]. Presumably, this enforced registration is intended to discourage the passing of license files and registration codes due to the seemingly non-anonymous nature of the information provided to the distributor (IP address, name, email, etc). Such simple ELM systems have serious flaws in implementation and are subject to intense pirating, such as obvious reuse of personal data from multiple users.

In order to perform more secure ELM, more recent schemes employ system fingerprinting and hardware binding which attempt to tie a software installation, not to a user’s name, email address or the like, but rather to the machine on which the program is being installed. Such hardware binding product activation schemes have been deployed by Microsoft, Macromedia, Adobe, and Autodesk, among others. Essentially, the process of product activation is similar to the simple ELM scheme described above, but instead of relying on a user’s voluntarily provided information, the machine’s hardware configuration is polled upon attempted installation to gather some identifying characteristics. Microsoft’s scheme, for example, gathers information on 11 hardware characteristics, including the types of display and SCSI adapters, the MAC address, the amount of system RAM, and others[8]. This hardware information is then sent by the software program, upon install, to the distributor’s server, whereupon the secure server uses the information provided to generate a unique license file with information derived from the information provided. Upon program startup, this license file is consulted, a hardware polling occurs, and the results of the poll are compared with the license file information. If a discrepancy occurs, program startup fails. In order to combat passing of license files, some hardware-binding schemes write information to the zero track of the hard drive, an area of the disk normally used by partition management software and OS boot loaders. Macromedia currently uses such a system and calls the information written to the zero track as the “anchor file.” Its states that the anchor file’s primary reason is to “help users avoid loosing and corrupting their license during administrative activities…[9]” but it seems clear that storing the license here serves the dual purpose of software license protection from cracking efforts. In the end, this amounts to security through obscurity, and it is only a short matter of time for this protection to be bypassed in an automated manner available to the general public.

The weakness of all systems detailed above (except the server side computing model) lie in the fact that these protective systems must rely upon some sort of hiding of the security mechanism. Detailed analysis of the security mechanisms by an attacker provides the information needed to spoof or bypass the protection. An attacker, when attempting to break a software protection scheme, will focus upon disabling or bypassing the security mechanisms, and so an effective protection of software must in some way rely upon the concealment of how the code which executes the protective measures operates. The ultimate problem faced by the developer is the fact that a software product, once released into the hands of the public, is at risk of cracking. Given enough time and effort, any conventional protection scheme can be broken, assuming an attacker has near unlimited resources, in terms of time and skill. This is due to the fact simple fact that any computer program can be patched to perform as any other computer program[10], which indicate that any protective code in the hands of the attacker (within the protected program) can be bypassed. Two approaches exist to combat the patching of protective code: obfuscation and tamper-proofing.

Tamper-proofing attempts to prevent changes to a software program from being made by end users. A typical attack on software protection mechanisms involves the bypass of security mechanisms, which involves changes the attacker makes to the executable through patching. In response, an approach to tamper-proofing involves the incorporation into the software product of a module which performs checksum operations on the executable before it runs, stopping operation if changes are detected. For example, a cyclic redundancy check (CRC) can be performed on the protective portion or module of the code to ensure it is free of changes before this protective code is executed to perform the primary protective measures[11]. Such checksum measures typically are used to compare the program, upon being opened by the user, with the original program installed. Once the nature of the checksum usage is understood, though, the attacker can readily remove or patch these checks¹.

The practical goal of most protection schemes should be to raise the level of effort and understanding necessary to crack the scheme so that novice crackers are incapable and capable crackers give up. A good measure of protection would require as much effort and technical expertise to crack the program as was required to write the program in the first place^1, [12]. In order to protect a program from reverse engineering attacks that set out to bypass protection, code obfuscation is utilized. Two main types of obfuscation exist: lexical and control obfuscation.

Lexical obfuscation attempts to conceal the purpose of identifiers by renaming them¹. A simple example would be to rename a function or variable from the title “KeyIsValid” to a more obscure title, such as “oXc24le0.” Such obfuscations may foil more novice attackers who rely upon text searches of disassembled code. Similarly, it is important to not explicitly declare a security violation when protection checks fail. A non-descript error message such as “Memory Corruption Error” should be issued to the attacker, rather than a message such as “Incorrect registration code entered.[13]” In the end, though, lexical obfuscation is not very effective, as the meaning can often be inferred by context^{1, 4}.

Control obfuscation attempts to obfuscate the flow of program control. While an attacker’s strategy is generally to identify the mechanisms by which protective checks are made, if the flow of control is difficult to follow, the attacker may be foiled. A simple example is the use of opaque predicates, in which the program code contains some conditional statements whose evaluation is always the same, in the hopes that tracing through the fruitless evaluations will prove tedious for the would be attacker^{1, 4}.

In the end, the cost of obfuscation is in program runtime and time required to institute the changes to the program code. An obfuscated program generally runs much slower than its corresponding unobfuscated version. In addition, it is difficult to use an automated obfuscation producing tool, due to the fact that an automated process lends itself easily to an automated process which undoes the obfuscation.

[1] Memon, N. & Naumovich, G. (2003) Preventing Piracy, Reverse Engineering, and Tampering. Computer, IEEE, 18-9162, 64-71;

2 Rainbow Technologies, Safenet Inc (2002). Curtailing the piracy epidemic: the case for hardware keys. Available online: http://www.safenet-inc.com/Library/8/SECURITY_KEYS_ROI.pdf.

3 Wikipedia: the free encyclopedia (Accessed: August 7, 2004) Copy Protection. Available online: http://en.wikipedia.org/wiki/Copy_prevention

4 Collberg, C.S. & Thomborson, C. (2002) Watermarking, tamper-proofing, and obfuscation: tools for software protection. Transactions on Software Engineering, IEEE, 28-8, 735-746

5 CD Media World (accessed: August 7, 2004). CD/DVD Protections. Available online: http://www.cdmediaworld.com/hardware/cdrom/cd_protections.shtml

6 Endeavors Technology. Press release: Endeavors Technology’s streaming applications delivery solution accelerates sales and increases revenues during Autodesk’s AutoCAD Trialware Program (2003). Available online: http://www.endeavors.com/PressReleases/casestudy_microsoft.html

7 Safenet, Inc. Electronic License Management (2002). Available online: http://www.safenet-inc.com/Library/8/ELM.pdf.

8 Microsoft. Technical details on Microsoft product activation for Windows XP (2001). Available online: http://www.microsoft.com/technet/prodtechnol/winxppro/evaluate/xpactiv.mspx

9 Macromedia, Inc. Macromedia Product Activation (2003). Available online: http://www.macromedia.com/software/activation/whitepapers/product_activation.pdf.

10 TSM GmbH. Security Background: SlockPK for Delphi and C++Builder. Available online: http://www.crypto-central.com/slock/slock_prot_basics.html

11 Bradshaw, W(2004). ShareGuard Copy Protection 1.5: Copy protection for shareware developers. Available online: http://www.devarchive.com/f1860.html.

12 Nettle, P. (2001). Software Protection. Available online at http://www.flipcode.com/cgi-bin/msg.cgi?showThread=04April2001-SoftwareProtection&forum=askmid&id=-1.

13 Safenet, Inc. (2003). Preventing Software Piracy. Available online: http://www.safenet-inc.com/Library/8/Preventing%20Software%20Piracy_03.pdf.