All right, we finally made it. This is the last talk of the day.
You survived, you're still awake, and we're ready to wrap it up here today.
And we're ending with a really fun talk today.
It's a thing about Zelda using After Free.
Let's show some really cool stuff. A little robot doing some awesome, fun stuff.
And there you go. All right.
Hello, everyone. Can you hear me all right? Yes.
I see a few people with Taskbot shirts out here. I love that.
So if you have not met me before, I am Duango AC, Keeper of Taskbot.
I'm just going to slightly adjust this mic because I'm not that short.
With me today are some amazing folks. First of all, I have...
Soren. Hi. Yeah, I guess I'm audible.
I'm a tools developer and music arranger for the N64 community,
and I was the director of Triforce Percent. Also with us...
My name is M-Link, or Liam. I'm here to speedrun Ocarina of Time,
and I love speedrunning, so...
Before we get started,
there's a couple quick things to say. First of all, this was all made possible
by a huge team of people behind us. It's not just us.
There are so many different people that are part of making this happen.
We're here to talk about The Legend of Zelda Use After Free,
which is basically a way of saying how Taskbot glitches the future into OOT.
Yes, alliteration. I can't help it.
We're going to have a human runner, M-Link over here, start playing on a brand new file.
It's going to start from scratch.
You're going to hear some game audio.
We'll have that kind of hanging around in the background there for a little bit.
So you can hear that.
And this is an unmodified Ocarina of Time cartridge.
This is not a flash cart, no ROM changes. This is the real game.
Kind of real N64.
Yep, the only thing that's going on to give you a nice crisp image,
I have an RGB mod and an RGB upscaler here, so we can get a nice clean image.
I'm doing everything through OBS, so if anything goes wrong and you see things splashed on the
screen, it's my fault. So there's a bunch of things I could say, but we're going to get under
weight with the actual game, so let's get started. What M-Link is going to be doing is
setting up an arbitrary code execution by using a few different glitches, but first we're going
to hop into some slides. I'm just going to move this mic to the other side.
I can see. It's fine. It's fine.
All right.
So yeah, this is DEF CON. We're all hackers in one form or another, so why do we hack?
It depends on who you are, right? So most people, a lot of people,
depending on what hat you are, a lot of people will do it for money. Some people will do it for
purposes. Some people will do it to be the person that others are defending against.
Everybody does it for fun, right? But what about creating an arbitrary code execution,
a remote code execution payload for emotional impact? We're not talking about the emotional
impact of, like, oh, my God, all my files are gone. So what hat would you take?
I might think of it as a white hat. Nintendo probably thinks of it as a black hat.
You want to have a black hat.
But we're not doing that.
We have arbitrary code execution on the video game console.
And the reason we have a human runner here, Mlink here, is because Mlink is holding a
real controller connected to controller part one, and we have our friend Taspat here connected to three самات here, connected to threetı
controller courts 2, 3, and 4 for most of this. Briefly he'll connect to all four at the same time.
And there's a little bit to unpack here. So first of all, this is Taskbot. He has been around for
almost 10 years now, raising money at games and quick charity events and other things.
He is currently holding a replay device made by Onasaurus with code from Rasteri and additional
code from Sorin here as well. And that allows us to pretend to be a controller. You might consider
this a little bit of an evil maid attack, because we look like we're completely innocent, we're just
plugging into a normal port, but our intentions are not necessarily what Nintendo had in mind.
But the Taskbot is really just putting in normal compliant controller input into the controller
ports as if you had three people with controllers pressing buttons really really quickly.
Exactly. By the way, I'm very very thankful that Sorin is here for two reasons. First of all,
he'll keep me from forgetting anything on the talk, I guarantee that, and second of
all he was the director. He is right there, and he's going to talk to you at the end of the talk.
director of the project that you're seeing here, and without his expertise, this would
not have happened, so.
Okay, so let's talk about aces in video games.
So the first arbitrary code execution that beat the game quickly was one by MasterJune
back in 2012, and it managed to complete Super Mario World in two and a half minutes by using
what was then called a corrupts memory glitch that had to do with moving things around in
the object attribute map on Super Mario World.
That was followed up with another game in glitch by Lord Tom and Tompa back in 2014,
but along the same lines, Seth Bling figured out how to do an ace with human ability alone,
and this was pretty incredible.
It took a little longer, but arbitrary code execution, same method in Super Mario World,
using the object attribute map to overload a bunch of different things.
If you want to know how this works, Retro Game Mechanics Explained, who we'll be mentioning
a little bit later, has a video on how this works.
So if you're interested, you can go check out Retro Game Mechanics Explained.
So that was doing an ace, but now with human input only.
Well, I got involved all the way back in 2013, preparing for a AGDQ 2014, a charity
fundraiser at that time for the Prevent Cancer Foundation.
There I am with a lot less facial hair.
And a lot less sprinkles.
Oh, man!
Words hurt!
Anyway.
We were presenting at AGDQ 2014, and we did something more than just beat the game quickly.
We took advantage of the fact that we could do arbitrary code execution to put Pong and
Snake inside of the game.
Master June put together this amazing payload that took the world by storm.
Ars Technica covered it, and it kind of exploded from there, and that's where TASBOT started.
You can see the picture of that's the original TASBOT based on a ROB robot, and we've come
a long way since then.
There's also some interesting large sketches.
There's some detail payloads that happened with some other games.
Not everything is just on a Super Nintendo.
This was Pokemon Yellow.
This was Mr. Wint in 2017, February 2017.
He used some item manipulation and a few other glitches in the game to turn it into
Pokemon Gold version.
He shoved Tetris in there.
He shoved Super Mario Bros. in there.
He added portal references, and then he really pushed it over the edge by showing actual
video on a Game Boy Color full-frame video.
It's pretty impressive.
I highly recommend watching this.
You can go to TASVideos.org and see this run there.
But we wanted to really ratchet things up.
We knew we could do anything with Ace.
So the TASBOT community that I lead went a little bit crazy.
We found arbitrary code executions for a Nintendo game, Super Mario Bros. 3, another Nintendo
game, in that case Mega Man, and Legend of Zelda Link to the Past.
We used all three of them.
We had some rather stupid trickery to place a Skype call over the consoles.
This was silly.
I wouldn't recommend it, but we had James Chen wandering around making a Skype call
over a Super Nintendo.
Obviously a Super Nintendo does not have the processing capability to do this.
We did use some trickery, and we were shoving full frames of video through the Super Nintendo
and using the two Nintendo consoles as the audio sources.
We got to this point, like, how do we go any farther?
We've done the most technical things we possibly can.
Where do we take this next?
Along the same time, by the way, large-scale Ace payloads started happening even with human
runners.
Seth Ling went on to make a Flappy Bird version, a clone, entirely with just human input.
So he turned Super Mario World into Flappy Bird.
Credit for that man's ingenuity.
I've met him in person several times.
He's a great guy.
You should check him out.
I'm going to hand it over to him, to Soren, for the next part.
Yeah.
So all of those examples of large-scale Ace payloads that we showed were sort of meme-y.
You take over the game.
You're basically just using the game as an entry point to take over the console and then
put in some exploit that does something unrelated.
But how about exploiting the game in order to change the game's plot in a way that is
actually meaningful in the context of the original game?
So Mr. Cheese came up with this in 2017.
In Pokemon Blue, there was an urban legend that if you went to this particular place,
and used a Pokemon's ability to push this.
This truck.
You could find Mew under the truck.
And this wasn't in the game until you had arbitrary code execution.
And then it was in the game.
And so he made that.
And he made, because it's not ROM changes, it's sort of within the game.
It's just gameplay.
It's just input.
So he did that in 2017.
And I saw that video and posted this comment on it.
Using Ace to recreate what should have been in a game is one of the best things to do
with it.
I am a Joe.
I'm just waiting for Ace in Ocarina of Time so we can program in a cutscene where Link
gets the Triforce and put two decades of rumors to rest.
So what am I talking about here?
In 1997, before Ocarina of Time came out, Nintendo showed, like, advertisements on TV
about that contained this scene of Link getting the Triforce.
This was not in the final game.
But people had seen it on TV, and then they got the game, and then they wanted to do it,
and it wasn't there.
And so people wanted to figure out how to do that, and there was all these little pieces
of, like, beta content.
References to things.
So people thought it might have still been some secret buried in the game this whole
time.
In 1999, somebody made a hoax about getting the Triforce with some Photoshopped images.
Nowadays, this would not pass muster for Photoshop quality.
But in 1998, this was, like, a big deal, and people were all believing this.
And yeah.
So that was all...
That was two years before Ace was found in Ocarina of Time.
It was found in 2019 by...
Several people worked on this.
The names are listed here.
And so then I posted on that video.
Now we just have to use Ace to get the Triforce.
So two and a half years later, that is exactly what we did.
We made a large-scale Ace payload that creates a completely new plot within Ocarina of Time
injected entirely through controller input that has little pieces of beta content and
little pieces of urban legends and other things.
And it leads to Link getting the Triforce, and then it leads a little further beyond
that we'll talk about at the end.
So arbitrary code execution sort of has two main components.
Components of the Triforce.
Component one is you have to somehow get your code onto the target system in some fashion.
And then component two is you have to get that code to get executed.
Yes.
It's not an easy setup.
Sometimes it goes wrong.
Somehow you have to get the code executed on the target system.
So what...
In the N64 context, what that means is we somehow have to get some amount of the N64's
memory to be new MIPS machine code.
That is something that we write for whatever we want to do with it.
And then we have to somehow get the program counter pointed to that MIPS machine code
to execute it.
And what that basically boils down to is sufficient control of memory and breaching the separation
of code and data, which normally is, you know, an important part of how a computer works.
So those two things are accomplished through...
We encode certain data in rotation values.
In other speed runs, they use Link's name in Japanese to encode two MIPS assembly instructions.
Okay.
So in this one, what we're mainly focusing on is memory holding the state of all of the
buttons on all the controllers, the buttons and control sticks, because that is memory
that we have a pretty easy way to manipulate the values of the memory.
And then breaching the separation of code and data happens through a use after free
bug, which is what the title of this talk is about.
And the manipulation of that use after free bug in the speed running community is called
stale reference manipulation.
And both of these things are accomplished through a combination of speed running tricks
and heap manipulation.
Which is what we're going to talk about next.
All right.
This is the part where OBS goes wrong.
Oh, I love the confidence.
This is actually more like the part where I go wrong, but that's okay.
So let's see what happens when I show this.
All right.
So this is the wrong location for this.
This should be over here instead.
Let's make that over there.
All right.
There we go.
I told you.
I forgot to relocate.
It's fine.
It's fine.
It's okay.
So RGME, retro game mechanics explained by Isofreeze.
There's a whole video about this.
I am using this with permission.
Thank you very much to him for that.
There's a lot of information you're going to see on the screen now that I'm not going
to get into.
This part of the talk is kind of like running on a treadmill.
I'm going to have to keep up with all of these notes and it's not exactly easy.
All right.
So first of all, right now it's a video explaining how the controller input works.
We're not going to go through all of that.
But what I am going to go into is the heap.
Okay.
So if you're unfamiliar, a heap is an area of dynamically allocated memory where data
blocks of different sizes are reserved for use by various objects and functions.
So in Ocarina of Time there's a specific heap called the actor heap that contains code and
data for all of the actors that are currently loaded in the game.
So an actor in this context.
It's any sort of object or entity, link, for instance, rupees, hidden objects and triggers
like that.
There are two main kinds of things held in the actor heap.
There's actor overlays and the actors themselves.
Actor overlays contain the code that is run for each type of actor.
In other words, how they behave, let me move it forward a little bit, there we go.
There we go.
So things like how a particular object type behaves and things like that.
Whereas the individual actors are instances of that actor.
So as actors are loaded into the game, they're allocated into memory on the heap.
So the game starts searching from the top, finds an empty spot, drops it in, as you can
see in this graphic here.
So it will find the first spot that it will fit in and it drops it there.
So if a new type of actor is loaded, the corresponding actor overlay is also loaded.
And when you transition to a new area, all of the actors in the new area are allocated
to the heap.
Before all of the old actors are loaded.
They are freed.
So this results in actors and overlays being assigned memory locations that aren't consistent.
In other words, the location and memory will depend on exactly how many actors were already
loaded and how they were organized within the heap structure.
This signpost actor you see here may be located there at the moment, but if you were to leave
the area and come back, it might be somewhere completely different.
So some actors need to keep a pointer or a reference to another actor in their data.
For instance, right here.
There's this boomerang that needs to keep a reference to the actor it's grabbed, such
as this rupee.
So under a normal circumstance, if an actor references a second actor, the second actor
should not unload or be freed from the heap until or before the first actor is either
unreferenced or is unloaded by itself.
If this were to happen, we'd call it a stale reference, right?
Means that the pointer that this actor has is not pointing to a memory location that
is not being used anymore.
That means that if another actor were to be allocated to the heap.
In the location where that old actor used to be, like this chest, then it might be pointing
to an actor it probably shouldn't have access to.
So if we use the boomerang as an example, by unloading the actor it has grabbed, the rupee,
and going into a room transition while it's off screen, a different actor will take its
spot.
This causes the boomerang to modify that new actor's position instead, which can cause
some really unusual behavior such as objects teleporting around.
This was actually how this was first discovered.
So this is an example of an actor being allocated in the same memory location as an older actor.
Okay.
So what would happen if an actor overlay loaded into this memory location instead?
In other words, when the boomerang modifies an actor's position, what is it actually doing?
So for all actors, their X, Y, and Z coordinates in the world space are held at offsets that
you see on the screen.
And the boomerang will take the addresses of the pointer to the actor it's holding,
add those values to it, and write data at those memory locations.
This basically means that it's...
This would effectively modify the X, Y, and Z coordinates of the actor it's holding.
If it had a stale reference that is now pointing to an actor overlay instead, some really strange
things happen.
Really strange things.
So first of all, each actor overlay is different, but the important thing is that the blocks
of code...
We're now looking at blocks of code instead of blocks of data.
So the boomerang is still going to obliviously write to those same data offsets, but it's
going to be writing 32-bit float data into where 32-bit MIPS assembly instructions are
supposed to be held.
Now, if the code that this overlay gets executed...
Or for this overlay gets executed after the boomerang modifies it, it'll usually just
flat-out crash, since the code has been overwritten with data that is unlikely to be valid or
sensible.
But if we could control what values were being written by the actor, and in other words,
exactly which instructions from the actor were being overwritten, we could effectively
modify the code that the game executes.
And we could make it do whatever we like.
This is basically the essence of what we refer to as a stale reference manipulation exploit.
So this is a use-after-free bug, but with a little bit of extra stuff in there.
In the Triforce percent run, we achieve this by...
And you might have seen this on the screen a little bit ago.
We achieve this by having Link pick up an item while it's cold.
In this case, not being drawn off screen.
Then without allowing the item to be unculled, we pass through a loading zone so the item,
the item unloads and Link has a stale reference.
That's the important part.
We then come back through the loading zone to get a particular actor overlay to occupy
the memory that was originally taken up by the item that Link was holding.
So let me just jump in here.
So the bugs that we're using are camera bugs to manipulate where the camera goes.
Because we can have Link holding an object that is so far away from the camera that it
gets culled.
And then the other bug, which you could say is a bug, is that they didn't check when the
camera goes.
And then something unculls whether it is being held.
And to have Link let go of the thing if it's being held.
But that wouldn't happen in normal game way without the camera bugs because Link is always
on screen in front of the camera.
Yeah.
So RGME, Isofreeze on his RGME channel made a really cool memory map.
This is a map of all of memory in...
All of the actor.
All the actor.
Yeah.
Yeah.
The whole thing.
So I'm probably getting a little off of my location here, but that's all right.
All right.
So basically, by collecting various items like rupees, we prevent them from loading
back in each time the loading zone is triggered.
And since Mido is nearby, you just saw him on screen a little bit ago, the direction
that the camera is facing is important.
Because if the camera is facing towards the main room, Mido won't unload, which causes
his overlay to stay put while his actor instance moves around in memory.
So we're switching the direction of the camera while walking back and forth over the loading
zone.
And all of the actors and actor overlays in the heap are getting culled.
They're being shuffled around in a very specific way.
That's why you saw M-Link going back through the doors so many times.
If you're wondering how we found that set of actions that lead to this particular shuffling
of memory, a bunch of the people who worked on this wrote scripts to like programmatically...
Basically programmatically do those actions and see what would happen.
Yeah, exactly.
So basically, we're using a glitch here to force the camera to always stay behind Link,
then using another item glitch to move around while a text box is open.
And that allows us to get the camera very far away from Link, which will cull away any
actors that are nearby him.
You're going to see that in just a second here.
So he's going to hit this rock.
And the camera angle...
Let me fast forward a little bit here.
So that rock is kind of important.
So here you're going to see that as Link smacks that rock, the camera pulls way, way away.
So that culls any actors that are near him.
And because of the heap manipulation we did earlier, we know exactly where in the heap
that data for that rock actor is.
So when Link is culled...
When Link is carrying an actor, he's updating the position and rotation of that actor so
that it appears in his hands above his head.
This gets pretty interesting.
So in other words, the rotation of an actor, which is a 16-bit value, is stored at that
offset.
If the rock is stored at that address, we know that that address is the one that will
be modified.
And in this case, it's the rotation value written as...
It's just Link's rotation value that's written in.
Since it's pretty easy to control what angle Link is facing just by walking around, it
means that this value can be used...
It can be used to write an arbitrary data.
We're literally using Link's, either his actual position or the camera's position to
manipulate this.
I'm going to fast-forward a little bit, unless there's anything you want to say about
that.
So there's a specific item called the wonder item, and I could get into a lot more specifics
here.
We're basically overwriting the offset of a branch instruction to get the code to branch
to somewhere else that we can control by setting what this rotation is.
So you can just skip a few.
Yeah.
There's a bunch of extra things that you should go watch the RGME video about to get
some more details.
Everything is linked on our website, which is on the lower bottom of the screen here.
Yep.
Get Triforce.Link for the rest of this.
Oh, wait.
They can't see that.
Oh.
Yeah, it's off the screen.
It's because the video is up.
That's why.
The video is covering it.
Oh, yeah, yeah.
Once we go back to the slides, it'll be up there.
Oh, yeah, that's right.
Yeah, yeah.
Because I kind of got moved off screen.
I actually think that for purposes of time, I think we should keep moving forward.
Yeah.
But you can watch the rest of this.
The RGME video does go into great detail of exactly...
Exactly what the rock angle is and what Link's angle needs to be.
But we're gonna switch back...
Switch back to the slides, yeah.
Yep.
Back to the slides here.
All right.
Oops.
Let me go to...
That's the wrong one.
Here we go.
All right.
Okay.
So...
Right.
So...
We're...
Basically...
We don't have time to go over the entire chain of where execution goes, but the...
It goes from this rock rotation...
To Link's rotation.
It goes from Link's rotation to the controller input.
We start executing the controller, the memory containing the state of all the buttons and
control sticks as code that runs one instruction per frame.
That collection of one instruction per frame over many frames is bootstrapper one.
The function of bootstrapper one is to write bootstrapper two into memory.
Then we run one controller input as code to jump to bootstrapper two.
That changes how controllers are pulled, changes a few things.
It's only a few dozen bytes of code, so it's not a lot.
But then we do, again, one instruction per frame, which is bootstrapper three.
The function of that is to write bootstrapper four into memory.
We then jump to bootstrapper four repeatedly over and over.
And what bootstrapper four does is it takes the rest of the controller input and writes
that to memory.
And what that is is the first big part of the payload, which is called the hyperspeed
loader.
And at the end of...
And once that has all been written, then we jump to that once.
That turns off all the arbitrary code execution, sort of puts everything back to normal, and
then starts listening on controller ports two, three, and four for combinations of controller
input that represent packets that describe arbitrary memory writes, arbitrary function
calls, and basically we can do whatever we want from that point.
So we are up to the point where the human speedrunner is done, MLink is done, and we
switch to TaskBot to play in a short task movie file over all four controller ports.
So this is going to be TaskBot manipulable.
I'm manipulating the controller input, which will be executed as code.
So I'm switching...
Switched controller one to be controlled by TaskBot.
So all four controllers are being controlled by TaskBot.
And let's hope this works.
And we can have a little bit more game volume now.
So this wiggling around is wiggling, but it's also code.
And there's faster wiggling, which is faster code.
And you see the little green bar in the corner?
That means the game is pwned.
Yes.
Well done, MLink, by the way.
That is not easy.
The human portion of this was actually one of the scariest parts of doing this talk.
Thank you.
So the reason it's a green bar is that the game has its own crash debugger.
And when the game crashes and the crash debug gets activated, it puts a yellow bar in the
corner.
And so we made a green bar to mean it's pwned.
But it's also that that's being done by the hyperspeed loader.
So I've changed controller one back to MLink.
If you could go walk towards my house, but not enter it.
And what I'm going to do next is run a script that will now basically send messages to this
hyperspeed loader.
It's pulling controllers eight times per frame at 60 frames per second for a total
speed of 5,400 bytes per second of memory transfer, or whatever we want it to be.
And what I'm going to be injecting is this is stuff that is linked to statically assigned
addresses in memory, as opposed to later is going to be files.
And I'll talk about that in a couple of slides.
But that's done.
That just took a few seconds.
And now what I'm going to run is the rest of the injection.
So this is going to start dumping files and all kinds of changes we want to make to the
game into the game's memory.
By the way, you're wondering where do we get all this memory from?
We have an expansion pack installed, which is an extra four megabytes of RAM.
So we're going to run that.
And so the game only uses the first four megabytes.
We have the upper four megabytes to just do whatever we want with.
So I've started that.
If you could go into the house, please.
So we need to go into a house to clear out some residual glitches that are still active
and leave again.
And then if you pause and press L. So this is the first thing that we would show during
the Triforce Percent run.
This is the inventory editor.
This was created by the developers to set up link state and test the game.
And we just need to, because we're not going to show the full thing today, we don't have
enough time.
We're just going to give ourselves a couple of things here.
So yeah, that's right.
And the next thing that we would show is the R-Wing.
So, oh, what did you?
I did L and D-pad down.
I did L and D-pad down.
And nothing else?
Nothing else.
Well, that's never happened before.
That has never happened before.
Yeah.
Okay.
Are you sure?
Okay.
Whatever.
Let's see if it crashes after you exit yourself.
All right.
Now we see what happens.
Yeah.
That's how sane the game is.
We should be okay.
Yeah.
Actually, what you should just do is just don't advance it at all.
And we'll just try to warp to the ending at the end and see if that succeeds.
So, okay.
Sorry.
We can't show you much of the R-Wing.
But, oh, well, I don't know exactly what happened.
Maybe you hit one of, like, D left or D right.
Okay.
Okay.
Whatever.
I've never seen that before.
Basically, they left the R-Wing on the cartridge, and that was the shtick we used to present
this at GameStop Quick.
It did.
It was saying that it was a beta showcase.
Hey, this is all beta content that's on the cartridge.
And any time there really was beta content on the cartridge, we called it out.
Unfortunately, a lot of people got really upset about the time we started introducing
other elements because when we didn't say, this isn't beta content on the cartridge,
the message didn't quite get through.
Right.
You know, we put a bunch of things on screen.
We say, this one 3D model is beta content left on the cartridge, and everything else
is made up by us.
And then people heard, oh, it's all left on the cartridge.
But, anyway, so, yeah, so this is still dumping data into memory.
We'll continue for a few minutes.
And we're going to go back to...
Yeah.
We've got the slides back here.
We can take the...
We can have the volume bit low on the game.
And we're going to switch back to slides.
Yeah.
All right.
So what we're doing with this hyperspeed loader, I mentioned some static data.
The first one is a debugger.
So this is, like, another debugger that sits on top of the game's one.
You can see this is an example where one of the threads crashed, and we say, press C
right to pay respects.
That's because on the original, like, beta N64 controller, the buttons were A, B, C,
D, E, F. And so C right was the F button.
Next thing is DMA patching system.
So, you know, the cartridge has ROM in it.
We can't modify the ROM.
But we can modify the OS data, the OS code that will load from ROM, and we can have it
load from other places instead.
And so there's three ways of doing that.
If you actually change the address to load from to a RAM address, it'll copy from RAM.
We made another map from, like, an extra part of the cartridge, virtual cartridge, to RAM
that it can load from.
And then also, if it loads from something from the cartridge before returning that to
the code that called it, it can go through a list of binary patches and sort of apply
a binary diff to change the data.
The third thing is the rest of the statics, which I'll talk about in a minute.
And then just a bunch of assets for totally new stuff, whatever we wanted to create in
the game.
So, this is the really technical part.
If the first part wasn't too technical, I'm going to go very briefly over some of the
stuff that is in all of the statics files, because this is DEF CON, and I think you might
like it.
But, you know, don't worry if you don't catch every detail.
All of our code that we've created for this is up on our GitHub, which is linked from
our website, which is on the screen here.
Yeah, it's on the screen.
So, statics contains some one-time code patches for various things.
There's an update function that gets run on the 60 frames per second DI tick.
There's update.
That gets patched into links actor.
There is a mechanism for registering further static data, like audio and interface patches.
There are random patches for other things that we couldn't fit where they needed to
be, and so we just put them here and then had the patch code to call in here and then
call back.
This is the code for the R-Wing, which you saw and then something happened with.
But yeah, this is checking for some buttons and then looking for an R-Wing, and if it's
not there, then spawn one.
Yeah.
This is some scene patches, so this is like a cutscene terminator, so at the end of one
cutscene, where does it go next?
This is the entrance table, so for example, normally if you go from Granny's Potion Shop
to Kakariko Village, we replace that with a route from Chamber of Sages to Triforce
Room.
This is changing the object heap size, depending on which scene you're in, based on how much
stuff you need to load.
This is some graphics code for scrolling textures in the Chamber of Sages.
For interface changes.
We would be loading custom icons and stuff on the GUI, and those get loaded from memory.
Since we want to make sure that things don't crash live, we have to check for, if things
are out of bounds, whatever, default to frog for the item icon.
When we equip medallions, which is a beta feature that we reconstructed, the medallion
has to fly across the screen onto the GUI, and so this is the code for that.
We have custom items.
We have to patch the function for loading the custom item name texture.
There's changes we made to the magic bar, that it renders twice as large.
There's changes to the message and text system, so we have a whole bunch of custom dialogue
for this totally custom plot that we showed.
And again, loading messages.
We actually hooked into some code left over for the N64DD expansion to OOT, also called
Uruz Zelda, which is like DLC that Nintendo was going to make in 1998.
And this is the final version.
And so we just hooked into their existing text patching code.
Again, if something is out of bounds, default to Frog.
This is Frog, by the way.
So we made audio changes, custom sound effects, custom music.
Audio has a separate way of DMing,
so we had to patch that.
This is manipulating what happens
when you play a new Warp song.
For the finale scene, we had to make
a new set of environmental chirps for birds and stream
sound for that scene that didn't exist in the game before.
We had to change Ocarina playback for plot reasons,
and so we had to re-encode Ocarina songs.
We had to change how Ocarina buttons were handled,
and then a whole bunch of assembly patches
for the graphical rendering of the Ocarina system.
Link has custom animations at the end,
and those are streamed from ROM, and so we had to make
it be able to stream them from RAM.
We changed how the game does animation interpolation.
It used Euler angles to interpret animations,
and we changed it to use quaternions globally,
because we had some problems with the Euler angles
in our custom models, so we just fixed it for the whole game.
This is an example of an action table
where we copied in our table, overwrite most of it
with the existing data, and then have our appended stuff,
because you can't just shift everything,
because everything is linked to where it is in ROM.
And we even have hair physics for the ending
that you'll see in a bit, hopefully, if things don't crash.
Yeah, and so this is an actual numerical integrator
for the double pendulum problem for Link hair.
And that's, yeah, the CPU has plenty of power available
compared to the graphics hardware, so there's usually
CPU available for us to do this kind of stuff with.
I want to talk a little bit about the assets.
So we made a whole bunch of custom assets.
You'll see some of them in a bit.
This is making the Triforce scene in Blender.
The black things that you see are camera keyframes,
basically, for the camera motion.
And this is all done through some plugins for Blender
called FES64.
FES64, which many people worked on, including myself.
For custom music, we use sort of normal music tools
for creating midis and then importing
those midis into the game.
This is actually the way I got into the N64 community,
is I worked on that software back in 2014, and then
since then, we did some instrument set changes also.
This is some of the custom text.
So this is the text for You Got the Triforce.
And you may notice that the text ID for this
is hex A-C-E for arbitrary code execution.
This is some custom actor codes.
This is Beru, one of the custom actors that we see.
This is some animations that she's talking to Link.
This is the Running Man boss.
This is some of his code.
There's a sort of a humorous thing
where this side character turns into a secret boss.
This is some of his code.
I mentioned a patching system.
So this is a patch written in text,
and then this is the same patch written in binary.
So it's like, go to this address and patch this one byte,
and go to this address and patch
this short, and this is an example that includes data,
and this is an example that has assembly instructions.
This is the patch for Link.
So it's a bunch of just patch out this and patch out this.
And so we're going back to the game here.
So what we did with all this, again, we
made a plot that leads to the Triforce.
We don't have time to show everything,
so we're going to just warp to the Triforce scene, hopefully.
Can you do that in the middle of a cut scene?
Yeah.
All right.
Well, let's see what happens.
Oh!
Oh!
I guess there was something wrong.
I don't know.
All right.
Do you have the flash cart with you?
Yeah, I have the flash cart.
There's my backpack.
Thank you.
All right.
So live demos sometimes go wrong.
Here's what we're going to do.
We're just going to very briefly cheat.
Cheat, yeah.
This is a flash cart.
I've got that off screen for a second.
It's only over there.
OK.
But should we do, like, because we still
have to wait for it to inject everything, which
is like six minutes.
Oh, you don't have the, uh, the, uh.
I do, but I don't know if the Twitch will work with that.
Oh, well, we might not be doing chat.
We'll see.
We can try it.
All right.
Let's see.
I think this one, this, we did not rehearse this.
We did not rehearse this back up.
Things might go wrong here.
We'll see.
This is what happens when you do live demos.
Now, luckily, this went correctly at Austin,
so we'll see if we can get some games done quick, 2022,
or summer games done quick, 2022.
So we may or may not have chat working.
We'll find out.
Give it a second.
There we go.
I forget if this had a.
I don't know how we got warped to that weird area.
Right.
This is, uh, we have to sit through the intro.
Oh, no.
Yeah.
Oh, no.
But let's just, let's just finish our talk.
Yeah.
And then we can, uh, yeah.
Yeah.
So.
Yeah.
We will not be watching the outro.
So there's a couple of things that he needs to say
and a couple of things I need to say.
And I'll let you start.
Yeah.
So sorry about that.
But I don't, I don't know what happened.
We, you know, we practiced, but, you know, live demo.
Yeah.
So what we showed at, you know, with this,
with this people grew up with this game
and people grew up on the internet
with these urban legends
and sort of wanting to get the Triforce and all of the,
you know, knew about all these little pieces of the game.
And these were all sort of,
part of what the, what everybody knew about the game,
but wasn't ever part of the actual game.
But arbitrary code execution is in the game,
even though it wasn't intended by the developers.
And so using these exploits,
we can make those things happen.
And, uh, you know, we, people have different opinions about,
you know, how valid that is in a game.
And certainly once we've switched to a flash card,
it's, you know, it's just a ROM hack.
Um, but, uh, this really made a lot of people feel,
and this was sort of the idea, um,
feel that this was, like, resolving their childhood
in a way, um, because, you know,
these are things that they always wanted
and, like, a chapter of their childhood,
uh, can you go from there?
Once you get control, then give the correct idea.
Um, yeah, so, um, we had a lot of people telling us
that, you know, this had a big impact on them.
And what you'll see, if we can make the ending work,
um, there's a little more to it than that,
but, um, yeah, I'll wait, I'll wait for that.
And you can talk about the,
the other parts of the impact here.
So, for me, this was the biggest thing we had ever done.
I showed you a slide earlier where we had taken
a bunch of different consoles,
cobbled them together, uh,
with a huge amount of help from Micro 500
and a ton of other people,
uh, and we made a Skype call over a Super Nintendo.
And it was technically interesting,
uh, but we weren't sure where we were gonna go next.
And where we ended up going next
was Sorin putting a huge amount of heart
and effort and years of, of direction
into making, uh,
making what we, what we ended up showing as
Legend of, Legend of Zelda Ocarina of Time Beta Showcase.
He put a ton of effort into making an emotional story.
The impact of that at Games Done Quick,
Summer Games Done Quick 2020,
2022 was incredible.
Uh, we helped raise over $228,000
for Doctors Without Borders in one hour of content.
So why do we hack?
It's not just to find use-after-free flaws
or, or stale reference manipulation in video games
or anything else.
We're doing it because we're able to showcase these
at big events and raise money for charity.
Uh, if you have any interest, go to, uh,
European Speedrunner Assembly in Europe,
uh, Games Done Quick here in the United States,
uh, we've done other events as well,
uh, RPG Limit Break,
uh, even MAGFest runs them.
Uh, very, very worthwhile checking them out.
Um, so, for me, this was the biggest thing
we had ever done.
Uh, we've now helped raise over $1.3 million
with TASPAC content.
It's been really amazing.
Let's make a save as soon as we get control.
So, I'm hopeful that we'll be able to show you
what the ending of this looks like.
No, no guarantees on the chat part, but...
So, I realize there won't be chat,
because the chat comes in through the hyperspeed loader,
and there's no hyperspeed loader in a ROM hack.
Ah, okay.
So, but we can, um,
we can hopefully make the rest of this work.
So, this is Link in the Triforce Room scene.
This is what we were trying to work to.
So, everything you're seeing on screen here was injected,
except, well, this is a ROM hack,
but it would have been if things hadn't gone wrong.
So, you know, we said, oh, well, this is...
Right, we wanted to make sure that the text
that was on screen with Link getting the Triforce
was text that couldn't possibly have been in the ROM,
because it's referencing the time.
I should have updated to 24 years now.
I know, right?
I forgot.
I made so many other changes,
and this is not going to have the right credits in it.
I know, right?
Because I updated that.
I didn't update this.
I'm so sorry about this.
But, anyway, um, yeah.
So, you know, with that moment at GDQ,
we had the eyes of 100,000 people,
we got the Triforce, we made their dreams come true,
and then what do we do with that, you know,
attention and goodwill of the audience?
We took it a little farther,
and this is Link talking to the goddesses,
the goddesses of the Triforce.
Before we get to the next scene,
everything you're seeing is on the real console normally,
the real cartridge normally.
This is only just using a different cartridge in this case,
but there's all kinds of audible things that you'll hear here,
there's several different unique aspects.
Graphical features.
Yeah.
But I think we're generally going to be silent
and let you guys experience the emotional impact
of what Link is able to do here.
So, Link gets a wish from the Triforce,
and we sort of convinced the GDQ audience
to have us pick See the Future,
because that's the only one we implemented.
See the Future.
We'll get a little bit more game volume here,
you're going to want to hear this.
See the Future.
So, yes, this is not a video.
This is the N64.
Myself and Glank,
who is one of the, like,
greats of N64 stuff worked on the cell shading and made a cell shading algorithm for N64,
which wasn't previously thought to be possible. Also, these models are much higher poly than
normally for the N64. They're substantially reduced from the versions on the Switch.
Link! It seems you managed to get together a great number of people. I'm so happy to see this.
I knew they were out there, but it would be nice if we could see them, don't you think?
Yeah, yeah, it would be.
Unfortunately, we don't have the chat because it's not live.
But yeah, so you can imagine the sky filled with chat messages.
We've made it go for a pretty long time to make sure a lot of people got to see their messages on screen.
Also, at GDQ, it was a subscriber-only chat, so we told everybody,
hey, you gotta subscribe, which all that money went to Doctors Without Borders also.
But imagine this sky filled with people saying, we're here together after a pandemic of not being
able to be together, not being able to be in person. Everyone around the world is here.
Imagine the world connecting and tightening here together. No matter where they were,
that connectedness had a huge impact.
There's one more bit of a finale here.
Yeah, one more, 10 more seconds here.
Thank you, Link, for all you have done for us.
Zelda-hime, arigatou.
Zelda-hime, arigatou.
Zelda-hime, arigatou.
So we wonder if DEFCON actually stole their theme for this event from
Triforce Percent, the whole let us create the future together.
That was in summer 2022 when we showed this, and it lined up pretty well.
So thank you so much to DEFCON for having us here.
Yeah, absolutely.
Hey, we are going to come to a close because we're at the end of our time,
but I recently got laid off.
So if you are looking for a hacker for hire,
you can find me on Twitter.
I don't know how to get paid for doing this kind of stuff,
so I'm doing security consulting on the side or just test engineering.
Hit me up afterward.
I cannot thank M-Link enough and Sauron enough for making this happen.
Thank you very much to DEFCON for having us,
and I hope to see you again in the near future.
Thank you.