U.S. Pat. No. 11,273,380

It should be noted that the figures are not drawn to scale and that elements of similar structures or functions are generally represented by like reference numerals for illustrative purposes throughout the FIGURES. It also should be noted that the figures are only intended to facilitate the description of the preferred embodiments. The FIGURES do not illustrate every aspect of the described embodiments and do not limit the scope of the present disclosure.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

As previously discussed, a player looking to gain additional advantages may monitor the games' memory during game play to identify where in memory certain useful program (e.g., crown-jewel) variables are stored. The present disclosure addresses these deficiencies by providing a system for code obfuscation and corresponding simplified programming tools for implementing accessing this functionality. In order to avoid exploits that attempt to monitor the software's memory file, the memory locations of protected variables are moved at regular but non-deterministic intervals. For example, if a variable comprising the player's location is protected and stored at memory location A at time T1, the system will move that variable to location B at time T2. If this is done at appropriate time intervals (e.g., every frame or every 33 ms), a player monitoring the memory will have greater difficulty in determining which memory location corresponds to the variable of interest—in this example, their location variable.

This is done by providing new managed data types, e.g., secure integer, that are protected by the game system automatically. Any general developer does not need to understand how the data is protected, only that they should use the types defined by this system for storing and accessing sensitive game values. The system then handles all memory management for the programmer and provides some configurable parameters that allow the programmer to optimize the storage of data given how it is used (e.g., written infrequently, but read regularly vs. written frequently, but read infrequently).

FIGS. 1A-Cillustrate an exemplary data flow process for code obfuscation. The system maps these abstracted types onto pools of memory that optionally obfuscate the data, slice the data into small fragments and shuffle those fragments within the pool. Turning toFIG. 1A, when initialized, a variable is split into two components: a descriptor and a raw-chunk of memory. When referenced, the descriptor contains enough information to either store-into or load-from the ‘true’ value yielded from the transformed raw-chunk. A data-transformation and/or encryption is applied to the raw-chunk. This transformation uses a random number generated during the initialization of the variable, to make two variables with the same values look different. The raw-chunk is then sliced into numerous pieces depending on the size of the variable. Each piece is then optionally masked with either a constant number, or a random number generated during game play.

Turning toFIG. 1B, the pieces are then individually stored in a memory pool. When storing, the location of these individual pieces in that memory pool are optionally masked. For example, logical operations (e.g., OR, XOR, AND, and so on) or encryption schemes (e.g., AES256) can be used to mask the pieces. At this point, the variable is considered as ‘in’ the system and labelled ‘protected.’ The descriptor mentioned above stores all the associated metadata necessary, generated or not, to retrieve the correct data from each memory pool; it is the glue between the developer and this security system. In some embodiments, the stored descriptors can be protected by an integrity check, such as a checksum. With reference toFIG. 1C, at predictably non-deterministic times, the following occur: (a) memory pools are moved in memory, (b) the individual pieces from raw-chunks are shuffled within the pool of memory, and (c) the individual pieces from raw-chunks are re-transformed, with different masks than previously used.

All of this complex computation is made transparent to the general developer. In some embodiments, this is done by encapsulating the basic-types in programming with custom wrappers by using C++'s template framework. An unprotected integer can be declared as follows:

int x=42;

This embodiment requires that the general developer only add a templated keyword around the type of variable of their choice. A protected integer would be declared as follows:

Securex=42;

When protected, all references to the variable x utilize the complex logic described above. In creating a base-layer framework that can be consumed by a general developer with an easy interface that developers are familiar with, the management of the applied obscurity and obfuscation is handled for them. In some circumstances, additional code is referenced to translate the secured value from its obfuscated form into its ‘true’ value. For example, if x=42 represents the amount of gold bars a player has, earning additional gold bars (i.e., x+=1) results in the value being temporarily transformed back to its true form in order to perform the operation before transmitting it back into its obfuscated form.

A further advantageous aspect of the current system is the creation of corresponding new data types that allow the programmers to use the obfuscated variables. As one example, a new data type named PlayerLocation can be created by an arbitrary developer and can then be made protected by wrapping it with the Securekeyword, as exemplified above.

As a result, developers do have to be mindful for the associated performance penalties in using this protection system. The process of obfuscating data values as a part of a write operation and likewise de-obfuscating data values as a part of a read operation naturally takes longer than more direct memory operations since additional CPU cycles are needed to transform the data between protected and usable forms. Specifically, the storing-to and loading-from variables becomes more complex the larger the variable is, as a result of it being broken into many more individual pieces. Additionally, there may be a performance cost when considering a situation whereby the game is attempting to read or write to a protected game variable while the system is in the process of shuffling the data. Such time sensitive operations have been factored into the design as to minimize the number of CPU cycles that the developer will need to wait in order for data to be available.

The disclosed embodiments are susceptible to various modifications and alternative forms, and specific examples thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the disclosed embodiments are not to be limited to the particular forms or methods disclosed, but to the contrary, the disclosed embodiments are to cover all modifications, equivalents, and alternatives.