US20100240449A1

US20100240449A1 - System and method for controlling usage of executable code

Info

Publication number: US20100240449A1
Application number: US12/407,261
Authority: US
Inventors: Guy Corem; Ori Hanegby; Orr Kowarsky
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-03-19
Filing date: 2009-03-19
Publication date: 2010-09-23

Abstract

Embodiments of the invention are directed to systems and methods for protecting and/or controlling usage of executable code. A method may include periodically producing morphed or otherwise modified executable code related to an application and providing such morphed code to clients. A method may include generating log data and providing log data to a referee unit. The referee unit may determine an outcome of an execution of an application related to the morphed code based on the log data.

Description

BACKGROUND OF THE INVENTION

Computer games and specifically online gaming industries are boosted by the development of the computing and networking industries. Modern gaming consumers expect to be able to participate in a variety of games that may require sophisticated infrastructures. For example, an online game may require an independent referee to determine the winner of a game, session or round. A typical solution involves a referee server. Such server may need to be actively involved in a game. For example, a gaming server may execute the game application and the players interact with each other via the server. Such solution has a number of drawbacks, e.g., scalability and network capacity limitations. Another drawback of such solution is that it does not enable true or pure peer-to-peer (P2P) gaming.
P2P gaming is an example of online gaming where one or more players play or compete, usually using their own home computers. In P2P gaming, computing devices interact with each other directly and not through or via a server. The problem of P2P gaming is that it does not provide a solution for an independent entity to provide a ruling for disputes or determine a settlement, e.g., referee function.
Robots, also known in the art as bots, are another problem of the gaming industry, one possibly shared with other industries. A bot may generally be described as a software program that imitates the behavior of a human, for example, controlling an interactive application. Bots may exist for any interactive application, e.g., a chat application, an email application or a gaming application. Sophisticated bots may be used to imitate a player. A bot programmer may examine a game software or application, possibly perform “reverse engineering” of the game application and based on information thus obtained, configure or otherwise enable a bot to “play” instead of a human player. Obviously, bots may be faster and/or otherwise more capable players than ordinary humans, accordingly, using a bot is considered cheating. Bots are considered a serious threat and a problem by the gaming industry and community. Solutions for the referee function and the bots problem are urgently needed.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanied drawings. Embodiments of the invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like reference numerals indicate corresponding, analogous or similar elements, and in which:

FIG. 1 shows an exemplary system for gaming according to some embodiments of the present invention;

FIG. 2 shows control relations of exemplary components of a system according to some embodiments of the present invention;

FIG. 3 is a flowchart diagram illustrating an exemplary method according to some embodiments of the present invention;

FIG. 4 is a flowchart diagram illustrating an exemplary method according to some embodiments of the present invention; and

FIGS. 5A and 5B show exemplary code segments according to some embodiments of the present invention.

