Understanding the Glitch

For many, debugging the games was still out of reach. Interacting with the code on the machine level was simply too complicated for novices. For glitch hunters, emulation, or using software to simulate the machine of the Game Boy on a computer, was mostly used to soothe paranoia and allow for easy save states at first. Emulation itself was growing in interest as the games became harder to access and gain interest from new players to the series as a historical interest, as well as the spread of illegal piracy.

Emulation also created new ways to play these games – they blazed the path for easy modification of games in the form of ROM hacks. These hacks were programmed into the ROM files before the game is booted. Because of this, they couldn’t be easily played in a cartridge, making emulation a requirement. These changes resulted in entirely different gameplay by modifying graphics, stats and even core features, and could be distributed legally using patch files.

ROM hacking is deeply involved with the data of the game – tinkering bytes and injecting assets in the ROM to change a game towards a hacker’s desires. ROM hacking communities over time accumulated a massive amount of documentation about the inner workings of the games – these discoveries are extremely useful for understanding the way the game works on a programming level, giving foundational knowledge for disassembly. In addition, ROM hacking and other tinkering helped improve the ability of emulators to view other aspects of the game, such as memory values and loaded graphics. Over the years, emulator users and developers built a community of knowledge on how these games function, from the scripts and data processing, to the processor’s assembly language itself. In taking new awareness of the Game Boy’s physical specifications, players discovered how the game unfolds into Pokémon from this physical cartridge, and understanding how specific edge cases in this process leads to all these fantastic glitches.

Missingno, for example, is caused by reading cleared out Pokémon data in the Pokémon index table. Specifically, there are 39 slots empty slots in total, with three of them occupying sprites used in cutscenes, such as the Pokémon fossils and the Ghost sprite. Normally, this is not a problem, because all Pokémon encounters are pre-coded into the game, and these empty slots can just be ignored. However, with shorelines, there is an oversight – wild encounter data is loaded in from the last map to save resources on maps that only have a small amount of water tiles, such as the shore of Cinnabar Island. This means that when going to Cinnabar Island, this data is never refreshed. When talking to the Old Man to watch his tutorial, the player’s name is temporarily stored in a part of memory that is used to also store this encounter data. Because you fly directly to Cinnabar Island, your name is still loaded into this part of memory, allowing you to see Missingno, ‘M, and high level Pokémon, depending on the characters in your name.

All of the different sprites of Missingno. can be encountered with commonly used characters in names, but Missingno. and ‘M are the only glitch Pokémon accessible through the old man glitch, and because of the way that the game writes names, only custom names will be able to see level 0 ‘M. This is because characters after the terminator byte are set to 0x00, which correlates to ‘M. Most other glitch Pokémon, and Pokémon like Mew are inaccessible with this method because not all 255 possible values are used as valid characters. Meanwhile, Missingno. is encountered at level 80 because the name terminator byte shares this value.

As people understood how graphics were compressed in the game, it also became clear how encountering most Missingno. results in the corruption of the Hall of Fame data. Because the sprite is being read from unintentional data, it writes beyond the buffer assigned for decompressing and displaying the sprite graphic – writing over Hall of Fame data. Since this data was stored in SRAM, its corruption was permanently saved.

What about the item duplication though? When Pokémon are encountered, to record them in the Pokédex, a “seen” flag is set by adding 128 to a byte. Because ‘M and Missingno. have Pokédex number 000, they are treated internally as number 256. As it turns out, the place where the 256th seen byte would be located is exactly where the quantity of the 6th item is stored in memory. All of its stats are read from ROM as well, but from an area where enemy Trainer data is usually stored, leading to its strange but consistent behavior.

Amazingly, all of this random behavior came together in a form that was stable enough to cause minimal damage to the game state, only causing temporary graphical corruption, and function almost completely normally, allowing Missingno. to truly become a creature in its own right. The creature production functions were just doing what it was told to do, and it broke itself apart to become an animal.

The Mew glitch worked using a completely different way of loading data into RAM through the cracks – it loads a battle into memory, and flies away before the battle sequence can begin. When the player leaves Lavender Town, the battle loads as a wild encounter, and it sets the species identifier the least significant digit of the last battled enemy’s Special stat. There happens to be a Trainer early in the game that has a Pokémon with a Special stat of 21, the same as Mew’s index number – making the Mew glitch easy to trigger and access. Again, by sheer coincidence, one of the most difficult to obtain Pokémon was made easy by a series of unpredictable mistakes.

