Basic Search Techniques

These are about the easiest codes to hack. To hack one, take the value of desired item to get infinite of, and do a known value search for it. Next, manipulate the amount of it (lose a life, shoot your weapon, etc.), and search for the new value. Keep doing this until results are narrowed down enough to test some. This usually doesn't take much when searching for exact values. Most games store the simple stuff this way; however, some will use float or BCD values, depending on the game system.

04 is used in 80/90 memory range 

05 is used in 81/91/92/93 memory range

42000000 90000000 This must be the first line of the code when dealing with 90 memory range 

1. Configure the search type to 16-bit.

2. Maintain continuous pressure on a button located on the controller.

3. Input the value associated with the button you're holding into the search bar (consult the Button Value Tables for reference).

4. Repeat steps 2 and 3 until you obtain a few search results.

5. Select one of the results, right-click on it, and choose "Memory Viewer."

6. In the Memory Viewer tab, tick the auto-update checkbox located in the top right-hand corner.

7. Experiment by pressing random buttons on your controller. If the value displayed changes to match the button you're pressing, you've successfully identified the correct value. If not, select another address and retry the process.

8. Deactivate the auto-update feature and make a note of the address.

9. Refer to the Button Activator section for guidance on utilizing this address.

1. Begin with an initial 32-bit search using the value 3F800000. 

2. Choose a selection of the results and perform a multi-poke operation, setting them to 40200000. 

3. If any changes or events occur on the screen as a result of this action, revert the poked values back to 3F800000 and narrow down your selection to a smaller number of results. 

4. Continue this process iteratively until you successfully pinpoint the specific outcome you're seeking. 

1.  Start out with a specific 32 bit search of 00000000

2. Jump and hit Pause on the debugger while the character is in the air.

3. Do an unknown search set to greater than.

4. Hit play on the debugger. When the character hits the ground, do a known search for 00000000

5. Move around and then do an equal to search. This will get rid of some junk results.

6. Repeat 1-5 until you have a manageable amount of results.

7. Pick an address, and go to memory viewer.

8. Turn auto-update on and jump. If the value changes from 00000000 as you character jumps, and then returns to 00000000 then you have most likely found the right value. If it doesn't, then try another address. It should be a smooth change. Slowly going up then slowly going back down.

9. Turn auto-update off, and copy this address to notepad. Throw a button activator on it and you'll be good to go.

Timers can be painfully simple, or they can send the hacker into violent tantrums. It all sort of depends on the game and system. The general idea is to just keep searching greater/less depending on the way the timer is counting, but they can vary a lot. Timers come in any size from 8-bit to 64-bit, but 16-bit and 32-bit ones are more common.

Basic Timer Hack Strategy

1. First get to the point in the game where the timer starts counting up/down. Then pause/freeze and start an unknown value search (initial dump). 32-bit is probably the way to start, if possible. If this fails, try 16-bit and so on.

2. Now let the timer count down just a little, and do a less than search. Keep letting it count down and doing less than until the results are narrowed enough to test.

3. In some cases, restarting the timer and doing a greater than followed by continuing with the above step will help.

4. Now when the results are narrowed enough to start testing, set a constant write/freeze on the address using a high value to see if the timer still counts down. If the trainer being used lists all the previous values of the timer, a little educated guessing can help with picking out the right result to try. Sometimes a timer will be as simple as the value on screen being the same value in memory, but don't bank on it.

5. Don't be surprised if none of the results work. Try a different bit size or one of the extra tips below.

Timer Tips

* clock style (00:00:00) timers tend to be 32-bit, but they can be found even if the user is searching 16-bit. One thing to be cautious of though is the amount of time going by between searches. Let the seconds or minutes count up/down a couple digits, depending on the timer's speed.

* Don't be afraid to try searching the opposite direction when the search instructions above don't work. Sometimes a timer counting down on screen is really counting up internally. It's odd, but it happens. The timer on Starfox64 kept some hackers guessing for years because the timer on screen was stored a as 32-bit value counting down, while the real timer was a 16-bit value counting up! Just to add insult, the real timer was only a few bytes from the on-screen one.

* Beware of fake timers. A lot of timers there's both and on-screen timer and a real one. Test the code for as long as it would normally take the timer to run out to be sure it's really being stopped.

* In some cases, the right address is found, but attempts to freeze it will fail. This is because the game reads/writes the location faster than the cheat device can. The only way around this is to try hacking it with assembly. Hackers wanting to attempt this will need this address, so hang onto it.

Hacking a walk through walls code involves locating the game's clipping routines, which can often be very spread-out and embedded deep in the physics engine. This theory will focus on 3D games, but much of it can also be applied to many 2D games. 2D games simply lack a Z axis.

Locating the clipping routines may take a few different steps, depending upon the game and how it was programmed. Locating the main character's coordinates is the best place to start. Coordinates can be found with a simple 32-bit unknown search. With 3D games, there are always three coordinates named "X", "Y", and "Z". The Y coordinate is the usually easiest to find because no matter which way the character or "camera" are facing, the Y axis is always up-and-down. Reference Position Modifiers for more information on locating coordinates.

Coordinates are almost always placed in memory in order; the Y coordinate will appear between the X and Z coordinates. This idea can be exploited to locate all three coordinates after finding just one of them. Once the X and Z coordinates have been pin-pointed, these can be used to locate the clipping routines.

The second step requires a write watchpoint on either the X or Z coordinate. Choosing which coordinate to use is entirely up to the hacker, as they will typically both lead to the same routines. Setting a breakpoint on one of the coordinates will usually cause a break right away, even with the main character standing completely still. If the break-causing store instruction is disabled, sometimes additional breaks will occur. It is wise to keep a list of all addresses which cause breaks without moving, and the instruction data they contain. This makes it easy to re-enable the instruction later. As soon as there are no other breaks occuring while the main character is standing still, this step is complete.