It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, modules, units and/or circuits have not been described in detail so as not to obscure the invention.
Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, “processing,” “computing,” “calculating,” “determining,” “establishing”, “analyzing”, “checking”, or the like, may refer to operation(s) and/or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulate and/or transform data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information storage medium that may store instructions to perform operations and/or processes.
Although embodiments of the invention are not limited in this regard, the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more”. The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like.
Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed at the same point in time or overlapping points in time. As known in the art, an execution of an executable code segment such as a function, task, sub-task or program may be referred to as execution of the function, program or other component.
Embodiments of the invention may be applicable to any application, program, executable code or parts thereof that may be distributed to a number of clients. In particular, interactive computer applications may greatly benefit from embodiments of the invention. For example, internet relay chat (IRC) applications, mail applications, gaming applications, instant messaging applications, VoIP applications or any application related to human interaction may all benefit from embodiments of the invention.
For the sake of clarity and simplicity, gaming application will be referred to herein, however, it should be noted that the scope of the invention is not limited by the nature, type or other aspects of the application, program or executable code that is generated, distributed, controlled, managed and/or otherwise maintained as described herein.
Reference is made to FIG. 1 that shows an exemplary system 100 for gaming according to some embodiments of the present invention. Code repository 110 may be any suitable storage device or system that may store source code of a gaming application. Code morphing unit 115 may be any applicable device or system for morphing source code as described herein. Morphed code repository 120 may be similar to code repository 110 and may be used for storing morphed source code. Building and testing unit 125 may build a gaming application based on morphed code retrieved from morphed code repository 120 or from code repository 110. For example, unit 125 may compile and link source code retrieve from repositories 110 or 120 and thus produce an application or executable code, also referred to as binary code in the art. Executable code (or binaries) may be stored in binaries repository 130. One or more versions of the same game, application or parts thereof may be stored in binaries repository 130. For example, as described herein, source code of a specific game may be morphed periodically or according to various other criteria. Accordingly, a number of executable or binaries versions of the same game may exist simultaneously, such number of versions may be stored in repository 130.
Distribution unit 135 may distribute binaries from repository 130. For example, game clients 150 and 155 may be provided with binaries needed for participating in an online and/or P2P game by distribution unit 135. Game clients 150 and 155 may be any suitable or applicable computing device. For example, game clients 150 and 155 may be a personal computer, a desktop computer, a mobile computer, a laptop computer, a notebook computer, a terminal, a workstation, a server computer, a Personal Digital Assistant (PDA) device, a tablet computer, a mobile phone, or any other suitable computing device. It will be recognized that although for the sake of simplicity and clarity only two game clients are shown, a large number of such clients is possible, and is typically comprised, in system 100. It will further be recognized that system 100 is scalable. Any suitable number of code morphing units, building and testing units, distribution units, referee units and management units described herein may be deployed to enable any number of game clients to benefit from embodiments of the invention. Any method, scheme, logic or other distribution aspects may be implemented or otherwise realized by distribution units such as distribution unit 135. In some embodiments, distribution unit 135 may be “passive”, e.g., clients may “pull” the right binary from distribution unit 135 upon receiving an instruction, e.g., from management unit 145. In other embodiments distribution unit 135 may “push” updates to clients, referee unit 140 or any other relevant component, e.g., units included in system 100, such “push” may be controlled by management unit 145.
As shown by block 140, system 100 may include referee unit 140. As described herein, referee unit may supervise a game in which clients 150 and 155 participate. Referee unit may determine a winner or other aspects of such game as described herein. Management unit 145 may be involved in, tasks such as, but not limited to, coordination, scheduling, arbitration, supervising, operation and/or management of any unit or part of system 100.
Network 170 may be, may comprise or may be part of a private IP network, the internet, an integrated services digital network (ISDN), frame relay connections, modem connected to a phone line, a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a wireline or wireless network, a local, regional, or global communication network, an enterprise intranet, any combination of the preceding and/or any other suitable communication means. Network 170 may enable any components, units or applicable parts of system 100 to communicate. It will be recognized that embodiments of the invention are not limited by the nature of network 170. Network 170 may comprise any suitable networking systems or devices, e.g., relays, routers, gateways etc.
It will be recognized that units 115, 125, 135, 140 and 145 may be or may comprise any suitable components, devices, systems or sub-systems. For example, these units may be implemented by hardware, software, firmware or any combination thereof. For example, while building and testing unit 125 may be an ordinary, possibly off-the-shelf computing device, distribution unit 135, referee unit 140 and/or management unit 145 may be dedicated hardware and/or firmware. As known in the art, dedicated, possibly firmware operated devices are hard or impossible to login to and accordingly are used for implementing sensitive tasks. Accordingly, some units of system 100 described herein may be implemented by dedicated, specific hardware.
It will further be noted that distribution of units and/or functionality of system 100 may vary without departing from the scope of the invention. For example, code repository 110 and morphed code repository 120 may be combined into a single repository or they may be broken into any suitable number of repositories. Likewise, a number of units may be combined into a single device. For example, code morphing unit 115, building and testing unit 125 and distribution unit 135 may all be incorporated into a single computing device or referee unit 140 and management unit 145 may similarly be combined. Yet another possible configuration may combine units 115, 125, 135, 140 and 145 into a single device or system that may be connected to a single repository that combines repositories 110 and 120. For example, a hardware server connected to a storage device may implement units and repositories described above. Such server and storage device may be commercial products or they may be custom made or dedicated, specifically manufactured hardware, software and/or firmware.
According to one embodiment of the invention, logs may be created and used for determining an outcome of a game, a round or session of a game or the logs may be used to otherwise provide a ruling related to a game. For example, binary code produced by building and testing unit 125 may be configured to produce log data when executed. Such log data may include data, information, parameters, indications, settings, configuration, context, or any relevant aspects of a game being played. For example, log messages or packets may comprise a timestamp that may be related to the time an action was performed by a player, the time the packet was sent or any applicable point in time.
A log message or packet may include various parameters. For example, identification parameters such as a binary, possibly unique, identification code, where the binary may be related to a morphed or un-morphed code version related to a gaming application. Another, possibly unique, identification parameter may be the current game or session. For example, a specific execution of a binary code. Identification parameters may be “hard coded”, e.g., compiled into a binary code or they may be dynamically configured or provided. For example, identification parameters related to a game session may be provided by management unit 145 while binary identification parameters may be part of the binary itself.
Binary identification codes or parameters may be compiled into the executable code of a game application and may be attached to each log packet. According to some embodiments of the invention, information communicated by and/or between various components of system 100 may be encrypted, encoded, morphed, obfuscated, scrambled or otherwise concealed. For example, log messages produced by a gaming application as described herein may be encrypted or morphed. Accordingly, in order to perform functionalities described herein, referee unit 140 may need to decrypt log messages. Encryption of log messages may be according to specific parameters that may be compiled into a respective specific binary version and may accordingly vary from one binary to another. In order to enable referee unit 140 to decrypt, decipher or otherwise convert encrypted log messages to usable form, referee unit 140 may be need to be provided with decryption parameters for each binary version from which it receives log messages. In some embodiments, referee unit 140 may be provided with a specific set of decryption parameters related to a specific binary identification code and may further store such parameters and binary identification code. Accordingly, upon receiving a log message, referee unit 140 may extract the attached binary identification code, use it to locate the correct decryption parameters and use the decryption parameters to decrypt the log data. Decryption parameters described herein may be provided to referee unit 140 by management unit 145, for example, upon generation of a new binary version as described herein.
Another parameter in a log packet may be a client unique identification code or number. For example, clients may obtain such code in a number of ways as known in the art, e.g., a cookie from management server 145, a code provided from a web site etc. Attaching a game client identification code to log packets may enable identifying clients and further keeping scores over long periods of time and/or over a series of games. Alternatively, identifying clients may enable blacklisting clients as further described herein.
Binary or executable code thus produced may further include code verification functionalities. For example, prior to commencing a game involving game clients 150 and 155 code executed on client 150 may verify that code executed on client 155 is compatible and/or suitable for playing the selected game. For example, building and testing unit 125 may embed a version number in the code used for the game, accordingly, code on a first game client may only engage in a game with a client that is executing the same version. Such verification may be mandatory for referee unit 140 in performing its task since ascertaining such compatibility may guarantee that logs produced adhere to the same format and may be deciphered under common constraints, criteria and/or context.
In some embodiments, verifying versions may be performed with relation to a management entity. For example, upon game start, management unit 145 may verify that each client code is current, e.g., is the latest morphed code version, by examining the related verification code, e.g., the binary identification code. If a game client is executing an obsolete or otherwise unsuitable version, management unit 145 may force such client to update its version. If a client is being controlled by a malicious entity, e.g., a bot, that prevents such updating of the client code, for example, by reporting a faked new game code version or faked binary identification code, this client may be prevented from participating in the game, since encrypted packets received from such client may be considered mal-formed enabling management unit 145 to determine such client is unsuitable for participating in a game. Moreover, referee unit 140 may fail to decipher log packets received from such client and may report such failure to management unit 145 that may take appropriate action.
For example, while clients 150 and 155 are engaged in a game they may produce log data that may be collected by referee unit 140. Alternatively, log servers (not shown) may be utilized for collecting log data, accordingly, referee unit 140 may retrieve logs from such log servers. Logs produced by game clients may be examined or processed in real-time or they may be processed in offline mode. In offline mode clients may send log packets periodically, e.g., instead of sending a log packet upon detecting an event related to a game being played (e.g., a mouse being moved or clicked or a keyboard key being pressed) log data may be aggregated in the clients and sent according to a predefined time interval or when a predefined amount of data has been collected. Log servers may store log data in non real-time, such stored log data may be provided to referee unit 140 with any acceptable delay.
Obviously, ruling produced, e.g., by referee unit 140, based on such non real-time information may be provided to clients some time after a game is finished or an event requiring a ruling has occurred. However, non real-time examination of log data as described herein has its benefits, for example, it may require lower network capacity and modest computing resources. In some cases or scenarios, delayed or non real-time logging and ruling may be acceptable and used by embodiments of the invention.
In real-time mode, log data may be provided to referee unit 140 in real-time by game clients participating in a game. Accordingly, referee unit 140 may examine or process log data in real-time and provide ruling in real-time, i.e., substantially upon detection of an event.
Game clients involved in a game may choose or elect to be provided with a service of a referee or they may agree to determine an outcome of the game by themselves. If the participating gamers elect to use a referee service then upon termination of a game or when an event requiring a ruling is detected game clients may report such event to management unit 145. Such reporting may be accompanied by game client identification code, game identification code, and/or game binary identification code described herein. Management unit 145 may cause referee unit to examine the relevant log files and provide a required ruling. Exemplary events that may require a ruling may be a termination of a game, session or round, a client disconnecting from the network, a client aborting a game session etc.
Examination or analysis of log data may be performed in various ways or depths For example, in one embodiment referee unit 140 may examine metadata such as timestamps attached to log packets as described herein. Such “shallow” analysis may enable referee unit 140 to deduce various aspects related to a game without performing in depth or “deep” analysis. For example, by examining various headers or metadata referee unit 140 may reconstruct a timeline or progress of a game and determine, for example, if a game client aborted the game, was disconnected from the network etc. Such “shallow” examination or analysis may have the benefit of being fast, possibly real-time. Additionally, such shallow analysis may be performed with very limited knowledge of the actual game being played, e.g., the game rules, constraints etc. However, it may be impossible to reconstruct the game in its entirety utilizing such method.
According to other embodiments, an in depth analysis may be performed. In some embodiments referee unit 140 may be provided with any information required in order to actually reconstruct a game session played by game clients. Other than the log data described herein, referee unit 140 may be provided with any rules, limitations, data, information, parameters, indications, thresholds, criteria, settings, configuration, context, or any other aspects related to the game. Equipped with all required information and the log data from clients, referee unit 140 may reconstruct or accurately simulate a game session. Based on such simulation or reconstruction referee unit 140 may determine an outcome or derive a ruling related to the game played. Referee unit 140 may be provided with information as described herein by distribution unit 135. For example, when a new version is being distributed to game clients, e.g., clients 150 and 155, referee unit 140 may also be updated with related software, identification codes, deciphering parameters, rules, criteria or other relevant parameters or information so that true and accurate simulation of a game may be performed.
Referee unit 140 may store any number of rules related to any number of respective game versions. Accordingly, upon being required to examine log files or simulate a game referee unit 140 may extract the game version from the log data and locate the correct stored parameters according to the game version. It will be noted that examination of log data by unit 140 may be controlled by management unit 145. For example, as described herein, players may be allowed, e.g., by management unit 145, to declare a winner or reach other rulings by themselves. Accordingly, game clients may inform the management unit 145 of such declaration or decision. In such case, possibly based on a configured policy, management unit 145 may refrain from commanding referee unit 140 to examine log data produced by the client. In some embodiments, possibly based on a configured policy implemented by management unit 145, if clients so choose, log data may not be produced while the game is played, this can have the benefit of easing the processing demands on the client computing devices, for example by reducing client network related activity. Obviously, a referee unit described herein may benefit from such configuration.
It will be recognized that the functionality of referee unit 140 as described herein may be detached from the discussion related to code morphing. Referee unit 140 may perform tasks described herein for either morphed or un-morphed logs and binaries or scenarios.
One of the objectives of embodiments of the invention is to defeat or overcome bots. For example, bots used by gamers in order to win online or P2P games. Antivirus like techniques (e.g., heuristics and/or binaries signatures) used in the art today may detect a bot according to various reactive techniques. In contrast, embodiments of the invention may defeat bots or other human replacement or cheating software in a proactive way. In the context of gaming, developers of bots operate by gaining knowledge of the inner workings of a game software and then using such knowledge to program or configure a bot to imitate a human player, e.g., by controlling input to the game software. For example, a bot may be configured to modify game data or code, or to interact with a gaming application based on documented or undocumented interfaces in a manner which may exceed human capabilities. For example, after analyzing the game data structures, a programmer can write an aiming bot that collects data related to an opponent's position or location and helps a player to accurately aim his weapons, e.g., automatically modifying the player cross position as known in the art.
Gaining knowledge may comprise “reverse engineering” of a game software. Embodiments of the invention may prevent bots from operating by at least two measures. The first being obfuscating, hiding and/or obscuring the logic or other aspects of the game software by code morphing, the second being by periodically replacing the morphed executable code of a game. For example, a differently morphed binary code (executable code) may be loaded onto game clients every 20 minutes, or at any time after a predefined period of time has elapsed and no game is in progress. Any applicable criteria may be used in order to decide to replace executable binaries on game client machines. For example, detecting a serial winner may cause management unit 145 to instruct distribution unit 135 to download a new version to client computing devices.
While each morphed binary version is produced from a different morphed source code the logic of the binaries may remain unchanged. Morphing may comprise various alteration, additions or other changes to the source code without affecting the logic or functionality of an application. While the binary file may change from one version to the next, a human using the code for playing a game may not feel the difference as the functionality of the code may remain unchanged or unaffected. While a human may not be affected by changes made to code through morphing, a bot may be highly sensitive to such changes. Such sensitivity may be due to a number of reasons.
Reference is made to FIG. 2 that shows control relations of some components of system 100. Controls or interactions described herein may be realized through computer communication facilities, e.g., using user datagram protocol (UDP) or transmission control protocol (TCP) connections over network 170. As shown by arrow 216, management unit 145 may control code morphing unit 115. Morphing of code may be according to various aspects, rules and or any applicable configuration parameters. For example, increased complexity of the morphed code may better protect the resulting executable code but may also increase the executable code size and/or may cause such executable code to run slower or require extended resources (e.g., computational resources) when executed, morphing may be applied only to specific files or specific sections of specific files, e.g., header files, parts thereof etc. Accordingly, management unit 145 may instruct or configure code morphing unit 115 to produce various versions according to various needs. For example, according to instructions or control from management unit 145 code morphing unit 115 may generate a heavily or highly morphed version by applying extensive morphing techniques, executable code generated from such version may be distributed to specific clients as described herein. However, situations, scenarios, context or other aspects related to online gaming requiring client machines to interact may further require such clients to execute compatible morphed binary versions. Client machines executing incompatible versions may be, for example, unable to communicate over a network because their respective morphed or encrypted network packets may differ as a result of their respective, different morphed version of their respective morphed binaries. Management unit 145 may also determine a time for generating and/or distributing of a new morphed binary version, e.g., periodically, upon a predefined or configured time period has elapsed. Another exemplary event that may cause management unit 145 to instruct a generation and/or distribution of a new morphed binary version may be a release of a new un-morphed version of an application. For example, a new gaming application or upgrade has been released by a producer of such application. Any other aspects of morphing by code morphing unit 115 may be similarly controlled by management unit 145.
As shown by arrow 226, management unit 145 may control building and testing unit 125. Building and testing unit 125 may inform management unit 145 upon detecting events such as in cases where a building or testing of a new version fails, management unit 145 may then initiate a generation of a new version, possibly by instructing code morphing unit to produce a new morphed source code version, or management unit 145 may take other suitable actions, e.g., revert back to a previously successfully morphed version of the source code.
As shown by arrow 236, management unit 145 may control distribution unit 135. For example, management unit 145 may instruct distribution unit 135 to select, and use for distribution, a specific version of executable code in binaries repository 130. Management unit 145 may maintain various tables, lists or other structures related to various aspects of an applications. For example, a blacklist of suspected players may be kept. Such list may indicate players who violate various rules. For example, clients who are suspected in operating a bot, clients who often abort a game, e.g., when odds are against them etc. Accordingly, management unit 145 may take any appropriate action or apply sanctions based on such blacklist.
As shown by arrows 256 and 251, management unit 145 may interact with, or control game clients 155 and 150. For example, an agent software module may be compiled into a gaming application. When the game application is invoked on a client machine, such agent may interact with management unit 145 thus enabling management unit 145 to control the game application executed on a client machine. Accordingly, any logic, functionality or task performed or executed by a client computing device or machine, e.g., game client 155, as described herein may be attributed to an agent software module described herein. For example, management unit 145 may interact with an agent module that may be part of an application, e.g., a gaming application, executed on game clients 150 and 155. For example, upon invoking a gaming application on game client 150, the agent module may prevent the application from enabling a user to play if the client has not been identified and/or authenticated, the game binary identification code has been examined, software versions were verified and, if need be, updated etc. Updating a blacklist as described herein may be performed based on parameters, data or any relevant information received from a client machine as described herein. Any aspects of executing an application may be similarly controlled by management unit 145 or other components, e.g., units described with reference to system 100. Furthermore, an agent described herein may provide management unit 145 with various reports or indications. For example, such agent may report a client has aborted the game, or detect and report that the speed with which a game is being controlled is above a predefined threshold, possibly indicating the game is being controlled by a bot.
An agent module described herein may inform management unit 145 of an outcome of an execution of an application. For example, an outcome, result or winner of a P2P game. Management unit 145 may compare reports from two or more such agents related to two or more respective gamers and determine the result based on such reports or it may cause referee unit 140 to determine the outcome as described herein, for example, in cases where reports of an outcome described herein differ. In other embodiments, management unit 145 may cause referee unit 140 to determine the outcome regardless of reports described herein. It should be noted the management unit 145 may designate and/or command any suitable component, e.g., one of the units included in system 100 to act as a referee, for example in order to assist or replace referee unit 140, for example by load balancing referee functionality between referee unit 140 and other units or components. In some embodiments, a third party client machine may be configured by management unit 145 to act, possibly temporarily, as a referee.
As shown by arrow 241, management unit 145 may control referee unit 140. For example, management unit 145 may provide referee unit 140 with various criteria, thresholds or other parameters that may be used for reaching a ruling related to an application, e.g., a game played. For example, management unit 145 may provide referee unit 140 with a list of client machines that are not to be subjected to ruling etc.
Reference is made to FIG. 3 showing a flowchart diagram illustrating an exemplary method according to some embodiments of the present invention. As shown by block 310, the method may include detecting an event that indicates that a new version may be required. For example, a predefined time period has elapsed since the last version was generated. Other events may be detecting a player suspected of operating a bot or otherwise cheating or a release of a new version of an original, un-morphed code. Any applicable event, condition, context or configuration parameters may cause, for example, management unit 145 to determine a new version is required.
As shown by block 315, the method may include morphing source code. Any morphing method or technique known in the art may be used by embodiments of the invention without departing from the scope of the invention. For example, constants or variables may be randomly relocated, a representation of variables in memory may be randomly changed, external functions or procedures may be randomly converted to inline functions, code segments may be converted to macros, possibly defined in header files, redundant instructions (e.g., no instructions as known in the art) may be added as well as redundant variables, class data members may be reordered, instructions order may be changed (without changing related software logic) etc.
Reference is additionally made to FIGS. 5A and 5B that show exemplary code segments according to some embodiments of the present invention. FIG. 5A shows an incomplete template source code segment (from a header file). The code shown in FIG. 5A may be processed by code morphing unit 115, e.g., by executing a morphing preprocessor. FIG. 5B shows the resulting morphed code that may be the output of morphing the code shown in FIG. 5A. As would be obvious to a person of ordinary skill in the art, embodiments of the invention may perform morphing that is far more complicated than randomly adding and subtracting a constant such as 163 as exemplified by FIGS. 5A and 5B.
According to some embodiments of the invention, any applicable code may be morphed. For example, not only a specific application, e.g., a gaming software may be morphed but also parts of an operating system or platform, device drivers, protocol stacks, kernel modules, dynamic or other libraries etc. For example, as known in the art, cross platform compatibility may be achieved by employing virtual machine (VM) technology, e.g., Java® virtual machine (JVM). For example, a VM and a related VM compiler may be morphed together. A build server, e.g., building and testing unit 125, may invoke the morphed VM compiler in order to compile the parts of an application, e.g., a gaming application, that are written in the VM language source code, (for example, Java, LUA scripts, etc) into a morphed byte code. Such byte code may only be executed by the specific morphed VM, where such VM may have been morphed in association with a specific VM compiler. The morphed VM and related morphed byte code may then be distributed to client machines.
Embodiments of the invention may produce morphed versions of such virtual machine, distribute such versions and force clients to use such VM versions. For example, code morphing unit 115 may produce a morphed source code version of a VM and VM compiler, building and testing unit 125 may build and test resulting morphed VM and related morphed byte code, distribution unit 135 may provide clients with such morphed VM and related morphed byte code, e.g., as part of a gaming application, and an agent embedded in a gaming application as described herein may verify that a client is using such distributed morphed VM and related morphed byte code. In some embodiments of the invention, morphing of a VM as described herein may be correlated with a morphing of an application such that only compatible application may execute on a specific VM morphed version. For example, a specific gaming application morphed version may only properly run or execute on or in relation to a predefined compatible morphed version of a VM, accordingly, such gaming application may crash if executed on or in relation to any other, non compatible VM versions.
In order to enhance protection from bots or other malicious software, network related code may be morphed as shown by block 315. For example, code implementing logic related to network packets generation, reception, processing, sending, receiving format and structure may be morphed. According to some embodiments of the invention, network packets generated by an application may contain morphed information, accordingly, only entities provided with information required in order to decipher (or un-morph) the content of such network packets may be able to use them. For example, while based on information provided by code morphing unit 1I 5, units of system 100 may be able to decipher content in network packets exchanged between them, e.g., between game client 155 and management unit 145, a bot or other software unauthorized to view the content of network packets generated by an application protected by embodiments of the invention may be prevented from using information in such packets.
As shown by block 320, the method may include building and testing a new version. For example, building and testing unit 125 may compile, link and run a new version produced from morphed source code possibly, but not necessarily, provided by code morphing unit 115. As described herein, any executable or other code or binary may be built and tested as shown by block 320, e.g., an application, a virtual machine, a virtual machine compiler or scripts. Typically but not necessarily, when a number of components are being generated a regression test may be performed to verify all newly generated components function correctly. As shown by block 325, the method may include distributing a new version to client computing devices or machines, for example, as described herein. As shown by block 330, the method may include executing the new version by client computing devices.
Reference is made to FIG. 4 showing a flowchart diagram illustrating an exemplary method according to some embodiments of the present invention. As shown by block 410, the method may include invoking an application on a client machine For example, a gaming application may be invoked on game client 150. As shown by block 415, the method may include verifying configuration and parameters. For example, an agent described herein may interact with management unit 145, distribution unit 135 or any other relevant entity and verify that software and/or other components installed on the client machine are suitable and accordingly the application may be executed. Verification may include verifying that a related client is executing compatible software. For example, an agent described herein executing or running on game client 150 may interact with a similar agent on game client 155. Such interaction may include comparing relevant versions and/or any applicable configuration or other parameters. Alternatively or additionally, agents may interact with a management entity, e.g., management unit 145 in order to perform versions checks or other verifications. For example, such interaction may reveal that game clients 150 and 155 do not have the same or otherwise compatible software versions or it may reveal that game client machine 155 has a hardware component installed that is unsuitable or unacceptable for a game that is about to be played.
As shown by block 420, the method may include determining if an update is required. Such required update may relate to an application, e.g., a game or it may relate to other aspects, e.g., a VM, device driver, kernel modules, dynamic or other libraries etc. As shown by block 425, if an update is required, the method may include updating the client machine, for example by downloading software from distribution unit 135. As shown by block 430, the method may include executing an application on the client machine, for example, a P2P gaming application. As shown by block 435, the method may include generating and providing reports.
Reports, log data, alerts, warnings or other indications may be generated in real-time, batch mode or even in offline mode. As is obvious, real time reporting, e.g., sending log data related to a progress of the game may consume computational resources of client machines as well as network bandwidth. Accordingly, reporting as show by block 435 may be configurable based on various parameters. For example, if network capacity is not an issue, computing power of the client machines is sufficient and one or more idle referee units are available then clients may be configured to produce real-time logging information and indications. Another criterion forcing a client to provide real-time log data to a referee unit may be detecting a suspected client, e.g., one suspected of operating a bot. Such client, which may be a human identified by a password, a peer, computing device or other client machine, identified by various means, e.g., a media access number (MAC) address. A suspected client may be forced or required (e.g., by an agent described herein) to provide real-time log data to a referee unit. Any applicable parameters, scenarios, context or other aspects may be used for determining the logging scheme to be in effect, for example, management unit 145 may configure clients reporting and logging according to considerations described above.
As shown by block 440, the method may include providing a ruling. For example, based on log data and reports provided as shown by block 435, referee unit 140 may determine an outcome of a game, e.g., determine the winner in a game, a score related to a game or any other applicable ruling related to a game. It will be noted that providing a ruling as shown by block 440 may be applicable to any applicable application. As shown by block 445, the method may include determining if the application is to rim again, e.g., another game session is to be played, if so, as shown by the arrow connecting blocks 445 and 415 the method may repeat some sections described above, otherwise, the method may terminate as shown by block 450. Termination may comprise any logging or reporting, e.g., a final, conclusive report may be sent to a management unit, memory may be freed etc.
Embodiments of the invention may include an article such as a computer or processor readable medium, or a computer or processor storage medium, such as for example a memory, a disk drive, or a USB flash memory, encoding, including or storing instructions, e.g., computer-executable instructions, which when executed by a processor or controller, carry out methods disclosed herein.
It will be understood that the method of the present invention is intended to be performed on one or more computing devices, and that the method is intended to produce actual results, for example, periodic distribution of morphed code, verification of compatibility, determination of a ruling, etc.
While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.

