Arbitrary Code Execution is in Another Castle!

When one buys a computer, it should be expected that the owner can run any code on it that they want. Often this isn’t the case, though, as most modern devices are sold with locked bootloaders or worse. Older technology is a little bit easier to handle, however, but arbitrary code execution on something like an original Nintendo still involves quite a lot of legwork, as [Retro Game Mechanics Explained] shows with the inner workings of Super Mario Brothers 3.

While this hack doesn’t permanently modify the Nintendo itself, it does allow for arbitrary code execution within the game, which is used mostly by speedrunners to get to the end credits scene as fast as possible. To do this, values are written to memory by carefully manipulating on-screen objects. Once the correct values are entered, a glitch in the game involving a pipe is exploited to execute the manipulated memory as an instruction. The instruction planted is most often used to load the Princess’s chamber and complete the game, with the current record hovering around the three-minute mark.

If you feel like you’ve seen something like this before, you are likely thinking of the Super Mario World exploit for the SNES that allows for the same style of arbitrary code execution. The Mario 3 hack, however, is simpler to execute. It’s also worth checking out the video below, because [Retro Game Mechanics Explained] goes into great depth about which values are written to memory, how they are executed as an instruction, and all of the other inner workings of the game that allows for an exploit of this level.

13 thoughts on “Arbitrary Code Execution is in Another Castle!

  1. I am curious where this will go. This video was posted quite some time back. And there are other games with similar glitches (some are even intended). Since the software on theses systems can be considered tiny compared to modern operating systems, it might be interesting to check the games formally for invariants (and so on). Nintendo checked the games before they were released. It would be very interesting to know, what kind of checks they performed back then. If anybody has further information on that topic, it would be great if you could share. BR

    1. Considering the games were written in assembly and the hardware is so rudimentary, I doubt they did much past having testers play the game seeing as how Nintendo is the master of cutting costs/corners.

      1. They are champs at cutting costs, but Nintendo does not cut corners.

        My favourite example of the Big N cost cutting: the lead from the NES power supply to the mains socket got shorter and shorter throughout the console lifespan; from several meters to barely a meter. Think about how much money they saved by simply snipping two meters of cable * several million consoles. And i bet people didn’t even notice or mind.

        1. My favourite are the Gameboy’s non-backlit screen and its power LED, which was probably added to signal low battery (it got very dim when batteries went low due to its forward voltage, and was labeled “battery” in the original GB). They couldn’t afford a proper voltage comparator and a dual-color LED / interrupt in the (already custom) CPU to show a low battery screen, so they added a simple always-on LED.

          But other times they add completely useless and expensive stuff: does anyone know that the DSi has three separate power management chips and four different CPU cores (ARM7, ARM9, Xtensa-based WiFi and a TeakLite 2 DSP, used only by some games and the built-in AAC music player)? The ARM7 is connected to almost everything and has hardware controllers for most of these connections (including SPI, I2C, SDIO and parallel interfaces), but the RTC’s serial bus is bitbanged by the firmware.

          Another example: the Gameboy Color has a lot of custom chips, including the audio amplifier (“AMP-MGB”, also used in the Gameboy Pocket), but still that always-on battery LED. Fitting a voltage comparator in one of those chips shouldn’t have been so difficult and expensive.

    2. Sure, I’ll bite. Full disclosure: I’ve shipped titles on multiple Nintendo systems in the past.

      Nintendo’s game approval process is what is known as “Lot Check”. During Lot Check, their testers will test, point-by-point, one of a few hundred potential requirements that, if not met, will cause your game or title to be rejected.

      Some of these are pretty straightforward: The game shouldn’t crash. The game should not destroy user data unless there is an explicit confirmation step. The user should be able to eject the game disc, and the game disc should display a prompt to re-insert the disc, and not crash. The game must respond in a timely manner to a HOME button press, or it should display a stricken-out Home Menu icon in the upper-left corner of the screen for a minimum amount of time.

      Some of them are less straightforward: The entire game, from end to end, is played into a special desktop PC which is equipped with a video capture card and software which can analyse the likelihood that a given sequence of frames is likely to trigger seizures in those with photosensitivity: Your title can ship as long as it doesn’t exceed a given number of “yellow” ratings, but if it goes into the red, your title will be rejected.

      One of the things that Nintendo – and most likely Sony and Microsoft, for that matter – almost certainly do not do is perform any sort of in-depth code analysis. With game projects that can run into the millions of lines of code, and with tens or hundreds of possible developers who all have their own bespoke build processes, it would not be economically feasible for Nintendo to do this. So they don’t. The extent of the crash detection that they do is limited to actual physical testing of the game itself by their testers; there’s a reason why developers are expected to submit their games in the form of an already-built, masterable disc image, or cartridge image (depending on the system).

      Videos like this represent hours, days, weeks, or even months of collaborative analysis on the part of many members of the ROM hacking community, on analyzing one bug in one game one system. It’s positively ludicrous to expect even a first-party company to vet to that level every single game that they make or manufacture.

      1. “Full disclosure: I’ve shipped titles on multiple Nintendo systems in the past.”

        Very interesting comment. I love first-hand accounts of bringing products to market.

        I’d assume you’re under one or more NDAs and can’t say what games you worked on, but can you share which systems, and your general role in the production process?

        1. > The user should be able to eject the game disc, and the game disc should display a prompt to re-insert the disc, and not crash. The game must respond in a timely manner to a HOME button press, or it should display a stricken-out Home Menu icon in the upper-left corner of the screen for a minimum amount of time.

          Sounds like he worked on Wii (maybe Wii U?) games. Also, from my experience, the stricken-out home icon is displayed in one case only: when pressing the home button after the black screen prompting to re-insert the game disc appears. Coincidence? I don’t think so.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s