The Hero's Skip and the Hacker's Leap: Exploring Null References from Hyrule to the Enterprise

Today we have with us Luke Worst and he's going to be presenting on the heroes skip and the hackers leap. Thank you Luke.

>> All right, thank you everyone for coming today. And as you can see most of my images are AI gener generated and I really feel for the artist that does these amazing uh pieces that their uh AI is taking away from his work. But one of my passions and uh what this talk is going to be about is making a complex topic as simple to understand as I possibly can. And the way I'm going to do that is talking about um the Zelda Ocarina of Time game for the Nintendo 64 and how speedrunners work to uh effectively exploit it to achieve their goal. And their goal was to finish it as quickly as possible. Then I'll relate that

through to um [clears throat] a chromium use after free exploit which is related to what happens in ocarina of time which I'll abbreviate to OOT and give some real real world examples as well. So that's how AI decided to interpret my uh presentation synopsis. I'm going to mix together game specific language, speedrun specific language, and cyber language, but I'll give a preference to cyber language where possible. So, actors always work to exploit systems with an objective and motives in mind. For speedrunners, that's mostly finishing the game or whatever category they happen to be running. But what I'm going to be talking about today is finishing in the sense of reaching the end credits. And that's the uh for the any

percent category that's simply reaching the end credits by any means necessary. And the core of this talk is running arbitrary code inside an unmodified game which I just think is absolutely fascinating and hence why I put forward the proposal to um to besides to share it and talk about it. So some of the terms I'm going to cover off are arbitrary code execution. Apologies. I'm going to start my timer because I forgot and I don't want to run over time.

So, arbitrary code execution is a key method for malicious actors to achieve their objectives inside a system. And in this case, it's about uh sorry, I'll get to that later. So, some game specific terms are an object. So inside the game world that is anything that can be um in a level effectively and an actor is an object that can be interacted with. So the player picks up a rock that rock will be an actor and that actor has certain attributes uh and functions associated with it. And when I say function uh pieces of code that um are associated with that actor. So for a rock for example, if the rock is thrown, it will wait until it collides with a

piece of uh or a floor and then it will trigger a function and that function might decide to shatter the rock because it's hit the floor. And I'll use glitch and exploit interchangeably. And one thing I did want to cover off is the phenomenal skills of speedrunners. So for PAL games, frames are 40 milliseconds long and often they will need to have an input that is frame perfect. That is they have a 40 millisecond window to hit a button when something happens in the game. So an actor is interacting with something, a character is up against a wall, they have one frame when a piece of code is run to hit a button to get the desired

outcome, which is often a glitch. So glitch and exploit I will say is the same thing. So other examples are hitting a button through a wall or clipping through an object that you otherwise wouldn't be able to go through. So the case study I'll be working through is uh Zelda Ocarina of Time was released in 1998 for the Nintendo 64. Often considered one of the top 10 best games of all time. So for those who aren't familiar, Link is on the left. Yes, Zelda is on the right, even though it's called Legend of Zelda. Link is the protagonist. You play as him. And uh in the game, there is a time travel mechanic. So uh there's an old

version and a young version. You'll only see the young version today. So how long does it take to finish Ocarina of Time? Um, so in casual play through it's 25 to 35 hours depending on how many side quests and how many things you want to collect. 100% with glitches is 3 hours 44. That's doing all the optional um objectives. All dungeons with glitches is 1 hour 11 minutes. and glitchless, which is using no game mechanics, playing it normal as the in quotes as the developers intended, 3 hours 35 minutes. So, have a think what the what you consider or what you think the current world record for any% will be. And while we do that, I thought I'd

uh have link as a computer hacker, which I thought was quite good. But I thought, you know, hackers, they're kind of angry, so made them a bit angrier. And I like it. It's in a basement, which is quite fitting. But then I thought, well, Link, he actually comes from the forest. So, here's Link being angry hacking on a computer in a forest, which I thought was great. So, the answer to the question is 3 minutes 47 seconds to reach the end credits in an unmodified version of the game. And I find it hilarious that the end credits then go for 9 minutes. So stepping back a bit, I'm just going to go through some fundamentals. Um, and

part of this talk is going to be very different to a lot of the other um, main track talks in that I'm going to explain a lot of the uh, deeper details without much assumed knowledge. So what I'm going to go through is a memory map and a program counter. a memory map. Uh, an example of which which is not the Nintendo 64 is on the right there. And that typically has every item in a system, a computer system. And it's especially true with older consoles and more simplistic computers or microcontrollers, but everything is in a big long line starting with the memory up the top. So, the RAM, and then you'll have the ROM.

