🔓Safety

Safety

About Cheats Memory Inspection Context There are many ways to cheat a game, let's enumerate some and solve them correctly:

The cheat engine and other cheat tools work by inspecting the memory of a target application. It creates memory snapshots like a dictionary of addresses and data. It is mainly used to look up a specific data content and change it. An example of a process for cheating using these tools:

Create the application's first memory snapshot;

Search by content (eg current gold value);

Track all memory addresses of results with that given content;

Change this value in some way (eg spend gold or win);

Search again for the new content;

Repeat up to 4 until only one result appears.

Change to whatever the user wants (Give funds to himself. Memory inspection resistant Purpose: Hide sensitive data in memory All sensitive data is stored encrypted.

The process works as follows: Symmetric encryption. For mutable data, we use fast XOR encryption: the data space used for content is doubled. One is for the encrypted data and the other is for the random key. This approach ensures that these search tools fail. Only advanced ones would work, and I don't know any capable of exploiting it.

Instead of searching just one field, it needs to search 2 and XOR, so the search complexity would be O(N^2), a much worse search, but still viable. Asymmetric data encryption. For stronger encryption and for content that doesn't change much, we use asymmetric keys. So effectively, we've at least tripled the space needed to store the data. One for the encrypted data, one for the encryption key, and one for the decryption key. Memory location policy:

Every time data is read or written, the position of the data is changed randomly (within an array and using dynamic memory allocation and deallocation). So effectively each time the data is accessed, it moves its position. This prevents the search algorithm described earlier from working correctly. We effectively exploit garbage collection to store data in garbage sectors by creating lures to falsely trigger search algorithms.

Storage Exploitability Purpose: Encrypt local storage All local storage data is considered exploitable. Therefore, we encrypt the data stored locally, but all sensitive data is stored on our servers. We locally protect users' wallet keys in an encrypted form via a user-supplied password and not even developers can recover it. So if the password is lost, the wallet keys will also be lost.

User must secure wallet keys elsewhere. If the password is lost, the user must reset the wallet with the password seed and then recreate the password. User can set to remember password to unlock keys, but it's an exploitable security issue, so we don't recommend this when you become a targeted user (with a lot of money invested).

Data Packet Interception To address it, we use deterministic physical simulation. We only transfer the user inputs and validate the physics on the server side. Even if the user's position or other data in a game session has been cheated, it will not affect other players because we only sync the user's inputs and in the eyes of other players the cheater will be out of sync and disconnected.

Each game session is unique. A seed is provided for each level to create small changes to each obstacle. At the end of a match, our servers take some time to check the validity of the match, and cheaters are permanently banned. Bytecode Tamper A released package can be tampered with to bypass many client-side protections.

The server is free to ask the client to hash random positions in the client's bytecode from time to time. We prevent jailbreak or rooted devices to run the game.

If all else fails We use enterprise-grade third-party solution services to secure the game