These are of course just some tricks the games work with, but now you know how tricky games could be!
Try to be trickier and find a lot of stuff!
If you start searching with the Unknown search-method and continue searching with the search-methods "Changed" and "Not changed" you will find also values that are hard to find (you will also find values that you will not find using the "Increased" and "Decreased" search-methods).
Some games store the values (best example: your number of lives) with one greater or one less than the displayed value.
If you have 3 lives left, it could be stored as 3, as 4 (3 left and the actual life you are playing with) or as 2 (just the 3 lives left, and 0 is your last life).
The Range search-method is useful if you know, that the value you are searching for is between two other values.
For example, is a timer (for example the timer in the game Hunter Hunted from Sierra).
In this game the timer is in every game on a different place in memory. Even if you restart a level the timer will be on a different location. When I found the address of the timer I recognized that the remaining seconds (in the game) are multiplied with 20 (in memory).
If you once know this, the search for the timer in the game Hunter Hunted is easy: just take the timer-value (example 100 seconds), multiply it with 20 (you get 2000) and search with the Range search-method for a 4 Bytes value: 1st value 1950, 2nd value 2050. Then play a bit and on the next search choose "Decrease". You should find the address quickly!
If you search for a value and you do not know the exact value (example a timer or the shield-strength) you have to search with the Unknown search-method. If you could not find a certain value you should also use this search-method.
In the game Mass Destruction for example you see on the screen the tank-armor 1000 but the game stores this multiplied by 6 (stores 6000).
You can reduce the number of searches if you search not always for the same kind of changes. If you always search for lower values it takes more searches to find the address, than if you search for lower, higher and equal-values (changing the kind of changes).
So try to loose some shield, search, then play a bit without loosing any shield, search, then loose some shield, search and so on. Then you should get some shield (by restarting the level, loading a savegame or picking up an shield-restore-item) and search again.
If you JUST search for the same kind of changes (example: you search always for lower values by loosing some shield) it takes much longer.
You can find this way a lot of stuff, like the x- and y-position of the player or the speed of a vehicle.
Some games do not just have one god-mode. They have many god-modes!
Like a god-mode for not getting hit by bullets, a god-mode for not getting injured by explosions, one for not getting hit while falling down and so on.
It could be possible that the value of an address you have found (for example health or a timer) is stored in the next level/stage on a different address in memory. If you restart the current level the values could be on the same address (means, the health for level 1 is always at the same position). It could also be possible that these values are stored on every re-initialization of a level (loading a savegame, getting to the next level, loosing a life) in a different position in memory.
Example: If you have found the timer in level 1, and restart the level, the timer is stored in a different address in memory!
The reason why you find the health in one level but it is stored in the next level on a different place in memory could be, that the game first stores the level-data in memory (every level is different) and then the player-data.
In the game Shadows of the Empire for example you will recognize, that your number of lives and your challenge-points are stored always at the same memory-address! Your health is stored in every level at a different address in memory (even in every stage)!
In the game Commandos (German Version) the bullets of your sharpshooter are stored in a different position in memory after every re-initialization of the level, even if you save a game and load it afterwards the address will be different!
I recognized that in some games only some values change their position in memory. The other values are at every level/stage always at the same position in memory.
The game Deathtrap Dungeon for example stores the player-health at every re-initialization of a level at a different position in memory. The other values are always at the same position.
Other games store the health always at the same position but the other stuff (weapons ammo) is always changing the position in memory.
The addresses mostly change their position at the same way (means that they all moved with the same difference in memory) so you can use the "Auto apply the offset" to make them valid.
Values could be multiplied with an other number (example: the tank-armor in the game Mass Destruction is multiplied with 6, or money in Warcraft 3 is multiplied with 10). Games do this to have a more detailed damage calculation.
Values could be calculated with a fixed number.
Example: 100 bullets are stored as 12300 (12200+100), 50 bullets are stored as 12250 (12200+50) and one bullet is stored as 12201 (12200+1)
- Games store the health this way to have a more detailed damage-calculation.
Rach health-point is stored with 3 (just as an example) values.
0 Health = 1, 2 or 3
1 Health = 4, 5 or 6
Of cause only one value (of the 3) is stored in memory.
You can find health stored at this way only with the Unknown search-method.
Health stored as Damage.
Your amount of health could be stored as health (so if you get hit it decreases).
It also could be stored as damage (if you get hit it increases). When the damage is at a maximum value you will be dead.
So if you search for your health and could not find anything (also not with the Unknown search-method) you should try to search for a damage value.
Values could be stored in many addresses (with checking the result to prevent people from cheating)!
The best example here is the game Diablo.
Your Hit-Points (Health) are stored in Diablo the following way:
The Hit-Points (example 127) are divided by 4 and the result (31.75) is rounded down (result 31). The first address in memory stores this value 31. If you multiply 31 by 4 you get 124, so there is a difference of 3 between 124 and 127. This difference is stored at the next address in memory.
So if you have 127 Hit-Points they are stored in memory as the values 31 and 3!
Sometimes games work with so called "slots" (inventory-slots).
In the game MDK for example works with these slots. There you have so called slot-addresses in memory, where one address stores the type of the item you have and an other address stores the quantity of this item. You also have a slot-counter (how many inventory-slots are filled with an item).
If you change only the address, that stores the type of the item, you can convert one item into an other! The capacity stays the same!
So if you want to give you an inventory-item (in this example you have nothing in your inventory before) you have to increase the slot-counter by the value 1 (in our example to 1), enter at the address, that stores the type of the item for the inventory-slot 1, the type of item you want to have and enter at the address, that stores the quantity of the item for the inventory-slot 1, how many items you want to have!
Many items could be stored in one byte (one address). One byte contains 8 bits.
The game Frogger uses this technique to store the baby-frogs you have collected.
At his game the green-frog is stored as the value 1, the yellow-frog is stored as the value 2, the purple-frog is stored as the value 4, the blue-frog is stored as the value 8 and the red-frog is stored as the value 16.
If you want to have all frogs collected you have to enter the value 31 (1+2+4+8+16).
value 1 - 1-st bit is on
value 2 - 2-nd bit is on
value 4 - 3-rd bit is on
value 8 - 4-th bit is on
value 16 - 5-th bit is on
value 32 - 6-th bit is on
value 64 - 7-th bit is on
value 128 - 8-th bit is on
Values stored in many addresses.
The value 1244 (your money for example) could be stored in one address.
But it could also be stored in 2 addresses (one address is having the value 12 and the other the value 44).
This value could also be stored in 4 addresses (every address stores one digit).
Reload needed before searching.
In some games like Half Life (German Version) you have weapons and bullets. In the game you can reload your weapons. I recognized, that I had to reload the weapon before I started the search for the ammo of it. Only then I found the ammo for my guns.
Change of the weapon necessary.
In some games I noticed the following: I searched for my ammo (for example: my shotgun-ammo) with the Exact Value search-method.
I recognized that the number of found addresses was not changing: I always found 80 addresses even after 14 searches.
My current ammo for the shotgun was 32 shells.
Then I went back to the game, did not shoot but changed my weapon. Now I was holding a pistol with 179 bullets.
Then I searched again for my shotgun-ammo (32 shells) and found 1 address! This was the address of the ammo.
So the other 79 addresses stored the ammo of the current (selected) weapon. After I changed the weapon these addresses were also changing their value.
Numbers are stored inverted.
Numbers could also be stored inverted in memory. The numer 52 could be stored as 25 and the number 1234 could be stored as 4321.
Games could make this to hide or protect the values without having to decoding it.
Of cause all these tricks could be mixed up!
Like the value is stored as text and inverted (the other way around) or a timer is stored as Float-value in one address (the minutes are the value in front of the decimal point and the seconds the value behind it).
You can find these values only with the Unknown search-method.
If you have found some other ways, how games hide their values, or have other tips, tricks or hints, please send them to us.
Written by Oliver Sahr.
Copyright (C) 1996-2017, System SoftLab
Last update of this page: July 29, 2017.