Systems and methods for identifying modified program data

Abstract

To partly improve conventional approaches by using attestation programs that employ "code reuse" techniques.SOLUTION: The invention relates to auto-generating attestation programs for, among various aspects, detecting whether a program has been modified. In one non-limiting example, the technology uses a tool that scans a software program (e.g., a video game) code for usable code sequences. The tool can automatically combine code sequences to generate a large number of attestation programs of different varieties (e.g., memory checks, hashing).SELECTED DRAWING: None

Description

[Technical Field]

[0001] For decades, video game systems have allowed players to participate in a variety of different game environments. Games are designed to present players with a finite set of parameters, boundaries, and rules for playing the game. For example, a video game may allow a player to "level up" a certain amount, or the player may be "restricted" to certain movements within the game environment (e.g., walking through walls). Some players may modify game programs and / or game metadata in ways not intended by the original designer(s) of the game. For example, a player may modify software in a game to allow a game character to level up more quickly or to walk through walls. Therefore, there are several drawbacks to designing a video game environment to reduce or limit such modifications.

[0002] Copyright Notice A portion of the disclosure of this patent document contains material that is subject to copyright protection. As this patent document or this patent disclosure is on file or record with the Patent and Trademark Office, the copyright owner has no objection to the facsimile reproduction thereof, but reserves all copyrights whatsoever. Summary of the Invention [Problem to be solved by the invention]

[0003] Software programs may restrict users from performing certain actions (or accessing certain features) for a variety of reasons. For example, a business software product (e.g., a word processing application) may restrict a user from certain functions (e.g., printing or editing a document) until the user agrees to purchase such feature. Similarly, video game technology may restrict a user from both unlocking certain features (or DLC) as well as performing various actions (i.e., "cheating") in the game environment.

[0004] Cheating in video games has been prevalent since the dawn of gaming. Decades ago, users could press certain buttons in a specific order in certain games to unlock features, such as the player's amount of "lives." Video game cheats have evolved significantly over the years, to the point where users can modify software and / or metadata to gain an unfair advantage.

[0005] Such cheating becomes increasingly prevalent when the gaming environment expands to multiplayer games, especially multiplayer games over the Internet. In particular, users can modify software to allow them to gain advantages over other players on different systems in multiplayer games. These unfair advantages make the game less satisfying for users, thereby negatively impacting the overall human-user experience and interaction in the game. Furthermore, such modifications to game programs create particular security risks to game systems.

[0006] Some prior art techniques exist for detecting when a user may have modified a particular software program. For example, one prior attestation architecture exists for using an attestation program to detect whether software has been modified. This system employs a client-server architecture in which an attestation program is selected from a server and sent to a client device. The client runs the attestation program and returns the attestation result to the server. The server compares the result with the expected result, and if a discrepancy is detected, the client is flagged as "compromised." System administrator(s) can decide what type of action to take against the "compromising" client (e.g., ban the user, send a warning, or take no action).

[0007] As a more specific, non-limiting example, the server may use hashing techniques to detect "mismatches" in the data. It should be understood that certain program data may be run through a proof program to generate a hash result that outputs a known (e.g., fixed-length) value. The hash result can be obtained by the server and verified against the known value to determine whether a "mismatch" has occurred. If the result produces a "mismatch," the server identifies the program as having been altered, and the client system is marked as "compromised."

[0008] This conventional approach is advantageous because it allows the game system to determine whether different users have modified the software, allowing system administrator(s) to take appropriate action. However, this conventional approach has several drawbacks. For example, in the conventional approach, a user could compromise the hash function (or proof logic) in the game, which would require the developer to create a patch and distribute it to all client devices running the game program. Furthermore, the conventional approach requires cooperation from the client-side device to run the proof logic on the client, and therefore true detection of "cheats" cannot be performed "remotely" on the server-side (or remote) system. [Means for solving the problem]

[0009] Thus, the techniques described herein improve upon conventional approaches in part by using proven programs that employ "code reuse" techniques. As a non-limiting example, certain return-oriented programming ("ROP") or jump-oriented programming ("JOP") techniques can be used by an "attacker" to bypass security defenses by selecting specific sequences of instructions already present in system memory to execute the instructions in an intended order to achieve functionality that may not have originally been present in the software.

[0010] The techniques described herein can use ROP / JOP techniques to automatically construct proof programs from code sequences that already exist in a game. As an example, a typical game may have thousands of possible code sequences. By themselves, these sequences do not necessarily relate to a particular proof program / technique. However, these code sequences can be combined and chained together to perform novel functions (e.g., memory checks, hashing operations).

[0011] The proof result computed by each proof program depends on the code sequence used. Because a typical game has thousands of possible code sequences, the result cannot be easily predicted or forged. The logic described herein does not necessarily rely on secrets (e.g., keys, algorithms) and can function even when the system is fully compromised.

[0012] Thus, the technique can rely on a large number of possible combinations, each of which may produce a different result. It should be understood that the complexity of the proof logic can be scaled up depending on the particular conditions (e.g., by using different code sequences or more chained code sequences). Updating the logic in this manner advantageously avoids the need to release patches for the software program.

[0013] Thus, the technology described herein relates, among various other aspects, to automatically generating proof programs for detecting whether a program has been altered. As one non-limiting example, the technology uses a tool that scans the code of a software program (e.g., a video game) for usable code sequences. The tool automatically combines the code sequences to generate many different proof programs (e.g., memory checking, hashing).

[0014] Each selected code sequence in the proof logic may perform a specific operation (e.g., load from memory, perform a mathematical operation, or invoke a hash function). The final proof result may be based on both the value at the test location in software memory and the operation performed by each code sequence. For example, code sequence N may transform a value read from memory using constant multiplication or constant addition. If the server may maintain a database(s) of expected "good" results for each proof program, each program can generate a unique "good" result. A "proof check" can be performed by the server based on the program running on a particular client to determine whether the client may have modified the program.

[0015] To forge proof results, an attacker must analyze the program, extract code sequences and the order associated with the code sequences, and analyze what each code sequence does. Typically, a typical software program has many possible code sequences, making it very difficult to do so in real time. Therefore, the techniques described herein advantageously enable a system to generate and store many proof programs and to "remotely" detect when a program has been altered (e.g., to "cheat").

