EnHacklopedia:Generic Code Hacking

Using Trainers

Trainers come in various forms and are called different things (code generator, code searcher, etc). They may vary in look and features, but they all function the same way. They "dump" the memory from a game and search for values in it. Most trainers save this dump temporarily for making relative comparisons (greater/less/equal/different) at different points in the game. The idea being to change something in the game and compare the new memory to the old, in order to find which locations in memory have changed each time. This allows the hacker to find the address in memory of something, whether it be lives, health, or removing Lara Croft's underwear on Tomb Raider.

Typical Search Options

• Initial Dump / Start Search - This grabs the current memory for comparing to after causing something to change.
• Known Value - Searches for a user entered value.
• Greater Than - Find values that have increased.
• Less Than - Find values that have decreased.
• Different To / Not Equal To - Find values that have changed.
• Equal To - Find values that are the same.
• In-Range - Find any value within a certain range (like between 1 and 10).

An Example Search For a Health Bar

1. Get to the point in the game where health is actually displayed.
2. Start Search (Initial Dump).
3. Get back in the game and lose health.
4. Search for values that are Less Than.
5. Go back to the game and lose health again.
6. Search Less Than again.
7. If health is gained by pickups or something, pick one up, and search Greater Than.
8. Repeat this until the number of results shown by the trainer is reasonably small. Sometimes it will narrow all the way to 1 result, but don't count on it.
9. Test the result(s) until one effects health.

Known Value Searches

A known value search is the most basic search that there is. It is used to search for things that you know the exact value of, generally something displayed onscreen, such as a score or number of lives. It's worth keeping in mind that the on-screen value is not necessarily the value that is stored in memory. It is not uncommon for the value to be stored in memory with one added or subtracted to it. Additionally, the value may be stored as a BCD or float values instead of a normal hexadecimal number. If searching for known values is not successful, unknown value searches may be necessary to find the code.

Unknown Value Searches

For use when the user doesn't know the exact value to search for, like timers, and health bars. Unknown value searches consist of comparing memory dumps in relation to how the target has changed. If health/time decreases, search "Less Than." If it increases, search "Greater than." Examples of such comparison search options include: Greater Than, Less Than, Different To, and Equal To.

Signed Searches

Some trainers allow signed searching by sign-extending values being compared, just as the game would sign them for doing things. This allows for finding things that would might be handled by a game as negative values. With a regular 32-bit search, for example, 0xFFFFFFE0 would be greater than 0x42C80000. However, if these were compared as signed, 0x42C80000 would be greater because 0xFFFFFFE0 is read as negative 0x20 (-32). Games use signed values for anything from acceleration to coordinates. For example, acceleration might be stored by a game as a negative value while driving in reverse because that's how vectors are stored. The direction is like the most significant bit, so looking at them signed makes them easy to search for. There are also times when games display a negative number for something on the screen as well.

• Unsigned
  • For 8-bits
    • 0x00 -> 0xFF = 0 to 255.
  • For 16-bits
    • 0x0000 -> 0xFFFF = 0 to 65535.
  • For 32-bits
    • 0x00000000 -> 0xFFFFFFFF = 0 to 4294967295.
• Signed
  • For 8-bits
    • 0x00 -> 0x7F = 0 to 127.
    • 0x80 -> 0xFF = -127 to -1.
  • For 16-bits
    • 0x0000 -> 0x7FFF = 0 to 32767.
    • 0x8000 -> 0xFFFF = -32768 to -1.
  • For 32-bits
    • 0x00000000 -> 0x7FFFFFFF = 0 to 2147483647.
    • 0x80000000 -> 0xFFFFFFFF = -2147483648 to -1.

Hacking With Emulators

An emulator is a computer program that acts as a virtual game console, so to speak. It imitates the actual hardware in order to run backups of games (ROMs) for the given system. There may not be an emulator for every system, or the ones available may not work very well (if at all). Not every emulator can run every game. This is partly because of incompetence on the part of emulator authors, especially in the case of Nintendo64. The authors do NOT provide ROMs, so don't ask!

