I believe it's been posted before, but sethbling (of vanilla-minecraft-hacks fame) pulled off the impossible and did the credit warp on an actual SNES, live[1]. As this video very-nicely explains, this required incredible amounts of pixel-perfect accuracy.
Lining up the line of koopa shells on exact x-offsets and very narrow heights mid jump (!) to write the landing-sled - using a controller, realtime - is utterly insane.
As a side note sethbling's latest project is teaching[2] (using neuro-evolution) his machine learning bot to play SMW[2], SMB1[3], and Mario Kart (original)[4]. While he machine learning is simple by today's standards, his brief videos give a really nice introduction to the topic that should be accessible to most people.
Note that this video is of SethBling pulling off the credits warp for the very first time, when the current setup for the warp was unknown. Here is a video of Seth performing the warp that was explained in the posted video, which is faster by over four minutes:
For the Pong and Snake games, the code that is written is a bootstrap to read values from the controllers and write them to memory. Then it jumps to those routines.
It uses similar techniques to write code to different locations of memory, just like this game credit warp. After the bootstrap code is written, Yoshi eats another Chuck, and the code executes the bootstrap. At this time, the NES reads from the controllers.
The controls aren't just your typical controller, as I recall, they are actually multiplexed controller cables plugged in, allowing more bits to be read and thereby written. The code at this point can be anything. Including this [https://youtu.be/bu4Z_-1K_Gw].
Probably not as awful as it sounds on the surface, with an emulator you can sit and stare at the current state of the machine quite handily. It would be essentially impossible to work this sort of thing out without the aid of tools.
Totally, but even with an emulator, the number of obscure glitches that have to be strung together in just the right way to make this work is staggering.
> I'd also love to see a similar explanation of the mario pong/snake glitch. It seems it goes even further and is able to actually input large amounts of arbitrary code.
The video showed how to use sprite positions and similar to construct a small amount of code, and then the bug in Yoshi's eating to jump to that code. As hinted at in the video, there's a jump table for what happens when Yoshi eats various things, and if you eat something you "shouldn't" be able to, you jump to an unexpected location, which with care can be used to jump to the code you wrote in the sprite table.
In the video, this is used to write to a state value that determines what the game is doing, jumping directly to the last bit of the credits. That requires quite a bit of precision, but with enough practice, a player can do it in real-time, just as players can learn to perform tricks that require frame-precise inputs.
For the arbitrary-code variant, as with other "total control" hacks (exploiting a game to execute arbitrary code), the goal is to code a tiny loop that rapidly reads controller input into memory and then executes it. Sometimes the initial read-and-execute loop is simplified and only reads a few bits from the controller at a time, but is then used to bootstrap a more complex loop that can input code from the controller(s) more rapidly. For instance, SNES total control hacks often bootstrap into a loop that reads from 8 controllers (two multitaps of four controllers each) simultaneously, once per frame.
In the case of the TAS you mentioned, that input loop reads and executes code implementing games of Pong and Snake using sprites already available in memory, which minimizes the amount of data required. The original Total Control hack, for Pokémon Yellow (https://www.youtube.com/watch?v=p5T81yHkHtI), took a while because it read in an image and music, input 8 bits at a time using the single Gameboy controller (four directions, start, select, A, and B, for 8 bits). To improve entertainment value, it bootstrapped into a loop that displayed values as they were read, as well as reading an appropriate message from the original game first ("It's the game program! Messing with it could bug out the game!").
See https://www.youtube.com/watch?v=p5T81yHkHtI#t=10m25s to skip to the point where it starts entering code via the controller, and notice the displayed controller inputs at the bottom inputting a byte at a time. If you watch carefully after the code starts being displayed, you'll notice that the inputs match the displayed code, such as all the buttons being pressed or released at once to input FF or 00.
And the use of an image and music from something that didn't exist at the time Pokémon Yellow was released made the magnitude of the original Total Control hack clearer even to non-programmers: brand new data was being input into the game.
A more recent hack for Super Mario World put a faithful recreation of the original NES Super Mario Bros into memory and executed it, which you could actually play. (It input and used the graphics from Super Mario Bros, but reused sounds such as jumping and collecting coins from Super Mario World, both to reduce the "download" size and to simplify the code, since the sound hardware on the SNES is drastically different.)
All total control hacks for current games follow the same general pattern: find a way to jump to any user-controlled data that can be formed into useful machine-code instructions (an item list with item indexes and quantities, character stats, sprite positions, etc), use those (possibly constrained) instructions to read controller input into memory and jump to it, bootstrap into a more efficient (and entertaining) read-and-execute loop if necessary, read piles of arbitrary code into memory, and jump to it.
IIRC, the sound sample thing was just a happy accident. They had no intention of adding sound, but they left in the sound playing code and discovered that Nintendo used the exact same sound lookup table. Which is perhaps even cooler.
Just forwarded the link to my work email. This is the ultimate answer to any objection to security efforts on the grounds that "the vulnerability is too complex for anyone to bother exploiting".
Just out of curiosity, anyone know why only 12 sprites can be loaded at a time into memory? Is that a hardware limitation or a design decision by the developers?
Lining up the line of koopa shells on exact x-offsets and very narrow heights mid jump (!) to write the landing-sled - using a controller, realtime - is utterly insane.
As a side note sethbling's latest project is teaching[2] (using neuro-evolution) his machine learning bot to play SMW[2], SMB1[3], and Mario Kart (original)[4]. While he machine learning is simple by today's standards, his brief videos give a really nice introduction to the topic that should be accessible to most people.
[1] https://www.youtube.com/watch?v=14wqBA5Q1yc
[2] https://www.youtube.com/watch?v=qv6UVOQ0F44
[3] https://www.youtube.com/watch?v=iakFfOmanJU
[4] https://www.youtube.com/watch?v=S9Y_I9vY8Qw