[0016] This Summary is intended 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. Rather, this Summary is intended to provide an overview of the subject matter described in this document. Accordingly, the features described above are merely examples, and other features, aspects, and advantages of the subject matter described herein will become apparent from the Detailed Description, Drawings, and Claims that follow.

[0017] In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular nodes, functional entities, techniques, protocols, etc., to provide an understanding of the described techniques. It will be apparent to those skilled in the art that other embodiments may be practiced apart from the specific details set forth below. In other instances, detailed descriptions of well-known methods, devices, techniques, etc., omit unnecessary detail so as not to obscure the description.

[0018] The sections used in this Detailed Description are intended only to orient the reader to the general subject matter of each section. As will be seen below, many features are described across multiple sections. Headings should not be construed as affecting the meaning of the statements contained in the sections. [Brief explanation of the drawings]

[0019] [Figure 1] 1 shows a block diagram of a system by way of a non-limiting example. [Figure 2A] 1 illustrates non-limiting example user interfaces generated and / or displayed by client devices associated with the system. [Figure 2B] 1 illustrates non-limiting example user interfaces generated and / or displayed by client devices associated with the system. [Figure 3] 1 shows a block diagram of a non-limiting example of the internal components that make up a server system. [Figure 4] 1 shows a non-limiting example block diagram for generating an example proof program. [Figure 5] 1 shows a block diagram of a non-limiting example of a database of the system. [Figure 6A] 1 shows a flowchart as a non-limiting example of processing performed by the system. [Figure 6B] 1 shows a flowchart as a non-limiting example of processing performed by the system. [Figure 7] A block diagram is shown as a non-limiting example of the hardware components that make up the system. DETAILED DESCRIPTION OF THE INVENTION

[0020] [Example of a system for identifying modified program data]

[0021] 1 illustrates a non-limiting example of a system 1 including one or more gaming devices 10A-n that communicate with server system(s) 20 via a network 30. As a non-limiting example, the gaming devices 10A-n can play various games and participate in a multiplayer gaming environment via the network 30. Each gaming device 10A-n may comprise a portable gaming device, a stationary gaming console, and / or a hybrid machine that can be used in both stationary and portable configurations. These examples are, of course, non-limiting, and the system may use any type of information processing device that comprises the gaming devices 10A-n.

[0022] It should be understood that network 30 may comprise a network of interconnected computing devices, such as the Internet. Network 30 may comprise a local area network (LAN), or may comprise peer-to-peer connections between different devices in system 1.

[0023] Server system(s) 20 may comprise a variety of server devices, including, but not limited to, database servers, file servers, web servers, application servers, server clusters (e.g., cloud-based computing environments), standalone servers, and / or any other portable or stationary computing device with server-based capabilities. It should be understood that server system(s) 20 may be implemented using remotely located hardware (e.g., remote hardware) or may be implemented using the same hardware (e.g., within a single server device enclosure).

[0024] As a non-limiting example, a user(s) may execute a game using game devices 10A-n and then play the game in a multiplayer game mode. In such a mode, a user(s) may initiate a remote connection with server system(s) 20 and enter a game lobby to set up a multiplayer game environment among multiple users. In the lobby of the multiplayer game environment, at least one user may customize the multiplayer game environment by selecting a game mode type, a game map, and / or game characteristics (e.g., game bots, weapon types, number and difficulty of shield types), among various other aspects.

[0025] When users play in a multiplayer gaming environment, they may perform certain actions to benefit themselves and / or to be used to defeat other users. As a non-limiting example, users may play a multiplayer first-person shooter game in which users may attempt to "shoot" other enemy characters. These users may play as individuals and all other users may be "enemy" characters, or these users may play in teams, with certain characters being "ally" characters and other characters being "enemy" characters.

[0026] 2A and 2B illustrate user interface 100 as a non-limiting example of a game that may be played by one or more users operating game devices 10A-n. In one non-limiting example, FIGS. 2A and 2B illustrate a first-person shooter game in which a user can operate in a virtual space from a "first-person" perspective. While playing the game, a user may move targeting reticle 101 to aim within the virtual space.

[0027] 2A, a user may view different enemy objects 102A and 102B against which a targeting reticle 101 can be aimed. User interface 100 also shows different allied characters 103A and 103B against which a user may be prevented from aiming or shooting in virtual space. In a particular non-limiting example game, a user may be restricted from shooting and / or damaging allied characters 103A and 103B under a "friendly fire" restriction technique.

[0028] 2B illustrates a non-limiting example of a point in time in a game when a user aims at an enemy object 102B. In the example illustrated in FIG. 2B, the user has positioned the targeting reticle 101 so that the enemy object 102B is in the user's "field of view," allowing the user to shoot and destroy the enemy object 102B. In doing so, the user may damage (or destroy) the enemy object 102B while earning "points" for such action.

[0029] At the end of the game, users may be ranked based on certain criteria (e.g., highest point total, number of "kills"). A leaderboard of different players may be displayed at the end of game play to show where a particular user "places" among other users. Similarly, the system may report in-game performance to server system(s) 20 so that the user may be ranked among a larger number of users. Similarly, server system(s) 20 may reward users for certain performances, for example, by awarding them virtual currency and / or unlocking certain game features, among various other aspects.

[0030] In the example shown in FIG. 2B , a user may employ modifications to a program running on their particular gaming device, thus allowing the user to “cheat” in a multiplayer gaming environment. For example, the user may have modified the game program to implement an “auto-aim” cheat, allowing the user to easily and automatically aim at enemy object 102B. By doing so, the user can more easily aim at different enemy objects (102A / B) and obtain a higher score (and thereby potentially unlock more game benefits) more quickly. The technology described herein can detect modifications to different game programs, in one non-limiting example.

[0031] 3-6B illustrate various aspects of the present technology that enable the system to detect changes to programs running on client-side devices (e.g., game devices 10A-n). In particular, FIG. 3 illustrates a non-limiting example server system 20 for generating and maintaining different proof programs. The example server system 20 may use tools to automatically create different proof programs associated with individual games and may determine whether a user has changed the program running on the user's terminal.