Some emulators have built-in cheat searching utilities, just like trainers for the consoles themselves. They work the same way. More information on hacking with specific emulators may be found with the in-depth system info for some systems. There are alternatives to built-in trainers as well, like external programs used in conjunction with an emulator or using save states. These methods can be lifesavers when an emulator's cheating utilities are lacking or non-existent.

Renegade

Most trainers and hacking tools available are for specific consoles and/or emulators. Renegade, on the other hand, is one of the few hacking tools made to support many emulators and pretty much anything else that allows the user to save a copy of the memory. Renegade can seem overwhelming at first, but hacking normal codes with it is really the same as anything else.

Attaching to an Emulator

1. Start the emulator, and get a game running.
2. Pause the game. Most emulators have the option to pause emulation entirely. This is recommended.
3. Open Renegade
4. Go to the Cheating menu. Choose Attach To Emulator.
5. Choose the emulator that's running in the dialog box. The textbox beside there will tell if the running emulator was found by Renegade or not.
6. The Attach button should be enabled when it verifies the selected emulator is running. Click Attach
7. Now go to the Cheating menu and choose Code Search, Memory Editor, or open both.
8. Now the search options look pretty much the same as in any other trainer; there's just a lot more of them.
9. Do an Initial Dump or Known Value search to start.
10. Switch back to the emulator and change the thing being hacked.
11. Pause the emulator again, switch back to Renegade, and search accordingly.
12. Keep this up to narrow results as with any other trainer.
13. When the time comes to test results, the results window displays the addresses in the form of raw addresses. This simply means that the user is expected to use the right code prefix, etc for the system being hacked (80/81 on N64, for instance).
14. Another thing to note is that the results are automatically stored in a text file in the searches directory each time the Results button on the Code Search window is clicked. The filename is always search#.txt. The results can also be exported as N64 codes for easy testing.

Comparing Files

1. Open the Code Search window without attaching to an emulator as described above. If it was already attached, simple select Detach From Emulator from the Cheating menu.
2. There's an option to specify the byte order.
3. Also notice the Header option. This can be configured to ignore the first so many bytes (header) of a file.
4. If doing a Known Value search, one file is required to start.
   • On the Search Type dropdown list choose Known Value, In-Range, or any option that can be done with a single file.
   • Click the Search button and a file dialog appears. Choose the file to be searched. Searching will commence, and result count will be displayed
   • The search can be continued by simply setting the search type as desired, and clicking search again. The dialog will prompt for choosing the next file.
5. For doing comparison searches, there is no actual "Initial Dump." Just start by comparing the first two files.
   • Set the search options for the desired comparison and click the Search button. The difference here is after the dialog prompts for the first file, it will immediately prompt for the second.
   • The search is continued the same as if it were started by searching for a known value. Choose search options, then click Search to be prompted for the next file.

Save States

Save states are like a RAM dump, a copy of the game's memory at any given time. These can be compared or viewed in a hex editor just like a regular RAM dump. Most emulators have the option of saving the current state of the game. Some are even nice enough to have an actual "RAM Dump" option.

Two Important Notes About Save Sates

1. Save states typically have extra information in them besides the RAM dump itself. This is in the form of extra bytes before or after the actual dump shows up in the file. The number of bytes varies by emulator but not by game. This is because different emulator authors store information differently. Finding the right RAM addresses for values found in these files is just a matter of subtracting the size of the header from the address in the file. Meaning if the header is 0x40 bytes and the a code is found a 0x45690 in the file, the actual RAM address would be 0x45650. This is pretty much the same concept as porting codes, but the porting is being done from save sate address to RAM address.
2. Some emulators will compress save states by default. These will need to be uncompressed before they can be handled as normal RAM dumps. Some emulators have the option of turning off the compression, others don't. In most cases, programs like WinRAR can decompress the save states because they use common compression algorithms. However, there are times when this won't work, and there isn't really any solution short of asking the emulator author.

