Contents
|
Legal
All files (HTML, CSS, images) included in EnHacklopedia are licensed under the Creative Commons Attribution-ShareAlike 3.0 License. All authors contributing to EnHacklopedia should be made aware of the license before contributing. If the author does not agree to the licensing, his or her contributions will not be accepted into the project. History
|
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 OptionsA 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.
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.
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.
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-existant.
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
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 SatesTo Do
To Do
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.
To Do
To Do
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.
To Do
To Do
To Do
To Do
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 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.
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.
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.
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.
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.
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 StrategyTo Do
To Do
To Do
To Do
To Do
To Do
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, =0x0203FA70 | @ 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 soley 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.
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 syncronize 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.
To Do
To Do
To Do
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.
To Do
To Do
To Do
To Do
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.
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.
