Patent Application
20080209558
The present invention relates to computer software protection and, more particularly, to a method and system for enhancing the ability of protected licensed computer software to withstand attack.
A common way of enforcing a license regarding the usage rights of a software program (herein also denoted as a “program”; as “software”; as an “application”; and as variants thereof) is to furnish the program with executable code that regulates the usage of the program according to the terms and conditions under which the program is licensed to the user. Furnishing the program in such a manner is typically done by embedding the regulating executable code (herein denoted as “protective code”) into the program, or, equivalently, by packaging the program and the protective code together within a single computer file (herein denoted as a “file”). Such a program is said to be “protected” (also denoted herein as “protected software”) within a “protective envelope” (also denoted herein as an “envelope”) which is made up of the protective code. In addition to monitoring and regulating program usage according to the license, the protective code typically performs other functions related to software protection. For example, the program may be encrypted, and may be decrypted by the protective code only immediately before execution. The terms “executable code”, “executable program code”, “executable software”, “executable computer code”, and “code” are herein used synonymously and denote instructions, statements, commands, or other directives which may be executed or interpreted by a computer to perform data handling and data processing operations. The term “executable program code” further is used herein to denote such code as recorded on machine-readable media, including, but not limited to: RAM; ROM; PROM; EPROM; EEPROM; Flash Memory; magnetic and optical recordable media; data storage devices; and computer network storage.
When the user runs a protected program by invoking the program's file on the computer, the protective code typically executes to perform initialization functions (such as decryption of the encrypted program, as noted previously). Thereafter, the protective code typically runs simultaneously with the program in the process background to monitor and regulate program usage according to the license terms. Typical license terms govern factors which may include, but are not limited to: the computer(s) on which the program can be run; the number of concurrent users; the time period(s) during which the program can be used; the number of times the program can be used; and the computer resources (e.g., file and network services) which the program can access.
Protected programs, however, are subject to attacks (also denoted in the art as “tampering”) whose goals are to evade the license-regulating mechanisms. In one mode of attack, the attacker seeks to separate the program from the envelope in such a way that the protective code is removed, disabled, or bypassed. If the attack is successful, the program can be run in an unprotected fashion, without any regulation according to the license terms. The user can then operate the program contrary to the license agreement in an unauthorized manner. A program originally provided in an envelope but which has been successfully separated from the envelope in the above-described manner is commonly said to have been “cracked”; it is also commonly said that that protective envelope has been “cracked”—both expressions are taken to denote the same consequences for the program. In addition to allowing the attackers themselves to violate the license, the precise methods of cracking the program are often published in the form of executable code that disables the envelope. Moreover, cracked programs themselves are typically freely distributed, in further violation of the license agreement. The term “cracking attack” in the context of protected software herein denotes an attack whose characteristics and purpose are to remove, disable, or otherwise evade license protection for the software and thereby render the software usable in violation of one or more license terms thereof. The descriptions and references herein to “attacks”, “attacking”, “attacker”, and so forth, are with respect to cracking attacks as so defined.
There has been considerable effort made to provide protective code that can withstand such attacks. U.S. Patent Application Publication 2005/0183072 of Horning, et al., titled “Software self-defense systems and methods” (herein denoted as “Horning”) provides an overview and survey of many details of cracking attacks and ways of defending the protective code against these attacks through the use of self-defensive programs (a self-defensive program is denoted in Horning as an “SDP”). Unfortunately, however, because software itself is inherently passive and visible, it is only a matter of time and motivation before suitably-skilled attackers can disable protective code, regardless of the self-defensive techniques employed.
The term “self-defensive” in the context of protected software herein denotes the inclusion of characteristics or features in the software, which are intended to resist attacks on the protective envelope.
U.S. Pat. No. 6,463,538 to Elteto, titled “Method of software protection using a random code generator” (herein denoted as “Elteto”) implements a defensive feature intended to thwart cracking attacks on a protected program by randomizing each instance of the protected program so that the protective code will differ substantially from one instance to the next, making it effectively impossible for the attacker to develop (and publish) a crack that would succeed in general for all (or many) different instances of the program. In theory, Elteto's approach is valid, but in practice it fails to solve the problem because an attacker need crack only a single instance of the protected program and then publish that cracked instance. Although publishing and distributing an entire program is more involved and cumbersome than publishing only the crack itself, the ever-increasing bandwidth of networks and the ease of network distribution, particularly over the Internet, ultimately make it just as feasible to publish the entire cracked program instance as it is to publish only the crack itself.
The limitations of the prior art, exemplified in Horning as well as the failure of Elteto and similar approaches to prevent cracking has led some to conclude that there is no decisive solution to the cracking problem in the realm of self-defensive programs—that self-defensive programming techniques, while useful, can never be sufficient. For example, U.S. Patent Application 2006/0174346 of Carroll, et al. entitled “Instrumentation for alarming a software product” (herein denoted as “Carroll”) takes the approach that any software protection can ultimately be broken and discloses a scheme for signaling an alarm over the Internet when a software license is violated.
A weakness of prior-art protection schemes, as exemplified by the above references, is that skilled attackers can often disable software protection within days (or even hours) of obtaining the protected software, and thereafter rapidly distribute the crack or the cracked program globally via the Internet. Even issuing a timely alarm (as provided by Carroll), is of limited value under such conditions. Moreover, whereas Carroll discloses collecting and transmitting information related to the identities of infringing users, Carroll does not disclose how it might be possible to collect and transmit information related to the identity of the attacker who cracked the program and enabled distribution of the unauthorized unprotected copies in the first place. This is noteworthy, because if legal action against infringement is contemplated, it is far more effective to prosecute the small number of infringing attackers rather than the large number of infringing users. A further weakness of Carroll is that attempts to signal an alarm over a network to a remote server are readily-detectable by an attacker, who can then pinpoint and disable the code in the program responsible for sending the alarm. In effect, then, the approach disclosed by Carroll introduces additional vulnerabilities which can be easily exploited by attackers.
It is emphasized that an important and hitherto unaddressed factor in software licensing is that of “cover time”—which herein denotes an order-of-magnitude estimate of the amount of time available to a licensor of a licensed protected software product before a successful attack results in wide-scale distribution of cracked versions of the program. In many cases, the natural market obsolescence of commercial computer software means that distribution of unlicensed copies of a particular version of the software has only a time-limited impact on the licensor. When the licensor releases a newer version of the software to supersede previous versions, the availability of cracked older versions is often of little or no concern to the licensor. In fact, many licensors offer free licenses to use superseded versions of a program as a marketing aid for their latest release versions of the program.
Therefore, if the current release of a licensed software product can be provided with protection featuring a cover time comparable to the useful market life of that release, the software licensor would be adequately protected in spite of the fact that the software can be expected to be eventually cracked.
There is thus a need for, and it would be highly advantageous to have, a method and system for extending the cover time of protection for a licensed software product. This goal is met by the present invention.
The present invention is of a method and system for extending the cover time for the protection of a licensed software product, by increasing the difficulty and time required for an attacker to produce a workable cracked version of the program. The present invention achieves this increased difficulty and time required for attack by suppressing the transmission of critical information about the effects of the attack to the attacker, thus disrupting the attack/response cycle, and thereby inducing the attacker to release a version of the program which has in fact not been successfully cracked, but which in fact retains protective capabilities.
The suppressing of transmission of critical information is accomplished by suspending the response of the self-defensive mechanisms of the program in such a manner as to simulate the behavior of a cracked program, thereby conveying a false impression to the attacker of the attack's effectiveness. The critical information that is thus withheld from the attacker is that the attack has not in fact succeeded in removing the protective capabilities of the software. Protected software according to embodiments of the present invention, in fact, continue to maintain a latent response capability to enforce the license, which is subsequently activated by one or more predetermined conditions according to specified rules.
Therefore, according to the present invention there is provided a method for extending the cover time of protection for a licensed software product by suppressing the transmission of information about the effectiveness of a cracking attack on the licensed software product, the method including: (a) detecting the cracking attack; (b) conditionally-enabling a latent license enforcement protective measure; and (c) simulating the behavior of a cracked program.
In addition, according to the present invention there is provided a system of modules of executable program code for extending the cover time of protection for a licensed software product by suppressing the transmission of information about the effectiveness of a cracking attack on the licensed software product, the system including: (a) an attack detector, for determining if an attack on the licensed software product has been initiated; (b) a cracked program simulator, for simulating the cracked program behavior of the licensed software product, the simulator activated by the attack detector; (c) a latent protective envelope, for providing suspended protection for the licensed software product; (d) at least one activation rule for determining activation of the latent protective envelope; and (e) a latent protection activator, for activating the latent protection envelope according to the at least one activation rule.
The invention is herein described, by way of example only, with reference to the accompanying drawings, wherein:
The principles and operation of a method and system for self-defensive protective software having suspended latent license enforcement according to embodiments of the present invention may be understood with reference to the drawings and the accompanying description.
In addition to definitions of terms appearing elsewhere herein, there are the following term definitions:
The term “computer” herein denotes any device or apparatus capable of executing data processing instructions, including, but not limited to: personal computers; mainframe computers; servers; workstations; data processing systems and clusters; networks and network gateways, routers, switches, hubs, and nodes; embedded systems; processors, terminals; personal digital appliances (PDA); controllers; communications and telephonic devices; and memory devices, storage devices, interface devices, smart cards and tags, security devices, and security tokens having data processing and/or programmable capabilities.
The terms “computer memory” and “memory” herein denote any device or medium from which information may be retrieved on computer command, or which can both store and retrieve information on computer command, including, but not limited to: RAM; ROM; PROM; EPROM; EEPROM; Flash Memory; magnetic and optical recordable media; data storage devices; and computer network storage.
The term “loaded” in the context of executable software within a computer environment herein denotes that the software has been entered into the memory of a computer such that the computer is capable of executing the software. The terms “loaded image” and “image” in the context of executable software within a computer environment herein denote the version or copy of the executable software in computer memory which is executable by the computer. The term “running” in the context of executable software loaded on a computer herein denotes that the software is executing within a process of the computer, including, but not limited to, a background process.
As mentioned previously, the descriptions herein utilize the terms “protect”, “protection”, “protective”, and so forth, in the context of licensed software to denote features and characteristics of the software to enforce license terms related to the software. The terms “defensive”, “self-defensive”, and so forth, however, denote features and characteristics of the software to resist attack, regarding both attacks on the software itself as well as attempts to disable the protection.
Enforcing a software license according to embodiments of the present invention includes, but is not limited to, the following protective measures which may be taken if terms and/or conditions of the software license are violated:
The terms “protective measure” and “measure” in the context of protective software, herein denote an action taken to enforce a software license, such as the above non-limiting examples thereof, and thereby denote a function performed by the protective code of protected software.
License terms and conditions typically include, but are not limited to, authorizing use of the software only:
In addition, the term “module” in the context of computer software herein denotes a conceptual or functional identification of a software unit or subunit having executable computer code and/or data for accomplishing a specific purpose. The term “module” as used herein is not limited to contiguous executable code nor to software units or subunits which appear as integral elements in source code, object code, or binary code form. Rather, any collection of executable computer code and/or data which operates to accomplish an identified purpose is considered a “module” for accomplishing that purpose as defined herein.
The term “system” in the context of computer software and computer program products herein denotes a set of modules which function together for accomplishing a specific purpose.
The term “time-stamp” herein denotes any recorded information containing a function of time, including, but not limited to, the calendar date and the clock time (for example, the local date and clock time). Non-limiting examples of time-stamps typically present the time in a predetermined format and with a predetermined resolution, and which is current to a reasonable degree of accuracy at the time of the creation and recording of the information. Non-limiting examples of time-stamps conforming to the foregoing definition and suitable for use in embodiments of the present invention are found in the Internet Society's published document RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). In addition, a time-stamp may also contain information about the geographical region thereof, such as time-zone information (e.g., a time-stamp reading “2006-12-21 06:32.57 EST”, which specifies the United States Eastern Time zone).
There are various ways of detecting that an attack is underway or has already taken place. As disclosed in Horning, for example, it is often possible for software 201 to detect if a debugger is in use. The use of a debugger is considered a likely indication that the software is under attack, so detecting that a debugger is currently executing software 201 serves as a means of detecting that an attack is in progress. Also, Carroll discloses that protected software can be presumed to have been attacked if a violation of the current license is detected. In addition, a method for directly determining that an attack has been made is disclosed in the co-pending US Patent Application of the present inventors entitled “Method for detecting that a protected software program is cracked”, which was filed simultaneously with the present application.
Returning to
The terms “simulate”, “simulation”, and variants thereof, in the context of cracked software and the behavior thereof herein denote any procedure, process, method, or step for causing a protected software program to mimic, or to give the appearance of being cracked and/or having reduced or impaired protection, including, but not limited to, giving the appearance of lacking protective measures altogether. According to embodiments of the present invention, cracked program simulation is typically performed when a protective envelope is in place and is capable of providing license enforcement measures. In a non-limiting embodiment of the present invention, simulating the behavior of a cracked program is accomplished actively by presenting at least one program response that is, or would be, characteristic of a cracked version of the protected software program. In another non-limiting embodiment of the present invention, simulating the behavior of a cracked program is accomplished passively by disabling, suspending, inhibiting, bypassing, or otherwise preventing from operating at least one license-enforcement measure that would normally be taken by the protected program's protective envelope. In a further non-limiting embodiment of the present invention, simulating the behavior of a cracked program is accomplished by enabling the normal functioning of at least one feature of the protected software program that is subject to a license enforcement measure.
In a similar fashion the term “cracked program simulator”, as well as variants thereof, denotes any device or executable code which is operative to simulate the behavior of a cracked program, as defined previously, including, but not limited to, active and passive means, as presented above. In yet a further non-limiting embodiment, a latent protective envelope (as detailed herein) is itself a cracked program simulator.
It is noted that simulating the behavior of a cracked program is an inventive step of the present invention—the prior art teaches away from this feature of the present invention: It is a teaching of the prior art that as soon as an attack is detected, the normal functioning of the program should be immediately restricted or prevented. For example, this is stated explicitly in Horning, paragraph 476 (“Useful functioning of the SDP should be restricted or prevented once tampering has been detected.”). In contrast, the present invention discloses immediately enabling and facilitating the full functioning of the program as soon as an attack is detected. The present invention teaches that restricting and preventing useful functioning should be suspended, or held in abeyance, pending the occurrence of predetermined future conditions.
Thus, when the attacker performs tests 111 to determine if software 201 runs without protection at decision point 113, tests 111 will return a confirmation so that the attack is always deemed successful at point 115. Effectively, there is a block 114 so that the attack concludes at point 115. Subsequently, release 117 occurs, resulting in the placement of protected software 221 being placed in distribution 119. In certain descriptions and illustrations which follow, software 221 is presented as a non-limiting example of software according to embodiments of the present invention, which has been attacked and subsequently released by the attacker.
It is noted, however, that the status and condition of protected software 221 according to embodiments of the present invention is different from that of cracked prior-art software 121 (
The above properties of self-defensive protected software 201 according to embodiments of the present invention are further illustrated in the conceptual system block diagram of
Self-defensive protected software 201 contains an application code module 301, which is the executable code that performs the intended user functions of software 201. A basic protective envelope 303 is the executable code which ensures that application code 301 is employed by the user in accordance with the license provisions established by the licensor. In a non-limiting embodiment of the present invention, protective envelope 303 includes decoy code 304, which is protective code that is anticipated to be easily-recognized by an attacker, and which would be expected to be disabled promptly by an attacker. The use of decoy code according to this embodiment would thus serve to draw attention away from other protective code in software 201 and thereby reduce the likelihood that the attack would disable all the protective code.
A self-defensive group 305 of modules includes an attack detector 307, which determines if software 201 is being attacked and/or has been attacked—in other words, that an attack has been initiated on software 201. Means for performing such a detection have been discussed in detail previously. Certain embodiments of the present invention have associated with attack detector 307 an attacker identifier module 309, whose function is to provide information which can identify, or assist in identifying, an attacker who is and/or who has carried out an attack on software 201. A means of providing such information about an attacker is as follows:
In many cases, an attacker outputs a memory dump of the application code (such as application code 301) of an executing program to a file in order to crack the program. This is advantageous to the attacker, because doing so may allow capture of the decrypted (and operational) executable application code of an encrypted program without having to break the encryption itself (the protective code does the decryption before loading the image into computer memory). However, by including information about the computer and the user, as described above, the attacker may unknowingly also dump information about himself and his computer into the output file, especially if the information is encrypted so that the attacker cannot easily determine that such information about him and his computer is in the output file containing the executable application code. Therefore, by including such information in the image and later examining a cracked file (such as by extracting the computer-related data from the application code image, and analyzing the computer-related data, using the appropriate decryption keys, as necessary), it may be possible for the licensor to gain information about the identity of the computer and/or the attacker himself, as well as information relating to the environment of the attack (such as the time and geographical local of the attack) to aid in enforcement of the license. The term “attacker” herein denotes any person involved in a cracking attack on protected software.
Accordingly, attacker identifier 309 contains executable code for injecting information about the current user and current user environment into the application code image of loaded software 201 in computer memory. Such information includes, but is not limited to: data related to the configuration of the computer; a network address of the computer; machine name; MAC address; hard drive serial number; username; and personal data related to a user of the computer. Additionally, according to an embodiment of the present invention, the time of the attack is stored in a time-stamp. In further embodiments of the present invention, attacker identifier 309 further includes executable code for extracting such information from software 201 or the loaded image thereof. Thus, according to embodiments of the present invention, attacker identifier 309 provides information related to an attacker involved in an attack on software 201, where “information related to an attacker” herein denotes information about the attacker personally and/or information about the computer which the attacker used in carrying out the attack. According to embodiments of the present invention, as described above, attacker identifier 309 stores information related to an attacker and retrieves information related to an attacker.
Returning to
According to certain non-limiting embodiments of the present invention, latent protective envelope 315 performs license enforcement features substantially comparable those of to basic protective envelope 303. Also according to certain non-limiting embodiments of the present invention, latent protective envelope 315 includes at least some of the same executable code as that of basic protective envelope 303.
Latent protective envelope 315 is activated by a latent protection activator module 317, which obtains information about the environment via an environment monitor 319. According to an embodiment of the present invention, environment monitor 319 monitors environmental factors including, but not limited to: the current date and time; data related to the number of times software 201 has been loaded and run; data related to the computer upon which software 201 is running, such as a network address of the computer, machine name, MAC address, hard drive serial number; and data related to the user who is using the computer, such as username and other personal information. Any apparatus, system, device, or interface, including but not limited to software interfaces, data converters, and device drivers which is capable of presenting a data representation of the environment can be used as an environment monitor as defined herein. According to an embodiment of the present invention, a module in protective group 313 compares data from environment monitor 319 with data stored by attacker identifier 311 (as detailed above), and is able to determine (to a suitable degree of certainty, i.e., with a suitable overall probability that such a determination is correct), whether the computer on which software 201 is currently running is the same computer on which an attack on software 201 has been made.
Various non-limiting embodiments of the present invention provide for different modules as shown in
As shown in
Rules according to embodiments of the present invention include, but are not limited to:
According to embodiments of the present invention, activation rules (such as the rules above) may be combined logically. In a non-limiting example of such a combination, a time rule can establish a period during which software 221 (
The terms “conditionally enabled” and variants thereof, in the context of latent protection, herein denote that the latent protection and the protective measures thereof are not immediately made operational, but rather are allowed to become operational subject to the fulfillment of certain additional predetermined conditions. The terms “activate” and variants thereof in the context of latent protection herein denote that a conditionally-enabled latent protection measure is made operational to enforce a license term, by virtue of the fulfillment of at least one additional predetermined condition.
A further embodiment of the present invention provides a computer program product for performing a method disclosed in the present application or any variant derived therefrom. A computer program product according to this embodiment includes a system or set of executable commands for a computer, and is incorporated within machine-readable media including, but not limited to: magnetic media; optical media; computer memory; semiconductor memory storage; flash memory storage; and a computer network. The terms “perform”, “performing”, etc., and “run”, “running”, when used with reference to a computer program product herein denote the action of a computer when executing the computer program product, as if the computer program product were performing the actions. The term “computer” herein denotes any data processing apparatus capable of, or configured for, executing the set of executable commands to perform the foregoing method, including, but not limited to the devices as previously described as denoted by the term “computer”.
While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made.