[0032] As a non-limiting example, the server system 20 may include a game code library 21 containing game code for different games. For example, the game code library 21 may include game code for the first-person shooter game shown in FIGS. 2A and 2B. The game code library 21 may, of course, include code for hundreds (or thousands) of different games, and the server system 20 may utilize such game code in constructing the proof program. It should be understood that the game code may be the original source code of the game, or the game code may include program binaries for the game. Of course, the examples described herein relate to game code, but are not limited thereto. In other words, the present technology contemplates implementing the novel technology described herein in association with any software program. Software programs include, but are not limited to, system software, application software, freeware, shareware, open source, and / or cloud-based software, among other types.

[0033] Server system 20 also includes a proof program builder 22 that can build one or more proof programs associated with different game programs / software titles. In one non-limiting example, proof program builder 22 may use game code from game code library 21 and analyze the code to generate different proof programs. These proof programs may produce different results corresponding to techniques associated with modifying the game / software program on the client device.

[0034] Server system 20 may also include networking module(s) 23 for performing network functions for server system 20. For example, networking module(s) 23 may implement Transmission Control Protocol (TCP) and / or User Datagram Protocol (UDP) for communicating over network 30. These examples are, of course, non-limiting, and networking module(s) 23 may perform various communications using different protocols, including, but not limited to, Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Internet Protocol (IP), etc.

[0035] It should be understood that the server system 20 may communicate with the different gaming devices 10A-n using the networking module(s) 23. In one non-limiting example, the different server system(s) 20 may use the networking module(s) 23 to implement a multiplayer gaming environment among the different devices 10A-n. In another non-limiting example, the server system(s) 20 may use the networking module(s) 23 to implement attestation logic that interacts with the devices 10A-n and determines whether software has been modified on each device 10A-n. These examples are, of course, non-limiting, and the technology described herein contemplates various ways in which the server system(s) 20 may communicate with the different gaming devices 10A-n.

[0036] Herein, system(s) 20 may generate (e.g., using proof program builder 22) different proof programs associated with a particular game. Once each proof program is generated, the program may be stored in proof program database 24 of system 20. In one non-limiting example, proof program database 24 includes one or more of a relational database management system (RDBMS), an object-oriented database management system (OODBMS), an object-relational database management system (ORDBMS), a NoSQL data store, an object cache, a distributed file system, a data cluster (based on technologies such as Hadoop), and / or other suitable types of data storage systems.

[0037] Server system(s) 20 may also include proof detection logic 25 for determining whether a program has been modified by a client-side device (e.g., gaming device 10A). As a non-limiting example, proof detection logic 25 may interface with gaming devices 10A-n and may use one or more proof programs stored in proof program database 24. Proof detection logic 25 may compare results generated from the client-side device with results stored in proof program database 24 to determine whether a particular modification (e.g., an auto-aim cheat) has been implemented on client-side device 24.

[0038] Server system(s) 20 further include attestation resolution logic 26 for making appropriate decisions based on the detections of attestation detection logic 25. As a non-limiting example, upon determining (e.g., using attestation detection logic 25) that a client-side device has modified a particular program, attestation resolution logic 26 may perform procedures to "resolve" the detection. For example, attestation resolution logic 26 may "flag" the client-side device to indicate that the user operating the device has "cheated."

[0039] The certification decision logic 26 may take specific corrective / disciplinary action, such as locking (or banning) the user account, warning the user of a detected "cheat," or modifying the client device (e.g., with a software "patch") to remove the "cheat." Similarly, the certification decision logic 26 may take no action but simply "flag" the user (or client device) as a "cheat" for which specific action may be taken at a later date.

[0040] It should be understood that the components illustrated in Figure 3 may be implemented within a single system. The components may also be incorporated into multiple systems and / or a distributed computing environment (e.g., a cloud computing environment). As such, the system is not limited to a single component but may be incorporated into multiple components.

[0041] Figure 4 illustrates a particular, non-limiting example embodiment of proof program builder 22 that builds one or more proof programs using code from game code library 21. In the example illustrated in Figure 4, builder 22 can build a particular proof program 22A using game code 21A stored in game code library 21.

[0042] 4, game code 21A may include different code sequences 1 through n. As non-limiting examples, these different code sequences may include different sets of instructions in a particular programming language, or may include different combinations of programming "blocks" that include pointers to different memory locations as well as "calls" to different functions.

[0043] 4, game code 21A may include code sequences 1-n for executing a game cycle of a particular game. For example, code sequences 1-n may perform functions including accepting and processing user input, executing game logic based on the input, executing artificial intelligence logic, and / or updating the game's output sounds and displays.

[0044] Proof program builder 22 may automatically rearrange the execution order of code sequences 1-n to generate any number of different proof algorithms (e.g., memory checks, hashing). Each code sequence may perform a specific operation (e.g., load from memory, perform a mathematical operation, invoke a hash function). Proof program builder 22 may automatically generate a proof program by listing references to available code sequences in the game binary in the order used by the proof algorithm, corresponding to the proof algorithm.

[0045] The final proof result (e.g., proof program 22A) may depend on both the value at the test location in the game's "memory" and the operations performed by each code sequence. For example, code sequence n (shown in proof program 22A) may transform a value read from memory using constant multiplication or constant addition. As a non-limiting example, code sequence 2 of program 22A may read a value from memory at a particular location (e.g., the location to be tested), and the next code sequence n may transform that value through some type of operation (e.g., adding a constant, performing a logical operation). The following code sequence 1 may perform a memory hash operation, and the next code sequence 3 may combine the result of the hash operation with the transformed value read from memory. The final output of proof program 22A produces a result that is stored and later compared with the result from the client-side device to determine whether modification of the client-side program has occurred.

[0046] As another example, a “final” proof program for testing a change in memory location A may be constructed from four code sequences. These sequences may include: (1) reading a value from memory location A and placing the read value in register R; (2) multiplying the value in register R by a constant 1 and storing the result in register R; (3) adding a constant 2 to register R and storing the result in register R; and / or (4) returning the result in register R to server system(s) 20. If the execution order of sequences (2) and (3) were swapped in another program (or if sequence (2) were used twice in a row without using sequences (2) and (3)), the result of the proof program sent to server system(s) 20 would change. While the result still depends on the value in memory location A, the result also depends on the order of execution of the sequences and the operations performed by each sequence. It should be understood that the value in memory location A may yield a “golden value” that is stored in server system(s) 20. If a user attempts to change the result at memory location A (e.g., to achieve a desired game cheat), the result of the proof program executed in association with memory location A will differ from that stored in server system(s) 20, thereby notifying system(s) 20 that a change has occurred in the game.