Guess and Check Style Hacking

To Do

Porting Codes

To Do

Pointers

A pointer is an address in memory that actually contains the value of another address. Say for example the 8-bit values at 0x80045020 are 0x80 0x25 0x78 0x40. That's probably a pointer to the address 0x80257840, rather than just the values of something. Games use pointers to keep track of where certain blocks of data are located in the memory. The pointer usually references the beginning of such a block. Some cheat devices support loading these pointers from the address given in order to write to the address plus a user defined offset. For instance, health may be at 0x80257854 in memory. The pointer at 0x80045020 indicates that the block of data (player data in this case) starts at 0x80257840. The difference between the beginning of the data block and the health location is 0x14. Now a pointer code type could tell the device to load the value (pointer) at 0x80045020, add 0x14, and write the value for full health to the resulting address.

Miscellaneous Hacking Tips

To Do

Fake Codes

To Do

Infinite Money/Ammo/Items

[Difficulty: Beginner]

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 (eg. lose a life), 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.

Have Items

To Do

Activating Unlockables

To Do

Level Modifier

To Do

Character/Team/Costume Modifier

To Do

Moon Jump

[Difficulty: Intermediate to Hard]

With this type of hack, the objective is to find the player's up/down acceleration. A more technical name for this would be a Y Speed Modifier, because it alters the speed the player's Y coordinate is moving. This causes the game to think the player is floating upward just as if the jump button was pressed. In some games, there is no jump button, but this can still be done if there's a place to fall off of as falling is part of Y speed too.

There are multiple ways to go about these, since different games on different systems tend to handle it differently. The basic theory doesn't change much with the search methods though. Y speed is usually a 16 or 32 bit signed value in memory. It increases when moving upward, and decreases when falling. This is signed because most games store vectors this way. The value is based on both the direction being moved and how fast the player is moving in that direction. Most times, Y speed will be 0 when standing still, but don't rely on this. If the player has a little bouncing stance or something, the Y speed could very well be changing just slightly the whole time. Also note that on older systems (like NES/GBC), Y speed can be as simple as an 8-bit value being 0 on the ground and 1 or higher while moving upward.

The GLEE Method

The "GLEE" method was pioneered by macrox. The basic theory at the time was that the player's Y speed increases when not on the ground (whether rising or falling). This may seem to contradict the theory above, but it's still technically true. This is because the GLEE method treats moon jumps like most other basic codes: it uses unsigned searches. The steps are outlined below. It's probably best to set whatever search tool is being used to compare 32-bit values first, if available. If that option is unavailable or doesn't work, try 16-bit and so on.

1. If the character is stands totally still on the ground, it's a reasonable assumption that Y 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 jump, or fall from a high place if the game has no jumping. While in the air and rising/falling, search Greater Than. Even if the game does allow jumping, falling from something instead to do the Greater Than might shave some extra results off the list.
4. Once the player lands on the ground again and is standing still, search Less Than.
5. Repeat the steps above until the results list is narrowed considerably.
6. When ready to test some results, jump again (if possible) and do a Greater Than while still rising. Catching the value when just beginning to rise is best, though not always easy. The current value should give an idea of what to use for a moon jump value. Turn on a result at a time and look for effects on the player's Y speed.
7. Once the correct address is found, try different values until the desired rising effect is reached. A value too high can orbit the player instantly (and even crash the game), and a value too low will force the player to the ground or perhaps keep the play from falling. On games that don't allow jumping, try freezing the value of each address to 0 and attempting to fall until an effect is noticed. Note that getting the rising effect on games which don't allow jumping sometimes still requires falling off something.
   • If the game doesn't allow rising without falling off something, then be possible to hack a code to tell the game the player is in the air. This can be hard or next to impossible on some games, but it works on others.
   • The idea is to start a new search while standing still. Then move to a different position, and search Equal To.
   • Fall off something, and search Different To while in the air. Following this up with an Equal To while still in the air might help cut down the results.
   • Once the player in back on the ground, search Different To again. Repeat these 3 steps until the results are narrowed.
   • Try the results with addresses nearest the Y speed address first. Doing this can sometimes save time, especially when it gets hard to reduce the amount of results and there are still a lot left. When testing results use the value from when the player was in the air along with the Y speed code to attempt forcing the player to rise.
