Patent Application
20120191803
Computer programs for personal computers are prone to reverse engineering. For example, license enforcement code in such programs may be detected and disabled by editing a program's machine code. As a consequence, once a computer program hits the market, attackers may reverse engineer its protection mechanism and produce a new copy that appears functionally equivalent to the genuine copy, but with disabled anti-piracy enforcement.
Various embodiments are disclosed that relate to decommissioning factored code of a program on a computing device. For example, one disclosed embodiment provides a method of operating a computing device. The method comprises executing a program on the computing device, and while executing the program, identifying a remote location of a factored function via a code map, sending a call to the factored function and receiving a return response. The method further comprises, upon occurrence of a decommissioning event, receiving a copy of the factored function, and updating the code map with a location of the copy of the factored function.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
Recent developments in anti-piracy technology have led to the development of split computational anti-piracy methods. Split computational methods involve partitioning, or factoring, a program into two or more pieces that are executed remotely or separately from one another. For example, in some implementations, a smaller, functionally important piece of a program is located on a server, while the remainder of the program is located on a client. The client executes the program up to a point where the control flow leads to the server partition. The client then may prepare the appropriate data as input and make a remote procedure call to the functionality present at the server. If the client copy of the program is authorized, the server executes the call and returns results to the client. On the other hand, if the client copy is not authorized or if the server detects tampering attempts, the server will refuse to execute the call or will execute the call differently than it would for authorized clients, thereby disrupting execution of the program on the client.
However, such split computational anti-piracy methods may increase run-time operational costs for the program. Thus, at some point during the lifetime of the factored program, it may be desirable to transfer the remotely executed piece of code so that it can run locally. Such downloading of a remotely executed piece of a factored program so that the remotely executed piece can run locally is referred to herein as “decommissioning.”
A factored program may be decommissioned after the occurrence of a predetermined threshold event, such as an event count threshold or a time threshold. Further, a factored program may be decommissioned at any time by a publisher. For example, once a publisher of a factored program has recovered profits expected from an initial investment, the publisher may desire to reduce nm-time operational costs of the factored program, as the value of the factored program following the recovery of profits may be lower than the operational costs associated with maintaining the program in factored form. Thus, at some point in the life of the factored program, e.g., after an opportunity width of a sales curve has passed or at any publisher-determined time, the factored program may be decommissioned to run partially or entirely from a client with no remote service dependencies. Any event, request, or other occurrence that triggers a decommissioning process is referred to herein as a “decommissioning event”
Accordingly, embodiments are disclosed that relate to decommissioning a factored program. Prior to discussing the decommissioning of a factored program, an embodiment of an example use environment is described with reference to
Both the authorized and unauthorized versions of the program code are missing one or more functions that instead reside on a remote computing device 110 that is accessible via network 112. It will be understood that the term “function” and the like as used herein to describe factored code may signify any code portion separated from the rest of a program. The missing function i may be selected for separation from the rest of the program code based upon various considerations, including but not limited to an importance of the use of function 108 to a satisfying user experience, a difficulty of inferring an operation of the function 108 from an input/output analysis, any economic and/or computing resource costs associated with the remote hosting of the function 108, and other such considerations. While the missing function i is depicted as being stored on a remote server system, it will be understood that the missing function may be stored on any suitable remote computing device. Further, it will be understood that the term “server” as utilized herein may refer to any such remote computing device that hosts one or more missing functions.
The program code may additionally include a code map 103. The code map indicates the location of the code to be run by the program. For example, the code map may be a library such as a manifest file or xml document which includes location information of the functions called by the program. As described below, the code map may be dynamically updated during decommissioning of a factored program so as to track the locations of the functions during the decommissioning process.
Remote computing device 110 comprises a factored function store 114 in which missing function i is stored, and also comprises an authorized user information store 116 in which information on authorized users may be stored. As an example,
At 304, method 300 includes identifying a remote location of a factored function, e.g., function i shown in
At 306, method 300 includes sending a call to the factored function. For example, as shown in
At 310, method 300 includes detecting the occurrence of a decommissioning event. The decommissioning event may take any suitable form. For example, the decommissioning event may correspond to the occurrence of a threshold event, such as a count threshold or a time threshold. In other embodiments, the decommissioning event may be initiated by a publisher of the program based on any suitable factors. For example, a publisher of the program may decide to decommission the program once the program has recovered profits expected from an initial investment, when operational costs associated with maintaining the program in factored form exceed profits expected from the published program, etc. Upon detecting a decommissioning event at 310, method 300 comprises receiving a copy of the factored function at 312.
When decommissioning a factored program, the factored program may be running, and thus at times may be executing the factored functions. Thus, in some embodiments, a program may be progressively decommissioned so that execution of the program is not affected or interrupted during the decommissioning. For example, a progressive download of a remotely-located function may be interrupted when the factored function is in use by the program, and then resumed when the factored function is not in use by the program. As such, in some embodiments, receiving a copy of the factored function at the client may comprise receiving at least a portion of the copy when the factored function is not in use by the program so that execution of the program is not affected by decommissioning operations. Likewise, decommissioning may proceed through various interruptions, such as interruptions in connectivity.
In some examples, following a detection of an occurrence of a decommissioning event, the code for a remotely-located function may be downloaded from the remote server to the client device so that the function can execute locally with all the overhead in execution rather than integrating the function into the running executable during a download. In this example, the decommissioning could be performed via a change of the executable and a link to a dll received from the remote server as a decommissioning product, for example.
Further, if a plurality of remotely-located functions are downloaded to the client during the decommissioning process, downloads of the remotely-located functions may be prioritized based on which functions are in use by the program. For example, if a first remotely-located function downloaded to the client is needed by the program, then the download of the first remotely-located function may be interrupted and a download of a second remotely-located function not in use by the program may be initiated. Once the first remotely-located function is no longer in use by the program, the download of the first remotely-located function may then continue where it left off before the interruption. Tracking what functions are in use by the program may be performed in a variety of ways. For example, the code map may be employed together with program run-time information to determine which functions are in use by the program. Further, when decommissioning multiple functions, downloads of the functions may be staggered in order to reduce deadlocks during the downloads.
During the progressive download of remotely-located functions during decommissioning, the code map may be dynamically updated to generate a function location and dependency map so that the program may continue to run during the downloads.
At 314, method 300 includes saving a copy of the factored function. For example, as shown in
At 316, method 300 includes updating the code map with a location of the copy of the factored function. In this way, the program, which looks to the code map for function location information, may execute the downloaded function locally.
At times, a publisher of the program may desire to update the program, and to provide the update as factored code that is stored on a remote computing device to protect the new features of the program. Thus, at 318, method 300 optionally includes updating the program with a second factored function accessible at a remote location. Then, remote computing device 110 may execute the second factored function in response to a call to the function, and send a second return response to the client.
At 320, method 300 includes updating tire code map to identify the remote location of the second factored function so that the program is updated with the new functionality. Further, in some examples, the code map may include an indicator of a version of the program that is executing. The code map also may include information such as which remotely-located functions have been decommissioned and any new functionality or updates.
Computing system 400 is shown in simplified form. It is to be understood that virtually any computer architecture may be used without departing from the scope of this disclosure. In different embodiments, computing system 400 may take the form of a mainframe computer, server computer, desktop computer, laptop computer, tablet computer, home entertainment computer, network computing device, mobile computing device, mobile communication device, gaming device, etc.
Computing system 400 includes a logic subsystem 402 and a data holding subsystem 404. Computing system 400 may optionally include a display subsystem 406, communication subsystem 408, and/or other components not shown in
Logic subsystem 402 may include one or more physical devices configured to execute one or more instructions. For example, the logic subsystem 402 may be configured to execute one or more instructions that are part of one or more applications, services, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform a task, implement a data type, transform the state of one or more devices, or otherwise arrive at a desired result.
Logic subsystem 402 may include one or more processors that are configured to execute software instructions. Additionally or alternatively, logic subsystem 402 may include one or more hardware or firmware logic machines configured to execute hardware or firmware instructions. Processors of logic subsystem 402 may be single core or multicore, and the programs executed thereon may be configured for parallel or distributed processing. The logic subsystem may optionally include individual components that are distributed throughout two or more devices, which may be remotely located and/or configured for coordinated processing. One or more aspects of logic subsystem 402 may be virtualized and executed by remotely accessible networked computing devices configured in a cloud computing configuration.
Data-holding subsystem 404 may include one or more physical, non transitory, devices configured to hold data and/or instructions executable by logic subsystem 402 to implement the herein described methods and processes. When such methods and processes are implemented, the state of data-holding subsystem 404 may be transformed (e.g., to hold different data).
Data-holding subsystem 404 may include removable media and/or built-in devices. Data-holding subsystem 404 may include optical memory devices (e.g., CD, DVD, HD-DVD, Blu-Ray Disc, etc.), semiconductor memory devices (e.g., RAM, EPROM, EEPROM, etc.) and/or magnetic memory devices (e.g., hard disk drive, floppy disk drive, tape drive, MRAM, etc.), among others. Data-holding subsystem 404 may include devices with one or more of the following characteristics: volatile, nonvolatile, dynamic, static, read/Write, read-only, random access, sequential access, location addressable, file addressable, and content addressable. In some embodiments, logic subsystem 402 and data-holding subsystem 404 may be integrated into one or more common devices, such as an application specific integrated circuit or a system on a chip.
The term “program” may be used to describe an aspect of computing system 400 that is implemented to perform one or more particular functions. In some cases, such a program may be instantiated via logic subsystem 402 executing instructions held by data-holding subsystem 404 It is to be understood that different modules, programs, and/or engines may be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Likewise, the same module, program, and/or engine may be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. The term “program” and “engine” is meant to encompass individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc.
Display subsystem 406 may be used to present a visual representation of data held by data-holding subsystem 404. As the herein described methods and processes change the data held by the data-holding subsystem, and thus transform the state of the data-holding subsystem, the state of display subsystem 406 may likewise be transformed to visually represent changes in the underlying data. Display subsystem 406 may include one or more display devices utilizing virtually any type of technology. Such display devices may be combined with logic subsystem 402 and/or data-holding subsystem 404 in a shared enclosure, or such display devices may be peripheral display devices.
Communication subsystem 408 may be configured to communicatively couple computing system 400 with one or more other computing devices. Communication subsystem 408 may include wired and/or wireless communication devices compatible with one or more different communication protocols. As nonlimiting examples, the communication subsystem may be configured for communication via a wireless telephone network, a wireless local area network, a wired local area network, a wireless wide area network, a wired wide area network, etc. In some embodiments, the communication subsystem may allow computing system 400 to send and/or receive messages to and/or from other devices via a network such as the Internet.
It is to be understood that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense, because numerous variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. As such, various acts illustrated may be performed in the sequence illustrated, in other sequences, in parallel, or in some cases omitted. Likewise, the order of the above-described processes may be changed.
The subject matter of the present disclosure includes all novel and nonobvious combinations and subcombinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.