[0047] It should be appreciated that the server system(s) 20 may maintain a database of results for each certification program (e.g., in database 24). These stored results allow the server system(s) 20 to compare results generated from client-side devices (e.g., game devices 10A-n) to determine whether modifications have been detected.

[0048] It should be understood that to forge the results of a proof program, an "attacker" would need to analyze the program, extract the code sequences and their order, and analyze what each code sequence does. A typical game has a vast number of available code sequences, making this process extremely difficult to perform in real time. Therefore, the system 1 described herein advantageously allows for "remote" detection of cheats.

[0049] 5 shows a non-limiting example of a proof program database 24 that stores different results for different proof programs associated with various games. In one non-limiting example, database 24 can store each of the proof programs generated by proof program builder 22, and proof detection logic 25 can access to determine whether software modifications have occurred on the client-side device.

[0050] 5, proof program database 24 includes different proof programs for games 1 through X. Games 1 through X include any type of video game, including, but not limited to, shooter video games (e.g., first-person shooter, third-person shooter), action video games, adventure video games, sports video games, puzzle video games, and / or dance video games.

[0051] As a non-limiting example, herein, the proof program builder 22 can scan code from games in the game code library 21 to generate a different proof program associated with each game. The proof program generates specific results that can be compared with the game running on the client terminal to determine if the client program has been altered.

[0052] In the example shown in Figure 5, proof program database 24 includes games 1 to X. Each of games 1 to X includes a proof program associated with it. For example, game 1 is directed to a first-person shooter game, and the first-person shooter game has proof programs AP1 to APn created for that game. Each of these proof programs AP1 to APn generates a proof result AR1 to ARn.

[0053] It should be understood that each of Games 2-X has its own associated attestation program AP1-n for each game, and each program AP1-n generates a respective attestation result AR1-n. Herein, system 1 may perform an "attestation check" on a program running on a client device and compare it to one or more of results AR1-n stored in database 24. For example, one "attestation check" may be performed on game device 10A for Game 1, and the "attestation check" may generate a result from game device 10A.

[0054] As a particular example, server system(s) 20 may send an attestation program to gaming device 10A. The attestation program may include a reference to a code sequence to be sent to gaming device 10A. It should be understood that each program stored on / running on gaming device 10A-n may have an associated thin library that understands attestation requests received by device 10A-n from server system(s) 20. The attestation request (e.g., attestation program) causes device 10A to generate an attestation result, which is sent back to server system(s) 20.

[0055] More specifically, results from gaming device 10A are transmitted (e.g., using networking module(s) 23) to server system(s) 20, which compares the results with those stored in database 24. For example, a “proof check” may be performed on gaming device 10A playing game 1 to detect a particular “auto-aim” cheat feature. The “auto-aim” cheat feature may correspond to that generated by proof program AP1 having a corresponding proof result AR1. It should be understood that one target may be the detection of widely distributed exploits (e.g., cheats). For example, the desired exploit may be of a type that even a non-technical user could install on their system (such exploits may be found on websites such as “maxcheats.com”). The techniques described herein can calculate proof results for games with such specific modifications and store such results along with the program. Thus, each proof program stored on server system(s) 20 will have (1) an expected "golden result," (2) one or more exploits and their corresponding "bad" results, and / or (3) certain "unknown" results for which exploits may not yet be identified.

[0056] System(s) 20 may query database 24 for results generated by gaming device 10A playing game 1 to determine whether particular results match those stored in database 24. System(s) 20 may perform such queries using a standard database query language (e.g., SQL). In doing so, system(s) 20 may detect whether particular modifications associated with this particular feature (e.g., an "auto-aim" cheat) for game 1 have been made by device 10A, and upon detection, system(s) 20 may take some type of administrative action.

[0057] These examples are, of course, non-limiting, and the system contemplates various ways of storing and comparing the attestation results with results generated from different "attestation checks" on the client device. Furthermore, a "cheat" may be detected from many different attestation programs, and thus a "cheat" is not limited to only one attestation program. In other words, a particular cheat for a game may be reproduced using many attestation programs (each with a different attestation result).

[0058] 6A and 6B illustrate a flowchart 600 as a non-limiting example of a process performed by system 1. FIG. 6A illustrates, in particular, a flowchart 600 of a non-limiting process for generating one or more proof programs (e.g., using proof program builder 22). FIG. 6B illustrates, in particular, a flowchart 600 of a non-limiting process for detecting alterations and implementing “fix” actions (e.g., using proof detection logic 25 and / or proof determination logic 26). It should be understood that the processes illustrated in FIGS. 6A and 6B may be performed by system 1 (e.g., using server system(s) 20). Of course, this example is non-limiting, and the processes illustrated in FIGS. 6A and 6B may be performed in a variety of different ways.

[0059] The process begins with system 1 obtaining program code (e.g., from game code library 21) for a given program (action S1). For example, system 1 may obtain program code for game 1, which is a first-person shooter game. The game code may include thousands (or even hundreds of thousands) of code sequences nested within various functions of the game software. Each of these functions may call other functions or may include pointers to different areas of memory to perform specific tasks. It should be understood that, as used herein, a program may include the source code of a program or may include a program binary.

[0060] In action S2, the system 1 can scan the program code (e.g., scan the program binary using the proof program builder 22) for usable code sequences. As a non-limiting example, the program code may contain specific code sequences that are not themselves relevant for proof purposes, but can be combined to generate a desired proof algorithm.

[0061] In action S3, System 1 can combine these code sequences to generate a proof algorithm that produces a particular result. Herein, the original game code may include intended execution sequences (i.e., implementing the game logic). System 1 can combine these sequences to "strategically" achieve a desired function. In one example, the desired function may include checking memory locations for modifications and / or performing a hash check of the memory.

[0062] In action S4, System 1 uses these combined code sequences to generate a proof program. As a non-limiting example, System 1 can use a collection of combined code sequences to generate a proof program for detecting particular "cheats" in a particular game (e.g., auto-aim, walking through walls, leveling up a player character).

[0063] The results of the proof program may be maintained in a system database (e.g., proof program database 24) (action S5). In one non-limiting example, a proof result may be associated with each proof program for a particular game. These combinations are shown, for example, in FIG. 5 described herein.

