Anti Cheat Procedures

About Cheats

Memory Inspection


There is lots of ways to cheat a game, lets enumerate some and address it properly:
Cheat engine and other cheating tools works inspecting the memory of a target app. It creates memory snapshots as a dictionary of addresses and data. It is mainly used to search for a specific data content and changing it. An example of a process to cheat using thees tools:
  1. 1.
    Create the first app memory stapshot;
  2. 2.
    Search for content (ex. current gold value);
  3. 3.
    Track all results memory addresses with that given content;
  4. 4.
    Change somehow that amount (ex.: spend gold or earn it);
  5. 5.
    Search again for the new content;
  6. 6.
    Repeat to 4 until only one result appears.
  7. 7.
    Change it to whatever the user wants(give funds to yourself.

Memory inspection resistant

Goal: Hide sensible data in the memory
Every sensible data is stored encrypted. The process work as follows:
  • Symmetric encryption. For mutable data, we use a fast XOR encryption: the data space used for the content is doubled. One is for the data encrypted and the other is for the random key. This approach guarantees such search tools would fail. Only advanced ones would work, and I don't know any capable of exploring it. Instead of searching for only one field, it needs to search 2 and XOR it, so the search complexity would be O(N^2), a way worse search, but still viable.
  • Asymmetric data encryption. For more robust encryption and for content that does not change too much, we use asymmetric keys. So effectively, we at least triple the space needed to store the data. One for the encrypted data, one for the encryption key, another one for the decryption key.
Memory Location Policy:
  • Every time the data is read or written, the data position is changed randomly(inside an array and using dynamic memory allocation and deallocations). So effectively every time data is accessed, it moves its position. This prevents the search algorithm described before to work properly.
  • We effectively exploit garbage collection to store data in garbage sectors creating baits to falsely trigger the search algorithms.

Storage exploitability

Goal: Encrypt the local storage
  • Every local storage data is considered exploitable. So we encrypt the data stored locally, but all sensitive data is stored on our servers.
  • We protect locally the users' wallet keys in an encrypted way via a password provided by the user and even the developers cant recover it. So if the password is lost, the wallet keys are lost too. The user must protect the wallet keys elsewhere. If the password is lost, the user should reset the wallet with the passphrase seed and then recreate the password.
  • The user can set to remember the password to unlock the keys, but it is a security exploitable issue, so we don't recommend it once you become a targetable user(have too much money invested).

Data Packet Interception

  • In order to address it, we use deterministic physics simulation. We transfer only the user inputs and validate the physics on the server-side.
  • Even if the user position or other data in a play session were cheated, it won't affect the other players because we sync only the user inputs, and by the eyes of the other players the cheater will become out of sync and disconnected.
  • Every game session is unique. A seed is provided for each level to create minor changes on each obstacle.
  • At the end of a match, our servers take some time to check for the validity of it, and cheaters are banned permanently.

Bytecode Adulteration

A released package can be adulterated to bypass lots of client-side protections.
  • The server has the liberty to ask the client to hash random bytecode positions of the client from time to time.
  • We prevent jailbreak or rooted devices to run the game.

If all fails

We use enterprise-grade third-party solution services to protect the game
Last modified 1yr ago