Paper Mario ACE RTA with OoT
Feb 23rd, 2021 (edited)
- Arbitrary Code Execution (ACE) has been found in Paper Mario. This basically means we can use a glitch to write and run our own custom code in the game. As of right now, it's TAS only since it requires positioning Mario in 6 different float-perfect x/y/z coordinates. If you want more information on the TAS method, MrCheeze has a good twitter thread here that I'd recommend: https://twitter.com/MrCheeze_/status/1363199136963649543
- However, there is one known way to do this RTA. Rain managed to find that with a specific setup, we can manage to overwrite a small part of code. We use a glitch called menu storage to store just enough graphics effects at once. When we release the effects, they make so much data that it overflows to where code is being executed, and the code we overwrite corrupts the stack. By sheer crazy coincidence, this jumps execution to a part of memory where there are player flags and an idle timer. If we let that idle timer reach 0x81f, which is about 69 seconds (nice), before releasing the stored effects, then execution jumps to expansion pak memory, which Paper Mario doesn't use, and then it crashes from garbage data.
- This is where Ocarina of Time comes in. OoT was shaken up at the end of 2019 with a discovery known as Stale Reference Manipulation (SRM). It's pretty difficult to explain how that works too, but dannyb does a really good job of explaining it where this AGDQ run is timestamped: https://www.youtube.com/watch?v=rqrx8XEF-vI&t=5m31s. We're doing something pretty similar, but with a different result.
- To do what we need to do in OoT, we'll need a very specific filename. A more recent application of SRM in OoT known as "Lightnode SRM" means that without even leaving Kokiri Forest, we can write the value of one half of the filename to the location specified in the other half. We can take advantage of this by writing an assembly instruction to expansion pak memory.
- After this is where the real magic happens. If we quickly turn off the console, swap cartridges to Paper Mario, and turn the console back on, that instruction will still be there in memory (luckily when OoT boots, it clears the expansion pak memory, but Paper Mario just ignores it). If that reminds you of Banjo Kazooie's Stop 'n' Swop, that's because it's the exact same idea.
- From here, we can perform the glitch I described above, and instead of crashing, the assembly instruction we wrote in OoT will jump to where filenames are stored (in practice, depending on how much RAM decays between swapping games, usually anything between 0x81d to 0x81f on the idle timer I mentioned earlier will work). We'll use the filenames to write a payload that updates our current room to the "The End" screen, saves, and then crashes. From here, we can reset the console, load the file, and we'll be at the end of the game.
- TL;DR: We're using SRM in OoT to write code to memory that we can reach with a glitch in Paper Mario after quickly swapping cartridges, and then that code lets us write more code with our filenames that warps us to the end of the game. We've decided as a community to put this on the Category Extensions board because of the use of an outside game, but it's still pretty cool. :)
Please, Sign In to add comment