Arbitrary Code Execution

Arbitrary code execution (ACE) means making a program execute instructions chosen by someone other than its developers. In games, an exploit can use ordinary controls to prepare bytes in memory, then exploit a bug to direct execution there. The result might be a shortcut to the ending or a new program running inside the game.¹²

Data and machine code

An inventory normally contains data: item identifiers and quantities. Those numbers do not become instructions merely because a player arranges them carefully. A separate fault must make the processor fetch them as code. Once that happens, the processor interprets the bytes according to its instruction set.¹

This is not compilation from source. The game has not translated an inventory into a program. The player has chosen values whose byte patterns already encode suitable machine instructions. Preparing them can require a detailed understanding of the game’s memory layout and the processor’s instructions.¹

Pokémon’s 8F item

TheZZAZZGlitch documented an exploit using the glitch item 8F in Pokémon Red and Blue in April 2013. Its identifier is 0x5D; it should not be confused with the different ws m item used in Pokémon Yellow.¹

Using 8F can transfer execution into memory holding the player’s party. A specially arranged party supplies a short starting sequence which redirects execution into the inventory. Item identifiers and quantities there supply further instruction bytes. These arrangements depend on the particular game version; an arbitrary bag of items is not a working program.¹

The community’s Red/Blue disassembly makes the normal item dispatch visible: ItemUse_ looks up a handler in ItemUsePtrTable, loads its address and jumps to it. This is reconstructed assembly source, not source code released by Nintendo.³

A Super Mario World demonstration

Masterjun’s January 2014 demonstration used manipulated sprite state and an invalid sprite routine lookup to reach prepared data, then controller registers. TASBot supplied a carefully prepared input sequence through the controller ports on a real SNES at Awesome Games Done Quick.²

This was a tool-assisted demonstration, prepared with emulator tools and replayed on hardware. It was not a person improvising button presses at that speed. The submission explicitly pursued a demonstration rather than the fastest completion, even though its setup reused an exploit from a completion run.²

What an exploit needs

These examples combine control over some bytes with a way to redirect execution. They do not require an initial ability to write any value to any address: the restrictions imposed by an inventory or sprite system are part of the problem the exploit solves.¹²

Nor does one successful exploit establish that every version or every console game supports the same technique. The useful questions are concrete: which bytes can the player influence, how does execution reach them, and what can that particular instruction sequence do?

See also

• Tool-Assisted Speedrun
• Sequence Breaking
• Self-Modifying Code

Footnotes

1. TheZZAZZGlitch, “Arbitrary code execution in Red/Blue using the ‘8F’ item”, original post 25 April 2013, subsequently updated. The post distinguishes the Red/Blue and Yellow items and documents party and inventory arrangements. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Masterjun, Super Mario World arbitrary code execution submission, 6 January 2014, especially the explanation, TASBot section and judging notes; publication record, 12 January 2014. ↩ ↩² ↩³ ↩⁴

3. pret, Pokémon Red/Blue disassembly, engine/items/item_effects.asm, ItemUse_ and ItemUsePtrTable; see the repository’s description of the reconstructed source. ↩