[0064] 6B shows a non-limiting example flowchart 600 for performing an "authenticity check" on one or more client-side devices. Processing begins with action S6, where system 1 can detect a particular program running on a client-side device. As a non-limiting example, server system(s) 20 may detect that gaming device 10A is running game 1 in a multiplayer gaming environment.

[0065] At action S7, system 1 may perform a "proof check" on the client device. For example, server system(s) 20 may communicate with gaming device 10A using networking module(s) 23 via network 30. Server system(s) 20 may perform a "proof check" on game 1 running on gaming device 10A and generate one or more proof results. In one non-limiting example, system(s) 20 may send a reference to a particular code sequence to gaming device 10A. Gaming device 10A may utilize a thin library associated with the particular game to generate a result associated with the reference to the code sequence sent from system(s) 20. The result may be generated and sent from gaming device 10A to server system(s) 20.

[0066] At action S8, the system 1 can compare the proof results generated by the client-side device with those stored in a database memory (e.g., the proof program database 24) of the system 20. As a non-limiting example herein, the client-side device may generate a proof result corresponding to a particular game cheat. This result can be queried against the database 24 for that particular game. It should be understood that the database may include "good" results corresponding to properly functioning software on the client-side device. The database 24 may also include "bad" results corresponding to known cheats. Similarly, the database 24 may also store "unknown" results that do not match known "good" results but also do not match known "bad" results (e.g., cheats).

[0067] If a match is found (action S9), the system can flag the client-side device and / or take certain corrective actions (action S10). In situations where the result does not match either a "good" or a "bad" result, it is possible that the client-side device did not make any changes but there is a hardware malfunction, or that the client-side device made changes that do not match the results in the database 24. Similarly, if the client-side device returns a "good" result, it is possible that the software has not been changed by the client-side device and the process may end.

[0068] It should be appreciated that based on whether a match is detected, system 1 can determine how to most appropriately proceed. That is, if the result returned by the client-side device matches a known "bad" result, or if the returned result matches an "unknown" result (or does not match a value stored in database 24), system 1 may flag the client-side device as having modified a particular program (e.g., for cheating purposes). System 1 may also determine and perform some type of administrative / corrective action on the client-side device. For example, system 1 may simply send an alert to the client-side device (e.g., using email or messaging service(s)) informing the user that a particular modification has been detected. System 1 may also perform certain disciplinary actions, such as locking the game (or user terminal) and / or temporarily or permanently banning the user.

[0069] It should be understood that in some instances, the results output from the client-side device may not match the stored “good” or “bad” results, and therefore there may not be sufficient evidence to determine whether a change has occurred. Therefore, the system 1 may also decide not to take corrective action on the client-side device. For example, the system 1 may determine that a particular result obtained by the client-side device may have occurred by chance or due to some kind of “glitch” in the client-side device. In this case, the system 1 may not flag the client-side device or take any corrective / management action on the device. Similarly, the system 1 may determine that the device should be flagged but no other corrective action should be taken.

[0070] In a particular example embodiment, system 1 may flag these devices and maintain a list of flagged devices that produce similar results. If more devices begin to return results similar to those of the flagged devices, it may indicate a new cheat for which system 1 does not have a corresponding certification program to detect such cheats. After a period of time, the results may be determined to correspond to a particular type of cheat, at which point corrective action may be taken against the client-side device producing the previously "unknown" results. These examples are, of course, non-limiting, and the system contemplates a variety of actions that may be taken upon a "certification match" being found.

[0071] While actions S1 through S5 and actions S6 through S10 have been described above as separate actions performed in a given order, it should be understood that this is for ease of explanation. It should be understood that in various embodiments, the actions described above may be performed in various orders. Alternatively or additionally, some of the actions described above (actions S1 through S10) may be reordered and / or performed simultaneously with some of the other actions (actions S1 through S10).

[0072] 7 illustrates a block diagram of a non-limiting example of a hardware architecture for system 1260. In the example illustrated in FIG. 7, client device 1210 communicates with server system 1200 via network 1240. Network 1240 may comprise a network of interconnected computing devices, such as the Internet. Network 1240 may also comprise a local area network (LAN) or a peer-to-peer connection between client device 1210 and server system 1200. As described below, the hardware elements illustrated in FIG. 7 may be used to implement the various software components and actions described above as contained in and / or executing on client device 1210 and server system 1200.

[0073] In some embodiments, client device 1210 (which may also be referred to herein as a “client system”) includes one or more of the following: one or more processors 1212; one or more memory devices 1214; one or more network interface devices 1216; one or more display interfaces 1218; and one or more user input adaptors 1220. Additionally, in some embodiments, client device 1210 is connected to or includes a display device 1222. As described below, these elements (e.g., processor 1212, memory device 1214, network interface device 1216, display interface 1218, user input adaptor 1220, display device 1222) are hardware devices (e.g., electronic circuits or combinations of circuits) configured to perform various different functions for computing device 1210.

[0074] In some embodiments, each or any of the processors 1212 is or includes, for example, a single or multi-core processor, a microprocessor (e.g., which may also be referred to as a central processing unit or CPU), a digital signal processor (DSP), a microprocessor associated with a DSP core, an application specific integrated circuit (ASIC), field programmable gate array (FPGA) circuit, or a system on a chip (SOC) (e.g., an integrated circuit that includes a CPU and other hardware components such as memory, a network interface, etc.), and / or in some embodiments, each or any of the processors 1212 uses an instruction set architecture such as x86 or Advanced RISC Machine (ARM).

[0075] In some embodiments, each or any of the memory devices 1214 is or includes random access memory (RAM) (such as dynamic RAM (DRAM) or static RAM (SRAM)), flash memory (e.g., based on NAND or NOR technology), a hard disk, a magneto-optical recording medium, an optical medium, a cache memory, a register (e.g., that holds instructions), or any other type of device that performs volatile or non-volatile storage of data and / or instructions (e.g., software executed by or to the processor 1212). The memory devices 1214 are examples of non-volatile computer-readable storage media.