8. After locating the Y speed and the right value to get the player rising up without actually jumping to the moon, look up the button activator/joker for the game and the button value desired for the moon jump code. Using the same button the game does to jump is the preferred choice.
9. Put the Y speed code with the activator and test it. If a code was hacked to tell the game the player is in the air, put this on an activator for the same button.
10. Enjoy the new moon jump code.

Signed Searching Method

Another way to hack moon jumps is with signed searching. This can be useful on some systems, if a trainer is available with the option.

1. Start an unknown value search while just standing still.
2. If the game leaves the player standing completely still, then it's safe to assume the Y speed isn't changing. Move around then stand still again. Search Equal to. Repeat a few times if desired.
3. Now here's where signed searching differs from GLEE. The Y speed is positive while rising up, negative while falling, and either 0 or slightly less when standing still. Press the jump button and quickly freeze the game while the player is still rising. Search Greater Than.
4. As the player begins to fall, search Less Than.
5. When the player hits the ground and is standing still again, search Greater Than.
6. Now jump again, and quickly freeze the game while rising once more. Do a Greater Than search.
7. This may have been enough to get down to a decent amount of results. If not, repeat the steps as needed, remembering the way Y speed values work signed.
8. Once the results are done enough to warrant even looking at them, look for the positive, negative, 0/negative combination of current and previous values for each result. Pick out the ones worth trying and test them with the positive value. The value may still need to be increased a little, but again, keep in mind the signing factor. Don't raise it too high and turn it negative or the player will be glued to the ground.
9. Take the right address and value, and put the code on an activator for pressing the jump button (or other button, if desired).
10. Up, up, and away!

Speed 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. Keep in mind that simpler systems such as the NES and GBC may use 8-bit values for the speed value.

To hack this code, a slight deviation of the GLEE method may be used.

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.

Position Modifier

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.

Infinite Time

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 timer 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.

Size Modifier

To Do

Objects That Change Size Normally

To Do

Objects That Never Change Size

To Do

Image Modifier

To Do

Cutscene Modifier

To Do

Skip Intros

To Do

Assembly Hacking

Assembly is a generic all-encompassing term for human-readable machine code. A CPU is very good at working with numbers and interpreting their meanings; humans are at a disadvantage here, and it makes working with machine code very difficult. Assembly makes it quite a bit easier by providing a 1:1 ratio to machine code. Where machine code might look like a long string of ones and zeros, assembly might look more like this:

Opcode          Operands          Comments
lw              r0, =0x203FA70    @ Load pointer to lives variable
mov             r1, #31           @ Load number of lives we want
str             r1, [r0]          @ Store lives value to variable
bx              lr                @ Return

This example is ARM/Thumb assembly for CPUs such as the ARM7 and ARM9 available in GBA and NDS. The comments help the programmer understand the assembly code even better than the CPU does; the CPU will execute any instruction given to it without determining the consequences or raising concern. The responsibility of executing the right instructions falls solely on the programmer. This example brings to light what is meant by "human readable machine code." Compared to "0011010011101001100101..." the assembly is a lot more understandable.

That aside, assembly is not without its own faults. It is often very difficult for a novice (with no previous programming experience) to learn and understand. This is due to assembly's naturally low level; an assembly programmer talks to the machine in its own language (via a translator).

Programs that translate assembly into its machine code counter-part are called assemblers and are available for various target CPUs and platforms. The target CPU is what the assembler needs to output machine code for. The platform is the CPU/OS that a programmer will use to write the assembly and translate/assemble the code. Assembling code for a target that differs from the working platform called cross platform development.

