Cheat Engine

[cooleko]

An old man stuck in his ways of cheating games just as it was done in the 90s would love to know if there are easier ways to do it with all the new features that seem to pop up every few months.

The problem: some engines use one instruction to write every address, so the standard AOB injection becomes much more tedious.

The old way of doing it is to gather all of the addresses you like and slowly, one-by-one check the surrounding values, registers, and stack until a pattern emerges so you know how the game is discerning values from one another. This has always been tedious and in my old age I'm just not always up to doing this for a few hours each time.

Is there a better way? Have I been doing it wrong for the last few decades? Is there a new feature to cheat engine that makes this easier to scope out?

I have been meaning to write LUA that makes this easier via break and trace by supporting a list of desired addresses instead of just one that when the instruction accesses one of them it automatically stores the values from the register/stack for easy reference. One day, I dream.

I noticed that the new find commonalities between selected addresses gets really close to helping but I never seem to get the results I'm looking for from there.

I'm currently experiencing this in "Tales of Maj'Eyal." Super easy to find addresses but trying to find a way to reset cooldowns for every character ability while not touching any of the thousands of other addresses the same instruction reads/writes is taking much longer than I would like.

Any advice would be welcomed. It doesn't even have to be for the game I'm working with since this problem is common to lots of different engines.

[TheyCallMeTim13]

You could backtrace to where the "setValue" function (or whatever they might call it) is called. All those might me in different places.

Or you could use the "injection copy" method and store the base of what you want to change and compare against that.

[++METHOS]

The last step of the CE tutorial covers data structure dissection, which is a good starting point.

There are many ways to filter out addresses:

• You can use a pointer address for your filter, inside of your script, for the value that you are trying to manipulate.
  
• You can use pointer trees inside of the data structure to find something viable.
  
• You can shift the data structure (+ or -) and/or expand its size to find something useful.
  
• You can use the structure spider to find workable strings and/or for comparative analysis.
  
• You can check the register values by attaching the debugger or setting a breakpoint to see if something can be used for your filter (or the use the new commonalities feature).
  
• You can check to see if there are any instructions that are exclusive to the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
  
• You can check to see if there are any instructions that are exclusive to any other address/value inside of the data structure for the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.
  
• You can analyze assembly code to see if an identifier is being checked or assigned somewhere.
  
• You can backtrace from injection point to determine of there are any instructions that are exclusive to the value or address that you are trying to manipluate
  et al.

[cooleko]

Thanks for the responses guys! So nothing has changed :) ++Methos has been using that list for at least a decade now!

[++METHOS]

[danrevella]

This argument is really interest...
Please, are there any "deep" tutorial about?
Also video tutorial will be ok for me..
As @cooleko I'm too old (65) to still learn without help...
Thanks to all.
Dan

[cooleko]

[TheyCallMeTim13]

Actually what I was referring to is the idea that at some point it's separated already. So you have say "player.setHealth" and in that it calls "entity.setHealth" and passes the player object, and in that it calls "setValue" and passed a "value" structure. So if you backtrace the function calls to "player.setHealth" you can change the value for just the player.

[++METHOS]

[danrevella]

[cooleko]

I'll give you an example based on the game "They are Billions."

It is an RTS, where the map has resources, fog of war, units, buildings, towers (think tower defense) and enemy units.

There are a number of ways to cheat. I'll discuss it with respect to what I call an entity structure. If it exists and is manipulatable by the user in the game, it is an entity.

Every entity has a name, health, armor, vision radius, movement speed, build time, and the requirements to both build it and sustain it. If the entity is a unit, it has two pointers to different structures based on whether it is a regular unit or a veteran unit with aspects of its damage, attack range, attack delay, refire delay, projectile speed, and splash radius.

If you want to give your units infinite health, you would see what accesses the health value. One hit kills is attack damage values. One hit clear map is splash damage values.