Claims

1. A system for controlling a usage of executable software code, the system comprising:

a code morphing unit to periodically produce a morphed executable code related to a peer to peer (P2P) game;

a code distribution unit to receive said morphed executable code from said code morphing unit and to distribute said morphed executable code to at least first and second computing devices, said first and second computing devices being configured to receive said morphed executable code from said code distribution unit, and engage in a P2P game by executing said morphed executable code.

2. The system of claim 1, comprising a management unit to verify compatibility of said morphed executable code and prevent said first and second computing devices from engaging in said P2P game if compatibility is not determined.

3. The system of claim 1, wherein said code distribution unit is to periodically distribute a plurality of versions of said morphed executable code do at least said first and second computing devices.

4. The system of claim 1, wherein if said game comprises two or more sessions, then after terminating a first session and before commencing a second session, subsequent to said first session, said first and second computing devices are required to execute a new morphed executable code, different from executable code used in said first session.

5. The system of claim 1, wherein said code morphing unit is to produce said morphed executable code by generating a morphed source code and compiling said morphed source code to produce a morphed binary executable code.

6. The system of claim 1, comprising a referee unit, wherein said first and second computing devices are configured to provide said referee unit with log data related to said game, and wherein said referee unit is configured to determine a ruling related to said game based at least in part on said log data.

