What is arbitrary code execution (ACE) and how does it affect speedrunning?
There has been a lot of records being set in The Legend of Zelda: Ocarina of Time within the last couple of weeks or so. A lot of these records keep stating that "ACE" is the reason for this. I have read that "ACE" stands for Arbitrary Code Execution, but why is ACE all of sudden now setting incredible records?
From an article I've read ACE can be described as...
This means that the game can be forced to load and execute a save file name as if it is game code — so using a save file name that is game code can access parts of the game left over from its development and testing.
So basically within a series of in-game inputs, you can use a filename in order to run some development code left over?
Solution 1:
Arbitrary Code Execution (ACE) is a glitch that allows the player to cause the instruction pointer to jump to a section of memory that can be written to by the player (such as the filename, the angle and position of certain actors, controller inputs, etc). When the instruction pointer enters this section of memory, it runs that portion of memory as code.
In other words, it allows the player to write "code" with regular input and execute it in game.
The most obvious speedrunning application is to write and run code that tells the game to run the end credits, as we see in the OoT any% speedrun, but that's certainly not the only one; in Ocarina of Time 100% No Source Requirement, ACE is used to give Link almost every item. ACE is usually only allowed in the any% category, which does limit applications permitted by the rules.
Ocarina of Time is not the only game with ACE. For example, Super Mario World also uses ACE in its any% speedrun, writing code using sprite coordinate data to run the end credits (more commonly known as "credits warp"). It can also be used to write and run an entire game.
This is not to be confused with other memory manipulation glitches. For instance, Super Mario World's Cloud Glitch abuses the fact that Bowser's "time remaining until next fight cycle" timer and the cloud's x coordinate share a register, since they were never meant to appear in the same room together. Since the instruction pointer remains within the normal range, you're not running any arbitrary code here even though you are manipulating the game's behavior by abusing this shared memory.
Solution 2:
I'm not 100% sure about the inner workings of various assemblers and processors, but I'm attempting as best as I can to explain, how I understand it
Let's say the machine instructions to perform a map transition / warp is some value, for example AC.
Let's say, this instruction takes a value to decide where to warp the player. For example, the final boss room has value C8.
So if you tell your game to call the routine to execute AC C8, it knows that it should teleport the player to the final boss.
Now, assume you have some inventory mechanism that saves items by their id. A bomb has id C8 and a stick has id AC.
Assume the data for the inventory is laid out sequentially, so having a stick first and then a bomb is represented as AC C8 as well.
Now "all you need to do" is to trick the program into jumping to a wrong location while it tries to execute some kind of action. This is usually done by the "program counter" which points to the address of the instruction to execute.
If you manage to manipulate the program counter to point to the start of your inventory instead of the address it normally should point to, the program will now read the data from your inventory, but treats it as executable code instead. So since your inventory contains "stick, bomb" the data that will be read is AC C8, which causes the program to warp you to the boss room now.
I think something like this is usually achieved by corrupting parts of the memory or somthing similar. The section of memory that is corrupted contains "nonsensical" data now, but can still be executed.
I'd say, a good example of how all of this can be exploited is shown here: How to beat Pokemon Yellow in 0:00