Reverse Engineering a Childhood Memory

Video games have been a part of my life since as long as I can remember. I was one of the first kids in the late 1980's and early 1990's to have a PC at home due to my dad's job as an early computer programmer. My first memories of playing video games are from when I was around 4 or 5 years old and had a chance to play games like the Word Rescue  or Funny Faces and even the original Duke Nukem. Later on I remember playing computer games at the homes of various cousins and came across games like Commander Keen, Ski or Die and Doom.

The games that truly defined by childhood though were not for the PC but for a forgotten handheld console made by Sega in the early 1990's called the Game Gear. For years I was the only kid that had one, probably because of all the consoles during this era the Game Gear was the cheapest; the Game Gear had a Zilog Z80 chip which was a widely used chip in the 1980's, most famously in the Sinclair ZX Spectrum and Sega's early console, the Master System. The Game Gear as actually just a miniature version of the Master System that was developed to compete with Nintendo's runaway hit, the Game Boy. It had the competitive advantage of being one of the only handheld systems with a color screen and it had an impressive selection of games to choose from. Even I had over 20 games for it which I was able to collect over the course of 1994-1998 when I played with it the most.

I vividly remember one of the first games I got for it was Jurassic Park. This was hot off the heels of the movie release in the summer of 1993 and like every kid in that era I was obsessed with dinosaurs. I wasn't even allowed to watch the movie until years later, so my main cultural contact with Jurassic Park was this game and collectable trading cards, from the latter I could piece the story of the movie together. It was a different time in the 1990's, a time before the internet. Most of what I knew about movies or series came from a mixture of things I heard others say at school and random bidbits of infomation I gleaned from magazines and television. If I felt I was missing something, I would make educated guesses at what the holes in stories might contain or just used my imagination.

The Jurassic Park game in my memory was amazingly beautiful. The Brachiosaurus level had sunsets that even now fill me with wonder. The Pteranodon level had grey, gloomy skies and storms. The game was pretty challenging to me at the time. I could never beat all 4 levels in one sitting. One time a friend came over and beat the game as I stared in disbelief next to him, however he had lost too many continues and got the bad ending, where the T-Rex remains free and the park cannot reopen. I didn't even know games could have alternate endings back in those days, so I wondered why the game had such a morose sendoff.

It was perhaps a year later, playing my portable Game Gear, at my grandparent's place on a gray and windy day, when I was able to beat the 4 levels with enough continues to reach the last level and attempt to defeat the elusive and monstrous T-Rex myself. I wasn't up to the task at that time, but getting that far and realizing there was a 5th secret level was an exhilarating experience.

Over the past few years I've been trying to learn more about low-level computing, be it programming microcontrollers or breaking into CrackMe programs. There's something about looking beyond the visible layer of software that fascinates me, and I imagine fascinates a lot of other people as well. I like finding forgotten things and studying lost fragments. Reverse engineering programs has become a great way for me to find a lot of the weird stuff that I like that lurks underneath all the software we use all the time.

Inspired by Low Level Learning's video on reverse engineering Aladdin for the SNES, I thought this would be a nice challenge to undertake myself but in my case, I wanted to look into old Game Gear games. There was no better place to start than with Jurassic Park. I set myself a few basic goals I thought I could reasonably accomplish and would help me finally beat the game :

1. Find the sections in memory where the amount of health packs are stored, effectively making me immortal in the game.
2. Find other sections in memory that held the values for the amount of continues and the current health level and maximum health. This way I could always be sure to make it to the last level of the game and have plenty of health.
3. Look for anything weird or hidden in the game, such as secret strings or references to other parts of the game.

With these basic goals in mind, the next step was to figure out how to go about debugging Game Gear games. After watching Low Level Learning's video on YouTube, I went to his Twitch channel that had a recording of the entire process of debugging Aladdin for the SNES. At first I thought he was using Cheat Engine, a popular game debugger that's used to find memory addresses in games and modify them at will. Upon watching his stream, I learned he had found a SNES emulator that had a built-in debugger. In my case, I was hoping to get lucky and I did, finding Gearsystem, a multiplatform Game Gear emulator that has a built-in debugger.

After installing Gearsystem and find the ROMs I need from archive.org, I ran Jurassic park in debug mode for the first time.

At first it was all pretty overwhelming. There were multiple pages of memory, RAM, VRAM and CRAM, and everything mostly  in raw hex-encoded binary. The first thing I was able to find where parts of the cartridge memory where ASCII strings would pop out. I found all of them but there was nothing all that special in them, just the text you see throughout the game. The window that needed to be focused on was the Memory Editor window, where you can see different pages of memory along with the memory address to the left, then the raw byte values in the register in hexadecimal followed by an attempted ASCII/decimal translation of the byte values.