7. The system of claim 6, wherein said code distribution unit is to update said referee unit with a parameter of said morphed executable code upon distributing said morphed executable code, and wherein said referee unit is configured to determine said ruling based at least in part on said parameter of said morphed executable code.

8. The system of claim 6, wherein said first and second computing devices are configured to provide said log data to said referee unit in real-time.

9. The system of claim 6, wherein said referee unit is configured to determine said ruling in real-time.

10. The system of claim 1, wherein said morphed executable code comprises a virtule machine (VM) and a morphed byte code and wherein said morphed byte code is generated by:

morphing a compiler thus producing a morphed compiler,

generating a morphed VM related to said morphed compiler, and

producing said morphed byte code based on said morphed compiler and said morphed VM.

11. The system of claim 1, wherein said code morphing unit is to produce said morphed executable code by performing at least one of obscuring data variables, adding redundant instructions, adding redundant variables, changing an order of two or more class data members, changing instructions orders, changing a footprint related to a morphed executable code, and replacing instructions with macros.

12. A method of controlling a usage of an executable code, the method comprising:

periodically producing a morphed executable code related to a peer to peer (P2P) game;

distributing said morphed executable code to at least a first and second computing devices; and

engaging in a P2P game by executing said morphed executable code by said at least first and second computing devices.