[0076] In some embodiments, each or any of the network interface devices 1216 includes one or more circuits (such as a baseband processor and / or a wired or wireless transceiver) and implements layer 1, layer 2, and / or higher layers of one or more wired communication technologies (such as Ethernet (IEEE 802.3)) and / or wireless communication technologies (such as Bluetooth, WiFi (IEEE 802.11), GSM, CDMA2000, UMTS, LTE, LTE-Advanced (LTE-A), and / or other short-range, medium-range, and / or long-range wireless communication technologies). A transceiver may include circuitry for a transmitter and a receiver. The transmitter and receiver may share a housing and may share some or all circuitry within the housing for transmission and reception. In some embodiments, the transmitter and receiver of a transceiver may not share circuitry and / or may be in the same housing or separate housings.

[0077] In some embodiments, each or any of display interfaces 1218 is or includes one or more circuits that receive data from processor 1212, generate corresponding image data based on the received data (e.g., via a discrete GPU, an integrated GPU, a CPU performing drawing processing, etc.), and / or output the generated image data to display device 1222 (e.g., via a high-definition multimedia interface (HDMI), a display port interface, a video graphics array (VGA) interface, a digital video interface (DVI), etc.). Display device 1222 displays the image data. Alternatively or additionally, in some embodiments, each or any of display interfaces 1218 is or includes, for example, a video card, a video adapter, or a graphics processing unit (GPU).

[0078] In some embodiments, each or any of user input adaptors 1220 is or includes one or more circuits that receive and process user input data from one or more user input devices (not shown in FIG. 7 ) included in, attached to, or otherwise in communication with client device 1210, and output data based on the received input data to processor 1212. Alternatively or additionally, in some embodiments, each or any of user input adaptors 1220 is or includes, e.g., a PS / 2 interface, a USB interface, a touchscreen controller, etc., and / or user input adaptor 1220 facilitates input from, e.g., a keyboard, a mouse, a trackpad, a touchscreen, etc. (not shown in FIG. 7 ).

[0079] In some embodiments, display device 1222 may be a liquid crystal display (LCD) display, a light emitting diode (LED) display, or other types of display devices. In embodiments in which display device 1222 is a component of client device 1210 (e.g., the computing device and display device are included in an integrated housing), display device 1222 may be a touchscreen display or a non-touchscreen display. In embodiments in which display device 1222 is connected to client device 1210 (e.g., it is external to client device 1210 and communicates with client device 1210 via wired and / or wireless communication techniques), display device 1222 may be, for example, an external monitor, projector, television, display screen, etc.

[0080] In various embodiments, client device 1210 includes one, two, three, or more of each or any of the above-mentioned elements (e.g., processor 1212, memory device 1214, network interface device 1216, display interface 1218, and user input adapter 1220). Alternatively or additionally, in some embodiments, client device 1210 includes one or more of: a processing system including processor 1212; a memory or storage system including memory device 1214; or a network interface system including network interface device 1216.

[0081] The client device 1210 may be arranged in many different ways in various embodiments. By way of example only, the client device 1210 may be arranged such that the processor 1212 includes: a multi- (or single-) core processor; a first network interface device (which implements, for example, WiFi, Bluetooth, NFC, etc.); a second network interface device implementing one or more cellular communication technologies (e.g., 3G, 4G LTE, CDMA, etc.); and memory or storage (e.g., RAM, flash memory, or a hard disk). The processor, first network interface device, second network interface device, and memory device may be integrated as part of the same SOC (e.g., one integrated circuit chip). As another example, client device 1210 may be arranged as follows: processor 1212 includes two, three, four, five, or more multi-core processors; network interface device 1216 includes a first network interface device that implements Ethernet and a second network interface device that implements WiFi and / or Bluetooth; and memory device 1214 includes RAM and flash memory or a hard disk.

[0082] Server system 1200 also comprises various hardware components that are used to implement software elements for server system(s) 20. In some embodiments, server system 1200 (which may also be referred to herein as a “server device”) includes one or more of the following: one or more processors 1202; one or more memory devices 1204; and one or more network interface devices 1206. As described below, these elements (e.g., processor 1202, memory devices 1204, network interface devices 1206) are hardware devices (e.g., electronic circuits or combinations of circuits) configured to perform various different functions for server system 1200.

[0083] In some embodiments, each or any of processors 1202 is or includes, for example, a single or multi-core processor, a microprocessor (e.g., which may also be referred to as a central processing unit or CPU), a digital signal processor (DSP), a microprocessor associated with a DSP core, an application specific integrated circuit (ASIC), field programmable gate array (FPGA) circuit, or a system on a chip (SOC) (e.g., an integrated circuit that includes a CPU and other hardware components such as memory, a network interface, etc.), and / or in some embodiments, each or any of processors 1202 uses an instruction set architecture such as x86 or Advanced RISC Machine (ARM).

[0084] In some embodiments, each or any of memory devices 1204 is or includes random access memory (RAM) (such as dynamic RAM (DRAM) or static RAM (SRAM)), flash memory (e.g., based on NAND or NOR technology), a hard disk, a magneto-optical recording medium, an optical medium, a cache memory, a register (e.g., for holding instructions), or any other type of device that performs volatile or non-volatile storage of data and / or instructions (e.g., software executed by or to processor 1202). Memory device 1204 is an example of a non-volatile computer-readable storage medium.

[0085] In some embodiments, each or any of the network interface devices 1206 includes one or more circuits (such as a baseband processor and / or a wired or wireless transceiver) and implements layer 1, layer 2, and / or higher layers of one or more wired communication technologies (such as Ethernet (IEEE 802.3)) and / or wireless communication technologies (such as Bluetooth, WiFi (IEEE 802.11), GSM, CDMA2000, UMTS, LTE, LTE-Advanced (LTE-A), and / or other short-range, medium-range, and / or long-range wireless communication technologies). A transceiver may include circuitry for a transmitter and a receiver. The transmitter and receiver may share a housing and may share some or all circuitry within the housing for transmission and reception. In some embodiments, the transmitter and receiver of a transceiver may not share circuitry and / or may be in the same housing or separate housings.

[0086] In various embodiments, server system 1200 includes one, two, three, four, or more of each or any of the above-mentioned elements (e.g., processor 1202, memory device 1204, network interface device 1206). Alternatively or additionally, in some embodiments, server system 1200 includes one or more of: a processing system including processor 1202; a memory or storage system including memory device 1204; or a network interface system including network interface device 1206.