In this case, it's the uh game data on a physical cartridge which plugs into the uh console. But then you also have all your inputs and outputs. So your controllers uh from the system perspective appear on here as well and they update pieces of memory and the address of them is no different to any other piece of information in the memory map. So all your inputs, all your outputs, display, sound, everything happens and is interacted through the memory map and the program counter is what is currently executing um on that memory map. So what whatever it points to is going to be executed. So this is an example of the machine code uh the assembly language that actually

runs on a MIP CPU, which is what the Nintendo 64 uses. And the point I'm illustrating here is that um line 8 and nine are the same thing. Uh n line just has the hexodimal address of what it's going to jump to. So line 8 just says um jump to skip ad which is at line 11. The point here is if you can make the CP or the uh sorry the program counter run that line of code it will do whatever is at that line of code because it's relatively dumb. It simply does what it's told to do and in this case it's skip or jump. So line 10 will never be run in this case.

So this is link interacting with a program counter inside a computer which I thought was quite amusing. Now I have to do a mere culpa because it says not null on the right hand side. That's my reminder that um the topic of my presentation is actually wrong. When I wrote the proposal I was doing it from memory. I remember seeing this uh glitch uh this speedrun a long time ago and I forgot that it didn't actually use a null pointer. It uses use after free. So, apologies about that, but I will detail what use after free means. Now, this is probably the most um difficult to understand part of my talk. So apologies in advance if I uh don't do

the explanation justice, but the use after free um condition is ultimately putting the system state and the memory into a state that it shouldn't be in. So under normal circumstances using the game scenario an actor so the rock is interacted with it runs a piece of code memory is allocated to that somewhere on the um memory allocation and then the game engine will update the attributes of that actor uh every frame or however long or how frequently it chooses to. And that interaction keeps on happening until it's no longer uh being tracked by the memory manager and then it will be unloaded. That's the normal state that things should happen. What can happen is that

using mechanics in the game, you can dreference um the object. And what that means is that uh the object will no longer be there which you will I will illustrate in a moment but the memory is still there. The memory hasn't been deallocated and that's the faulty condition which allows uh use after free to be exploited. And part of the uh key point there is that it's not that difficult to get into this condition, but actually exploiting it uh is incredibly challenging very often. So this is a modified version of the game and it shows him picking up a rock and the attributes that are associated with that rock are shown. So this is highlighting some of the work

that speedrunners have done just to understand this game and how they can exploit it better. So some more details about actors. I've gone through a lot of this already because I just wanted to make sure I didn't forget, but actors when loaded have memory allocated and when unloaded they should have that memory freed up. If it's not freed up, that will be uh vulnerable to a use after free. And some of the knowledge required to pull off this style of exploit is quite phenomenal. So again, this is a modified version of the game, excuse me. And these rocks here, when you zoom the camera out, the rocks disappear. And using the knowledge of the game,

they found that when the sorry, they disappear in the sense that they are still there. They can be interacted with, but they're not being rendered by the game engine um just to save resources. But what they found was that an attribute is not set when it's not being rendered. And that attribute is its ability to traverse through a loading zone. And that attribute in combination with a chain of exploits and glitches is how they um carry out this attack. So setting up the exploit chain, they require the ocarina and a slingshot, and they play the game somewhat normally, but they do a number [clears throat] of glitches uh to acquire those as fast as possible.

And then it starts. And apologies, this is a terrible image. I get that. Uh it's very difficult to uh demonstrate pictorially how this works, but I'll walk you through it. So the first point or the first part is um using a glitch called walking while talking. It's interacting with a sign and breaking it and all sorts of things. And that locks the camera in place. And that's what it looks like when the camera is locked in place. And they need the ocarina. Uh that allows the camera orientation to be changed, but it doesn't change position. So that red circle there is where those rocks were. So the player actually navigates to there and picks up a

specific rock whilst the camera is locked. So they don't really know what they're doing. And then they traverse through a loading zone which is in the circle on the right. And just in case no one's uh familiar with what a loading zone is, it's often a curved corridor. So as you walk through it, the game engine will load the area that's in front of you and unload the area that's behind you. And because of the attribute of the rock, um, which should be able to go through a loading zone, but because it wasn't being rendered, that was never set. So when you go through the loading zone, this happens. The camera snaps back and Link no longer has a rock above his

head. So that is the key exploit which is setting up the use after free condition. Then what do you do with that? And that's coming into the extreme knowledge that um this collective group of people found um and was able to exploit. So the next part part is um spawning another actor into the memory location that the rock was. So the rock is still being updated but it was considered free. So a seed in the slingshot is then spawned and those rot that rotation information you can see there that is effectively the arbitrary code execution or at least the first part of the the ACE. The second part is the file name. So that is attacker

controlled. So all the attacker can ultimately control is the file name in this case and the inputs. So the two bytes of the rotation data uh from the seed and the slingshot when run as code triggers a jump which in turn reads the file name as code and what that does is copies um the first piece of the file name into the cutscene register and I believe that is the end credits and then it jumps to the controllers. So they use controller one and three um and hold the analog stick in a very specific position and hold down buttons and that sets up very specific um machine code which is then jumped to when they run

the exploit. So the controls have to be held in a a very specific way. And running the exploit looks incredibly boring because it's literally bringing a rock back into view. When it comes into view, it triggers a function. That function was associated with the um use after free portion and the exploit runs and the end credits come up. But there was lots of other things in there which relate to um corporate cyber security. So they had to make sure that they jumped to a part of the code that didn't crash the game and the only way they could get it to work was actually voiding the player out which then the game got lost and because when it didn't

know where the player was, it just looked at the next cutscene and the cut scene happened to be the end credits. So there is a lot that goes into there and the point of demonstrating it in that way was to highlight some of the complexity that goes into finding these issues. It's really quite phenomenal and part of the reason why it works consistently is because uh modern protections which I'll talk about in more detail in a little bit weren't present. So there's no address space layout randomization. the functions are in the same place every single time and it makes it very consistent to do this. So now I'm going to run through [snorts] a Chromium use after free exploit

and this is the exploit code. I'm sort of going to rush over this. Um, and the highlighted lines there are what carries out the use after free um, sorry, turning the use after free condition into an exploit. Well, actually, no, I apologize. It it sets up the use after free condition. And this is the cause from the documentation, which again just doesn't really tell me anything. And that's why I'm just in awe of so many of the other speakers who actually do this for a living and find these things. All I'm doing is talking about it, but they actually do it for real life, which I just think is incredible. And because uh Chromium's open source, I

could actually have a look at the bug fix and see what they did. Um, and that's what they did. Which part of the reason why I'm showing this is that the phenomenal complexity in modern systems, unless you have significant knowledge and understand the potentially hundreds, tens to hundreds of packages that relate to this system. You know, there's a huge amount that goes into this and to be able to turn it into an exploit is incredibly difficult. And as was spoken about in the Rust presentation yesterday, 70% of Chromium serious security issues are memory related and use after free is 36.1% of those. [clears throat] Sorry if I'm talking fast. I'm going excuse me I've gone faster than what I

thought but it means I can talk about uh this part here which is um I just find fascinating. So how do people find these vulnerabilities in the case of speedruns or the speedrunning community they went to the extent of decompiling Ocarina of Time. So, a collection of volunteers manually decompiled the game's 15,700 plus functions and rewrote them by hand. They made a 100% accurate copy of the original data. And in an interview with the lead of this, they stated that the sole intent was to find better speedrun exploits. um which I just find is absolutely incredible. So this is an example of what they um how they did it. So the middle column there is

uh from the the ROM the actual uh function that's stored on the cartridge in assembly language. On the left you have CC code which is compiled using the compiler that was uh used to build the [clears throat] original game and then the output of that CC code on the right and they iterated the C code until they had a 100% identical match and that's how they decompiled the whole entire game into uh readable C code. And the point of that is if a bunch of volunteers are willing to go to that much effort, can you imagine what a nation state is willing to do? And I find that concept uh or prospect just phenomenal because some nation states

have very clear objectives they want to achieve and they have near unlimited resources to achieve those objectives. So one real world example of that is the 1979 Iranian hostage crisis. So the US embassy in Iran was um uh taken over and before the staff left they shredded all their documents using old school you know big long strip shredders. When the Iranians got in there, they got all the documents, all the shredded bits of paper, and they reassembled them all. And I can't imagine how long that would have taken. And then they published the lot just to embarrass the US. So that's a concrete real world physical example of the sheer effort that an actor might go to to

achieve its goal. And in this case, it was simply just embarrassing the US. So how do you protect against use after free um in a modern system? So it's safe coding practices. Um as the rust presentation yesterday noted, simply using Rust uh means that you are immune from use after free and many other um memory exploits. Uh Java is the same. any memory safe language. If you need to use a older language, you can do things like setting pointers to null and properly freeing the memory. Patching is a big one. That exploit only works on version 1.0 of the Japanese game. So that applies to everything. updating software which I think everyone knows about that and it's the importance of

doing that. So and I think I've just covered on as address space layout randomization which means that not everything is going to be in the same place every single time which was certainly the case on older systems. All right, questions. Thank you, Luke. [applause]