 I was looking at the media.ccc.de today to check out how many talks of console hacking we already had at the Congress. And it's quite a long list, actually. So we had the Xbox 360, PlayStation 3 at 23, C3. We had PlayStation Portable at 24, C3. We had a lot more. It's a really, really long list. And I'm really excited to have Yvan Lu and Davy here today. And they're going to tell us a little bit about the hack of the PlayStation Vita. And yeah, let's see how they hack it. Please give a warm applause to Yvan and Davy. So thanks everyone for coming today. So I know some of you did this already, but show of hands how many of you own a PlayStation Vita. Okay, that's a few of you. How many of you own a Nintendo 3DS? Okay, so that's the audience. Well, I'm hoping by the end of this talk I can convince you to come to the better console. So who are we? We are Team Molecule. This is our mascot. And Davy, I'm Yvan. For the lawyers, I'm XYZ. And there's also Proxima who is not here today. We've been hacking PlayStation Vita since the very beginning. And we've done a lot of stuff on it. So overview of the talk today. So this is a foundational talk. So we wanted to focus more on the techniques that we've developed rather than just show the results. So some of the parts, you know, for those of you more experienced, might find it a little bit tedious, but I'm hoping that you'll go through it and learn something anyways. So Davy will be presenting the software side. And I will come back later on and enlighten you with some hardware stuff. And here's Davy. Hello. So I'm going to be talking about the software side of hacking the PlayStation Vita. And specifically, I'm going to be talking about a certain subset of the Vita. And that's the security code processor. So first thing I need to talk about first is the software, the security architecture of the PlayStation Vita. It kind of looks like this. These are the basic privilege levels for the console. And we've already worked on the PlayStation Vita for a long time now. It was released in 2012. So we're already up to the trust zone level. What's quite interesting about trust zone on the Vita is it's not actually trusted at all by Sony. It only works as a proxy to the security code processor. So we can simplify this privilege level down to this. So really what I want to talk about today is how I'm going to go about breaking into the food kernel and the food loader levels. So food, I just said that. What is it? It's a security code processor. And it's a special processor in that it's running a proprietary instruction set. We'll come back to the actual details of the hardware itself. But let's first talk about the two privilege levels I was talking about. The food kernel is the DRM layer of the system. It makes sure that games and firmware updates are properly authenticated and no authorized code is run. The food loader is more like the bit loader and the startup sequence. And it just makes sure that the food kernel itself is valid. So if we want to break into these, we need to think of a plan on how to attack this. And with a proprietary processor, we really need to start getting more information on it. So first thing we need to look at is the hardware architecture behind it. Then afterwards, we're probably going to have to look at the software that's actually running on the processor. And from that, we can start to think of a plan of action to break into it. So first I'm going to talk about the architecture of the system. This is the block diagram for the main system on chip for the Vita. This is called Kermit, actually named after the frock. They so they tend to name their systems, the main processors and stuff off of, in this case on the Vita, they name after the Muppets, there's also Ernie. There's no Bert though, which is disappointing. On the PSP, for example, they had Kirk and Spock and Pommel, so only those two on this. And we don't really care about the rest here, the CPU, the GPU, we really want to focus on food. And you can see inside food, there's the MEP C5 processor. MEP is actually a custom risk from Toshiba. And I'll talk a bit about the name food. We actually got that from the ELF headers of executables built for the MEP platform. You see the ELF identifier is F00D. So we just ran with that, named it food, and it's been history since. The MEP processors are normally used in parking assist cameras or security solutions, but in this case, Sony have decided to use it for the security coprocessor. There's a bunch of other stuff belonging to food, such as the crypto engine and the key slots. Not very important for this talk, but it also has its own private memory, the secure SRAM here. Only 128 kilobytes, but it cannot be accessed from ARM or, in fact, any other subsystem in the system. So with a custom risk here, how do we find out information about it? It's pretty much the same as anything else. You Google it. And what that turns out is a bunch of data sheets somewhere in English. Most are in Japanese, so Google translates your best friend there. So following that, a couple of Google searches gives you the data sheets, so from there we can learn about the instruction set, we can learn about some of the quirks. Thankfully, Red Hat have already ported the platform to GCC and Binyu tools. So straight off the bat, we've got a compiler, we've got tools to analyze L files. Perfect. But really, we want to learn more. And the best way to learn, for us at least, is to get a little hands on. So we've built an IDA plugin for it. We've built an emulator, which was really useful because it helped us learn some of the weird quirks behind it. And we even have a decompiler for this. So overall, what we've learned about the hardware is that the instruction set is heavily inspired by MIPS. It doesn't have any of the weird delay slot or anything like that. But the actual instruction format is pretty much the same. There's no virtual memory, and there's no memory protection whatsoever. So it runs purely on physical memory. It's not hard in for security. So this is very interesting. There's no SLR. There's no execute bits. All choice for a secure co-processor, we thought that it wasn't very secure. So whatever. Next thing we're going to talk about is the actual software running on food. And at runtime on the PlayStation video, there's this secure kernel that's running at all times. And the main purpose of that is to load applets, which are executables that encapsulate some sort of functionality on the system. Examples of this are encryption, signature checks, DRM. And whatever you want to use, like some feature that needs to be authenticated, what you do is you load it. And once you load it, you can then do some sort of RPC calls to then do some calculations, or decryption, or authentication, or whatever. And then afterwards, you unload it. Because the applets follow a lifecycle where you load an applet, you do your stuff, you unload it. And only a single applet can be loaded at once. And unfortunately for us, the applets are signed and encrypted. So we can't just create our own one, load it, and then have access to the food. So let's look at the lifecycle a bit more detail. Specifically, we'll start with applet loading. So you see here, there's three regions here. You see ARM, TRUSTZONE, and FOOD. As I mentioned, TRUSTZONE's mostly useless. It only works as a proxy between ARM and FOOD. So we can simplify this model down. And we can start talking about how the applet loading works between ARM and FOOD. So ARM will start off. It will read the applet into memory. It will then transfer the applet over to FOOD. Then in FOOD, it will then check the signature of it, make sure it's a valid applet, and then it will start decrypting and loading it. Once done, it will return the result, whether that was successful, it failed, or something else. For applet RBC, it's most of the same power in here. It formats a request, sends that over to the FOOD secure kernel. Secure kernel will then forward that to the applet. Then the applet will run whatever commands needed, and the result will be sent back to ARM. Unloading, pretty much the same thing as you'd expect. What happens is the request is unloaded. You request an unload. FOOD will oblige, and you'll get the result back, whether that was successful. So knowing this, we need to start thinking, how can we actually go about attacking this? So let's summarize what we know first. We can control all the input into FOOD, and importantly, none of this input is checked at all. TrustZone doesn't do it, so we can pass in as much or as little malicious data as we want. We know the memory layer of FOOD. This is mostly inferred from the data sheets we got. But also, interestingly, the applets have an ELF header, and they have segment headers in there which address it looks to. So we can build a pretty good model of what the internal memory looks like. The secure code processor has no secure features whatsoever, so that's really handy. We know what the life cycle is. We know that they're loaded. We know we can then do some RPC calls, and then we can then query those RPC calls for any sort of issues. What we need to watch out for is there's a signed executable, so we can't modify any of these executables. Otherwise, we'll get thrown back with an error. We can read these executables. They're all encrypted, so we can't do any analysis of them beforehand, and this basically makes the system a black box here. So ideally, what we're after in order to proceed any further is some sort of read primitive that'll allow us to go ahead, inspect the FOOD private memory, and then from there, we can start looking at the code and we could establish a more precise attack on it. So I'm going to go back to applet loading here, and we're going to try and discuss in detail what's happening. Specifically, we know that the applet's read into memory, and it's transferred over to FOOD, where it does a signature check, and then does the rest of the loading. But what happens for this little bit in between here? And there's two problems here. First one is that ARM operates with virtual memory, and FOOD does not. So this is a problem because virtual memory is not guaranteed to be backed by contiguous physical memory. So whenever we want to send data to FOOD, we're going to have to make sure that it's either copied to that or that we don't use virtual memory, which is kind of ridiculous. So there needs to be a better way. And Sony have a better way of doing this, and we'll come to that shortly. So this is virtual memory, and this is physical memory. You could see that we have page one through to page seven. And if you look at the physical memory side, you could see that the pages aren't in order. So if we were to pass page one's physical address to FOOD, it won't receive the right data. It will receive page one, some unknown data, page four, page three, not intended. What Sony do here is they add a physical address list, this Piatr list. Instead of passing the data, all it does is you pass the Piatr list to FOOD, and it will query the list, which has the first element is the location of the page that we want. So you can see the first element here points to page one. The second element in that list is the size. So what FOOD will do when it wants to read an executable is it will walk this list and build the model up from inside. And this is the way they can get around having to copy virtual memory to a contiguous block. So applying this to FOOD and to the app list specifically, the FOOD module is an applet. What you could see here is that the first three bytes of this FOOD module is represented by the first entry of the Piatr list. The second is the second of the Piatr list and so forth. You can see that all these data is backed in DRAM. This solution fixes the copying and then we've learned how data is passed to FOOD. And this is consistent throughout transfers to FOOD. There's a problem, though. If we go back to this model here and we could see that all the data is backed in DRAM, what happens if we modify one of these Piatr list entries to then point to the FOOD private memory? Well, as it turns out, FOOD does not blacklist its own private memory. Useful, maybe? Not here because the internal memory, FOOD keeps all its data internal, so it doesn't copy anything out with this header. So no leak, but data is also signature checked. The applet is also going to be checked. This makes it useless because we're passing in to unknown data, it's doing a signature check. It's obviously just going to fail. Or is it? Because if we make an assumption, if the data we're pointing to in SRAM matches the expected data that we have in the applet, we would expect the signature check to succeed. And then we can make a deduction here that if that signature check succeeds, we know the contents of the SRAM. So let's do this a bit better here. If we reduce the Piatr list entry point into the private memory to one byte, and then simplify the Piatr list with the module to look more like this, where you have the first entry that is the first part of the file, the one element for this point into FOOD private memory is the 00 byte. So we're interested in finding in FOOD private memory, where all the 00 bytes are. So every time we pass in this Piatr list, what we would expect is, whenever there's a 00 pointer in this element here that's in SRAM, that the signature check would succeed. So if we start by going through this, so we have the element pointing at the first byte in the private memory. And we can then pass it into FOOD. It fails. So what we've learned here is that that byte in memory is not 00. We can go on. We can go to the next byte and query that, also not zero. And we can do this so on and so on and so on. Until eventually, we should expect to see a success. So the module was loaded. And what we've learned from that is that byte there is 00. It matches the one in FOOD, the FOOD applet. So yeah, we've learned that that's 00. We can then go ahead and apply this all the way through the rest of FOOD private memory. And there we go. We've built up a model where all the zeros are. So we've learned where the zeros are. Not very useful. What we want to do now is look for the 01s. So if we then rearrange the Piatr list, so the missing byte in the FOOD applet is 01, we can then do the same thing again. We point our entry into the FOOD private memory to the start. We start querying. Eventually, we find another one. Keep going. Keep going. We don't need to query the zeros. We already know what they're there. Then we get here again, and we find another one. Then you could do the same thing again. Apply all the way down to the end of memory, and you find all the ones. So imagine we've built this model. So what we want to do now is then apply it to all the 02s, then all the 03s, and all the 04s, and all the 05s, all the way up to the FFs. And once you've done that, you build a model of the FOOD SRAM, and you get the plain text to the kernel. This is what we're calling the Octopus exploit. Don't ask why. So with this, we now have the FOOD kernel. We got read access. We can then do some further analysis. We could start looking for more precise vulnerabilities. We won't go into that, but we've got the FOOD kernel. So what's next? It's the FOOD loader. And the FOOD loader is the boot stage. And because it's the boot stage, it doesn't last very long. It doesn't persist through runtime. That makes the software attack surface very small. So to deal with that, what we're going to have to do is look at hardware. And I'm going to pass you back to Yifan. And thank you very much. Thank you very much. Told you I would be back. So we ran into a situation where the weak little software hackers have to be rescued by the hardware master race. So what I'm going to focus on today is glitching. And I know that word is kind of a buzzword these days. Many of you have heard it. I think even at Congress, there were a couple of talks on it. But instead of just saying, hey, we glitched it, I want to kind of go into the details of what is glitching, how does it work, and why does it work. So in short, a hardware glitch allows you to create a software vulnerability when none exists. And there's many ways of doing so. But we're really going to focus on one of these methods today, which is voltage glitching. And the reason is because the other ways are much more difficult and expensive to pull off. And some of them are only theoretical. So to show a concrete example, I have a bit of C code. So this code just does a size check. And then the processes data of the check passes. And I went ahead and compiled it into MIP assembly. So if you haven't seen MIP assembly before, and why would you, this is what it looks like. And then I will just execute it for you as the computer. So here, we load the size value. And then SLTU3 basically is less than unsigned. And it sets R0 to the result of that. So here, it's set to 0 because it was not less than. And because of that, we jumped to the error branch. And it's fully secure. There's no way of hacking it. Just give up. But if we introduce a voltage glitch at this point, what happens is that this will create a mistake in the computation. So as you can see here, R0 is supposed to be set to 0. But because of the voltage glitch, it's now 1, which propagates the next instruction when we're taking a branch base off of that result. And we managed to bypass this check. Why does it work though? This is something that's near and dear to my heart because I'm the kind of person who you can tell me the high level ideas, but I'm not really satisfied until I know the low level details. So to explain that, we unfortunately have to look at transistors and logic gates. So if you don't remember this, don't worry. I'll explain it as well. So this is NAND, or not AND. And here's a truth table. And we are going to implement this in modern transistor technologies, or CMOS. It's a complementary transistor technology. What that means is there's two different types of transistors that implements the gate. One is, as you see on top, is used on the, I guess, the top part of the diagram. I'll show you the diagram later. It'll make more sense. But basically, this acts as a switch. The gate activates, and then the current will flow from the source to the drain. So kind of like a light switch. But instead of using your fingers, it's controlled by the voltage at the gate. The only difference between these two is that the voltage to turn on the top gate is low. So when there's no voltage, the top gate turns on. And on the bottom one, it turns on when it's high. So when there is voltage, it turns on. And that's what makes them complementary, because one must always be on when the other one's off. So here's what the NAND gate looks like. So you see the bottom gates are off, the top gates are on, because zero NAND zero is one. And you see current flowing from the source to the output. Now, one NAND zero is still one. And the way that works is that one of the top gates is turned off, but the other one is still on. So it's still flowing through. The bottom one, one of them is turned on, but that doesn't matter because the second one is turned off. So it doesn't leak down to the bottom port. Now, one NAND one is zero. And you can see it's because the two are turned off. Now, why are the bottom two turned on? Because when you turn off a faucet, sometimes there's water that drips down. So you need something to collect that. So what happens when we glitch it? So here's back to the one NAND zero example. When we say we introduce a voltage glitch, what we do is we essentially connect the voltage source down to ground or zero volts. Essentially, you're disabling the power source. And immediately, that doesn't do anything. So you can see here there's still a little bit of leakage current flowing to the output. And that's because, like I said, it's like a faucet. You turn it off and it doesn't immediately all get drained. So it's still flowing a little bit, but a tiny moment later, then the output goes to zero. And that is incorrect, right? Because one NAND zero should be one. However, here's the important part, right? You have to then turn it back on and restore the value. Otherwise, if you keep it off, then all the transistors in the system are going to turn off and your system just powers down and you can't do anything useful. So the key here is that we have an incorrect output, but only for a small amount of time because we can't get away with leaving it off. And because if we leave it off for too long, then it turns off. But not all hope is lost because that mistake for that tiny amount of time will actually propagate if it's done at the right place. So here's like a tree built from multiple NAND gates. And let's say the voltage glitch caused this output to be incorrect. But that's an input for these two gates, right? Which is an input for these two. And these two are inputs for that one. So you effectively created mistakes in about half the circuit. But that's the ideal case. In reality, it's a lot harder to determine how the error is going to propagate because if you think about the truth table for NAND logic, there's only one way of getting a 1 and 3 ways of getting a 0 or the other way around. But my point is that it's not even to get the right output that you want. The upshot, though, is that we can cause an incorrect output for a short amount of time. We have to wait for it to propagate. And like I explained before, because these logic gates aren't completely symmetric, it's easier to reach one state than the other, the system can correct itself. And this is actually by digital system design. One of the reasons why your computer is so robust is because it can correct mistakes like this. We are injecting a voltage glitch manually, but glitches are a known thing in digital logic. And a lot of times, it happens without any external sources. So circuits are designed to correct itself, which is why we need to find specific targets with a voltage glitch to actually get them to really do what we want. And the ideal case is that one error propagates through much of the circuitry. And examples of that includes arithmetic instructions, AES hardware, like branching and processors. Anything where you can imagine changing the input a little bit will create a lot of gears turning metaphorically and result in a widely different output. So that's the theory. You guys can wake up now. We're going to get to the actual practical part, which includes finding out where to attack, what to attack, and a little bit of automation. And that will make more sense when we get to it. So what do I mean by where to attack? So this here is an image of the PCB where the Vita's main system chip permit is laid on top of. And with anything as complicated as this, there's dozens of different voltage rails that power different parts of the chip, including like DRAM and IO pads and so on. But we only care about the power pins that go directly to the transistors. So we need to find which pin that corresponds to. To make things worse, each power rail, voltage rail is actually connected to dozens of pins. So it's not just like one pin corresponding to one thing. And there's 724 pins. But I can show you a way that we can go through this manually. It's not easy per se, but it's doable. And it's doable over a weekend or two. And it's a process that involves mapping out the pins on a PCB. And so to back up, of course, we don't have a data sheet. I think it's a lot easier if you have a commodity chip where you can just look up the data sheet and see where each pin corresponds to. But if you have a system with a completely custom design chip, you won't have that resource. So one thing that you have to do, though, is what's called PCB delayering. And I think there's been talks about in the past, which I think I recommend you guys look up. But the takeaway is that it's relatively inexpensive and anyone can do in their own home with the right tool. Fortunately, someone by the name of Biteful uploaded full PCB scans of the Vita's board. And that's fortunate for me because I don't have to breathe the fiberglass particles when you start removing the solder mask. So with the solder mask gone, you see the copper layer corresponding to the different pins here. And one thing I want to point out here is you can see that some of the pins look like pins, and other ones look like they're part of a sausage or what do you guys call it here? Anyways, the ones near the center is more likely to be power-related because if you think about designing a chip, you want to put your power sources near the center so they can dissipate evenly, and the distance to each component should be relatively close. So what we want to do is we want to take one random pin, and we want to see what power source is connected to and what other pins is associated with it. And to do that, we mark the pins. So the convention I'm going to be using is I will be marking one layer in red, and then I will go down another layer, and then I will use orange to show a new marking on that layer. So here you see a bunch of these small dark holes. These are called vias. They're used to connect the two metal layers together. So when you have a viad, that means there's an electrical connection from one layer to the other for that specific copper pad. So we go down one more, and you see the vias on this layer are a bit bigger than the last one. And then we can just keep going down until eventually we reach a copper plane that this viad is connected to. And I'll put an outline around it so it's more clear. So this is where the source for that power pin comes from. And I'm not going to show you the actual chip that powers that plane because it's off this image. What's important here is that there's many of these other vias on this plane that I've highlighted and read. So all of these are connected together on this layer. Now we can work backwards and do the same thing and basically find where it's connected each time and highlight the copper that's associated with. And then we get to the top. And we see that all of these little sausages are connected together. And these are 35 pins that are corresponds to one voltage rail. And that means we only have 689 more to go. But good news, 245 of them are not connected. And you can just see that by looking at layer one to layer two, there's no connections. 175 of them are ground, which means on the first or second layer you can just easily see they connect to the large copper pad that most other things are connected to. So really there's only 269 pins left. It's not the best thing to be doing on a Friday afternoon. But if you're me, what else do you have? So this is what the chip looks like, fully mapped out. The red ones are the different voltage rails. The different shades corresponds to the different voltage rail. And the other colors are data pins that are not really relevant here. I just did it for extra credit. So we found nine different voltage rails. How do we know which one's the right one? And to find out, we just basically try each one. Brute forcing nine things isn't that bad. We write a counter that increments like five different registers. And then we just hook it up to the computer. And we just try voltage glitching each one until we see one of these counters change. So why does that work? Well, remember when we create a voltage glitch, it effectively creates a mistake in some computation. So here, because of how tight that loop is, most of the work the processor is doing is going to be incrementing or decrementing these counters. And when the glitch hits, it will probably hit one of the ALU operations, which will cause a mistake like this. So we have this tool, this tool that we found, which is a voltage glitch. We found the right power rail. We can arbitrarily create mistakes in the computation. But what can we do with it? So from previous talks and from other resources, the clear way to go is to bypass signature checks. However, on the Vita, that's a bit hard for us to do. And some of the reasons include we don't really have examples of what the boot loaders look like decrypted. So we don't really even know where this signature is. And we don't know if there's other kinds of checks like Shaw hashing or anything like that. So it's just hard for us to tell if our glitch worked and it bypassed the signature, but something else failed or if the glitch didn't work. Instead, we looked at something that's easier to understand, which is the boot partition headers. And the boot partition contains the boot loaders. It's a special partition format that's not standard. However, it is easy to understand. It's unencrypted, it's unsigned. And the fields, you are not that many and you can kind of guess what they mean. We'll just focus on looking at the header size field because spoilers, it worked. And the size field is checked to be less than 0xDE blocks. We found this out through basically a draw and error. So we tried writing 0xFF and it didn't boot up. Then we tried writing 0x40 and it worked. Then we tried writing 0xE0 and it didn't work. And then through this kind of manual binary search kind of thing, we found that this was the largest value before it doesn't boot up. If the check fails, it halts. And if it passes, then we can see that the actual boot loaders are read from the storage. So what happens if we manage to bypass the size check? Well, the theory is that it will overflow some buffer because why do you check the size if you don't have a static buffer, right? So the plan is we need to sniff the storage controller traffic and that's just some external pins. We have a MOSFET, which is basically just an electrically controlled switch that will do the shorting that we discussed earlier. And we need a FPGA to control that MOSFET because we need very precise nanosecond level timing. And the reason why is because so this is the process to find the right parameters of glitch with, the important thing here is we wait until that partition header is read. And we know that at some short amount of time after the header is read, it will do that size check. But we don't know when that is. So that's what parameter N represents, is the offset from reading the packet to when the size check is done. Then we do the glitch and we hold the power off. We short it for an M amount of time. And basically the reason why we vary M is because remember when we're glitching, we don't really know what results we're causing. So the longer you hold a glitch, the results vary wildly. And if you hold it for too long, then the system shuts down. So we basically just have a script that looks at every possible N and M value and try different ones. So how do we actually implement this? So I use the chip whisper, which is a open source hardware hacking platform. And one of the reasons why it's so nice is because you can use Python to the script. That process that I talked about earlier has an FPGA. And a MOSFET, which is the only thing you really need. And we added a custom trigger for monitoring the storage traffic. Also, we designed a custom board. And the only reason why is really to manage all the wires because there's all the wires to the different pins for the storage controller. And then there's a couple of GPIOs for status indicator and stuff. So it's easier to just put them all on a board. And we also use this board to dump and flash the storage to put our payload on. And it connects directly to the chip whisper. Here's what it looks like hooked up. I made very liberal use of transparent tape. And one thing I want to point out here that I haven't mentioned before is that we actually connected. We removed the clock of the Vita. And we connected it directly to the chip whisper. And the reason why is that we found that if you synchronize the two clocks, the devices clock and the chip whisper clock, then when we are searching for those MNM parameters, there's less drift. And it makes the results more repeatable. So this is what it looks like hooked up. Once again, I love tape. And so the final piece that we had to put together was actually help from someone in the ex-switch hacking community who told us to slow down the clock even more than what we already did. And it turns out if you're running the clock too fast, it creates too much noise. And that could disturb the glitching process. So take away if it's not working, try slowing down the clock. So ran this all night and woke up the next morning, looked at the logs, and we found a vulnerability. And this is the boot ROM, SHA-256 hash. So state of the Vita in 2018, we managed to dump every part of it. The boot ROM, unfortunately, is not too interesting. They don't have any keys in it. They don't have anything that's the attack surface is just so tiny. They don't have a USB stack in it because that's crazy, right? And we managed to dump all the code we can find on the system. So what have we learned? So let me get a little philosophical for a moment. Sony had a history of crypto failures. I think most of you here know about all of these. But if not history lesson, PSP didn't check code signing in the beginning. PS3, the infamous fell overflow, ECDSA factoring. And recently, we found on the PlayStation Classic, they shipped the private keys for the firmware updates on every single device. But the Vita is actually a very nice work in terms of security. Unfortunately, can't speak to amount of games or market share. Key reasons includes the secure boot is pretty simple. All their cryptographic stuff is relatively simple compared to other Sony devices. We didn't really touch on the ARM processor at all, the main one that your games run on. But they do implement most modern exploit mitigation. And this was back in 2012, which where a lot of stuff like KASLR or kernel random address space randomization is in standard. They implemented that way back in 2012. And instead of trusting TrustStone, they have a dedicated crypto processor. But not everyone is perfect. There is a slight issue with how they chose their bootloader description keys. And to be clear, this key protects every other key in the system. Now, after we dumped the boot ROM, naturally, the next thing we did was find this key. And it is a single byte repeating. But here's a little, let me pull back the cartons a little. Before we dumped the boot ROM a couple of months before, our friend XYZ, now you can decide if he has nine IQ or nine million IQ. XYZ decided to brute force the AES128 key. And for legal reasons, we won't share with you. But let's just show you an unrelated picture I found on Amazon. So lots of people to thank. These are just a few. I want a special shout out to Zerpe, who managed to get Linux running on the Vita last week, which was very impressive. And now they're trying to write all the drivers for it. So if any of you are interested in that one, want to help, I can put you in touch with them if you check us out at the Nintembro's assembly later on. Everything I talked about will be posted on GitHub. If you want to know more about Vita hacking and reverse engineering, the Henkaku Wiki is a good resource. And if you want to write Vita homebrew, the Vita SDK, which we helped with early on, is a good resource. With that, I would like to open up the questions. Hey, great. Thanks a lot. Great to see how much fun you guys had hacking the thing. Really cool. We have five to seven minutes for Q&A. So please line up at the microphones. And we have some questions, probably. So I think microphone number five, I see somebody. It's the same. Yeah. So the double A is the key for the bootloader. Is this a joke? Since it's totally not effective at all, in my mean. So yeah, this was interesting. So at first when we found this, we thought for a long time that we actually, so we thought we accidentally had a debug build. So we thought they accidentally shipped a debug build or something, and that's where the key was from. But turns out it is the bootloader that is used on retail devices. I think the reason why it slipped out of checks is because they only ever used this key encrypted and they have a crypto processor. So in addition to food, there's a separate crypto processor that only food can communicate with. And it's the one that does all the encryption. So this key is never found in any text pages or anything or any code. It's only available in this secret hardware crypto processor. So maybe someone accidentally left the wrong key in or what I read, nobody found out because it was hidden so well. Great, we have a question from the internet. Signal Angel, please. Thank you. Can your findings be reused in some ways for the PS4? Probably not. I think the design here is mostly exclusive to the PlayStation review here. I think the PS4 has some sort of similar security code processor, but it's not the same. And also, PS4 doesn't implement as many security mitigations as Aveda does. Great, microphone one, please. For your work and for your talk, you talked about you control the clock from the processor via the chip respirator. Did you also try to clock-legit? Sorry, what was the last part? Did you try to clock-legit? So I guess, OK, I didn't want to talk into this because it's a bit technical, but clock glitching actually doesn't work on most modern processors because they use something called a phase lock loop, or PLL, which derives the internal clocks. And when you glitch the external clock, it will be filtered out by the PLL. So most modern devices have a PLL now, which makes clock glitching not really useful. Yes. Thanks, microphone three, please. Thank you. My question is very similar, and I'm not quite sure whether my understanding of PLLs is wrong. But as far as I understand, they only do clock multiplication and division. So if you change the external clock, then the internal clock should also change. And I was just curious by how much you changed the clock. Right, so that is true. But if you look at the very precise response function, the transfer function of most PLL, there is something. I don't remember the technical name, but it's like a delay response. So your changes in the frequency is not instantaneous. And most PLLs are designed to not change quickly with the clock frequency. And it's a feature that they call filtering out jitters, because sometimes your external clock can be a bit noisy. And you don't want your internal clock to follow that noise. So most PLLs are also designed specifically to not respond quickly to frequency changes on the outside. Thank you. We continue with microphone one, please. Since the hardware and software is similar. Can you come closer to the microphone? OK, sorry. Since the hardware and software is really similar, does this apply to the PlayStation TV 2 or just to the PlayStation Vita? Because PlayStation TV has HDMI output and USB input output. It will be, I don't know, all just to wait on that console too. So could you repeat that again? The PlayStation TV is what we're looking for. Yeah, it's all the same, yeah. It's just the same device. Yeah, because I have both, and I just saw, like, there is the error same sometimes with the PlayStation TV, even if it doesn't. I actually have a question TV, so if you will come to their assembly later, we can. Oh, OK, OK. I will, I will. OK, so invitation to the assembly later, we go to microphone three, please. Hi. Thank you for the talk. Very interesting. Would you care to explain why it's called the octopus exploit? I'll give two quick explanations. I'll give X, Y, Z, who found the X-ray. His original explanation is that an octopus has three hearts. And somehow, you know, when we have these three little, like, pieces of the, of the P address table, one, like, you know, one piece pointed correctly, one piece pointing to the food private memory, and one piece pointing to the correct data. That's like three hearts. That doesn't make any sense to me. I retconned an explanation, which is the piator list is kind of like eight octopus legs grabbing onto DRAM, which makes more sense to me. So you see the piator list here. That's supposed to be the three hearts. Yeah, total, makes total sense, right? Makes total sense. Microphone number two, please. Yeah, so my question is the initial boot loader of the food processor. Where is it actually stored? Is it, like, in flesh or is it from, or what is that? This is actually a very interesting question. I didn't want to get into it, but the boot ROM is never mapped anywhere in memory. So what the Vita does is on boot up, it copies the instructions for the initial, you know, boot stuff from some secret hardware area that's never accessible through memory into the SRAM. And then as the boot ROM, we call it BootRAM, starts up, it slowly wipes each part of the key derivation and other stuff as it's executing. So yeah, it was kind of a pain to get. Wow, interesting. Last question, microphone number one, please. So while taking apart the hardware, did you figure out what the top right port on the original Vita is for? Is it used anywhere? We found this out a while ago. It's actually just a USB host port, a USB EHCI port with a custom connector. Thanks. Yeah, great. Thank you again. Great applause for Ivan Lu and Daisy please.