 All right, we finally made it, it's 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 having a really fun talk today. It's a thing about Zelda using After Free to show some really cool stuff. The robot doing some awesome fun stuff. And there you go. 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... Sorin? Hi, 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 Em Link, or Liam. I'm here to speedrun offering 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 were 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, Em Link over here, start playing on a brand new file. It's going to start from scratch. So you're going to hear some game audio. We'll have that kind of hanging around in the background for a little bit. So you can hear that. And this is an unmodified Ocarina of Time cartridge. This is not a flash card, no ROM changes. This is the real game, kind of real N64. Yep, the only thing that's going on to get 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, so we're going to get underway with the actual game, so go ahead and get started. What Em 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, you know, why do we hack? It depends on who you are, right? So, you know, 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 defensive 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 a arbitrary code execution, a remote code execution payload for emotional impact? Now, we're not talking about the emotional impact of like, oh my god, I'm going to do something crazy right now. So, what hat would you say to this white hat? I don't probably think it's a black hat. But we're not doing that, we have arbitrary code execution on the video game channel. We have a human runner here, Emily here, is because Emily is holding a real controller connected to controller port one. And we have our friend, Taspod here, connected to controller ports two, three and four for most of this briefly, he'll be connected to all four at the same time. And there's a little bit to unpack here. So, first of all, this is Taspod. 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 Onosaurus with code from Rasteri and additional code from Sauron here as well. And that allows us to pretend to be a controller. You might consider this a little bit of an evil made 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 Taspod 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 Sauron 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 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 Master June back in 2012. And it managed to complete Super Mario World in two and a half minutes by using what was then called a corrupt 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 Tampa back in 2014. But along the same lines, Seth Blaine 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 wanna 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 Taskbot started. I can see the picture of that's the original Taskbot based on a Rob robot, and we've come a long way since then. There's also some interesting large scale 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 Brothers 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 taskvideos.org and see this run there. But we wanted to really ratchet things up. We knew we could do anything with Ace. So the Taskbot community that I lead went a little bit crazy. We found arbitrary code executions for a Nintendo game, Super Mario Brothers 3, another Nintendo game, in that case Mega Man, and Legend of Zelda, Link to the Past. We used all three of them with 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. But 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 Link went on to make a Flappy Bird version 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. Like, 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 truck, you could find Mu 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. So 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, IMAjo. 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 advertisements on TV 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 beta content and other 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 Photoshop 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. 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 in the N64 context, what that means is you 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 wanna 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 an important part of how a computer works. So those two things are accomplished through, we encode certain data in rotation values. In other speedruns, they use Link's name in Japanese to encode two MIPS assembly instructions. But 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 speedrunning community is called stale reference manipulation. And both of these things are accomplished through a combination of speedrunning tricks and heap manipulation, which is what we're gonna 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. It's fine, it's fine. That'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 gonna see on the screen now that I'm not gonna get into. This part of the talk is kind of like running on a treadmill. So I'm going to have to keep up with all of these notes and it's not exactly easy. So first of all, right now it's a video explaining how the controller input works. We're not gonna 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 our creative 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 is 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 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 empty spot, drops it in, as you can see with this graphic here. So it'll find the first spot that it'll 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 freed. So this results in actors and overlays being assigned memory locations that aren't consistent. In the words, their 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 in through 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 if we, 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 with a little bit of extra stuff in there. In the try force 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, I'm not being drawn off screen. Then without allowing it to be unculled, we pass through a loading zone so that 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 cold. And then the other bug, which you could say is a bug, is that they didn't check when something unculls, whether it is being held, and to have Link go over 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 heat. All the actor heat, yeah, the whole thing. So I'm probably gonna a little off of my location here, but that's 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 Mito is nearby, you just saw him on screen a little bit ago, the direction that the camera facing is important because if the camera is facing towards the main room, Mito 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 shuffled around in a very specific way. That's why you saw M-Link going back through the doors so many times. Basically... 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 glitcher to force the camera to always stay behind Link then using another item glitch to move around while a text box is open. That allows us to get the camera very far away from Link, which will cull away any actors that are nearby him. You're gonna see that in just a second here. So he's gonna hit this rock and the camera angle. I'm gonna be fast forward a little bit here. So that rock is kind of important. So here you're gonna 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 heat manipulation we did earlier, we know exactly where in the heat that that data for that rock actor is. So 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 to write an arbitrary data. We're literally using Link's, but either his actual position or the camera position to manipulate this. I'm gonna fast forward a little bit unless there's no one to say that that. Yeah. 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. Yeah. So you can just skip a few. And 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 us. They can't see that. Oh, it's because the video's up. That's why. The video's covering it. Once we go back to the slides, it'll be up. Oh, yeah, that's right. Yeah, yeah, yeah, because I can't move it 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 what the rock angle is and what Link's angle needs to be. But we're gonna switch back to the slides. Yep, back to the slides here. All right, let me go to... That's the wrong one. Here we go. All right. Okay. Right, so basically, we don't have time to go over the entire chain of where execution goes, but 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. We, that collection of one instruction per frame over many frames is Bootstrapper 1. The function of Bootstrapper 1 is to write Bootstrapper 2 into memory. Then we run one controller input as code to jump to Bootstrapper 2 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 3. The function of that is to write Bootstrapper 4 into memory. We then jump to Bootstrapper 4 repeatedly over and over. And what Bootstrapper 4 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 2, 3, and 4 for combinations of controller input that represent packets that describe arbitrary memory rights, 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 switched to TaskBot to play in a short task movie file over all four controller ports. So this is going to be TaskBot manipulating the controller input, which will be executed as code. So I'm switching, switched controller 1 to be controlled by TaskBot, so controller, 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. So, 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 debugger gets activated, it puts a yellow bar in the corner, and so we made a green bar to, you know, mean it's pwned, but it's also that, like, that's being done by the hyperspeed loader. So I've changed controller one back to MLink. If you could go walk towards my dose house, but not enter it. And what I'm gonna 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 gonna be injecting is, this is stuff that is linked to statically assigned addresses in memory, as opposed to later is gonna 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 gonna 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 were wondering, where do we get all this memory from? We have an expansion pack installed, which is extra four megabytes of RAM, 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 go 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 test, you know, set up link state and test the game. And we just need to, because we're not gonna show the full thing today, we don't have enough time, we're just gonna 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? And nothing else? Well, that's never happened before. That has never happened before. Yeah, okay. Okay. Let's see if it crashes after you exit the scene. All right, now we see what happens. That's how the scene in the game is. We should be okay. 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 up, like D left or D right? Okay, whatever. That's interesting. Basically they left the R-Wing on the cartridge and that was the shtick we used to present this in the game. 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 through. Right, we put a bunch of things on screen and 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 and Tim and Ray will continue for a few minutes and we're gonna go back to... Yeah, we got the slides back here. We can have the volume a bit low on the game and we're gonna 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 games one. You can see this is an example where one of the threads crashed and we just 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 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 want to create in the game. So this is the really technical part. If the first part wasn't too technical, I'm gonna 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 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 VI tech. There's update that gets patched into links actor. There is, this 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 have the patched 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 it's gone wrong. 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 Carcarico Village, we replace that with a route from Chamber of Sages to Triforce Room. This is like 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'll be loading custom icons and stuff on the GUI and those get loaded from memory. And 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. If we're, when we equip medallions, which is a beta feature that we re-instructed, it has to, the medallion has to fly across the screen onto the GUI and so this is the code for that. We have custom items and so 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 Ocarina of Time, also called Urazelda, which is DLC that Nintendo was gonna make in 1998. 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, there's custom sound effects, custom music. Audio has a separate way of DMAing 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 the 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 and 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 it has a, this is an actual numerical integrator for the double pendulum problem for linked hair and that's, yeah, the CPU has plenty of power available compared to the graphics hardware so there's usually CPU available to do for us to do this kind of stuff. 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 like camera key frames basically for the camera motion. And this is all done through some plugins for Blender called Fest64 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 as 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. 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 code. So this is Peru, 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 and 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. 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 are we, you know, 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 and hopefully. Can you do that in the middle of a cut scene? Yeah. All right. Well, here's, so let's see what happens. Oh! I guess there is something wrong. I don't know. All right. Do you have the flash cart? Yeah, we have the flash cart. There's my backpack. 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. 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, the, I do, but like, but I don't know if the Twitch will work with that. Oh wow. We might not be doing chat. We'll see. We can try it. All right. Let's see. I think this one, we did not rehearse this. We did not rehearse this back. Things might, things might go wrong here. We'll see. This is what happens when you do live demos. Now, luckily this went correctly at awesome 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 you go. Forget if this had a, I don't know how we got warped to that weird area. Right. This is, we have to sit through the intro. Oh no. Yeah. Oh no. Let's just, let's just finish our talk. During the intro and then we can, yeah. Yeah. We will not be watching the intro. 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, you know, we, people have different opinions about, you know, how valid that is and everything. And certainly once we've switched to a flat part, it's, you know, it's just a wrong hack. But this really made a lot of people feel, you know, this was sort of the idea, feel that this was like resolving their childhood in a way. Because, you know, these are things that they always wanted and like a chapter of their childhood. Once you get control, then you get it back to the idea. Yeah. So 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, there's a little more to it than that. But yeah, I'll wait, I'll wait for that. And you can talk about 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 with a huge amount of help from Micro 500 and a ton of other people. And we made a Skype call over a Super Nintendo and it was technically interesting. But we weren't sure where we were gonna go next. And where we ended up going next was Soren putting a huge amount of heart and effort and years of direction into making what we ended up showing as 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 2022 was incredible. We helped raise over $228,000 for Doctors of Outboarders in one hour of content. So why do we hack? It's not just to find use-after-free flaws 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. If you have any interest, go to European Speedrunner Assembly in Europe. Games Done Quick here in the United States. We've done other events as well. RPG Limit Break, even Magfest runs them. Very, very worthwhile checking them out. So for me, this was the biggest thing that we had ever done. We've now helped raise over $1.3 million with Taskbot 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 guarantees on the chat part, but... So I realized there won't be chat because the chat comes in through the hyperspeed loader and there's no hyperspeed loader in a ROM hack. So but 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 have 24 years now. I know, right? I forgot, I made so many other changes. And this is not gonna 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, yeah, so with that moment at JDQ, we had the eyes of 100,000 people on us. 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 oddable things you'll hear here. There's several different unique aspects. Graphical features, yeah. But I think we're generally gonna 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 JDQ audience to have us see the future because that's the only one we implemented. We'll get a little bit more game volume here. You're gonna wanna hear this. So yes, this is not a video. This is the N64. Myself and Glank, who's one of the 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. So they're substantially reduced from the versions on the Switch. So unfortunately, we don't have the chat because it's not live, but yeah. So you can imagine the sky filled with chat messages. Also at JDQ, it was subscriber-only chats. We told everybody, hey, you gotta subscribe, which all that money went to doctors without orders also. Here it is. 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. Zero da hime, arigato. So we wonder if DEF CON actually stole their theme for this event from Tripors 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 DEF CON for having us here. Yeah, absolutely. Hey, we are gonna 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 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 him length enough and sorry enough for making this happen. Thank you very much for DEF CON for having us. And I hope to see you again in the new year.