Arbitrary Code Execution

Overview

Arbitrary Code Execution (ACE) is the most powerful class of speedrunning exploit. By manipulating game memory through carefully chosen inputs — controller presses, item arrangements, screen positions — runners trick the game into running code of their own design. The "code" is whatever bytes happen to occupy a region the CPU is about to jump to. The runner shapes those bytes through gameplay, then triggers the jump.

Done well, ACE collapses entire games to seconds: skip to the credits, set the win flag, jump to a custom payload. Done well and tastefully, ACE inserts a Twitch-Plays-Pokemon-style live console into the game, or boots a different game from inside the running one. ACE is computer security's "buffer overflow + code injection" applied to games — same skill set, friendlier consequences.

How ACE works

Every ACE exploit chain has three parts:

Step	What it does	Typical mechanism
1. Memory write primitive	The runner needs to write chosen bytes to chosen addresses.	Stack overflow, off-by-one in an inventory loop, buffer that wraps past its bounds, misindexed array.
2. Code crafting	Those chosen bytes become CPU instructions. The runner thinks in opcodes, not items.	Item slots whose IDs encode 6502/Z80/ARM bytes; controller buttons writing into a polled-input buffer; sprite coordinates landing as immediate operands.
3. Control flow hijack	The CPU has to actually jump to the crafted region.	Function pointer overwrite, return address corruption, jump table index out of range, trampoline through a known address.

A worked example: Pokemon Red/Blue 8F

The classic 8-bit ACE: in Pokémon Red/Blue (Game Boy), an obscure item glitch lets you insert item ID 0x5C (the unused "ws m" item, called 8F in the speedrun community) into your bag.

When you "Use" item 8F, the game's switch statement falls through to a handler at an unintended address — specifically, the game's own item-effect dispatch table, indexed by the item ID. With your item quantities corresponding to specific opcodes (e.g. quantity 76 = $4C, low byte of JP nn), the bytes the dispatcher reads are exactly the Z80 instructions you placed there by buying and selling carefully chosen item counts.

The runner builds a tiny Z80 program — half a dozen items' quantities — that writes the "won the game" flag and jumps to credits. Total exploit: under a minute of in-game prep.

Other famous ACE exploits

Game	System	Mechanism
Super Mario World	SNES	Yoshi-stack glitch + sprite-table corruption → controller-2 inputs become 65816 code
Ocarina of Time	N64	Stale Reference Manipulation (SRM, 2019, ZFG et al.): a freed actor reference is reused, letting Link's animation data overwrite return addresses
Super Mario 64	N64	Parallel Universes + held-object pointer corruption — the famous "0.5 A-press" sub-genre
Super Mario Bros. 3	NES	Wrong-warp via PRG-bank desync; minor controller-2 ACE variants
Pokémon Crystal	Game Boy Color	Coin-case glitch: reading an undefined save flag exposes the box-name buffer to an instruction fetch
Twilight Princess	GameCube / Wii	Wii version's "stack smash" — careful jar/torch placement smashes the return address

Categories and ACE

Category	ACE Status	Notes
Any%	Often allowed	The "anything goes" category — beat the game by any means
No ACE	Common restriction	Carve out the "go to credits" exploits but allow ordinary glitches
Glitchless	ACE prohibited	Plus most other glitches
TAS	ACE demos popular	TAS communities push ACE into "playaround" art — running custom games inside the original

How it works on 8-bit hardware

The 6502 and Z80 don't have memory protection. There's no W^X, no executable bit, no stack cookie. Every byte is potentially executable code. If you can:

Write bytes you control to a known location, and
Get the program counter to that location

you have arbitrary code execution. On a real 8-bit system this can be as simple as:

An OAM buffer (sprite data) that the game blindly trusts as instructions if a separate bug points the PC there. Sprite Y-coordinates and tile indices become opcodes.
A controller-2 polling loop that reads the second player's button pattern into RAM. Press the right combination, and the bytes there are valid 6502 — let a corrupted return address pop into PC and you're executing controller input.
A high score table written to non-volatile RAM. Enter your initials carefully; on the next boot, a load-game routine with a swapped pointer treats your initials as code.

The pattern is always the same: find a place where user input lands in RAM, find a way to redirect the PC there, and translate your goal into the target CPU's machine code.

Connection to security

ACE on consoles is exactly buffer-overflow code injection on PCs. Same primitives, same defences (none, on retro hardware), same pay-off. Modern consoles ship with hardware DEP and W^X to make ACE painful; jailbreak chains on PS3, PS4, 3DS, and Switch are all extended ACE exploits scaled up to deal with kernel-mode signatures and hypervisors.

The skills cross over directly. A retro speedrunner reverse-engineering an N64 ROM to find a stack overflow is doing the same job as a CTF player attacking a Linux binary — different ABI, same playbook.

Educational value

Understanding ACE teaches:

Computer architecture fundamentals — what's a stack, what's a return address, why does PC matter
Memory layout — code, data, stack, heap; what happens when they touch
Security concepts — bounds checking, validation, why "user input as code" is dangerous
Low-level programming — opcode encoding, addressing modes, calling conventions

Pretty much any low-level concept — short of caches and pipelines — has a 1-to-1 ACE example you can watch on YouTube.

Legacy

ACE represents the ultimate mastery of a game — understanding it so completely that players can make it do anything, including things developers never imagined possible. It is also the most direct line from the demo scene to the speedrun community to professional security research: every retro ACE you watch on stream is a primer for binary exploitation.

Playing the game's memory