Cheat Engine: Dev Basics

This year I've been playing through a lot of premium computer games that came out around the time Facebook was a platform where a lot of social-idle games were making a lot of money and getting a lot of attention from game designers. To the point that some of those mechanics for positive feedback loop economic models was being dumped into $60 games or linked via external social games on another platform. Even in the current era, where that stuff is less in fashion, a lot of the changes are still being applied to in-game economies (when not tied to micro-transactions and the quest for "AAA whales") compared to the process of balancing a game economy from the era previous. Some games have been patched to provide all the bonuses from engaging in external social games when those social games were taken down, others simply expect players to do more grinding in the game as that was always one of the play styles they considered viable at launch.

Personally, I've been approaching it from a different angle: one of someone who always wanted to know what the cheat codes were for games, even if I ended up not using them that much during a first playthrough. As a developer who has always believed that my code is usually a guest on someone else's hardware, the cheats available to me are rather broad. I don't feel the need to limit myself to the dev/debug commands that ship in a solo game (where I have not signed up to an agreed set of rules for play in a multiplayer environment). In my consideration, the means by which games are protected from players editing memory values to play content they do not own is called copyright law (as pasting in any parts of the game you have not sold them into memory would be an obvious violation of copyright) - knowing this makes the technical means by which you should operate clear. (And the ESA or anyone trying to shill DRM are not your friends.)

Old joke: Engineer asked to itemise $1k bill for marking a cross where mfr needed to drill a hole to fix machine. $1 piece of chalk; $999 knowing where to put the cross.
Feels like Ubisoft "Time Savers" are charging for a memory address.
*Opens Cheat Engine* I've got this boss!
— Jess Birch (@Shivoa) September 21, 2019

I occasionally have lively discussions with other devs on this topic but I'm against anti-consumer snooping or memory obfuscation having any place in solo experiences that have been sold to consumers (who should then expect to be able to tweak their play experience as long as it doesn't involve grafting on copyrighted content that was not included in the sale of data). Including source code is a method of assuring players that you have not hidden any anti-consumer systems in the thing they purchased (and given some expertise, they can explore and modify their experience however they like); some modding tools even approach this level of access.

Which brings us to today's topic: Cheat Engine. This is quite an advanced tool with a long history of updates so I'm only going to talk about a few of the simpler things that a lot of people use it for. If you make games but have never played with CE then this may be a good primer for what people are talking about when they discuss Cheat Tables for your game.

The simplest function of Cheat Engine is to scan the memory of a running application to find any instances of a certain value (a bit pattern that could be read as a certain value, optionally including fuzzy scans that find anything that might be a interpreted as a value or within a delta of it for floats) and save the list of those addresses. The Next Scan function allows this value to be edited & another scan run on only the addresses already found. A player can use in-game systems to tweak a number and then find all fixed memory locations that are mirroring that change by repeatedly scanning for addresses doing what the in-game value does. A canny player can even deduce that certain values in the UI are not immediately saved back to a permanent location (and the save process may not involve copying the same location as the UI is using) so to only rescan the memory at certain points (like after backing out of a buy screen into the main game UI, completing a virtual transaction).

Knowing where in memory the values are being updated, the player can track those locations and even lock their value to prevent them changing. This is very useful if the game is updating a handful of locations with the same value and the player wants to know which value is used for future calculations as the master value and which is just mirroring (or if they missed something in a previous scan and so don't have the core location they want in their current pool of memory locations - as developers then we have an advantage in how we think about memory & knowing what processes are going on that can cause data to be moved and plenty of players doing this stuff also have that knowledge). Often applying a lock and then trying to change the value in-game will show which location is key & which can be ignored. This is where the player can now basically save-file hack in the live game and change any value they can isolate. The scans are very fast so it's quite easy to do this at any point, especially if you're looking for an unusual bit pattern (eg not 0, 1, 2, 16, etc) that's easy to repeatedly change via in-game actions on demand.

November Edit: one nuance of this is that scanning for the bit pattern is only one of the various modes. Within a range, has not changed since last scan, has decreased (optionally by a specific value)... there's a lot of ways of doing a refinement. With a bit more time (we're talking only a few seconds to index it on a modern system with a typical binary) you can even start from "I don't know the initial value", which makes it surprisingly fast to find where player health etc are being stored in memory in a lot of games. And then locking that memory area (have Cheat Engine repeatedly writing that value to the location to erase any changes by the game). The versatility of the system was something I'd not considered before giving it a poke - average users really can find ammo, health, etc extremely quickly as they control when the value changes or stays fixed then refine memory locations mirroring their expectations.

But it's not common for these offsets to be fixed, so players would have to do this whenever they want to change something and maybe that's enough friction to consider it annoying. Which is where a slower but fancier trick Cheat Engine has comes it: once a player has an address they can look for any memory in the running application that looks like an offset or pointer to that address. Then they can do the same iteration & look for that value not changing. A player will note that after a while (or load, or game restart) the location of some in-game value moves and then check to see if any of those suspected pointers have moved to the new location they've found for that in-game value. Advanced use could even follow a chain of pointers. These saved pointer locations are often stable between level loads, game loads, and even some minor patch revisions (although the last one is uncommon, which is why Cheat Tables usually have the associated patch version tied to them). There is more complex stuff with code injection and advanced tweaks that can be done for fancy tables and reactive cheats (halving damage taken, boosting XP) but the bog standard DIY stuff is usually more limited. But this is still clearly powerful enough to have worked out where your CharacterInfo struct is and know how to follow the pointers and edit various values.

If a player wants a million credits to break your in-game economy, it's probably reasonable easy for them to hack it without that much expertise (most anyone could follow a tutorial on this stuff, even if it's sometimes faster to do with some expertise to understand the underlying systems going on moving data around in memory). Once upon a time, it was standard for computer games to include cheats and some development or debug tools that would make those extra credits something that didn't require an external tool. In recent years it has become a lot less common (maybe in part due to GTA Hot Coffee and similar "scandals" related to leaving assets and tools that the player was never meant to encounter in the release version; maybe the console push for Achievements​/​Trophies as "verified played good" permanent records for player profiles).

I think this stuff is good for games. Especially a few years after release, when players are going to want to really poke at all the systems in a game and find out the limits of how things work. Obfuscation work to frustrate players trying to do this is wasted resources that could be spent making a better final product and, often, isn't even entirely successful as it just takes one smart hacker to figure out what's going on and work out how to get round it by writing memory at a certain point or injecting a bit of extra code at just the right location. It's the user's memory so it's not like you can guarantee that they won't lift it from under you. Embrace the chaos, and kindly ask players to not submit bug reports if they've been editing their memory addresses while playing a game, because this is far far outside of developer supported play.