With those out of the way, TASBot moved on to a similar total control run of The Legend of Zelda: A Link to the Past. After a few minutes of setup, the Zelda screen faded out, then faded back in on a bordered window with an ersatz logo for the “Super N64.” Without any forthcoming explanation from the runners on stage, TASBot started apparently playing through a glitch-filled speedrun of Super Mario 64 on the Super NES, following it up with a similar glitch-filled speedrun through Valve’s PC classic Portal. After that, the scene somehow transitioned to a Skype video call with a number of speedrunners speaking live from the AGDQ event through the SNES.
No one on the AGDQ stage acknowledged how weird this all was, leaving hundreds in the Herndon, VA ballroom and nearly 200,000 people watching live on Twitch temporarily guessing at what, exactly, was going on.
AGDQ (and its Summer counterpart, SGDQ) are some of my favourite events in technology, and I have the entire marathon streaming for the whole week. The TASBot block this year was, as the excerpt above describes, insane, and this article explains how they did it.
Next: How i made a RCA compsoite monochrome tv tuner passthrough to a modern screen. None of the software is actually running on the SNES except the passthrough.
Having a steam machine that you stream from for example does not make you laptopbadass in the hardware department, it just means it can output the stream at the resolution.
You underestimate the accomplishment. Even after pre-processing the video on the laptop, they had to overclock the Zelda cartridge to make its internal RAM fast enough for the handoff-to-SNES-GPU process to work in real time.
Remember, this is accomplished purely through the cartridge port. (ie. They use a bug in the Zelda cart to load a new program into memory using precise button presses, then stream the data to that program… again, using simulated button presses.)
Edited 2017-01-19 07:15 UTC
Well, that’s sort of misleading too. They really accomplished this purely through the controller port(s). They had to use precise button presses to trigger a bug in the game that allowed them to upload code (through button presses) and then jump to it. Then they had to devise a protocol for sending the video data (and audio to the NES) through button presses and implement code to receive it and display it. And yes, they had to mess with the timings to make the Zelda cartridge fast enough to do it, too.
This was no easy feat, and I find it odd that people are writing it off as nothing.
And you’re being misleading as well. The “button presses” are a computer controlled cable hooked to the controller port of the console. It’s fully computer controlled by an appropriate program. There’s nothing really that great going on here beyond the fact that a computer was able to generate the proper inputs across a cable to make the console do what it wanted. Interesting to the scant few people in this hobby, but nothing special to folks in general beyond an attempt to get a “wow” out of the ignorant at a show.
OK, then, debbie downer.
I’d like to see you trigger an arbitrary code execution in a Windows 95 game via the PS/2 keyboard port, then overwrite the program and start streaming video (again, through the PS/2 port) using a custom encoding to work around the bandwidth limitations.
Oh, and it’s gotta look good in 256-color mode and run on a CPU slow enough that you can’t use a codec more complex than a sequence of raw frames… and per-frame palette switching is too demanding so you’ve gotta do a partial palette change every 5 frames to meet your performance goals.
Edited 2017-01-19 23:56 UTC
ssokolow,
I realize you are just making a point, but your idea could become a thing too
I’m not sure if any of the games that came with 95 had these kinds of exploits in them, but win95 was sometimes glitchy under normal use and with neither address-randomization nor execution prevention it’s very likely that it would work.
If the ends were more important than the means, then would there a reason to constrain the trick strictly to “exploits”? What about loading arbitrary code over PS/2 using a standard console or scripting functionality?
I remember for a long time windows 98 would crash with malformed network packets, this could probably be exploited to bootstrap arbitrary code from the network. Imagine if someone created a virus using this vector that installed linux for the user automatically
On a related note, the roku was once rooted using it’s virtual keyboard and the bundled IR remote control because of an unchecked input field (now fixed).
https://blog.exploitee.rs/2013/breaking-secure-boot-on-the-roku/
Edited 2017-01-20 03:46 UTC
Well, I did aim for the best balance of plausibility and illustrativeness that I could think of.
It’s no wonder I came up with an idea that would excite me to watch. (Or to code, if I had anywhere near the low-level skill and patience required for that kind of coding.)
Edited 2017-01-20 09:30 UTC
Yup… TASbot is not a person. It’s an “appropriate program,” but it was written by people. Very smart people who just did something that seemed impossible. Why are you trying so hard to diminish the accomplishment here?
Not intentionally… an honest-to-goodness misleading typo. I meant to write “controller port” everywhere I wrote “cartridge port” (I always say “cartridge slot” when I mean it) but I was several hours late for bed.
Far too early – move along, nothign to see here
Edited 2017-01-19 12:42 UTC