[TAS] Pokémon Yellow - Arbitrary Code Execution
MrWint4 HN recommenders · recommended in 4 months, 2020-2025
598K views · 9 years ago · demo · evergreen
A tool-assisted speedrun of Pokemon Yellow by MrWint that uses arbitrary code execution to push Game Boy hardware to its limits. Through crafted inputs it injects code and ends up running other programs, such as Tetris, inside the game.
HN points to it as the standard demonstration of arbitrary code execution on a Game Boy, and of glitches and bugs being turned into a working computer.
3:15[TAS] [Obsoleted] GBC Pokémon: Yellow Version "arbitrary code execution" by Fracta[...] in 03:14.15
TASVideosChannel
154K views • 13 years ago
2:29[TAS] Super Mario World "Arbitrary Code Execution" in 02:25.19 by Masterjun
Masterjun3
943K views • 12 years ago
6:08Super Mario World: Arbitrary Code Injection At AGDQ 2014, Performed Live
invalidation
225K views • 12 years ago
58:44TasBlock at AGDQ 2017: TASBot
TASVideosChannel
398K views • 9 years ago
1:12:43Ocarina of Time TAS by dwangoAC, TASBot, Savestate, Sauraen in 53:05 - Summer Games Done Quick 2022
Games Done Quick
564K views • 4 years ago
6:31SNES Code Injection -- Flappy Bird in SMW
SethBling
3M views • 10 years ago
36:41TASBot plays Brain Age by micro500, xy2_ in 20:06 - Awesome Games Done Quick 2016 - Part 154
Games Done Quick
6M views • 10 years ago
11:55Super Mario World Credits Warp Explained
Frieze
638K views • 11 years ago
39:03RustConf 2020 - Closing Keynote by Siân Griffin
Rust Programming Language
10K views • 6 years ago
9:34New NES Tetris Technique: Faster Than Hypertapping!
aGameScout
5.1M views • 5 years ago
22:21Reverse emulating the NES to give it SUPER POWERS!
suckerpinch
1.1M views • 8 years ago
12:09How I Fixed a 10 Year Old Guitar Hero Bug Without the Source Code
ExileLord
404K views • 9 years ago
24:56The Legend of Zelda: Ocarina of Time Speedrun in 22:38, live at AGDQ2013
CosmoSpeedruns
1.9M views • 13 years ago
2:48TI DOOM
TPMFofMFF
199K views • 18 years ago
56:5034C3 - Console Security - Switch
media.ccc.de
135K views • 8 years ago
24:32How We Solved the Worst Minigame in Zelda's History
Linkus7
1.1M views • 6 years ago
5:22:14The Complete History of the A Button Challenge
Bismuth
2.4M views • 3 years ago
3:28Quake on an oscilloscope
pekkavaa
2.5M views • 11 years ago
5:58MarI/O - Machine Learning for Video Games
SethBling
11.5M views • 11 years ago
44:1127c3: Console Hacking 2010 (en)
Christiaan008
33K views • 15 years ago
6 comments from Hacker News
There is an amazing video of a similar exploit in Pokémon Yellow where they basically run a bunch of different games: ▶ this video
Sometimes even after you've come up with the exploit, you can create something really beautiful for the console to run afterwards. Pokemon Yellow: ▶ this video Super Mario World: link
One of the crazier uses of ACE in Gameboy Pokemon games exploits is this "speedrun", by MrWint: ▶ this video ([TAS] Pokémon Yellow - Arbitrary Code Execution) I've timestamped the part where the actual exploit begins, after all of thesetup. It's worth mentioning that this isn't faked or edited in any way, and it's possible to download the input data and replicate on a emulator yourself.
Arbitrary Code Execution TAS like Triforce% or this Pokemon Yellow one[1] are more or less demos that target both the console and the "host game". I would say even some non-ACE ones like this Brainage TAS[2] are demos :D [1] ▶ this video [2] link
It mentions Pokemon Yellow, but really any code run isn't really "run in the game" more so that it uses bugs to hack together alternate instructions for the game boy to execute. Good example: ▶ this video (skip to 1:20 for craziness)
At the end of the day, if you look at a low enough level in the stack, there are no types. In a very concrete way, types are a high-level idea, and if the high-level stops matching the low-level, then bugs crop up. See for example Tetris implemented in Pokémon Yellow via runtime code injection: ▶ this video Their compiler missed that! So I think there's good reason to switch from talking about types as "assumptions", and think of them as compile time "assertions". Something lower-level in the stack could break the high-level code, but that doesn't make the high-level code useless, just imperfect.