Compromising a Linux desktop using 6502 opcodes on the NES(scarybeastsecurity.blogspot.com)
scarybeastsecurity.blogspot.com
Compromising a Linux desktop using 6502 opcodes on the NES
http://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html
18 comments
That's so insane.
Not only is there a bug consistent enough to get arbitrary code execution in the game, but to also be able to reliably breakout of the emulator and literally reprogram the current game all in RAM to something completely different.
I can't seem to think of words that would do what he did justice. It's amazing.
Not only is there a bug consistent enough to get arbitrary code execution in the game, but to also be able to reliably breakout of the emulator and literally reprogram the current game all in RAM to something completely different.
I can't seem to think of words that would do what he did justice. It's amazing.
You thought that was cool? SethBling (of Super Mario World Credits Warp fame) did a single nested version of this (in Super Mario World, of course), where he reprogrammed the SNES to play Flappy Bird.
By hand.
By hand.
Indeed. it is the coolest SNES hack I've seen.
https://www.youtube.com/watch?v=hB6eY73sLV0
https://www.youtube.com/watch?v=hB6eY73sLV0
It should be noted that he didn't create the hack, it's something that's been fairly well known. What he did was accomplish it manually, whereas all previous solutions automated it via virtualized controller inputs.
Yes. I did (try) to point that out. But the fact that he did it by hand was really cool.
absolutely, and if I recall, he did it his first live try.
It was definitely impressive but as a software person I'm more impressed by the ones who came up with the hack itself.
It was definitely impressive but as a software person I'm more impressed by the ones who came up with the hack itself.
[deleted]
That's friggin wild!
I actually saw that one a while ago.
IMO this is what the word "pwned" was meant to describe. When someone has not only exploited a machine, but has literally become it's master to such an extent that they are playing games at that point, abusing the original purpose of the console into this tormented, bastardized version to display memes from a twitch chat, or play a clone of a shitty phone game.
IMO this is what the word "pwned" was meant to describe. When someone has not only exploited a machine, but has literally become it's master to such an extent that they are playing games at that point, abusing the original purpose of the console into this tormented, bastardized version to display memes from a twitch chat, or play a clone of a shitty phone game.
Expanding on what you said, I feel like in terms of personal attacks it should only be used if you could alter someone's life through the accounts you gain access to.
Maybe, but it's been overused into meaninglessness now.
Which brings to mind this blogpost by Ted Unangst [http://www.tedunangst.com/flak/post/features-are-faults], in particular this quote:
> Right now there is what I can only describe as a conspiracy to connect something called gstreamer-plugins-bad to the internet. I do not want something called gstreamer-plugins-bad to be connected to the internet because that doesn’t sound like a good idea, but apparently somebody decided to call it a feature, and just like that it had to happen. It’s as if somebody looked at the UML diagram for my browser and realized that the boxes labeled malicious input and gstreamer-plugins-bad weren’t yet connected, and in their utopian vision of the internet, all of the boxes must be connected.
> Right now there is what I can only describe as a conspiracy to connect something called gstreamer-plugins-bad to the internet. I do not want something called gstreamer-plugins-bad to be connected to the internet because that doesn’t sound like a good idea, but apparently somebody decided to call it a feature, and just like that it had to happen. It’s as if somebody looked at the UML diagram for my browser and realized that the boxes labeled malicious input and gstreamer-plugins-bad weren’t yet connected, and in their utopian vision of the internet, all of the boxes must be connected.
Thanks for posting this quote! It's super awesome and is very close to my own thoughts on the matter :) I'll be sure to cite this link in any future blog posts on the topic.
"The attack surface of the Linux desktop does not appear to be under control, or adequately monitored for regression." No kidding. I ran into an interesting example for this a year or so back - the library used by KDE's search indexer for reading image metadata added support for video files with a bunch of classic buffer overflows in the new code, and even though it wasn't used to index video files a similar filename trick could be used to get the indexer to call it. Not sure how easy it would be to get code execution, but it wouldn't require any user interaction thanks to Google Chrome.
Yes,
http://arstechnica.com/security/2016/09/linux-kernel-securit...
This is probably the only reason I can somehow understand Google's draconian approach to the NDK APIs, versus what iOS and UWP allow for.
http://arstechnica.com/security/2016/09/linux-kernel-securit...
This is probably the only reason I can somehow understand Google's draconian approach to the NDK APIs, versus what iOS and UWP allow for.
You are clairvoyant :) I'm working on this area. Some distros have this problem with their default Gnome-based desktops too.
On a similar note, last year three huge security holes were discovered in ZSNES that allow an attacker to execute arbitrary x86 code using a malformed ROM. [0] [1]
After seeing that and seeing this article, I'm thinking this might be the start of a whole new era of finding security holes in emulators that allow PCs to be compromised by running something shady in an emulator.
[0] https://www.reddit.com/r/emulation/comments/3aq0t3/psa_zsnes...
[1] Seriously, if you're still using ZSNES to emulate SNES games, don't. That's a really scary vulnerability, it still hasn't been patched, and ZSNES has been horrendously inaccurate and buggy since even before that. Do yourself a favor and use Snes9X (or if you can, try something based on a bsnes core, like Higan, bsnes-classic, or RetroArch configured with a bsnes core; they're the most accurate, but the system requirements are high, and Higan's UI isn't user-friendly).
After seeing that and seeing this article, I'm thinking this might be the start of a whole new era of finding security holes in emulators that allow PCs to be compromised by running something shady in an emulator.
[0] https://www.reddit.com/r/emulation/comments/3aq0t3/psa_zsnes...
[1] Seriously, if you're still using ZSNES to emulate SNES games, don't. That's a really scary vulnerability, it still hasn't been patched, and ZSNES has been horrendously inaccurate and buggy since even before that. Do yourself a favor and use Snes9X (or if you can, try something based on a bsnes core, like Higan, bsnes-classic, or RetroArch configured with a bsnes core; they're the most accurate, but the system requirements are high, and Higan's UI isn't user-friendly).
There was just an article about exploits in Dolphin published yesterday that I found pretty interesting: https://dougallj.wordpress.com/2016/11/13/exploiting-dolphin...
I agree this will probably catch on as a popular new vector, especially given the popularity of emulators on mobile devices.
I agree this will probably catch on as a popular new vector, especially given the popularity of emulators on mobile devices.
> a whole new era of finding security holes in emulators that allow PCs to be compromised
Indeed. People acquire ROMs for emulators illegally from wherever they can get them anyway. Given what you say about ZSNES, I'd be surprised if no one has yet built a botnet by spreading a ROM attacking ZSNES.
Indeed. People acquire ROMs for emulators illegally from wherever they can get them anyway. Given what you say about ZSNES, I'd be surprised if no one has yet built a botnet by spreading a ROM attacking ZSNES.
Retroarch just uses cores from other emulators, doesn't it?
Yeah, that section of my post was poorly worded. I might edit my post a bit and fiddle with the wording.
This reminds me of an old joke that the best way to make software that will run 50 years from now is to write it as a NES cart.
Between the NES, Gameboy, Commodore PET and 64, Apple I and II, Atari 2600, and more, the MOS 6500 series of processors are truly immortal foundations in the history of computing and videogames.
The Game Boy was actually a Z80 variant (or, probably more accurately, an 8080 variant supplemented with part of the Z80's instruction set).
Nintendo's hit most of the big personal computing CPU architectures through the course of their history-- 6502 in NES and SNES, MIPS on the N64, PPC on Gamecube/Wii/Wii U, and ARM on GBA/DS/3DS/Switch. The only ones they really missed were 68k and x86.
Nintendo's hit most of the big personal computing CPU architectures through the course of their history-- 6502 in NES and SNES, MIPS on the N64, PPC on Gamecube/Wii/Wii U, and ARM on GBA/DS/3DS/Switch. The only ones they really missed were 68k and x86.
It's also shockingly easy to write an 8080 emulator, on which you can run CP/M complete with a C compiler.
The MOS 6502 also has quite easy to emulate opcodes. Hence why it is perhaps unsurprising to find one even embedded in an audio library as in the article here.
When I had to write some 6502 code for a lab class in college I didn't like the debugging options in most of the emulators I found and did write my own mini-emulator in JS (or maybe it was PHP; it has been a while) to debug some of the specific parts of code I was working on in that lab class.
When I had to write some 6502 code for a lab class in college I didn't like the debugging options in most of the emulators I found and did write my own mini-emulator in JS (or maybe it was PHP; it has been a while) to debug some of the specific parts of code I was working on in that lab class.
I wrote a logic-based 6502 emulator using bitfields a few years ago - less than 500 lines of C. With some patches it became able to run Apple I BASIC...
https://github.com/happycube/chadslab/blob/master/m6502/m650...
And hence the coding quality separation of gstreamer plugins. There is a reason the plugin ended up in gstreamer-plugins-bad, and most of them it is due to code quality or lack of maintainers or both.
Oh really, the -{good, bad, ugly} axis is coding quality? I always assumed it was licensing status / patents clearance.
EDIT it's both: https://gstreamer.freedesktop.org/documentation/splitup.html , http://askubuntu.com/questions/468875/plugins-ugly-and-bad
EDIT it's both: https://gstreamer.freedesktop.org/documentation/splitup.html , http://askubuntu.com/questions/468875/plugins-ugly-and-bad
The good plugins have both acceptable code quality and acceptable license/patent terms. The ugly plugins have acceptable code quality, but unacceptable license/patent terms. Bad plugins are lacking code review, documentation, or are unmaintained, or have other problems that keep them from being moved to good or ugly.
I would have expected that to be the "testing" branch, not a different packages. but I guesd it makes sense if you gave up updating the code
GStreamer is highly modular, so it makes totally sense to ship a set of plugins with subpar code, unclear patent/licensing, barely maintained in a dedicated package. They called it "bad", what do you expect?
The issue here is that distributions should offer more granularity with on demand codec installation. Does it make sense that to play an mp3 (not that sure this is the case) I get also the NSF decoder?
The issue here is that distributions should offer more granularity with on demand codec installation. Does it make sense that to play an mp3 (not that sure this is the case) I get also the NSF decoder?
I think the problem is not that they have a place for the bad/ugly code, but that Nautilus runs that code on any file it can with no sandboxing.
How would people pronounce "0day" in a way where the expression "an 0day" would flow naturally?
I read it as "an zero day", and that feels wrong.
I read it as "an zero day", and that feels wrong.
My best guess was "oh-day" but I agree with you that this sounds very uncomfortable.
When you say it frequently enough, you'll appreciate the one less syllable over "zero."
edit: I even think it's more natural. "Zero day" are two real words that could be a sentence fragment, "oh-day" feels like a new word. Saying "that's a zero day" feels like an incorrect sentence to me (uncanny valley), whereas "that's an oh-day" only sounds weird if you don't accept "oh-day" as a word. To me, "oh-day" is similar to most slang, where it feels natural to say/hear even when you don't know what it means.
edit: I even think it's more natural. "Zero day" are two real words that could be a sentence fragment, "oh-day" feels like a new word. Saying "that's a zero day" feels like an incorrect sentence to me (uncanny valley), whereas "that's an oh-day" only sounds weird if you don't accept "oh-day" as a word. To me, "oh-day" is similar to most slang, where it feels natural to say/hear even when you don't know what it means.
What about saying "a 0day" which I read as "a zero day <attack>".
This same thing happens with "MVP" I think. "An MVP" sounds good, but "An Minimal Viable Product" doesn't. So I use a/an depending on whether using the abbreviation or not, but I have no idea if there's a rule for this or not.
This same thing happens with "MVP" I think. "An MVP" sounds good, but "An Minimal Viable Product" doesn't. So I use a/an depending on whether using the abbreviation or not, but I have no idea if there's a rule for this or not.
As far as I'm aware, the rule is if the first syllable starts with a vowel, phonetically.
In your example "MVP", the first syllable starts with an "em", so a vowel. In "Minimal Viable Product" the first syllable starts with the consonant sound.
I had a major pain with this rule when dealing with auto-generation of some API documentation. It ended up just being an issue of detecting/guessing if the text was an abbreviation or some weird CamelCase thing.
In your example "MVP", the first syllable starts with an "em", so a vowel. In "Minimal Viable Product" the first syllable starts with the consonant sound.
I had a major pain with this rule when dealing with auto-generation of some API documentation. It ended up just being an issue of detecting/guessing if the text was an abbreviation or some weird CamelCase thing.
Yeah, that's the way I've always done it because otherwise it sounds wrong. I guess someone taught me the rule and I don't remember or something.
That's because "an MVP" is "an em-pee-vee". It sounds natural because the "an" is preceding a vowel sound. That does not happen in "an 0-day".
Apparently it's not that common but I'm used to hearing it pronounced 'oh-day'. Zero is sort of an annoying sound to make if you are having a longer discussion where the word comes up frequently. 'oday' is really easy to say though.
I've heard multiple security professionals use the pronunciation "oh-day".
I asked my infosec friend today, and he said that “zero day” and “oh day” are interchangeable pronunciations.
"An ought day" would work.
Which would more correctly be "a naught-day" anyway. "Aught" and "ought" are abbreviated, rebracketed forms of "naught" and "nought", respectively. But etymologically, their strict meanings may be interpreted as anything or everything. They are thus in the rare category of auto-antonyms or contronyms.
As such, I would only use them to give elven advice (that is, intentionally ambiguous advice). In the context of software vulnerabilities, an aught-day would either be a 0-day, or one with an indeterminate nonzero number of days lead time to patch. So, maybe something the vendor knows about, but it would take rare expertise crossed with obscure motive to exploit?
As such, I would only use them to give elven advice (that is, intentionally ambiguous advice). In the context of software vulnerabilities, an aught-day would either be a 0-day, or one with an indeterminate nonzero number of days lead time to patch. So, maybe something the vendor knows about, but it would take rare expertise crossed with obscure motive to exploit?
I more often say "oh-day", and less often, "zero day". This could be a generational thing. "oh-day" is preferred by many of the hackers I talk to who have been in the industry for a while.
This!
TIL some people pronounce 0 as "oh" and some people pronounce it as "zero".
Take this fact with you as you read all the other comments about pronunciation on this page. ...See? :)
TIL some people pronounce 0 as "oh" and some people pronounce it as "zero".
Take this fact with you as you read all the other comments about pronunciation on this page. ...See? :)
You should listen to people read phone numbers.
"One oh four, zero one eighty"
"One oh four, zero one eighty"
or "ought", maybe?
As an old-school geek who still enjoys 6502 assembly, I find this fascinating and disturbing. Nice work explaining the find!
If you haven't read this already, you might enjoy this article: A Great Old-Timey Game-Programming Hack:
http://blog.moertel.com/posts/2013-12-14-great-old-timey-gam...
http://blog.moertel.com/posts/2013-12-14-great-old-timey-gam...
Classic: http://beza1e1.tuxen.de/articles/accidentally_turing_complet... and https://www.gwern.net/Turing-complete
(Not to say that TC itself is bad, but unexpected/accidental TC is normally a sign of bad omen)
(Not to say that TC itself is bad, but unexpected/accidental TC is normally a sign of bad omen)
doesn't look like this is accidental TC.
> NSF music files, on the other hands, are played by actually emulating the NES CPU and sound hardware in real time. Is that cool or what? The gstreamer plug-in creates a virtual 6502 CPU hardware environment and then plays the music by running a bit of 6502 code for a little while and then looking at the resulting values in the virtualized sound hardware registers and then rendering some sound samples based on that.
> NSF music files, on the other hands, are played by actually emulating the NES CPU and sound hardware in real time. Is that cool or what? The gstreamer plug-in creates a virtual 6502 CPU hardware environment and then plays the music by running a bit of 6502 code for a little while and then looking at the resulting values in the virtualized sound hardware registers and then rendering some sound samples based on that.
Until I read this article I didn't know NSF files are chunks of 6502 ASM, I thought they were sequences of notes, like MIDI files. I certainly didn't think "rendering a preview of a sound file" as "enabling arbitrary code execution".
I would classify it as unexpected TC nevertheless. Audio decoding and CPU emulation are very different things.
but in this case audio decoding by cpu emulation was the intent of the developer. i'm sure she knew what she did.
I should probably learn 6502 asm at some point. But I think I'll start with ARM and Z80 first, because I have a physical ARM/Z80 machine (read: Gameboy Advance).
The link he gives in the article, Easy 6502, is a great way to learn 6502. I do recommend it.
https://skilldrick.github.io/easy6502/
https://skilldrick.github.io/easy6502/
Thanks!
That was surprisingly simple, if a bit mind-bending.
That was surprisingly simple, if a bit mind-bending.
The best way to to learn 6502 wisdom is to read the Woz's Apple ][ ROMs!
ftp://ftp.apple.asimov.net/pub/apple_II/documentation/misc/Apple%20II%20Original%20ROM%20Info.pdf
ftp://ftp.apple.asimov.net/pub/apple_II/documentation/misc/Apple%20II%20Original%20ROM%20Info.pdf
...Jeez Don.
I think just looking at that hurt my brain.
Maybe once I've got a grip on assembler?
I think just looking at that hurt my brain.
Maybe once I've got a grip on assembler?
It looks beautiful to me, because all the 6502 opcodes are three letters long. Other assembly languages always looked rough and jaggy to me.
Well, yes... But to somebody who's barely familiar with 6502... this is brain-melting.
Fixed in Ubuntu as of today.
http://changelogs.ubuntu.com/changelogs/pool/universe/g/gst-...
http://changelogs.ubuntu.com/changelogs/pool/universe/g/gst-...
The title alone is already worth my upvote.
if i understood this right: code execution - yes, but no privilege escalation?
Yes, but if you consider on what systems people listen to music (personal computers, not servers) then unprivileged code execution can be actually pretty serious.
You could get access to their email. You could steal their private SSH keys. Steal the browser's cookie cache. Get access to their password manager. Pull API keys out of private code bases. etc.
So I wouldn't shrug it off.
You could get access to their email. You could steal their private SSH keys. Steal the browser's cookie cache. Get access to their password manager. Pull API keys out of private code bases. etc.
So I wouldn't shrug it off.
I too would appreciate further insight in this specific aspect of this vulnerability. Perhaps with the amount of flexibility apparently available it wouldn't take much work to gain root access.
There are many parallels here to the libstagefright media codec vulnerabilites that were big news in the Android world back in 2015 - the primary problem seems to be remote code execution, not privilege escalation.
There are many parallels here to the libstagefright media codec vulnerabilites that were big news in the Android world back in 2015 - the primary problem seems to be remote code execution, not privilege escalation.
It gives you the ability to run arbitrary code with the same privileges as the media player. Going beyond that would require exploiting some other vulnerability to gain root access.
That probably wouldn't be too hard. Local privilege escalation seems to be a lot easier to accomplish. It's harder to secure a system from code running on it than from data coming in from the outside. It's sort of a bigger version of the article's suggestion to "watch out for scripting in unexpected places!"
You also don't necessarily need privilege escalation to do a lot of damage. If the media player isn't sandboxed in some way, then it'll have full privileges to access all your user's files. Traditional UNIX permissions means that you need special access in order to write to the kernel, but not to read your e-mails or that spreadsheet you have with your bank account details.
That probably wouldn't be too hard. Local privilege escalation seems to be a lot easier to accomplish. It's harder to secure a system from code running on it than from data coming in from the outside. It's sort of a bigger version of the article's suggestion to "watch out for scripting in unexpected places!"
You also don't necessarily need privilege escalation to do a lot of damage. If the media player isn't sandboxed in some way, then it'll have full privileges to access all your user's files. Traditional UNIX permissions means that you need special access in order to write to the kernel, but not to read your e-mails or that spreadsheet you have with your bank account details.
Code execution only.
Bear in mind the victim doesn't need to OPEN the .mp3 file... See the part of the article about the 'auto thumbnail' feature.
I would guess that a crafty attacker could package additional content inside the mp3 file, perhaps some local privilege escalation code...
Bear in mind the victim doesn't need to OPEN the .mp3 file... See the part of the article about the 'auto thumbnail' feature.
I would guess that a crafty attacker could package additional content inside the mp3 file, perhaps some local privilege escalation code...
My understanding is that code execution is tantamount to getting root, because there's always something to exploit.
But for practical purposes, running a botnet as a user and running a botnet as root end up accomplishing about the same thing.
But for practical purposes, running a botnet as a user and running a botnet as root end up accomplishing about the same thing.
my system (linux mint, based on ubuntu 14.04.1) might be affected. the versions match, the files are there.
i'm loath to download and execute the test file though.
while i'm almost completely sure this post is legit, i also don't want to delete the gstreamer-0.1 in case it trashes something important. think of trolls recommending the deletion of system32 to speed up the system and free disk space.
can i remove this safely? is there more information from another credible source?
i'm loath to download and execute the test file though.
while i'm almost completely sure this post is legit, i also don't want to delete the gstreamer-0.1 in case it trashes something important. think of trolls recommending the deletion of system32 to speed up the system and free disk space.
can i remove this safely? is there more information from another credible source?
The test file, if your system is affected, will only open a calculator. (if you are concerned whether it has been modified to an actual attack file, you can compare it to the one on the page in a hex editor.)
Don't delete gstreamer-0.10, because many things rely on it. It is however safe to delete libgstnsf.so.
Don't delete gstreamer-0.10, because many things rely on it. It is however safe to delete libgstnsf.so.
It will likely only open a calculator if you run it against the exact version of everything listed in the blog post, which is Ubuntu 12.04.5 without any further patches.
Any different version of Ubuntu (such as 14.04.anything), will have a different glibc binary. Among other issues, the exploit has a hard coded offset of the delta between the memset() and system() functions inside glibc. This offset will only be valid against the glibc binary for 12.04.5. With more work, the exploit could be modified to dynamically calculate the correct offset for almost any version of glibc.
If the offset is invalid, you're likely to still get a crash, just no calculator. So the presence of a crash or not can be used to determine trouble vs. ok.
That said, Ubuntu 14.04 isn't too badly affected. It does come with gstreamer-0.10, but it does not appear to be used for much. As far as I could tell, gstreamer-1.0 is used for the most important stuff (totem, totem-video-thumbnailer, etc.).
Any different version of Ubuntu (such as 14.04.anything), will have a different glibc binary. Among other issues, the exploit has a hard coded offset of the delta between the memset() and system() functions inside glibc. This offset will only be valid against the glibc binary for 12.04.5. With more work, the exploit could be modified to dynamically calculate the correct offset for almost any version of glibc.
If the offset is invalid, you're likely to still get a crash, just no calculator. So the presence of a crash or not can be used to determine trouble vs. ok.
That said, Ubuntu 14.04 isn't too badly affected. It does come with gstreamer-0.10, but it does not appear to be used for much. As far as I could tell, gstreamer-1.0 is used for the most important stuff (totem, totem-video-thumbnailer, etc.).
Just remove the libgstnsf.so file which will not break gstreamer.
sudo rm /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstnsf.so
sudo rm /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstnsf.so
As a cheap extra layer of protection, you could install the version of Linux Mint you've got installed on your real machine in a VM and then run the exploit in the VM. You could also do it from a VirtualBox installation on EC2 to get extra security: if things go south (or as a matter of good hygiene), you can disable the EC2 instance from the EC2 dashboard after you're done.
So, chiptunes are bad for you?
Vulnerability in gstreamer! News at 11!
Next you'll be telling me mplayer is riddled with vulnerabilities too...
Next you'll be telling me mplayer is riddled with vulnerabilities too...
The UX should say: "This file is a NSF file, do you want to open it?"
1) Make an argument. This isn’t one.
2) Why suggest a prompt that doesn’t give the user an understanding of what they are being asked and why it matters?
2) Why suggest a prompt that doesn’t give the user an understanding of what they are being asked and why it matters?
Implicit information is what allowed millions of devices to be infected via AUTORUN.INF files causing billions of dollars in damage.
People think in ways of making things simple and easy, but you end up harming people. It's a leaky abstraction of trust.
This would fall into the same category. You don't expect risk from a MP3. But then it's not an MP3, it's a NSF.
People think in ways of making things simple and easy, but you end up harming people. It's a leaky abstraction of trust.
This would fall into the same category. You don't expect risk from a MP3. But then it's not an MP3, it's a NSF.
and continuously prompting people for input is a good way to train them to always click "Yes".
https://www.nist.gov/news-events/news/2016/10/security-fatig...
https://www.nist.gov/news-events/news/2016/10/security-fatig...
Would not be fatigue.
If the extension is mp3 and the detected type is mp3, no need to show a dialog. Only show a dialog if there might be something phony going on.
In this talk, he uses the controller interface on the SNES to send commands to a Super GameBoy, which is running a real Pokemon Red cartridge. Commands are sent to Pokemon Red to activate an arbitrary code execution bug to write a bootloader that receives the rest of the attack program at high speed. Then - form inside the GameBoy environment - he takes over the Super GameBoy and gains arbitrary code execution on the SNES proper.
(for a finish, a Twitch chat client is written into RAM on the SNES that uses a custom network protocol to send requests over the controller port, so the livestream audience can ask questions live through the SNES).
[1] https://www.youtube.com/watch?v=s-bKWT9fj8Y