13. The method of claim 12, comprising verifying compatibility of said morphed executable code and preventing said at least first and second computing devices from engaging in said P2P game if compatibility is not determined.

14. The method of claim 12, wherein said first and second computing devices periodically receive versions of said morphed executable code.

15. The method of claim 12, wherein if said game comprises two or more sessions, then after terminating a first session and before conferencing a second session, subsequent to said first session, forcing said first and second computing devices to execute a new morphed executable code, different from executable code used in said first session.

16. The method of claim 12, wherein said morphed executable code is produced by generating a morphed source code and compiling said morphed source code to produce a morphed binary executable code, and wherein generating a morphed source code is by at least one of: obfuscating data variables, adding redundant instructions, adding redundant variables, changing an order of two or more class data members, changing instructions orders, changing a footprint related to a morphed executable code and replacing instructions with macros.

17. The method of claim 12, comprising determining a ruling related to said game by a referee unit, said determining being based at least in part on log data received from said at least first and second computing devices.

18. The method of claim 17, wherein said log data is provided by said at least first and second computing devices in real-time.

19. The method of claim 17, wherein determining said ruling is performed in real-time.

20. The method of claim 12, comprising:

producing a morphed byte code to be executed with relation to a morphed virtual machine (VM) by:

morphing a compiler thus producing a morphed compiler,

generating said morphed VM, said VM related to said morphed compiler, and