Asset - Scripts GMGuard Anti-Cheat toolkit

Fanatrick

Member
banner-1140x360_1.png

Current Version: GMGuard 1.0.0

YoYoGames Marketplace: https://marketplace.yoyogames.com/assets/9382/gmguard-anti-cheat
Itch.io:
https://fanatrick.itch.io/gmguard-anti-cheat

GMGuard is a toolkit for GameMaker: Studio 2.3+ designed to protect your games from common cheating techniques - without too much setup required and with only couple lines of code.

Features:
  • Protects from memory editing
  • Protects from speed-hacking
  • Protects game-files from tampering
  • Provides deterministic cross-platform RNG resistant against common unrandomizers
    • Safe UUIDv4 keygen
  • Customizable callbacks, logging and settings
  • Unique device identification
  • Domain name white-listing (HTML5)
  • Fully cross-platform, written in GML 2.3+ using only standard lib
  • Lightweight, documented, maintained and customizable plug-n-play library
  • Reverse-compatible updates and new modules in the future
Disclaimer
  • Software tends to be vulnerable no matter the effort put into protecting it, this toolkit when used correctly will prevent 99% of usual client-side cheating. It is not a magic-bullet tool but a formidable layer that's easy to add into your existing or future projects while being simple to use and still preventing players from exploiting your game's mechanics, systems, leaderboards and savefiles in most common ways
  • Do not rely just on client-side cheating prevention for online multiplayer games, instead ensure the server has the authority over game-states
  • Asset price will go up as new features are added
  • Supports GameMaker Studio: 2.3 and above
 
D

Deleted member 45063

Guest
Haven't purchased the asset as I currently don't have any project that requires it, but looking at the code example you provide I have a question:
GML:
//////////////////////////////////////////////////////////////
// Init and lock
map = new gmguard.lockmap_create();     // create storage
gold = 100;                             // set some value
map.lock("gold", gold);                 // lock the value

map.callback_set(function() { game_end(); } );  // Optional: set a custom callback method or script

//////////////////////////////////////////////////////////////
// On change
map.unlock("gold", gold);               // unlock
gold += 100;                            // change
map.lock("gold", gold);                 // lock
Looking at the code I assume the usage of the extension to be:
  1. Create a locked map were you store the variables
  2. Register each variable and its value in the map
  3. Whenever something needs update unlock the map beforehand (supplying the current value of the variable), update the variable and then relock the variable
With this pattern I assume that how the extension works is that everything gets stored in some sort of Hash Map and if the unlock operator provides a value different than the one in the map then someone edited the memory. But this then leads me to question:

If the lock map is also stored in memory (or potentially a file) then what prevents the cheater from editing also that memory region at the same time?

Not trying to question about internals (or worse, discredit your extension), I'm just genuinely curious (and as a potential customer I wanted to question this scenario).
 

Fanatrick

Member
Thanks for the input @Mert and @Rui Rosário

Looking at the code I assume the usage of the extension to be:
  1. Create a locked map were you store the variables
  2. Register each variable and its value in the map
  3. Whenever something needs update unlock the map beforehand (supplying the current value of the variable), update the variable and then relock the variable
With this pattern I assume that how the extension works is that everything gets stored in some sort of Hash Map and if the unlock operator provides a value different than the one in the map then someone edited the memory.
You assume right, that's exactly how the memory protection module is meant to be used.

If the lock map is also stored in memory (or potentially a file) then what prevents the cheater from editing also that memory region at the same time?
Lockmaps create their own unique keys and salt which produce hashes for values you're storing. The locking mechanism will practically never produce same keys and hashes across different lockmaps and different variables that are stored. In theory the cheater would need to find the lockmap memory region, guess the lockmap keys/salt, use the same locking mechanism and know which particular slot in the hashmap is responsible for the value in question (as editing them all would raise other flags) to cheat by memory editing and defeat the particular example. Keep in mind that you can use the locking mechanism on any serialized data - even lockmaps themself (you can use string() to serialize them):
GML:
main_lockmap.unlock("character", string(character_lockmap));

character_lockmap.unlock("gold", gold);
gold += 1000;
character_lockmap.lock("gold", gold);

main_lockmap.lock("character", string(character_lockmap));
At this point already the process of cheating by memory editing becomes far less successful and efficient than cheating by other more savvy means like disassembly. In the unlikely event of success by just brute-force memory editing, keys won't match across devices and runtimes which prevents people from creating and distributing trainers via Cheat Engine and similar editors.
 

Fanatrick

Member
Do lockmaps work with structs, ds_list, ds_maps, etc..?
It accepts numbers, strings, arrays and structs, it doesn't have deep ds_* serialization included. You could do lockmap.lock("my_ds_map", ds_map_write(map_id)) to serialize and lock ds_maps the easy way.
 
Top