Unlike debuggers such as Cheat Engine, the debugger built into Gamesystem didn't have a watcher where you could search for specific changing values in memory. I looked at a hardware manual for the Game Gear and saw that PAGE0, PAGE1 and PAGE2 are where the cartridge memory is located, so everything that has to do with storing values in the game must be located in RAM, as you'd expect. At first I tried changing values that I thought looked promising but doing this would quickly crash the game. It was fun in itself though, destroying this world in countless, bizarre ways.

After a few hours and many crashes later, I felt I was no closer to finding any of the values associated with health packs, continues or health. I assumed they would all be close to one other in memory, a part of a construct that held player data. Despite looking at the stream of bytes flashing before me until many a bedtime, I began having that sinking feeling that I bit off more than I could chew. I wasn't sure I had it in me at this point to deep-dive into Game Gear programming conventions and how memory is laid out. There must be an easy way to figure out where I should even start looking for player data values in memory. Then suddenly I remembered something I read about a few years ago and I knew would give me a place to start.

Back in the 90's there were these special cheating cartridges that were sold for different consoles that were slotted between a game cartridge and the console. The two most popular were Game Genie and Action Replay in my day, however I never owned one. I would only enviously look up the codes for these cheating cartridges that game magazines would publish and marvel how easy it would be to beat Sonic the Hedgehog if only I a Game Genie to give me 99 lives. In retrospect, it might have been a blessing in disguise not to have the fun of games drained out with rampant cheating, my young mind couldn't responsibly handle that kind of power.

It's probably obvious how these things worked: the Game Genie/Action Replay sat between the game cartridge and the console and the codes you put in were memory addresses in RAM that the would get overwritten with whatever value you wanted. I knew that if I found some Action Replay codes for Jurassic Park, I would find where in memory the information I was looking for is stored. Oddly enough, there are still websites that chronicle old Game Genie/Action Replay codes and I immediately found the code for Infinite Medkits: 00C03209. According to the hardware manual, C000 would be right at the beginning of the 8 kilobytes of RAM.

I couldn't believe I missed this: it should be pretty much the first place you look when searching for player data. I realized that I was too focused on the column that had decoded ASCII and decimal values instead of looking at the raw hex. Had I looked at the raw hex values, the numbers I was looking for might have had a chance to catch my eye.

Anyhow, this is information that I will keep in mind for the future. For other games, I have no intention of looking up Action Replay codes to find memory addresses, I know to start my search right at the beginning of RAM and to keep my eyes on raw hex values.  

So now with knowing where the value for medkits was stored, I immediately saw where continues, health and lives are stored, being right next to each other as was expected. I could alter these values at will when pausing the game and clicking on the values in the memory editor. Then when I continued I saw the values update in-game. Of course I tried to see how many lives and continues I could give myself and quickly shattered the reality of Jurassic Park in the process.

As I played, I also found the values for boss life bars and I could beat bosses by just typing in a binary value in hex and pressing enter. It was a very satisfying way to drop bosses that took me weeks to defeat as a little kid.

The only thing I was unable to directly figure out was how to change my score and how to set levels as being completed. I found corresponding level values in memory but changing them didn't do anything in-game. This is something I hope to study in more detail as the logic that controls level progression is more complicated than just setting a single value in memory. Also the score seems to be stored elsewhere in memory or is calculated somewhere else. Anyway, it's nice to see that there is more to look into and to learn.

All that was left was to beat the game. With all these values in mind, I quickly swept through each level, taking down every boss in a matter of seconds. Eventually I made it to the T-Rex and just as quickly, I fulfilled my childhood dream and beat Jurassic Park. I got to see the final images of the game and hear the endgame music. I had a vague sense that I might have beaten the game once before as some of the images looked familiar, but it didn't matter to me now. I beat the game in a completely new way and that was rewarding in itself.

So that was my adventure debugging Jurassic Park for the Game Gear. Personally, I thought I could continue looking into these parts of the game to learn more about how the game logic works:

1. Find out where the score is stored or calculated.
2. Find a way to jump to levels.
3. -BONUS- Beat the game by only manipulating hex values in the debugger.

I've been looking into other games as well and if I get deeper into any other games I will be sure to write about it here. Over the summer I have been playing Squally, a game where your character is a giant floating brain and you have to progress through the game by altering the assembly instructions within the game and cheat your way forward. It has set me on a reversing journey that has kept me pretty occupied. I hope that I don't get too deep into all of this and lose my focus as I do a lot of the time, but here's to hoping I keep on learning more and finding more fascinating stuff to admire.