Hacking assembly is just the opposite; a hacker will translate machine code into human-readable assembly to understand the code and make changes as necessary. A program which does this kind of translation is called a disassembler, which are just as widely available as assemblers. The trouble is, few disassemblers output assembly that can be assembled back into machine code by an assembler. For the purposes of this tutorial, doing so would be out of scope because it is not usually a requirement to rebuild an entire program just to hack it. Renegade64 contains a code assembler which is much closer to what a hacker will use when patching assembly.

Rundown of Assembly Languages

Assembly languages define a set of instructions specific to one family of CPUs. Depending on the CPU or assembly language, there may be only a small handful of instructions, or there may be a vast library of instructions available to the CPU. There are two common terms for CPUs which define the type of instruction set a CPU will use. The CISC machines generally have many different forms of the same instruction, while RISC machines typically have only one (rarely two or more) form of the same instruction. The names "Complex" and "Reduced" do not refer to the size of the instruction set, but to the ratio of instruction forms to single instructions (the smaller the number of instruction forms, the more "reduced" the instruction set). Some RISC machines have a far greater instruction set than CISC machines. For example: PowerPC(RISC) compared to 6502(CISC).

Regardless of the type of instruction set, an instruction is typically comprised of two parts: The opcode and the operands. The opcode defines the command which the CPU will use. The operands define how the CPU will execute the instruction. The number of operands can vary, depending on the language and the opcode. Some opcodes have no operands at all; these are called "implied" operands, since the operand is implied to be non-existent.

The most basic example of such an opcode is NOP. NOP, also sometimes called NOOP, exists on every major CPU in use today (though the assembly instruction is the same across all instruction sets, the machine code is not; yet another example of making machine code easier to understand). Its function is simply wasting CPU cycles; it does nothing else. This seems impractical by today's standards, where timing is not as crucial as it once was, and in most cases it may be desired to use every last cycle to its greatest potential. However, the NOP instruction is important for many tasks. It can be used to help synchronize multiple CPUs by having both wait for a small time, for instance. For a hacker, the NOP instruction becomes an invaluable tool for manipulating programs. Any instruction can be overwritten with a NOP to disable it completely. Overwriting the instruction which changes a character's health in a game will disable the game from changing any health at all.

To Do: Explain operands.

Breaking Limits

To Do

Infinite Ammo For All Guns/Levels

To Do

Changing Starting Items/Stats

To Do

Killing Timers

Timers can be stopped with assembly the same as anything else, but caution should be taken in doing so. Setting a breakpoint on write of the timer address and making disabling the instruction which write to the timer address. Now here's where the caution comes in. Some assembly routines aren't just used for that single timer. There are times when stopping a simple timer can freeze half the stuff in the game, so be careful.

There are also times when the real timer can't be found normally, but a fake (on-screen) one can. These are more difficult to disable, but the real timer can sometimes be traced by doing a write breakpoint on the fake timer. Sometimes, it's as easy as looking as the instructions nearby. The game may be converting the timer to a different format to show on-screen immediately after it decrements and stores it. If the answer isn't obvious, the only thing to do is to backtrace the assembly to figure out where the value for the fake timer came from. It has to get it based on the real one, somehow. This is difficult to explain in real detail because games vary so much.

Rapid Fire

To Do

Mega Jump

To Do

Invincibility

To Do

Debug Menus

To Do

Walk Through Walls

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 occurring 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 occurring 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.

Jesus Mode

A Jesus Mode code allows the player to walk on water just like Jesus in the bible did. One of the most complex hacks to make, it requires great skills with a debugger and a real familiarity with assembly language. The first Jesus Mode code made was for Super Mario 64 by Parayste.

The idea behind Jesus Mode is to figure out how the game determines when the player hits the water, and then edit the code so that the water routine acts the same way the routine for solid ground does.