The next step requires checking if any breaks occur while walking in an open area, without touching any walls. Most of the character control routines have already been disabled, by this point, and in most cases the main character should be "stuck" walking along only one axis. However, in a few other cases, a break will occur as soon as the main character begins to move. If this happens, the instructions causing these breaks must also be disabled. When the main character is able to glide peacefully along a single axis, the only breaks occuring should be when the main character hits a wall.

With all of the character controlling routines disabled, walking into any wall should cause a break as the physics engine is attempting to clip the character's forward movement against the wall while retaining lateral movement (to "slide" against the wall when hit at an angle). This works because most physics engines want to adjust the coordinate for clipping (the one which was disabled for standard control) separately from the standard control routines. (Note that not all games will exhibit this behavior. For such games, the clipping will be done before the standard control routines write to the coordinates.)

At this point, the first clipping routine has been located. Disabling it (either by disabling the single instruction with a NOP instruction, or by branching over the write or the entire routine if it can be done safely) should result in one of two possibilities: The character will either move through the wall, or yet another break will occur. In the case of the former, the code has been found (or at least one part for one of the two axes). For the latter, these clipping routines can be consecutively disabled, with each new routine found becoming another part of the completed code; all clipping routines must be disabled for both the X and Z axes.

That concludes the basic rundown for walk through walls codes. To recap: Locate the clipping routines by disabling the standard controlling routines. Then disable those clipping routines. Test the game with the clipping routines disabled by re-enabling all of the standard controlling routines, or simply by resetting the console with the clipping-disabling codes enabled.

Every game uses coordinate system to position a given object or character. These coordinates are located on a set of invisible axes. Two-dimensional games use two axes, referred to as the X and Y axes. Three dimensional games rely on three axes, referred to as the X, Y, and Z axes. The X axis is used for left/right movement, the Y axis for down/up movement, and the Z axis for near/far movement. As an object's X coordinate increases, it is moved to the right, and vice-versa. The same rule applies for the other axes. It is important to note that these axes have nothing to do with what is shown on the game screen. For example: the Y coordinate measures an object's absolute height, as opposed to how high the object is relative to the ground. It is recommended that 32-bit searches are used for three-dimensional games if the emulator or trainer has that option, although 16-bit searches will work just as well. For two dimensional games, 16-bit searches are usually sufficient.

1. Identify the target object or character, preferably one whose movement can be controlled by the player. Begin an unknown value search.

2. Identify the target axis. Hacking with only one axis in mind is much easier than attempting to keep track of movement on multiple axes. Remember that causing a change in the character's Y coordinates requires movement to a higher position in the level, which may not be easily accessible, so choosing to hack the X or Z coordinate may be easier.

3. Move the character several game "feet"/"meters" to the left, right, away from the camera, or towards the camera. Perform a Different To search. It's important to move the character far enough away from the original point if doing a 16-bit search. As each coordinate is usually 32 bits in length (in three-dimensional games), it's extremely important to move the character so that the first half of the value changes. For example: 0x12345678 would need to become 0x1235789A (or higher) so that a 16-bit search registers the change and doesn't discard a potential code. This is not an issue with 32-bit searches.

4. Move the character in the opposite direction, keeping the above warning in mind. Perform another Different To search.

5. Repeat steps 3 and 4 until there is a manageable number of results, preferably less than 20 or 30.

6. Test each code until the target character's movement on one axis is restricted.

7. Now the codes for the other two axes need to be found. They will usually be in close proximity to the code that was just hacked. On some systems, one can usually find another part of the code by adding or subtracting 0x04 to or from the newly-found code's offset. The offset containing the X coordinate is usually first, followed by the Y coordinate, and then the Z coordinate. Note the existing values for the surrounding offsets and enter those as codes.

* If the character is unable to move to the side or toward the game camera, then the correct code for the X or Z coordinate has most likely been found.

* If the character is unable to jump, then the correct code for the Y coordinate has most likely been found.

8. The first 16 bits of the value are usually enough to change a character or object's position, so assign those to a code and enjoy the results.

Due to their nature, position modifiers are very easy to find usable values for. Simply view the offsets from each of the codes for the target character/object's coordinates, and apply those to the target character/object's position modifier, or a completely different object's position modifier.

A speed modifier is a code that modifies the speed of an in-game character or object. In most cases, this is a 16 or 32-bit signed value in memory. When the character or object is stopped, the value is usually zero.

1. If the character is stands totally still on the ground, it's a reasonable assumption that the character's speed isn't changing. Start a an unknown value search (initial dump). If the character jitters while standing or something, the Equal To searches mentioned here may need to be skipped. This makes it more difficult to narrow the results, but it's still possible.

2. Move around a bit, then stand still again. Search Equal To. Repeat this step a couple times to eliminate some junk results.

3. Now start moving. Without stopping, do a Greater Than search.

4. Once the character stops or diminishes in speed, do a Less Than search.

5. Repeat the steps above until the results list is narrowed considerably.

6. When ready to test some results, try setting the speed to something really low. If the character is going really slowly, a speed mod has been found!

7. Once the correct address is found, try different values until the desired level of speed is reached. A value set too high may launch the character careening through the level or it may even crash the game.

8. Once you have your code, it's a good idea to put an activator on it. Else, the character will always be moving at fast speeds. Some good choices for activators include a "moving/not moving" flag in memory, or even button activators if an alternative isn't found.