[0087] Server system 1200 may be arranged in many different ways in various embodiments. By way of example only, server system 1200 may be arranged such that processor 1202 includes: a multi- (or single-) core processor; a first network interface device (which implements, e.g., WiFi, Bluetooth, NFC, etc.); a second network interface device implementing one or more cellular communication technologies (e.g., 3G, 4G LTE, CDMA, etc.); and memory or storage (e.g., RAM, flash memory, or a hard disk). The processor, first network interface device, second network interface device, and memory device may be integrated as part of the same SOC (e.g., one integrated circuit chip). As another example, server system 1200 may be arranged as follows: processor 1202 includes two, three, four, five, or more multi-core processors; network interface device 1206 includes a first network interface device that implements Ethernet and a second network interface device that implements WiFi and / or Bluetooth; and memory device 1204 includes RAM and flash memory or a hard disk.

[0088] As noted above, whenever a software module or process is described herein as performing some action, that action is actually performed by the underlying hardware components in accordance with the instructions that make up the software module. Similarly to the above, in various embodiments, each or any combination of client device 1210 or server system 1200 (each of which will be referred to individually as a "component" hereafter for clarity) is implemented using the example client device 1210 or server system 1200 of FIG. 7.

[0089] In such embodiments, the following applies to each component: (a) the elements of client device 1210 (i.e., one or more processors 1212, one or more memory devices 1214, one or more network interface devices 1216, one or more display interfaces 1218, and one or more user input adaptors 1220) and server system 1200 (i.e., one or more processors 1202, one or more memory devices 1204, one or more network interface devices 1206) shown in FIG. 7, or any appropriate combination or subset of the foregoing, are configured, adapted, and / or programmed to implement each or any combination of the actions, activities, or features described herein performed by the components and / or by the software modules described herein included in such components; (b) Alternatively or additionally, to the extent that one or more software modules are described herein as residing within a component, in some embodiments, such software modules (and data described herein as being handled and / or used by the software modules) are stored within respective memory devices (e.g., in various embodiments, within volatile memory devices such as RAM or instruction registers, and / or within non-volatile memory devices such as flash memory or a hard disk), and all actions described herein as being performed by the software modules are performed by the respective processors, in appropriate cooperation with other elements within and / or connected to client device 1210 or server system 1200.(c) Alternatively or additionally, to the extent that a component is described herein as processing and / or otherwise handling data, in some embodiments, such data is stored in a respective memory device (e.g., in some embodiments, in a volatile memory device such as RAM and / or in a non-volatile memory device such as flash memory or a hard disk) and / or processed / handled by a respective processor, in appropriate cooperation with other elements within and / or connected to client device 1210 or server system 1200. (d) Alternatively or additionally, in some embodiments, each memory device stores instructions that, when executed by a respective processor, cause the processor to perform each or any combination of the actions described herein performed by the component and / or by the software modules described herein included in that component, in appropriate cooperation with other elements within and / or connected to client device 1210 or server system 1200.

[0090] The hardware configuration shown in Figure 7 and described above is provided as an example, and the subject matter described herein may be utilized in conjunction with a variety of different hardware architectures and elements. For example, in many of the figures in this document, individual function / action blocks are shown, and in various embodiments, the functionality of these blocks may be implemented using (a) individual hardware circuits, (b) application-specific integrated circuits (ASICs) specifically configured to perform the described functions / actions, (c) one or more digital signal processors (DSPs) specifically configured to perform the described functions / actions, (d) the hardware configuration described above with reference to Figure 7, or (e) other hardware arrangements, architectures, and configurations and / or combinations of the techniques described in (a)-(e).

[0091] At various points in this document, software modules and actions performed by the software modules are described. This has been done for ease of description. Whenever this document describes a software module as performing some action, it should be understood that the action is actually performed by the underlying hardware components (such as a processor and memory) according to the instructions that configure the software module. [Technical advantages]

[0092] The techniques described herein provide improvements over existing techniques for determining whether a user has modified a program running on a user device. In particular, the techniques enable the automatic creation of different attestation programs that can be stored on a remote device (e.g., a server system), which can then perform "attestation checks" on programs running on different client devices. By comparing the results generated by the client devices during the "attestation checks," the remote device can determine whether the client device has modified a particular program.

[0093] In this manner, the techniques herein enable a remote device to automatically generate an attestation program for remotely detecting whether a different client device has modified a program on the client device. Such an approach advantageously allows the remote device to perform an "attestation check" without requiring attestation logic on the client device. By doing so, the techniques prevent the client device from modifying the attestation logic, thereby preventing the remote device from having to correct such modifications through widely distributed software patches. The techniques thus improve the overall security of the system as well as the human-user interface experience. Furthermore, because the need to distribute various software patches is reduced, the system reduces the amount of communication between components within the system, thus improving the overall communication bandwidth of the system. Selected Definition

[0094] Whenever an item is described herein as being present in "some embodiments," "various embodiments," "particular embodiments," "particular example embodiments," "some example embodiments," "representative example embodiments," or other similar language is used, it should be understood that the item is present in at least one embodiment, but not necessarily in all embodiments. Similarly, whenever an action "may," "can," or "can obtain" is described herein, or a feature, element, or component "may," "can," "can obtain," or is described herein as being within, capable of, or applicable to a certain context, or an item "may," "can," or "can have," or a similar phrase with the terms "may," "can," or "can obtain," it should be understood that the action, feature, element, component, attribute, etc. is present in at least one embodiment, but not necessarily in all embodiments. Terms and phrases used herein, and variations thereof, unless otherwise specified, should be considered open-ended and not restrictive. As examples of the above: "and / or" includes any and all combinations of one or more of the associated listed items (e.g., a and / or b means a, b, or a and b); singular terms ("a," "an," and "the") should be read to mean "at least one," "one or more," etc.; the term "examples" is used to provide examples of the subject matter, not an exhaustive or limiting list thereof; the terms "comprises" and "includes" (and other conjugations and other variations) refer to the presence of the associated listed items, but do not exclude the presence or addition of one or more other items; and when an item is described as "optional," such description should not be understood as indicating that the other items are not also optional.

