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?

  • 51
    I have wondered this for approximately forever.
    – user11502
    Commented Jul 15, 2012 at 4:21
  • 7
    I know I shouldn't be surprised by the excellent answers this question has gotten, given the depth of our community members... But wow.
    – Niro
    Commented Jul 15, 2012 at 17:29

3 Answers 3


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 CodeHandler reads the value at the code's address and compares it to the value in the code. IF the comparison returns true, then the CodeHandler 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

  • 3
    Hi, and welcome to the Arqade! Thank you for this great answer. This explains everything I was wondering about. Commented Jul 15, 2012 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
    Commented Jul 15, 2012 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!
    – Jane Ori
    Commented Jul 15, 2012 at 18:59
  • 7
    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
    Commented Jul 16, 2012 at 5:16
  • 2
    This was a very good explanation, thanks for posting it. I have a couple questions: 1. What guarantees that a particular variable (lives, ammo, etc.) will always be stored at the same memory address every time the game runs? That's not an assumption that should be made with any PC program, correct? 2. How much RAM does the Code Handler itself typically require (say for the N64)? If the game itself required all of the console's RAM to function, wouldn't the game fail to run with a GameShark attached? Were there any games that were incompatible with the GameShark for this reason? Commented Jul 18, 2022 at 21:25

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.

  • This is awesome. Thanks for breaking it down so a non-computer person like me can understand!
    – user11502
    Commented Jul 15, 2012 at 18:04
  • The actual instructions were patched? I always assumed it was just variables in memory being modified - interesting! Commented Jul 16, 2012 at 0:13
  • 4
    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. =)
    – Jane Ori
    Commented Jul 17, 2012 at 1:30
  • 3
    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.
    – Jane Ori
    Commented Jul 17, 2012 at 1:39
  • 2
    @James0x57, there are several places I've read that seem to indicate that the original GameGenie for the NES was patching the ROM, see here, here and here for example. I've no doubt you're correct about more modern/recent iterations of game cheat devices, however.
    – agent86
    Commented Jul 19, 2012 at 21:27

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.

  • 4
    This looks like it's probably right, but do you have any sources for this information? Commented Jul 15, 2012 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. Commented Jul 15, 2012 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? Commented Jul 15, 2012 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. Commented Jul 15, 2012 at 8:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .