 Down the speedrunning rabbit hole on YouTube, I know I certainly have, you have probably heard of Tazbot. Tazbot is a tool assisted speedrun robot. And if you don't know, speedrunning is an awesome community of hackers and gamers who come together to break and play games as fast as they possibly can. Tazbot pretends to be a controller and sends button presses to the console with inhuman precision. And this means that he can do some very interesting things. Tazbot has been alive for about ten years and in that time, he has raised $1.3 million for charity. Dwango AC, who is the keeper of Tazbot and Blastimac, who is the guy who plays the games, are here to tell us about his latest exploits. Folks, this is going to be awesome. Let's give it up. So glad to have such a wonderful crowd. I am Dwango AC. Welcome to the Tazbot Ocarina of Time ACE talk. I am a security consultant with Bishop Fox by day, but keeper by Tazbot by night, and this talk is an opportunity for me to combine both of my passions and one talk, which is awesome. I'm thankful to Bishop Fox for making it possible for me to travel here and be here. I also want to specifically thank Stitch, who I hope is somewhere, oh, right there, who personally invited me over three years ago to participate in this. So, so excited to be here. I really want to show you how we can take glitches and exploit them to create a work of transformative art from one of the most popular games of all time. There are a couple of things I want to chat about before we go on. There is just a massive number of people who contributed to what you're about to see from inside and outside of the Tazbot community. Over 25 people contributed to this over the course of about two and a half years, with even more people involved in prior research. Especially like to thank Soren, who was the director and the main pillar of what we did for what we call Triforce Percent. You'll understand a little more about that in a bit. Also, Isofreeze of Retro Game Mechanics explained. If you have seen the video on this, you'll note that the slides are very similar. He directly helped me create this and work with me to produce this slide ware. You'll see what I mean when we get into it. There's also Blastermac here, who will be helping by playing the game. Now, I have to say, the one person in this planet, on this planet, who has managed to pull off running the original cartridge was Safe State. They did it at Summer Games Done Quick 2022, a couple of weeks ago. We spent several weeks trying to replicate what they did without success. We have been unable to make it to an assisted speedrun of this because of various different issues. We are trying to recreate what they did without their skill level. Instead of trying to do it on an original cart, we are going to be using a flash cart. I'll show you what that looks like here. You'll see there are some addresses here on the screen. We are cheating a little bit. We are using a practice ROM that shows the angle of what Link is facing and a few other things, as well as the buttons that are being pressed. This allows us to also do tool-assisted speedrun like things like save states and being able to frame advance, which are going to come in really handy. What we're going to do right now is go through the intro and play through the game. This intro scene is a little long. We'll leave that in the corner here as we get started. You'll see that in that corner down there while we're just going through this rather repetitive intro section. I'm going to break this talk into about three ... Wow, that wind came through. Sorry about the mic. We're going to talk about three main parts in this talk. The first one is going to be how we're preparing to execute a glitch called a stale reference manipulation. It's basically a use-after-free exploit. That's the more common name for it. We're also going to do a dive into how we're doing the initial arbitrary code of payload execution. We'll take ACE and then do something interesting with it. Then part three is where we get to see all of the amazing things you can do once you have arbitrary control over a console. I should note that the majority of part one also applies to the ACE, any percent run, if you wanted to beat the game quickly. It also applies to what you would get on the original console. The original intro to 64, it uses the same sequence. Let's talk about what it takes to land an exploit on one of these. The state of the buttons and analog control stick for each of the four controllers is stored at memory address 8011D790. Each controller port takes up six bytes. There are two bytes for all of the buttons, A, B, Z, start, the D pad, L and R shoulder buttons and the C buttons. There's one byte for the analog sticks X offset, one byte for its Y offset, one byte for an error code in case the controller is unplugged or other players, and then one padding byte that's always zero. All together we have a total of 24 bytes. By pressing buttons and moving the control stick around, we can change the values to whatever we like if you're superhuman. Under normal circumstances, the games code reads these values to know where the player is currently, but what the player is pressing and updates the game accordingly. The memory here is just like any other memory in the system, and game code is found in memory and is executed here all the time. So what if we were able to jump, execution, or call a function that is defined to be at the same location as the controller data? So this is where things get really interesting. So the data representing the state of the controllers can be treated as MIPS assembly instructions and they can be executed just like any other code. By the way, Blaster Mac is currently going through and setting up the rupee route. We're going through and getting certain things in a particular area. Going in through the main beginning area and getting certain rupees that we need for this exploit. So right now, the specific code that gets executed when, I have to say this, if you were to execute these controller inputs as code, what gets executed would depend on what angle of the control sticks you're pressing and what buttons you're pressing. Now, it might be really difficult for a real controller or a real player to hold 56 buttons and four analog sticks to precise X and Y coordinates, but my buddy Taskbot here has no problem with that. So we're going to get him attached later. You'll see what kind of shenanigans he can be up to. Now, the original game developers never intended for players to execute the controller data as code, so we'll need to use some glitches to accomplish that. Luckily, within the starting area of the game, you can see a video on the screen here of what we're going to be doing here, there are some places where we can achieve arbitrary code execution, which, as it suggests, gives us the ability to execute any code that we want on the console. So the key glitch that enables this is known as stale reference manipulation. It's more commonly known as a use after free exploit. So before I go on, I want to look at how the heap works in Ocarina of Time. 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. In Ocarina of Time, there's a specific heap that's called the actor heap. It contains code and data for all of the actors currently loaded in the game. An actor in this context is any sort of entity. It doesn't matter whether it's link, NPCs, rupees, even some hidden objects and triggers. Now, there are two main kinds of things held in the actor heap. There are actor overlays that basically contain code that runs for each type of actor, how they behave and how they react, and then the actors themselves. If there are multiple instances of a single actor, say a rupee, only one actor overlay needs to be loaded into the heap since they all share the same code. So you'll have several actors, they'll all point to the same overlay. The actors themselves hold the data for each individual instance of that actor, stuff like the position, the rotation, and that actor's state. Actors are loaded into and out of the game all the time, and they're allocated memory on the heap dynamically while that happens. So the game will search the heap for a free chunk of memory. Basically, it's going to start at the top, all the way at 801DAA00, and search for space all the way down to this corner at 8023AB90. Yes, we're using this particular notation with a dollar sign. It's a stylistic choice of the animator. If a new type of actor is loaded, the corresponding actor overlay is loaded as well. So when transitioning 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. This results in actors and overlays being assigned memory locations that aren't consistent. Their location and memory will depend on exactly how many actors were already loaded and how they were organized within the heap structure. The sign post actor, for instance, that we're looking at here, back up just a bit. Okay, that sign post actor, oh, come on. Okay, it's going too fast, very well. It might be loaded in one place in the heap, but if we leave the area and come back, it might be somewhere else, like adjusted over there. And some actors might need to keep a pointer or a reference to another actor in their data. So this fact that they can move around is actually very important. So for example, the boomerang here, under normal circumstances, keeps a reference to the actor that it's grabbed, such as a rupee, which you can see you would want to be able to carry that rupee back to link. Under normal circumstances, if an actor references a second actor, the second actor should not unload or be freed from the heap before the first actor either unreferences it or unloads itself. If it happens, we would call this a stale reference. It's pointing at something that's no longer there. The pointer this actor has is now pointing to a memory location that's not being used anymore. And it means that if another actor were to be allocated into the heap at that location where the old actor used to be, the first actor would be pointing to an actor that it probably shouldn't have access to, like this, this item here. So using the boomerang example, by unloading the actor it's grabbed, by going through a broom transition while it's off screen, a different actor will take its spot. This can cause the boomerang to modify that new actor's position instead, which can cause unusual behavior, like objects teleporting around. And this is an example of an actor being allocated in the same memory allocation, location as an older actor. So the question then becomes, what would happen if an actor overlay loaded into this memory location? Maybe we got something different. In other words, what if the boomerang modifies an actor's position, when it modifies it, what's it actually doing? Let me just jump ahead a bit. Okay. So for all actors, their X and Y and Z coordinates in the world space are held at offsets 24, 28, and 2C within their allocated memory block in the heap. The boomerang will take the address to the pointer that the actor is holding, and add these values to it and then write that data at those memory locations. So this would effectively modify the X, Y, and Z coordinates of the actor it's holding. However, if a stale reference that is now pointing to an actor overlay instead, if it's a stale reference, some unintended side effects can occur, because each actor overlay is different, but they're just blocks of data. So the boomerang is still going to obliviously write data to offsets 24, 28, and 2C into that memory block, but it'll be writing 32-bit float data into places where a 32-bit MIPS assembly instructions are supposed to be held. If the code for this overlay gets executed after the boomerang modifies it, it will likely crash because it's probably not going to be sensible data. It might be completely invalid assembly instructions. But what if we could control exactly what values were being written by the actor and what instructions from the overlay are being overwritten. So we could effectively modify the code that the game executes. We could maybe make it do different things, basically whatever we like. And this is the essence of a stale reference manipulation or a use-after-free exploit. Okay. So in the Triforce Percent run, what we're referring to this run, we achieve SRM by getting Link to pick up an item while it's culled. In other words, it's not being drawn because it's either off screen or too far away from the camera. Without allowing the item to be unculled, in other words, put back in view, we pass through a loading zone so that the item unloads and Link has a stale reference to it. 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 is holding. But before doing all of that, we have to get the heap in a very specific state. So it may seem that actors being loaded and unloaded and freed from the heap is random. It's actually very deterministic. By collecting items such as rupees, we can prevent them from loading in each time the loading zone is triggered. Also, since Maito is nearby, he's a character that you're going to see in a second, the direction the camera that's facing is important as well, because he's also on screen. So if the camera is facing toward the main room, Maito won't unload, causing his overlay to stay put while his actor instance moves around in memory. By switching the direction of the camera while walking back and forth over this loading zone, all of the actors and the actor overlays in the heap get shifted around in a very precise way. So the data you're seeing at the top of the screen is the actual data in memory. It's just animated here with different symbols so you can see what that might look like as a representation. So after the seemingly arbitrary walking back and forth in this hallway, the heap will be laid out in such a way that it'll allow a very specific actor overlay to load in that location. And we want that to happen for later. So we jump ahead a little bit here. That was too far. Okay, so normally the camera sticks around the link as you're playing the game, making it impossible to pick up an item and walk around with it while it's cold. But we can use a glitch to force the camera to always stay behind link and then use another glitch. Whoa, that was a glitch. I lost my notes. We can use another glitch to... Okay yeah, there's this rock that we're going to talk about here in just a second. Let me get back into my notes here. Okay, so we've got this rock that we're going to mess with a lot. We're going to mess with this rock quite a bit and it's going to cause him a lot of trouble by the way. This rock is kind of a pain in the butt. But okay, so we're going to get this... Come on, let's play again for me. There we go. Good animation. Okay, okay, so this rock here is actually pretty interesting. We're going to use this glitch to force the camera to always stay behind link. We're going to use another glitch to move around while a text box is open so that we can get the camera to move very far away from link, which will call any actors that are near him. So because of the heap manipulation we did earlier, we know exactly where in the heap data this rock is. It's at 801f7310. You can see that on the screen in the right there. When Link is carrying an actor, he updates the position and rotation of that actor so that it appears in his hands over overhead. You can see us walking in an area that is kind of hard to see, so we put an overhead camera in here. The rotation of an actor is a 16-bit value, and it's stored off set B4 from the start of the actor's data. So if the rock is stored at this address, we know that the address will be the one that's modified. In this case, the rotation value is just Link's rotation value. Since it's very easy to control what angle Link is facing by walking around, this is the value we can use to write arbitrary data, which gets interpreted as arbitrary code when executed as part of the actor overlay, as you'll see in just a second. So the camera is still stuck in a position very far away. We carry it through this invisible rock all the way to this loading zone and then walking back and forth through it one last time. So the rock that Link is holding gets unloaded because it's cold away, and because of the heap manipulation we did earlier, an actor overlay gets allocated in the same memory region that the rock took up earlier. So you see Link is walking, we have an overhead camera view that allows us to kind of see where Link is going and see he's wandering into this other loading zone area, and that causes all of that memory change to happen. So there's a function that is going to be really important that belongs to an item, an actor known as the wonder item. So this wonder item is kind of interesting. So it's an invisible actor that triggers the collection of invisible items such as rupees, and there's a function within the actor overlay that gets run whenever the wonder item is unculled, which is whenever it's in view of the camera. So it lines up with the address we have control over thanks to SRN. The exact instruction we end up overriding is a branch instruction. Now we have, each instruction is about 30, yeah it's 32 bits wide, but the rotation value is just 16 bits. So we can only manipulate half of the instruction which is the branch offset. This is 0002 portion. We can replace the branch offset with any value from 8,000 to 7ff, which is negative 32,768 to positive 32,768 and decimal. It means that when the game executes this instruction and branches, we can get the program counter to jump up with 32,000 instructions forward or backward. The instruction that we're working with is located in address 801f73c4. So we can jump as far forward as 802173c4 and as far back as address 801d73c8. The only problem is the controller data is stored at 8011d790 which is outside of that range. What it means is that we have to daisy chain our jump instructions because we can't jump all the way to where we need to be in just one hop. With this modified branch we can jump to somewhere else in heap and because of our precise heap manipulation we know exactly where everything is loaded. This means we can encode a longer jump instruction somewhere within the memory of the heap that jumps directly to the controller data, then have our modified branch instruction branch to this new jump instruction. So the main disadvantage of this is we have some limitations. It's kind of frustrating. It only has 16 bits that we can work with. We need more than that. So a jump instruction allocates a full 26 bits to the jump address which is enough to get us to the controller data. So if we had to locate we need to find 32 bits somewhere in memory to locate and it turns out that the data in the heap for there's a portion of the data in the heap that has data for link himself like his angle his movement angle which direction he's moving which thing he's targeting and so on. So what we need to do is orient link at a very precise angle so that those two angles when interpreted as a single MIPS instruction encode a jump instruction that jumps to the controller data. So our whole point here is trying to get code to jump to the controller data right? So it's not easy to do but we can align the camera with exact cardinal directions then perform actions that are known to rotate link by an exact amount and that'll allow us to get the angles that we need. So here the values that we're going to get written in preparation for that. At 801f73c4 the rotation value of 8f80 is written in order to make the branch instruction jump to 801db1c8. Now this isn't the exact address that we need to jump to but it's close enough and the game eventually makes it down to there. So that's located at 801db25c and encodes a jump address to 801d77c. This isn't exactly, oh pardon, that was just catching up here a little bit, we're basically getting everything set up so that we can take Link's movement and his angles and make them into actual jump instructions valid. So we've shown you a video of kind of what it takes to get set up. We're going to try to do it live it might work, it might not work, we're going to find out. This is a very tricky glitch and you're going to see why in a second. So I'm going to switch away from my prepared slides and we're going to pull this up here. All right, so BlasterMac is going to attempt to get this rock in particular working. So this is the fun part, trying to get the camera locked correctly and get this, what we call a return state is very tricky. It takes a couple of attempts. Do you want to talk about what you're doing here? Well right now I'm setting the heap up in such a way that we know what it's going to be when we pick up the rock. So I'm walking back and forth between loading zones and unloading and loading stuff in a certain way so that we kind of get a better idea of what we're doing. And then after I'm done I will perform a glitch called return A that locks the camera in place and I will try to do some blind movement and what will get that in just a second. So if everything is correct. So this is a glitch that locks the camera in a funny way and it makes your, see where it says put away, if this is done correctly what ends up happening is it changes to return. So now you've got this return state stuck and it means that the camera is going to stay there. Looks like we lost our game audio but that's okay. I'm actually unsure why we lost our game audio. It's okay. I think we lost audio from game. There we go. There we go. Yeah we actually need those audio cues. We're going to need serious time here in a second because he'll need to listen to audio cues. Okay so right now he's walking back over to a this crawl area and this will lock links camera in a different direction. There you go. And now I think you're going to get medieval on a sign. What did that sign do to you? It was just in the way. It was in the way. Throwing nuts at it just to make a break. All right now this is going to require some interesting work here. Needs to lock the camera behind link and there's this rock we talked about earlier. This rock is kind of a pain so we've got to get this angle just right. And if it works it'll say grab at the top. You got it. There we go. Okay now okay this is serious time so he has to listen to some audio cues and here listen to some media some audio music beats so here take it away. Well luckily thanks to the magic of save states I can easily get back to my starting point. Right that is one thing that is advantageous with this practice ROM is it also shows you the rotation at the bottom of the what buttons are being held. Sorry I'm talking over his audio cue. So the problem is you have to do this entirely blind. You can see Link kind of wandering around down there but he's very tiny. Look at this a couple more attempts. It's not easy to do. So you can see each attempt through Blastermax moving link can see tiny link in the background and it's just a matter of getting the angles just right to get him through the doorway. It's not easy. At least it's good music. Let me know when you get to the audio cue part I'm going to quickly go back and show you why this is so difficult. So from here you can see Link has to wander not too far here. Right here. Right over there. Okay. So this is what's basically happening. We've got this rock here. Now this section here you can see overhead. There's a little bit of a jump cut in this video but Link is wandering around through this hallway. It's very difficult to get it lined up right. So what Blastermax trying to do right now is hit that tiny window of where that hallway is. So stop me if you need to stop talking. But one of the reasons that we've had difficulty over the past two weeks to reproduce what Save State did is Save State is just amazing at this game. They've spent a lot of time practicing doing rather intense glitches like this all the time. Well that was a different one. So yeah we're probably going to have to call it in a bit. You want to try one more time? I will try one more time. Yeah. Okay. Ooh bummer. Looks like you're too far south maybe? I think so. Let me try one more time. Sure. Then we can continue. I don't want to hold up the presentation too much. That's okay. Okay. That was my attempt. That was your attempt? Okay. All right. That's okay. So here's what we're going to do. Because this is so dang tricky what we're going to do is switch to a shortcut ROM. And this is not giving up by any stretch. So basically the shortcut ROM is going to allow us to go ahead and switch off. Yeah. You're good. The shortcut ROM is going to allow us to basically put the game in the state of getting the wonder item without having to do all of the complicated human set up. It's fascinating that this particular run requires both a human runner and a task bot. So task bot is currently connected to the controller ports two, three and four right now. We're going to connect them to controller port one as well here in a little bit. Normally if you were to do this on stage the way save state did it a couple of weeks ago you would have all of Link's positions right and everything would be perfectly in order. But it's really hard to reproduce so the shortcut ROM replaces only 271 bytes. All it does is takes the original 1.0 release of the Legend of Zelda Ocarina of Time, patches 271 bytes and makes it so that the wonder item appears immediately when you walk forward from the starting location. So you ready? Yeah. So what you're seeing here is we've got a different game different to ROM this is a shortcut ROM and I am going to pull up a terminal here okay all right we are gonna do all right you ready? He's all hooked up okay oh actually you need to reconnect and really tell Navi to go away. Navi gets gets very happy she really wants to tell you something and if you don't talk to her you'll also have to change your camera angle back because you're currently oh no it did it okay you're good all right we're good all right here goes so we have this terminal here I'm gonna move it up so you can see what's going on here here we go so this is going to be using a task team 32 replay device made by Onosaurus it's this little red box the task box holding in his hands we're going to be using player ports one two three and four we're going to be sending a shortcut ROM and I'm going to hit enter now and then funny things are going to happen so this is pressing buttons on the controller and it's making link do a lot of crazy things because as the moment we cross that threshold it started loading these instructions as data and they're actually being being stored right now so you can see what happens here in a second okay that green line in the upper left corner means that this was successful now a whole lot of things just happened I'm going to do one other quick script here which is we're going to do fixed this is sending data over controller ports one two three and four and I'm going to tell you a little bit about what's happening there in just a second but we are actually transmitting data first very slowly and increasingly quickly to the console now there's one more we're going to do and at this point it's now no longer using controller port one so blaster mac can unplug controller port one plug back in to controller port to his controller and now all he has to do is fix up some memory by entering this house over here and just to start enter the positive and exit and enter and exit a house so that will allow us to that'll allow us to get everything to the point where we can now do anything we wanted to with this game I'm going to give you a sneak preview of what that looks like but it ends badly for link if you're not careful okay what we now have is arbitrary code that allows us to take over the game and do whatever we like and there's a ton of beta content that was included in Ocarina of Time that most people have never seen before and one of them is this crazy thing they imported from Star Fox it's an R-Wing this is in the cartridge we didn't put this there this is actually in the cartridge and if you stand around you can target it we assume they use this to test a boss but if you stand around long enough it will start shooting at you which is very friendly right now we are weaponless so we're just going to run back into a house and make it go away I think that works I don't know if it does bad things I think the intended choice is to kill it but I think this works too so we're going to pause here now keep in mind in the background Taskbot is still connected and is still sending a whole lot of data and we're going to talk about what's going on there in just a second but for now we're going to leave that game behind and get back to what's actually happening here and this is really really nutty like really really nutty so we had a lot that just happened now Bootstrapper 1 there's multiple layers of bootstrapping here so there's Bootstrapper 1 which is running control data as assembly instructions which is very very slow so we want to write a smaller program that gets us a little faster so we make Bootstrapper 2 and then Bootstrapper 3 and then Bootstrapper 4 and then we make a hyperspeed loader so each one of these is basically building up our control over the system and how fast we can send data so we basically write a program to write a program to write a program to write a hyperspeed loader to write even more data that becomes a program it gets interesting once you get total control you can do some fun things so let's talk about how it's treating that control data as assembly code so there's just 24 bytes of memory dedicated to the controllers there are two bytes for the buttons two bytes for the analog stick and I'm just going to jump ahead a little bit here okay so there's the there's two bytes for the analog stick two for let's see there's the error code byte and one zero byte there's four sets of those and each of them one for each of the controllers now a MIPS assembly instruction is always 32 bits long or four bytes and aligned to a four byte boundary so if the controllers are created treated as assembly instructions here's how they'll be organized the first instruction consists of the first controllers buttons I actually need to go back up here a little bit here so the first instruction consists of this first controllers buttons and analog stick bytes the second instruction is the first controllers error code a zero byte and the second controller buttons the third instruction is the second controller analog bytes it's error code and then a zero byte and then the next three instructions are the same just for controllers three and four so if a controller is connected which all four of them are in this case the error code is just zero denoting no error this means these four instructions will always be half zero which is not very helpful additionally other code in the game zero is out all input from controllers two and four completely since they were used for some debugging features and we don't have the ability to read them at all before they get wiped out so this leaves us with only two instructions we fully control or rather almost fully control there are only 14 buttons on the Nintendo 64 controller which means there are two bits in this that in this data that will be mapped they'll always be zero basically so we have to limit ourselves to instructions that already have those as zero basically it's kind of annoying but it gets the job done so after executing the controller data as code we still need to return back to the normal game function and we can't just let the program counter keep running or it'll just crash so we have to reserve our last instruction as a jump back to safety we have to get we're currently running in this wonder item code so we have to return from that function there are two bits that are always forced to zero so we can't use a encode a return instruction and we need to restore this stack but we can't do this in only one instruction so we have to encode a jump instruction to some code which restores the stack for us so unfortunately this means we are limited to a single instruction as long as that wonder item is on screen this code will be run every single frame and we can change which buttons are being pressed on each frame so we can execute whatever we like but it's kind of slow it basically this game runs at 20 frames a second and in order to account for lag frames we have to send each one twice that gives us a final speed of one instruction per two frames at 20 frames per second or about 10 instructions per second that's not very much so with only one instruction we really can't do a whole lot there's just not not much so we have to use a global pointer to basically bounce data into and this global pointer register allows us to store one on one instruction and then load it into other areas of memory later so our first bootstrap alternates between loads and stores back and forth so it writes a program we call bootstrap or two so now we're doing 10 bytes every second okay so bootstrap or two it re-enables the controller reports two and four it jumps to controller data right away it restores the wonder item overlay so that allows us to patch some code and now we're getting one instruction per frame 60 frames a second that gives us two bytes per two instructions so now we're at 60 bytes a second I mean we're getting there but it's still pretty slow we can do we can do better so bootstrap or three and I'm sorry I went right past it so bootstrap or four I'm going to just jump ahead a little bit because I am running out of time and I really want you guys to see the payload here bootstrap or four restores a few things that were kind of mangled it gets done injecting its code and it does a jump instruction directly to the controller ports some other annoying things about these bits always having to be zero but that gets us 480 bytes a second but now we use that to load the hyperspeed loader now the hyperspeed loader no longer jumps to controller data it reads all 90 bits available from controllers two through four it pulls the controllers eight times for every frame and that gives us a final rate of 5400 bytes per second which is pretty good okay now we're going to pause here and go back to the game because there's some more stuff to show you I want to talk to you a little bit about what you can do here I would love to be able to show you everything but with only a few minutes left we're going to have to jump straight to the finale which is we have now finished loading all of the data that we needed to send over controller ports two three and four and what we're going to show you at this point is we built not just the ability to pull out the R-wing but we built out the ability to do anything anything we wanted to and there is so much lore in this game that we would love to show you but we don't have a whole two hours to do it so we built up several different stages of getting Link's heart in balance doing a quest that involves courage and another one that involves wisdom and another that involves power and going to stages and talking to them this whole additional quest of all this awesome stuff and at the end Link is granted access to a particular room that we want to show you you're going to want some extra game audio out of this now after 23 years the dreams of millions of players around the world have finally come true the Triforce was rumored to exist in early beta videos all kinds of other references to it but it never made it in the final game you couldn't obtain the Triforce but we were able to put it into the game ourselves along with so many other things now Link has obtained the Triforce and the goddesses have a question for him and I like this question a lot let me see it in just a second I can't make this part go faster if you go watch the summer games done quick 2020 run you will see the entirety of the quest that leads up to this it's an incredibly moving story with all kinds of absurd things like beating the running man and using all kinds of glitches and beta content and interesting ways but I really want you to see this next scene I want you to remember that this console is other than an RGB mod that passively taps the red green and blue lines it does not modify the console in any way and this is other than that small bit to jump to the wonder item this is the original us 1.0 release now we could be king of hyrule or ask for rupees but I think everyone wants to see the future so let's do it as link makes his journey I just want to pause for a moment and talk about how what we're doing here is transformative art we're taking a game that's beloved by so many people and we're transforming it into something new everything you're seeing here is being done directly on this n64 enjoy if we can get some additional game audio you're gonna want it here so I don't know exactly if this is gonna work we're gonna try I've got to find the right the right command oh gosh I didn't actually see what we had a power outage right before this we were editing some scripts and have no idea whether or not this will work I currently actually can't even find the script for it let's see I don't think this is gonna work so go ahead and advance forward in the original version we had twitch messages appearing one after the other this entire sky was filled with people who had typed here together people remote people in the audience at games done quick this whole movement of people coming together after two and a half years of a pandemic that kept us apart it was just such a moving moment for everyone and I wish we could reproduce it here but there's not nearly enough people and there were something like 150,000 people watching at the time this run at instant quick raised $227,000 for Doctors Without Borders it was the incredible cap of two and a half years of effort 25 people working on it for a very long time putting their heart and soul into it I don't know if we can ever transform a game quite like this ever again thank you, Link for all you have done for us let's do it together we close out you can watch the credits on the screen here these credits will be playing in the background where all Harold's is at thank you so much for showing us that there was awesome technical issues aside that was the coolest thing I've ever seen an unmodified or almost unmodified games cartridge you come on give it up for these two that was incredible unfortunately we have no time for questions we're running a little bit tight here but I'm maybe these two will hang around afterwards if anyone wants to come up and ask any questions of them that would be awesome yeah there we go that's it thank you thank you so much