Take the 2-minute tour ×
Arqade is a question and answer site for passionate videogamers on all platforms. It's 100% free, no registration required.

This has always boggled me. Obviously GameShark and Game Genie never got inside access to place their own cheats into every game. I don't think any developers gave them the source code to pour over for codes. And I don't think the original development process for these games included placing any of these codes themselves. So, what is a GameShark or Game Genie code, really?

Both of them usually take the form of a relatively short hexadecimal string (or multiple if that is the case) so my intuition tells me they use the same principle. But are they just memory addresses to flip a bit? Or lock it? Or XOR a series of bits with something? What is the code, and what does it do?

share|improve this question
24  
I have wondered this for approximately forever. –  Ashley Nunn Jul 15 '12 at 4:21
    
I have no idea what GameShark is, but a little googling got me mindspring.com/~glaciuscool/gspro/doc/gspro.htm#_Toc488133291 . –  Capt.Nemo Jul 15 '12 at 9:43
2  
I know I shouldn't be surprised by the excellent answers this question has gotten, given the depth of our community members... But wow. –  Fluttershy Jul 15 '12 at 17:29

3 Answers 3

up vote 115 down vote accepted

How it works

When GameShark (and other game enhancer products/homebrew) gets loaded by the console, the enhancer is what launches the actual game. In doing so, it leaves behind a Code Handler in the system RAM and "hooks" the game's programming.

Specific locations in a game's programming that get executed roughly every frame (like reading the controller data) are where "hooks" will be placed. (because SDKs are used, this makes finding hooks that work in all games for a system much easier)

What the hook actually does is redirect the flow of programming to the Code Handler the enhancer left behind. Once the Code Handler is finished executing, it returns the flow of programming back to the point of hijacking.

If you are familiar with GameShark's "Master Code", that is what sets the hook. (other enhancers - like Gecko OS for Wii - don't need master codes because the enhancer itself has a handful of SDK-based hooks that it can "find" in the game while it loads.)

Structure of codes

Now a code itself is separated into THREE parts:

  1. The CodeType (this is USUALLY the first byte of the code-- the first 2 Hex Characters). CodeTypes are specific to the enhancer.
  2. The address in ram that the CodeType will use.
  3. The value the codetype will use at the specified address.

The most common CodeTypes are:

  1. RAM Writes (typical options are 8bit, 16bit, or 32bit)
    With RAM Write, the CodeHandler will take the value and place it at the address. (changing whatever was there, like setting your health to 100!)

  2. Conditionals (typical options are >, <, =, !=)
    With Conditionals, the CodeHander reads the value at the code's address and compares it to the value in the code. IF the comparison returns true, then the CodeHander will execute the next line in the code. (how many lines it executes is up to the enhancer and often is an option in the codetype itself!)

There is plenty more info we could dive into, but that should give you a good basis for understanding. =)

Source: Game hacker since 1999, founder of http://GeckoCodes.org

share|improve this answer
1  
Hi, and welcome to the Arqade! Thank you for this great answer. This explains everything I was wondering about. –  Ktash Jul 15 '12 at 17:29
    
How times (and tech) have changed since the old days :) I've used devices on my GBA and DS that took this "memory resident" approach. There was typically a button you can press in-game to access the device's hooks (in order to activate/deactivate cheats, for example). –  agent86 Jul 15 '12 at 17:51
2  
QAtash: Thanks and no problem! Glad to help. =) @agent86 The devices for GBA and DS (GameShark, CodeBreaker, ActionReplay) work exactly like this too. The "conditional" CodeTypes are what checks if a button is pressed in game- that in turn might execute a RAM Write. Since the Code Handler is executed roughly every frame, the conditionals (checking for buttons being pressed- "Button Conditionals") will also be checked "live" as you play! –  James0x57 Jul 15 '12 at 18:59
2  
I once entered a deliberately wrong code to see what would happen. In a potentially unrelated but immediately subsequent event, my GameShark functioned for exactly zero minutes of gameplay and never worked again. –  Jon Purdy Jul 16 '12 at 5:16
    
@agent86 back in the DOS era I had a memory resident memory editor that required you to find everything manually the first time. eg if you wanted to be able to change your health value you needed to search for the value repeatedly after changing it each time. While might be 500 locations in memory that had a value of 95 after your first search the odds are you could narrow it down to a single location after taking a few hits/heals and searching for 95, 91, 100, 88 in sequence. Once you found the address you could change the value to anything you wanted or freeze. –  Dan Neely Jul 16 '12 at 19:29

For the purposes of this, I'm assuming we're talking about the "classic" GameShark/GameGenie devices, which sit between the cartridge and the hardware. I believe more modern devices follow a similar principle, but are far more advanced. James' answer to this question goes into some detail about the more "modern" approach to this problem.

What's in a ROM? Well... the game, essentially.

In a video game system, the data for the game is encoded in a number of Read-Only Memory (ROM) chips, on a circuit board, which we call the cartridge. Since these ROM chips contain the game, sometimes we use the terms "game program" and "ROM" interchangeably.

The game program/ROM essentially tells the system how the game is played. For instance, pressing A in Super Mario Brothers causes a sound to be played, Mario's sprite changes (he puts his hand up) and his sprite moves upwards for a given amount of time, and then he descends back to the ground. All of this information about how to respond to a button press is encoded in the ROM.

The mechanics of the game also include how other events are considered - such as what happens when Mario loses a life. There is a value in memory that is accessed to see how many lives Mario has, and that number is decreased by one.

Patching for Fun and Profit!

The way these devices work is, they sit between the console and the ROM. (Literally - this is why they attach to the cartridge in the way they do.) In most cases, when the console asks the ROM what to do next, the cheat device simply passes that request on to the ROM, the ROM answers, and the game plays normally.

When you enter a "cheat code" into the cheat device though, it replaces (or "patches" to use a common technical term) the instruction from the ROM with the instruction you specify. In this way, you can change the way the game plays.

For instance, if you wanted infinite lives, you'd want to patch the ROM so that when the game goes to edit the value of the "lives" area of memory, it skips over the "subtract 1" instruction. If you just wanted Mario to start with more lives, all you'd have to do is go into the area of memory where Mario's lives are initialized, and make it so that instead of setting the initial value to 3, you set it to 4, or 10, or 100 instead.

The end result is that a tiny, sometimes one or two byte change in the game's program radically changes the way the game works. Suddenly Mario never loses lives, or items are never consumed, or killing a single beast gives you 10 times the experience, or you start the game with the ultimate weapon, etc.

These devices have a limited ability to store codes, and some cheats require that you patch multiple locations in memory - the more complex the cheat, or more places it would have to touch, the more codes you'd need in order to change the program in the way you want. If you had one with a large enough code space, it would theoretically be possible to change the game completely! However, since these devices lost their memory when power was removed, you'd essentially be re-writing the ROM from scratch every time you played, which would be... tedious, to say the least.

Code Encoding

In the simplest case, the codes themselves are typically 2 parts. The first part is the ROM address to change, and the second is the value to set. These values are binary or hexadecimal values, and are typically encoded into some "easy to read" format for humans to enter into the system easily.

More complex codes had a third part, which was a "compare" value - the code would only change the value in the ROM if the existing value of the ROM program matched. This allowed certain codes to work on multiple versions of a ROM, or on cartridges that were complex enough to require bank switching (which is another topic altogether...)

The original NES GameGenie format encodes 16 bits of address and 8 bits of replacement value in hex format, which is then scrambled and encoded into 6 letters. If a "compare" value is required as well, this is another 8 bit value that generates 2 more letters, for a total of 8. This guide, by Benzene of Digital Emutations, explains the scrambling format and how you can decode a NES GameGenie code.

Finding Codes

I don't know precisely how the people who made the initial GameGenie devices went about determining the codes they used, but the basic idea is to find the specific part of the ROM code that you wish to change. This could be done on a debug version of the console, which allows a developer to view the instructions as they are executing. Have the game do whatever it is you want to change, and then watch what part of the ROM is requested by the console. Then change the value that is read, and voila, the cheat is created.