The seemingly erratic Super Glitch was even starting to be understood. People noticed that corruption of some forms of the glitch depended on where you were standing. It was eventually discovered that Super Glitch corrupts memory by referencing the screen buffer, which contains an image arranged as tiles of previous screens for easy access when navigating various game states. When trying to view the text, the text buffer for the textbox will copy data to an invalid address, referencing from the location inside the screen buffer, until a text terminator byte 0x50 is encountered. If a 0x50 byte is not quickly reached in memory, either from not being on screen or not being written previously in the space, large amount of data will be copied, overflowing the buffer and corrupting other data.

Because of how this glitch copies data, it is possible to write so much data that it enters a loop, copying the image of the screen buffer and other data repeatedly through the entire RAM, and crashing the game instantly. This destruction copies this image and overwrites all gamestate information, being executed arbitrarily and leading to even more corruption, eventually dissolving the entire game into a 00 39 “bar freeze”, repeating endlessly in memory and often shredding the save file beyond repair. All structures have dissolved into a homogeneous soup. The only thing the player can do is reset the game, erasing the state of the RAM entirely.

Understanding the connection to the screen buffer enabled some control over the powerful corruption abilities of Super Glitch – knowing that the current screen was copied as a buffer allowed for special places to be located where a 0x50 byte would be loaded relatively early into the corruption, creating safe places to manipulate Super Glitch and allowing the move to be viewed, manipulated and removed. More intriguingly was that in some cases the corruption was able to reach just far enough to corrupt the player’s inventory and changing the number of items they have to a very high value, allowing them to easily access considerable parts of memory directly through manipulating the player inventory. Corrupting the item list seemed to be a viable way to possibly make the game do even more things to the will of the player, without simply relying on Super Glitch’s profound corruption alone.

Wielding Arbitrary Code Execution

Arbitrary Code Execution (ACE) seemed like it was around the corner, but the complex, situational corruption caused by Super Glitch made it inaccessible to human players. Unlike ROM hacking, ACE allowed players to execute code at runtime, by moving the program counter to locations in RAM that were accessible to the player, such as the Pokémon Party. This was a way of injecting code as directed from the user, using these parts of the game as a way to assemble a bootstrap, to make the game almost do anything the player desired – completely destroying most limitations of the game.

It was not just glitch hunters pulling off impressive tricks that were interested in ACE – the ability to execute arbitrary code has interest for speedrunners. For example, in the Japanese versions of Pokémon Red and Green, a well known exploit known as the Dokokashira door glitch was able to change where entering a door would send them, allowing them to complete the game quickly. However, the conditions that made this glitch possible were removed in international releases. Save abuse, a technique that uses saving to corrupt memory, was a possible work around, but was unreliable and not viable in some categories. In 2013, an item underflow glitch exploiting a little known menu functionality was discovered in a Tool-Assisted Speedrun and blew open the possibility for even more manipulation.

This bug used Missingno’s item duplication abilities to create at least 255 of a single item. By exploiting how the menu automatically groups together stacks of items while sorting, the item menu can cleverly manipulated to have 0 items and 1 item at the same time. Using a cutscene in Saffron City to remove a Fresh Water from the players inventory causes the inventory quantity to underflow to -1, which is also 255, and giving the player access to huge corruption capabilities. By carefully manipulating the inventory, they are able to warp directly to the Hall of Fame, completing the game instantly.

Later that year, it was demonstrated that by exploiting this new item underflow glitch, an item called “8F” could be obtained through manipulating RAM. Using this item would execute code starting inside the Pokémon Party, allowing the arrangement of your Pokémon to be used as a bootstrap. This simple bootstrap program would allow a player to write bytes directly to memory. After completing the input, the Pokémon Party was rearranged to jump execution to the newly written code, allowing for a whole host of new possibilities. It was only limited by the size of the application that could be injected. A few years later, a “Dry” version of the glitch was discovered, allowing ACE to be executed potentially in any part of the game.