[0095] As used herein, the term "non-transitory computer-readable storage medium" includes registers, cache memory, ROM, semiconductor memory devices (such as D-RAM, S-RAM, or other RAM), magnetic media such as flash memory, hard disks, magneto-optical storage media, optical media such as CD-ROM, DVD, or Blu-Ray Disc, or any other type of device for non-transitory electronic data storage. The term "non-transitory computer-readable storage medium" does not include transitory, propagating electromagnetic signals. [Further application of the described subject]

[0096] Without limitation, although process steps, algorithms, and the like, with reference to Figures 1-7 may be described or claimed in a particular order, such processes may be configured to work in different orders. In other words, a sequence or order of steps explicitly described or claimed herein does not necessarily indicate that the steps must be performed in that order. Rather, steps of processes described herein may be performed in any possible order. Furthermore, some steps may be performed simultaneously (or in parallel) despite being described or implied as occurring non-concurrently (e.g., because one step is described after another). Furthermore, the illustration of a process shown in a certain figure does not imply that the illustrated process is exclusive of other variations and modifications thereto, nor does it imply that the illustrated process or any of its steps are required, or that the illustrated process is preferred.

[0097] Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. Nothing in the above description should be read as suggesting that any particular element, step, range, or function is essential. All structural and functional equivalents to the elements of the above-described embodiments known to those skilled in the art are expressly incorporated herein by reference and are intended to be encompassed by the present invention. Furthermore, a device or method need not address every problem to be solved by the present invention, for it to be encompassed by the present invention. No embodiment, feature, element, component, or step in this document is intended to be dedicated to the public.

Claims

1. 1. A system for detecting changes to program data, comprising: a processor; a memory configured to store computer-readable instructions; The computer-readable instructions, when executed by the processor, cause the system to: Obtaining program code for a first program configured to run on a client device; scanning the program code for the first program for available code sequences 1 through n; automatically rearranging the execution order of the available code sequences 1 to n to form a first proof algorithm, and forming a first proof program having a first proof result based on the first proof algorithm; storing the first proof program having the first proof result in a database in the memory of the system; sending data associated with the first certification program to the client device to cause the first program executing on the client device to perform a certification check that generates a first certification check result; receiving the first certificate check result from the client device; comparing the first certification check result with the first certification result associated with the first certification program to determine whether the first certification result matches the first certification check result; The system causes the client device to perform an action associated with the comparison.

2. The system of claim 1 , wherein a type of change to the first program can be determined based on the comparison.

3. the client device is a game device; the first program is a game program running on the game device; the modification to the first program indicates a user cheat associated with the game program; The system of claim 1 .

4. 2. The system of claim 1, wherein the program code for the first program is scanned using a software tool, and the usable code sequences are detected from scanning the first program using the software tool.

5. storing the first proof result in the database in association with the first proof program; transmitting the first proof program to the client device, the first proof program including a reference to a particular code sequence; 2. The system of claim 1, further comprising: comparing the first certification result stored in the database in association with the transmitted first certification program with the first certification check result to determine whether the first certification result matches the first certification check result.

6. 1. A system for detecting changes to program data, comprising: a processor; a memory configured to store a first proof program having a first proof result, the first proof program being formed from usable code sequences 1 to n associated with program code of the first program, the memory further configured to store computer readable instructions that, when executed by the processor, cause the system to: transmitting data associated with the first certification program to a client device to cause the first program executing on the client device to perform a certification check that generates a first certification check result; receiving the first certificate check result from the client device; performing an action associated with the client device based on a result of the first certificate check; forming the first proof program; automatically rearranging the execution order of the available code sequences 1 to n to form a first proof algorithm; translating the first proof algorithm into the first proof program by listing references to code sequences from a first program binary associated with the first program in the order used by the first proof algorithm; Including, system.

7. 7. The system of claim 6, wherein the first certification check result is compared to the first certification result associated with the first certification program to determine whether the first certification result matches the first certification check result.

8. The first proof result is stored in a database in the memory in association with the first proof program; transmitting the first proof program to the client device, the first proof program including a reference to a particular code sequence; 8. The system of claim 7, wherein the first certification result stored in the database in association with the transmitted first certification program is compared with the first certification check result to determine whether the first certification result matches the first certification check result.

9. 7. The system of claim 6, wherein the action performed in association with the client device includes at least one of flagging the client device, sending a warning to the client device, locking the client device, banning the client device, and / or not taking any action associated with the client device.

10. A non-transitory computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions, when executed by a processor of a system, causing the system to: scanning program code for a first program configured to execute on a client device for available code sequences 1-n; automatically rearranging the execution order of the available code sequences 1 to n to form a first proof algorithm, forming a first proof program having a first proof result based on the first proof algorithm, and storing the first proof program in a memory; performing an attestation check on the first program running on the client device in association with the first attestation program having the first attestation result; performing an action associated with the client device based on the certificate check; Execute A non-transitory computer-readable storage medium.

11. 11. The non-transitory computer-readable medium of claim 10, wherein performing the attestation check on the first program executing on the client device generates a first attestation check result.

12. 12. The non-transitory computer-readable storage medium of claim 11, wherein the first certification check result is compared to the first certification result associated with the first certification program to determine whether the first certification result matches the first certification check result.

13. 11. The non-transitory computer-readable storage medium of claim 10, wherein the action performed in association with the client device includes at least one of flagging the client device, sending a warning to the client device, locking the client device, banning the client device, and / or not taking any action associated with the client device.

14. The non-transitory computer-readable medium of claim 10 , wherein the first proof program is formed using return-oriented programming techniques.

15. The first proof result is stored in the database in association with the first proof program; transmitting the first proof program to the client device, the first proof program including a reference to a particular code sequence; 11. The non-transitory computer-readable recording medium of claim 10, further comprising: comparing the first certification result stored in the database in association with the transmitted first certification program with the first certification check result to determine whether the first certification result matches the first certification check result.

16. 1. A method for detecting changes to program data, comprising: scanning program code for a first program configured to execute on a client device for available code sequences 1-n; automatically rearranging the execution order of the available code sequences 1 to n to form a first proof algorithm, forming a first proof program having a first proof result based on the first proof algorithm, and storing the first proof program in a memory; transmitting data associated with the first certification program to the client device to perform a certification check on the first program executing on the client device to generate a first certification check result; receiving the first certificate check result from the client device; performing an action associated with the client device based on a result of the first certificate check; A method comprising:

Images