It could also be done by extracting the data from the ROM, and examining it to determine how it works. By reading back the ROM, you can see the instructions that are executed and in what order. After analyzing the program stored in the ROM, (a process termed "reverse engineering") it's a matter of determining which instruction is key to the game's behavior, and changing it so that you change that behavior. This process can be tedious, but it gets easier with practice, knowledge, and skill.

Either of these processes would likely be difficult to neigh impossible for the home user at the time of the first GameGenie devices, although you might be able to determine the pattern of a given cheat given an existing code. For instance, if the GameGenie shipped with a code that gave Mario 6 lives, a person could probably figure out how to change the value of "6" to "7" or some other arbitrary number. The hard work is in finding the location to patch, and not the patch itself, in these cases.

The Emulation Effect

In the emulation age, code generation is easier, but also somewhat different. Emulators aren't limited to patching ROM locations - they can examine the current value of the variables of the game in real-time. This makes all sorts of interesting things possible.

Instead of just changing the game's ROM - for instance, skipping the "subtract 1 from lives" command, the emulator can change the game's state - for instance, allowing the user to just say "I want 10 lives. Now." or "I want my inventory to contain 99 elixirs." This real-time viewing and editing of the game's state makes game hacks much, much easier and game hackers far more powerful.

Where's my Xbox 360 Game Genie?

Modern gaming devices have all sorts of copy protection programs that verify and validate the ROM, to prevent piracy and ensure a "fair" multiplayer experience, among other things. This makes creation of devices similar to the "classic" GameGenie very difficult and/or illegal in some cases.

share|improve this answer
    
This is awesome. Thanks for breaking it down so a non-computer person like me can understand! –  Ashley Nunn Jul 15 '12 at 18:04
    
The actual instructions were patched? I always assumed it was just variables in memory being modified - interesting! –  BlueRaja - Danny Pflughoeft Jul 16 '12 at 0:13
    
@BlueRaja-DannyPflughoeft, the newer models (and emulators) are capable of editing variables in memory (as James0x57 points out) but my understanding is that the "classic" GameGenie wasn't capable of this. –  agent86 Jul 16 '12 at 0:59
3  
Hello, @agent86! To my knowledge, all game enhancers for consoles are RAM-based executions. Including the original NES Game Genie (who's codes were encrypted). They all work because RAM is not protected, so the Code Handler can read and write anywhere after the footprint is left behind and the game is hooked. ROM hacks are a very different type of hack though-- patched once at the file-level, rather than applied each frame in the assembly. Most advanced code hacking prior to GameCube was done through manual assembly injection since CodeTypes were VERY limited. =) –  James0x57 Jul 17 '12 at 1:30
2  
Today there are some memory protections implemented in select games. The first one I remember seeing with memory protection was Metroid Prime on GameCube. In all cases to date, I'm fairly sure it has been bypassed since not all of the memory is protected. As for the legality, Galoob v Nintendo legalized this type of RAM-based hacking when Nintendo lost the case in 1992. –  James0x57 Jul 17 '12 at 1:39

I believe a GameShark code has two parts:

  1. The memory address to change, and
  2. The value to place in that address

By changing the values in these addresses, you get a cheat.

The codes were not placed in the game. After the game is released, with a pretty straightforward method, you can create your own codes for a game if you have a device which can access the RAM of the console, aka, a cheat device. These codes are then published.

share|improve this answer
4  
This looks like it's probably right, but do you have any sources for this information? –  murgatroid99 Jul 15 '12 at 4:49
1  
I don't really have an official source. But I've created my own cheats for certain games(using emulators since I don't have a cheat device). The trial and error method used to make them suggests this is how they work. –  Vinay S Shenoy Jul 15 '12 at 5:05
1  
This answer is correct, but this question definitely deserves a better answer than this. How were the exact memory locations and values encoded? How did the cheat-creators find these memory locations? How exactly did the GameShark/GameGenie device allow memory locations in the console to be edited? –  BlueRaja - Danny Pflughoeft Jul 15 '12 at 8:11
    
Yeah, it does. But that is concerned with a lot of things, like the design of the console, choice of memory, reverse-engineering of hardware, etc. which I have no clue of. –  Vinay S Shenoy Jul 15 '12 at 8:29

protected by Community Jul 22 '13 at 1:27

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.