Unfortunately, every single instruction, regardless of whether it accesses vision radius or unit damage, is called for both player entities and enemy entities.

The easiest way to continue using AOB injection is to figure out what addresses, in this massive collection of potential addresses in the entity parameter structure, are informative to whether the unit is owned by the player or not.

What I quickly noticed is that every entity in the game has a vision radius that is constantly polled to see if it should perform a new action based on what it 'sees'. I also noticed that only player controlled entities had an associated build time value. So to make the game easily manipulated, I set my code to run one the getVision instruction and further check the structure location of build time and if 0, terminate (that was for an enemy), and if anything else (my units) to execute my code.

My code could be further conditioned on something like the entity name, whether it had the pointer to regular or veteran unit stats, or anything else to have the desired effect.

I didn't have to choose getVision, I could have chose setHealth or any other function and since I knew the unique location to check (build time) I could easily discern friend from foe.

In another example (still They are Billions), I noticed that if the user clicks on a unit, all of its stats are pinged with a unique instruction instead of the global one. So I could also write an 'on click' edition of the same code with fewer checks based on whether I wanted to code to run in the background or require user interaction.

That is what I consider the super easy version of shared function calls as it is trivial and required little time and effort.

For the harder version of the issue, where the shared instruction is used by every function call in the game, more work must be put in.

The video I linked relates to if you want to see real time use of back tracing function calls to find a specific function instead of a globally used one. In that example, instead of the function being specific (in They are Billions example the entity parameters function was specific to entities, just globally used, so you couldn't backtrace further).

The video addresses what Tim13 rephrased to be the difference between a setValue function and the originating function, player.setHealth. Just note that even if you found a "setValue" function such as what is being discussed here, there may not be a "player.setHealth" function easily accessible as the differentiation may exist only in structure, not function call, so a backtracinge of the "setValue" function would only find a shared "entity.setHealth" from which you will have to find a difference within the structure to further condition from (like I described for They are Billions).

Jumping back to a word description of the "setValue" shared instruction, what happens is you have to backtrace your way through one or more levels of function calls.

Same as with the first example, there are easy instances and hard instances. In the easy instance, the originating value is accessed in the same function so you just scroll up in the code and see where it is set into the register or memory address your shared instruction uses. This is very common when you find an encrypted value. This is also unlikely the case for our discussion.

An intermediate difficulty instance is when the function call takes the value to be set as an input parameter. You scroll up, see that it is in a register, break and trace to find the calling instruction, scroll up and break and trace from where that value is set and find the originating value that way. That involves both scrolling up in the code to understand where the values are coming from as well as used of break and trace to step up in the chain of function calls to find the originating function.

The hardest difficulty instance which I'm stuck in for Tales of Maj'Eyal, is when the values are, or appear to be, obfuscated. Scrolling up gets lost in a myriad of cyclical instructions, 5 function calls deep in the break and trace step-up are still calling thousands of times and you begin to lose hope because there is no longer a super clear instruction history step through to find the originating function call (the "setHealth" that only touched health instead of setValue).

Perhaps all I need to do is step up two more function calls, or maybe I'm hopelessly lost and chasing the wrong chain of function calls due to the obfuscation and even if I step up 20 times I'll never find what I'm looking for. If you encounter the hardest difficulty, just run and hide. What is usually a straightforward path to success just invites hours of frustration! ++METHOS and Jim13 make it sound simple, and maybe it is if you approach it with their experience and knowledge, but that doesn't translate well unless they already tackled the exact instruction in the exact game and can dispel the mysteries for you to see and understand where you missed something that would have made your life much easier.

Hope this helps frame the problem for you, danrevella, so that you can find your own solutions as you tackle new games!

[danrevella]

Many thanks!! Many thanks to all!!
@cooleko, your examples are clear, so I have decided to buy the game "They are Billions.", I have find it on steam.
If I'll not be able in reversing the function, at least I will get a good game to play....
Have a good time!