Memory manipulation glitches can be some of the most game breaking and bizarre exploits in a game. Editing memory in unattended ways can lead to arbitrary code execution (ACE), a glitch that can completely break a game by allowing manipulation to its code. Super Mario World and early Pokemon games have ACE methods that completely break the game from a TASing perspective, and have allowed such crazy stuff as playing Flappy Bird on Super Mario World and completing Pokemon Yellow with a time of 0. For this reason, memory manipulation methods can be particularly valuable.
Mario 64’s memory manipulation methods are pretty limited, with cloning and ride cancelling (described in Week 4) being perhaps the only two up to this point. Last week while investigating the behavior of spinies, bad_boot discovered something interesting about how lakitu and spinies interact and how this interaction can be abused for a new form of memory manipulation.
Lakitu has to keep track of the number of spinies it has spawned to know when to stop throwing additional spinies (they throw up to three and then wait for the spinies to despawn). Whenever a spiny despawns, it decreases this value by one for its parent object. The parent of an object is typically whatever spawns it, so in this case, it lowers the value for lakitu. It does this by keeping a reference to a memory slot, which is initially set to the slot containing lakitu. If the memory slot somehow had a different object in it (not lakitu), it would lower a value by one for that object instead. However, since that object has completely different data than lakitu, decreasing a value within the object may have strange consequences. We can achieve this here by killing lakitu and loading a different object in its place, similar to cloning. This has been dubbed “spiny adoption” as a new object becomes the spiny’s “parent”.
So with lakitu sacrificed and a different object loaded into the slot, unloading the spiny changes that object in a way that was unintended. Certain objects are pretty boring, like being able to slightly alter a flame’s speed or how long a bob-omb blinks. Other objects are a bit more exciting, such as goombas. Goombas store their “size” value in the data that is changed by the spiny, so it is possible to make a large goomba in Tiny-Huge Island act like a small goomba (some aspects like model don’t change with this).
Perhaps even more interesting is the bob-omb respawner. Whenever a bob-omb is unloaded, it loads a new object in that will respawn the bob-omb after Mario moves far enough away. This spawner stores the data for the bob-omb, since this respawner can be used for different objects and would need to know what object to spawn. The spiny is able to alter the visual model ID of the object it will load in, specifically to a butterfly or a fish if you use more than one spiny. So with this, the spawner spawns a bob-omb with a butterfly or a fish model (which appears pretty buggy).
The type of memory manipulation that this glitch allows is not one that has been seen in Super Mario 64 before. Being able to arbitrarily alter values would have massive implications for the game and could conceivably lead to ACE (which would allow many things to become possible in SM64). Sadly, this alteration is fairly limited, since it uses lakitu which only appears in two courses in the game, it requires the target object to load into the level after the lakitu despawns, and it permits only a limited number of uses since lakitu doesn’t respawn and it must be offered as a sacrifice for the glitch to work.
This glitch may have other interesting consequences for objects that have not been checked yet, but it currently seems unlikely to allow ACE. Still, the glitch serves as an example of how an ACE-like glitch might behave and has supplied incredibly unique results on its own.
In Other News
- Kaze Emanuar posted two very unique hacks this week- one being HD and 60 fps and the other being in VR. Both of these hacks really put a different perspective on Mario 64.
- Version 1.6 of the Usamune Practice Rom has been released. It offers a lot of new things, the most important ones being: functions sorted by category, castle timer, misc timer, and custom coin counts.
- Superdavo0001 published his WR TAS of “Ztar Attack 2: A Blast To The Past” any% with a time of 1’57″43. Davo has a full explanation of the TAS in the description of the video.
- In task 18 of the Freerun Competition, competitors had an hour to create a freerun in a waterless Jolly Roger Bay. Dar Gos took first place in this task.
- Meanwhile in the Speed TASing Competition, competitors had an hour to TAS red coins in Rainbow Ride. CeeSZee took first, SteamedCabbage took second, and AleXx167 took third. Congrats to all of the competitors!