Patent Application
20080182659
The technical field relates generally to computer processing and more specifically to online gaming.
It is not uncommon for online game players to cheat in order to appear to be better players than they truly are. Cheating can adversely affect online game communities and can significantly impact a player's desire to play against others online. Players are known to cheat via utilities that modify a game's data memory at runtime. Modifications can include, for example, changes to game data constants and/or characteristics, such as the amount of ammunition, the strength of an item, the health of a player, the position of walls, deleting of walls from a map to enable a player to shoot through walls in the game, or the like. Modifications are commonly encapsulated in small cheat applications colloquially called “Trainers.” Because typical file tampering mechanisms verify the integrity of a file on-disk (e.g., by verifying a digital signature), once a file is loaded into memory, it can be modified without affecting the file on-disk (e.g., the file on-disk remains valid, although its in-memory representation has been altered). Thus, trainers can be applied directly to a game's memory during play, and avoid detection by file tampering detection mechanisms implemented by the game.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description Of Illustrative Embodiments. 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.
Tampering of select game data is detectable during game play. During game play, challenges to inspect select data are provided to a game device, such as a game console or the like. Memory locations of the game device in which the select data are stored are analyzed to determine if the data has been altered. If data has been altered, online execution of the game ceases (e.g. login session terminated). If data has not been altered, online game play continues. In an example embodiment, the challenges include references to the select data. The challenge, upon receipt by the game device, locates the select data in game device memory, and computes cryptographic hash values from the select data stored in the game device memory. In response to the challenge, the game device provides the cryptographic hash values of the select data. Upon receipt of the hash values by the challenger (e.g., by a server), the received cryptographic hash values are compared with expected hash values. If the cryptographic hash values match, online game execution to continue. If the cryptographic hash values do not match, game execution is halted.
The foregoing summary, as well as the following detailed description, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating in-play detection of altered game data, there is shown in the drawings exemplary constructions thereof, however, in-play detection of altered game data is not limited to the specific methods and instrumentalities disclosed.
During execution of a game, altered game data is detectable via challenges provided to a game device. A challenge includes an executable program that is capable of locating select data in memory and analyzing the select data to determine if the select data has been altered. In an example embodiment, select data are stored in memory of the game device. When a challenge is received by the game device, the challenge is loaded and the executable program therein is executed. The challenge locates, via an obfuscated lookup table, the select data stored in the memory of the game device. The challenge obtains the select data from the memory of the game device and computes cryptographic hash values from the obtained data. The calculated hash values are compared with hash values provided as part of the challenge. If the hash values match, game execution continues. If the hash values do not match, game execution is halted.
Select game data to be analyzed for alteration is identified at step 12. Select game data can be any appropriate data such as game constants, static characteristics, attributes, or the like. For example, select game data can include the amount of ammunition (e.g., bullets) assigned to a player, the number of walls in a game scenario, the ability to shoot through walls, the maximum health of a player, the maximum strength of a player, the maximum life/duration of a player, or the like. The relative addresses of the select game data also are identified at step 12. The select data and the relative addresses of the select data can be identified, for example, by a developer of the game. For example, the developer can establish a name for each data segment of the select data. And, the names of the data segments can be used during the challenge to map the requested data segments to entries in an asset table indicating the actual in-memory locations of the data segments.
Cryptographic hash values associated with the select game data and/or the relative addresses are generated at step 14. A cryptographic hash value is the value obtained from performing a hash function. A cryptographic hash function is a function that converts a variable length input into a fixed length output, referred to as the hash value. Within mathematical limits, two different inputs to a hash function will not result in the same hash value. In an exemplary embodiment, a cryptographic hash function, such as the well known MD5, SHA-1, or SHA-256, for example, is used to obtain hash values for the select data. Cryptographic hash values can be generated for any appropriate portions of the select data, such as, for example, static game data. For example, assume a particular map texture is 5 Kbytes in size. This could be hashed down to 20 bytes, and 20-byte hash value would be returned to the server in response to a challenge asking for the hash of that map texture. If the 20 bytes returned by the client match the 20 bytes that the server knows to be the correct hash value, the challenge has been successfully responded to and the client's login session is not terminated. In an example embodiment, an XML file of the names and relative addresses of the select data are generated at step 14.
The select data game data is stored in the game device at step 16. The game data can be stored in any appropriate location, such as storage in the game device and/or storage external to the game device. In an example embodiment, the select game data is stored in memory in the game device. The select data, along with other game information is loaded into the game device in order to execute the game. In an example embodiment, the game information, including the select data, is stored on a disc (e.g., optical disc) and provided to a user (also referred to as a player). The player inserts the disc into a game device to play a game. The select game data is stored in random locations in memory in the game device. At step 18, a lookup table is generated indicating the locations in which the select data have been stored. The lookup table is obfuscated. The lookup table can be obfuscated in any appropriate manner, for example the lookup table can be AES-encrypted (e.g., encrypted in accordance with the Advanced Encryption Standard) using a symmetric key stored securely within the program, in secure hardware, of the like. Keys can be securely stored in any appropriate manner. For example, keys can be securely stored in hardware, such a as TPM (Trusted Platform Module) chip or the like, and/or keys can be obfuscated in any appropriate manner. Encryption prevents attackers from reading the data in “clear text.” Further, a hash/signature can be utilized to ensure the integrity of the table. Also, an nonce (a value used only once)can be used to prevent replay attacks in which a legitimate (encrypted) table is copied from one process and later injected into another process. In an example embodiment, the game calls an Application Programming Interface (API) that provides the base memory locations in which the select data are stored, the size of the memory segments in which the select data are stored, and an appropriate name of the data segment, as established at step 12. The API generates the obfuscated lookup table and registers the memory for inspection. As described above, once a data segment has been assigned a name, the data segment can be referenced by a subsequent challenge, which will result in the associated memory, in which being hashed, with the resultant hash being returned as a response to the challenge. The memory in which the select data is stored is protected at step 20. In an example embodiment, the memory in which the select data is stored is designated as read-only memory to prevent tampering and/or any inadvertent modification to the select data.
During game execution, while signed in to an online game service, such as XBOX® LIVE for example, a challenge is received by the game device at step 22. A challenge can be provided by any appropriate source. For example, challenges can be provided by an online game service (e.g., XBOX® LIVE). A challenge can be received at any time during game play. For example, challenges can be received randomly, periodically, or a combination thereof. The challenge comprises an executable program configured to inspect the select data for an indication of alteration. The challenge can be in any appropriate form. For example, the challenge can be in the form of a module comprising a Dynamically-Linked Library (DLL) and a data manifest, such as an XML file or the like. In an example embodiment, the data manifest includes an XML file that comprises indications (e.g., names) of portions of the select data. In an example embodiment, the XML file comprises a list of data segment names for which hash values are to be calculated and returned (assuming the requested data segment is presently loaded/registered in the process). In response to the challenge being received, the executable program in the challenge is executed. At step 24, the challenge locates the selected data stored in the game device memory via the obfuscated lookup table. The challenge accesses the select data stored in memory and operates (at step 26) on the selected data with hash functions to obtain hash values indicative of the select data stored in the game device memory. In an example embodiment, the data segments are located in memory and a hash value is calculated for each data segment. In response to the challenge, an indication of the selected data in memory is provided at step 27. In an example embodiment, the indication of the select data comprises the calculated hash values. In an example embodiment, the calculated hash values are provided to the challenger (e.g., server of the online game service). The calculated hash values are compared, at step 28, with expected hash values. Hash values may not match for example, if the select data stored in the game memory was altered. Hash values of altered select data, within mathematical limits, will differ from hash values of unaltered select data. In an example embodiment, the comparisons of hash values are performed on a server of an online game service. If, at step 32, the expected hash values match the hash values calculated from the select data stored in game memory were received as part of the response to the challenge, online game execution is allowed to continue at step 34. If, at step 32, the hash values do not match, online game execution is halted at step 35. Online game execution can be halted in any appropriate manner, such as terminating the game device logon session for example. In various embodiments, a user can be barred from online gaming for a period of time, if it is determined that the select data in memory has been altered.
The processor 36 comprises a processing portion 38, a memory portion 40, and an input/output portion 42. The processing portion 38, memory portion 40, and input/output portion 42 are coupled together (coupling not shown in
The processing portion 38 is capable of implementing in-play detection of altered game data as described above. For example, the processing portion 38 is capable of storing select data in memory portion 40, generating a lookup table, obfuscating the lookup table, protecting stored select data, locating select data in memory via the lookup table, loading an executable program of the challenge, executing the executable program of the challenge, calculating hash values, providing hash values to the input/output portion 42, or a combination thereof.
The processor 36 can be implemented as a client processor and/or a server processor. In a basic configuration, the processor 36 can include at least one processing portion 38 and memory portion 40. The memory portion 40 can store any information utilized in conjunction with in-play detection of altered game data. For example, the memory portion 40 can store the select data, the look up table, hash values, names of portions of the select data, or a combination thereof. Depending upon the exact configuration and type of processor, the memory portion 40 can be volatile (such as RAM) 44, non-volatile (such as ROM, flash memory, etc.) 46, or a combination thereof. The processor 36 can have additional features/functionality. For example, the processor 36 can include additional storage (removable storage 48 and/or non-removable storage 50) including, but not limited to, magnetic or optical disks, tape, flash, smart cards or a combination thereof. Computer storage media, such as memory portion 40, 44, 46, 48, and 50, include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, universal serial bus (USB) compatible memory, smart cards, or any other medium which can be used to store the desired information and which can be accessed by the processor 36. Any such computer storage media can be part of the processor 36.
The processor 36 can also contain communications connection(s) 56 that allow the processor 36 to communicate with other devices, such as other devices in an online gaming scenario, for example. Communications connection(s) 56 is an example of communication media. Communication media typically embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media. The processor 36 also can have input device(s) 54 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 52 such as a display, speakers, printer, etc. also can be included. In an example embodiment, output device 52 comprises display portion 28.
A graphics processing unit (GPU) 308 and a video encoder/video codec (coder/decoder) 314 form a video processing pipeline for high speed and high resolution graphics processing. Data is carried from the graphics processing unit 308 to the video encoder/video codec 314 via a bus. The video processing pipeline outputs data to an A/V (audio/video) port 340 for transmission to a television or other display. A memory controller 310 is connected to the GPU 308 to facilitate processor access to various types of memory 312, such as, but not limited to, a RAM (Random Access Memory).
In an exemplary embodiment, the multimedia console 300 includes an input/output (I/O) controller 320, a system management controller 322, an audio processing unit 323, a network interface controller 324, a first USB host controller 326, a second USB controller 328 and a front panel I/O subassembly 330 that can be implemented on a module 318. The USB controllers 326 and 328 serve as hosts for peripheral controllers 342(1)-142(2), a wireless adapter 348, and an external memory device 346 (e.g., flash memory, external CD/DVD ROM drive, removable media, etc.). The network interface 324 and/or wireless adapter 348 provide access to a network (e.g., the Internet, home network, etc.) and can be any of a wide variety of various wired or wireless adapter components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.
System memory 343 is provided to store application data that is loaded during the boot process. A media drive 344 is provided and can comprise a DVD/CD drive, hard drive, or other removable media drive, etc. The media drive 344 can be internal or external to the multimedia console 300. Application data can be accessed via the media drive 344 for execution, playback, etc. by the multimedia console 300. The media drive 344 is connected to the I/O controller 320 via a bus, such as a Serial ATA bus or other high speed connection (e.g., IEEE 3394).
The system management controller 322 provides a variety of service functions related to assuring availability of the multimedia console 300. The audio processing unit 323 and an audio codec 332 form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is carried between the audio processing unit 323 and the audio codec 332 via a communication link. The audio processing pipeline outputs data to the A/V port 340 for reproduction by an external audio player or device having audio capabilities.
The front panel I/O subassembly 330 supports the functionality of the power button 353 and the eject button 352, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the multimedia console 300. A system power supply module 336 provides power to the components of the multimedia console 300. A fan 338 cools the circuitry within the multimedia console 300.
The CPU 301, GPU 308, memory controller 310, and various other components within the multimedia console 300 are interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include a Peripheral Component Interconnects (PCI) bus, PCI-Express bus, etc.
When the multimedia console 300 is powered ON, application data can be loaded from the system memory 343 into memory 312 and/or caches 302, 304 and executed on the CPU 301. The application can present a graphical user interface that provides a consistent user experience when navigating to different media types available on the multimedia console 300. In operation, applications and/or other media contained within the media drive 344 can be launched or played from the media drive 344 to provide additional functionalities to the multimedia console 300.
The multimedia console 300 can be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the multimedia console 300 allows one or more users to interact with the system, watch movies, or listen to music. However, with the integration of broadband connectivity made available through the network interface 324 or the wireless adapter 348, the multimedia console 300 can further be operated as a participant in the larger network community, such as an online gaming community for example.
A computer system can be roughly divided into three component groups: the hardware component, the hardware/software interface system component, and the applications programs component (also referred to as the “user component” or “software component”). In various embodiments of a computer system the hardware component may comprise the central processing unit (CPU) 521, the memory (both ROM 564 and RAM 525), the basic input/output system (BIOS) 566, and various input/output (I/O) devices such as a keyboard 540, a mouse 542, a monitor 547, and/or a printer (not shown), among other things. The hardware component comprises the basic physical infrastructure for the computer system.
The applications programs component comprises various software programs including but not limited to compilers, database systems, word processors, business programs, videogames, and so forth. Application programs provide the means by which computer resources are utilized to solve problems, provide solutions, and process data for various users (machines, other computer systems, and/or end-users). In an example embodiment, application programs perform the functions associated with in-play detection of altered game data as described above.
The hardware/software interface system component comprises (and, in some embodiments, may solely consist of) an operating system that itself comprises, in most cases, a shell and a kernel. An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. The hardware/software interface system component may also comprise a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, a Java Virtual Machine (JVM) or its functional equivalent, or other such software components in the place of or in addition to the operating system in a computer system. A purpose of a hardware/software interface system is to provide an environment in which a user can execute application programs.
The hardware/software interface system is generally loaded into a computer system at startup and thereafter manages all of the application programs in the computer system. The application programs interact with the hardware/software interface system by requesting services via an application program interface (API). Some application programs enable end-users to interact with the hardware/software interface system via a user interface such as a command language or a graphical user interface (GUI).
A hardware/software interface system traditionally performs a variety of services for applications. In a multitasking hardware/software interface system where multiple programs may be running at the same time, the hardware/software interface system determines which applications should run in what order and how much time should be allowed for each application before switching to another application for a turn. The hardware/software interface system also manages the sharing of internal memory among multiple applications, and handles input and output to and from attached hardware devices such as hard disks, printers, and dial-up ports. The hardware/software interface system also sends messages to each application (and, in certain case, to the end-user) regarding the status of operations and any errors that may have occurred. The hardware/software interface system can also offload the management of batch jobs (e.g., printing) so that the initiating application is freed from this work and can resume other processing and/or operations. On computers that can provide parallel processing, a hardware/software interface system also manages dividing a program so that it runs on more than one processor at a time.
A hardware/software interface system shell (referred to as a “shell”) is an interactive end-user interface to a hardware/software interface system. (A shell may also be referred to as a “command interpreter” or, in an operating system, as an “operating system shell”). A shell is the outer layer of a hardware/software interface system that is directly accessible by application programs and/or end-users. In contrast to a shell, a kernel is a hardware/software interface system's innermost layer that interacts directly with the hardware components.
As shown in
A number of program modules can be stored on the hard disk, magnetic disk 529, optical disk 531, ROM 564, or RAM 525, including an operating system 535, one or more application programs 536, other program modules 537, and program data 538. A user may enter commands and information into the computing device 560 through input devices such as a keyboard 540 and pointing device 542 (e.g., mouse). Other input devices (not shown) may include a microphone, joystick, game pad, satellite disk, scanner, or the like. These and other input devices are often connected to the processing unit 521 through a serial port interface 546 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor 547 or other type of display device is also connected to the system bus 523 via an interface, such as a video adapter 548. In addition to the monitor 547, computing devices typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary environment of
The computing device 560 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 549. The remote computer 549 may be another computing device (e.g., personal computer), a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computing device 560, although only a memory storage device 550 (floppy drive) has been illustrated in
When used in a LAN networking environment, the computing device 560 is connected to the LAN 551 through a network interface or adapter 553. When used in a WAN networking environment, the computing device 560 can include a modem 554 or other means for establishing communications over the wide area network 552, such as the Internet. The modem 554, which may be internal or external, is connected to the system bus 523 via the serial port interface 546. In a networked environment, program modules depicted relative to the computing device 560, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
While it is envisioned that numerous embodiments of in-play detection of altered game data are particularly well-suited for computerized systems, nothing in this document is intended to limit the invention to such embodiments. On the contrary, as used herein the term “computer system” is intended to encompass any and all devices capable of storing and processing information and/or capable of using the stored information to control the behavior or execution of the device itself, regardless of whether such devices are electronic, mechanical, logical, or virtual in nature.
The various techniques described herein can be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatuses for implementing in-play detection of altered game data, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for implementing in-play detection of altered game data.
The program(s) can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language, and combined with hardware implementations. The methods and apparatuses for implementing in-play detection of altered game data also can be practiced via communications embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a client computer, or the like. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates to invoke the functionality of in-play detection of altered game data. Additionally, any storage techniques used in connection with in-play detection of altered game data can invariably be a combination of hardware and software.
While in-play detection of altered game data has been described in connection with the example embodiments of the various figures, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same functions of in-play detection of altered game data without deviating therefrom. Therefore, in-play detection of altered game data as described herein should not be limited to any single embodiment, but rather should be construed in breadth and scope in accordance with the appended claims.
