Viva la Vita Vida
Lu, Yifan
Davee
Since its release in 2012, the PlayStation Vita has remained one of the most secure consumer devices on the market. We will describe the defenses and mitigations that it got right as well as insights into how we finally defeated it. The talk will be broken into two segments: software and hardware. First, we will give some background on the proprietary security co-processor we deem F00D, how it works, and what we had to do to reverse an architecture with minimal public information. Next, we will talk about hardware attacks on a real world secure hardware and detail the setup process and the attacks we were able to carry out. This talk assumes no prior knowledge in hardware and a basic background in system software. Focus will be on the methods and techniques we've developed along the way.
 I was looking at 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 23C3. We had PlayStation Portable at 24C3. We had a lot more. It's a really, really long list. And I'm really excited to have Yves-Henry and Davey 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 to hack it. Please give a warm applause to Yves-Henry and Davey. 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 Davey, I'm Yifan. 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 want 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 know, you'll like go through it and learn something anyways. So Davey will be presenting the software side. And I will come back later on and enlighten you with some hardware stuff. And here's Davey. 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 process there. 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 GoPro 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 coprocessor. 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 the games and firmware updates are properly authenticated and not authorized code is run. The food loader is more like the bit loader and the star up 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 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 about the name of food. We actually got that from the elf headers of executables built for the MEP platform. You see the 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? Well, it's pretty much the same as anything else. You Google it. And what that turns out is a bunch of data sheets. Some are in English, most are in Japanese. So Google translates your best friend there. Yeah, 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. And thankfully, Red Hat have already ported the MEP platform to GCC and Binyo tools. So straight off the back, we've got 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, like, 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 C calls to do some calculations or decryption or authentication or whatever. And then afterwards you unload it because the applets follow a life cycle 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 life cycle a bit more detail. Specifically, we'll start with applet loading. So, you see here, there's three regions here. You see ARM, TRUSSONE, and FOOD. As I mentioned, TRUSSONE is 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 or failed or something else. For applet RBC, it's mostly the same pattern here. It formats a request, sends that over to the FOOD secure kernel. The 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 coprocessor has no secure features whatsoever, so that's really handy. We know what the app lifecycle 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 will 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 the memory that we don't use virtual memory, which is kind of ridiculous. So, there needs to be a barrier way, and so they have a barrier way of doing this, and we'll come to that shortly. So, this is virtual memory, and this is physical memory. You can see that we have page one through to page seven, and if you look at the physical memory side, you can 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 applet specifically, the FOOD module is an applet. What you can 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 can 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, so this makes it useless, right? 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, right, if the data we're pointing to in SRAM matches the expected data that we have in the applet, we'd 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 pointing to the private memory to one byte, and then simplify the Piatr list with the module to more like this, where you have the first entry that is the first part of the file, the one element for this point in the 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. The signature check 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 and also not 00. 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, yep, we find another one. Keep going. Keep going. We don't need to create the zeros. We already know they're there. Then we get here again and we find another one. Then you could do the same thing again. Apply it 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. 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 can read access. We can then do some further analysis. We can 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. The FOOD loader is the boot stage. 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. I'm going to pass you back to Yfant. Thank you very much. I 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 jump to the error branch. And there's, you know, 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 we do, 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 manage 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 know, 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, you know, 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 the top gates 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, you know, like when you turn off a faucet, sometimes there's water that drips down, right? So you need something to collect that. So what happens when we glitch it, right? So here's, you know, back to the one NAND zero example. When we say we introduce a glitch, what we, or a voltage glitch, what we do is we essentially connect the voltage source down to ground or zero volts. Essentially, you're, you know, you're, 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, you know, like I said, you know, it's like a faucet, right? You turn it off and it doesn't immediately all get drained. So it's still flowing a little bit. But like a tiny little bit later than 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, you know, an incorrect output, but only for a small amount of time because we have to turn it, we can't get away, it was leaving it off. And because if we, you know, 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, you know, like a tree built from multiple NAND gates. And, you know, 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, you know, created mistakes in about half the circuit. But that's the ideal case. In reality, you know, it's a lot harder to determine like how the error is going to propagate because if you think about the truth table for NAND logic, it's there's only one way of getting a one way of getting a one and three ways of getting a zero or the other way around. But my point is that, you know, it's not even, even to get the right output that you want. The, you know, 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 the, like, you know, 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. Like, we are injecting a voltage glitch manually, but glitches are a known thing in digital logic. And it 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, you know, one error propagates through much of the circuitry. And examples of that includes arithmetic instructions, AES hardware, like, you know, branching, like in processors, anything where you can imagine like changing the input a little bit will create a lot of, you know, gears turning metaphorically and result in like 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, you know, 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 Kermit 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 IOPADs 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, you know, 724 pins. But I can show you a way that we can go through this like manually. It's not easy per se, but it's doable. And it's doable over a weekend or weekend. 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 like a commodity chip where you can just look up the data sheet and see like 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 this auto mask gone, you 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 you know like they're part of a sausage or what you guys call it here. Anyways, the the ones near the center is more likely to be power related, because if you think about like designing a chip, right, like you want to put your power sources near the center so they can dissipate evenly and and it's the distance to each component should be relatively close. So what we want to do is we want to take like one random pin, and we want to see where it is connected like where what power source is connected to and what other pins is associated with it. And to do that, we just, you know, we mark the pin. 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 metal layers, the two metal layers together. So when you have a vias that means there's an electrical connection from one layer to the other and for that specific copper pad. So we go down one more and you see, you know, 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 via 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 like the actual, I guess the actual power, the 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 in red. So all of these are connected together on this layer. Now we can work backwards and do the same thing and basically find, you know, 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 this, 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 like layer one to layer two, there's like 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 like most other things are connected to. So really there's only 269 pins left. It's not, you know, the best thing to be doing on a Friday afternoon. But you know, if you're me, what else do you have? Right? 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 do to find out, we just basically try each one, you know, brute forcing nine things isn't that bad. We write a counter that increments like five different registers. And then we just, you know, 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, you know, creates a mistake in some computation. So here, because like the most because of the how tight that loop is most of the work the processors doing is going to be increment or increment or decrementing these counters. And when, you know, when the glitch hits, it will probably like hit one of the ALU operations, which will cause a mistake like this. So, you know, 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, you know, 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 what the boot loaders look like decrypted. So we don't really even know where the signature is. And we don't know if there's like other kinds of checks like and like shah hashing or anything like that. So it was 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 doesn't work. Instead, we looked at something that's that's easier to understand, which is the boot partition headers. And the the boot partition contains a boot loaders. It's a special partition format that's not standard. However, it is easy to understand it's unencrypted unsigned. And the fields, you know, 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 zero x blocks. We found this out through basically draw an error. So we tried writing, you know, zero x ff and it didn't boot up. Then we tried writing, you know, zero x four zero and it worked. Then we tried writing, you know, zero x, easy, and it didn't work. And then through this like kind of like manual binary search kind of thing, we found that this was the largest value before it doesn't boot up. If you know if the check fails, it halts. And if it passes, then we can see that the the 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 you know why will you why do you check the size if you don't have a static buffer, right? So the plan is we need to sniff the the storage controller traffic. And that's, you know, 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 for we need a FPGA to control that MOSFET because we need very precise like nanosecond level timing. And the reason why is because so this is, you know, the the process to find the right parameters of glitch with the the important thing here is, you know, we wait until that boot partition header is read. And we know that at some time, 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 the offset from reading the packet to when the size check is done. Then we do the glitch and we, you know, hold the power off. We we short it for a M amount of time. And basically, the reason why we vary M is because remember when when we're glitching, we don't really know what results were causing. So the longer you hold a glitch, the the results vary wildly. And if you hold it for too long, then the system shuts down. So we basically, you know, just have a script that looks at every possible N and M value and, you know, 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. All 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 had a we designed a custom board. And the the only reason why is really to manage all the wires because, you know, we there's all the wires to the the different pins for the storage controller. And then there's a couple of GPIOs for like 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, you know, 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 this 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 M and M 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 the final the final piece that put that we had to put together was actually help from someone in the X switch hacking community who told us to slow down the clock even more than what we already did. And it turns out, you know, if you're running the clock too fast, it creates too much noise and that could disturb the glitching process. So, you know, 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 shot 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 like a USB stack in it because that's crazy, right? And, you know, 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, you know, 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, you know, work in terms of security. Unfortunately, you know, can't speak to amount of games or market share. Key reasons include the boot, the secure boot is pretty simple. All their, you know, cryptographic stuff is relatively simple compared to, you know, 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, you know, a lot of stuff like KASLR or kernel random address space, the system is not standard. They implemented that, you know, way back in 2012. And they, you know, instead of trusting trustome, they have a dedicated crypto processor. But not everyone is perfect. And 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, here's a little, like, let me pull back the cartons a little before we dump the boot ROM a couple months before our friend XYZ. Now you can decide if he has nine IQ or nine million IQ. XYZ decided to brute force the AES 128 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 Zerfi who managed to get Linux running on the Vita last week, which was very impressive. And now they're trying to, like, write all the drivers for it. So if any of you are interested in that and want to help, I can put you in touch with them if you check us out at the Nintenbros 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. So number five, I see somebody. So the double A is the root key for the boot, Ludo. Is this a joke? Since it's totally not effective at all in my mean. 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 we accidentally shipped a debug build or something, and that's where the key was from. But turns out it is the boot loader 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 like, you know, 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 like text pages or anything or any code. It's only available in this secret hardware crypto processor. So maybe, you know, someone accidentally left the wrong key in or whatever, and 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. No, it's, I think the design here is mostly exclusive to the PlayStation video here. It's, 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, okay, 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 PLL 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 there's actually, 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? Okay, sorry. Since the hardware and software is really similar, does this apply to the PlayStation TV2 or just to the PlayStation beta? Because PlayStation TV has HDMI output and USB input output. So it will be, I don't know, cool just to do it on that console too. So can you repeat that again? The PlayStation TV is what we're talking about. Yeah, it's all the same, yeah. It's just the same device. Yeah, because both of them, they just so like, there is the error same sometimes with the PlayStation TV, even if it doesn't. I actually have a question on TV, so if you come to their assembly later, we can... Oh, okay, okay. I will, I will. Okay, 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 Pader list is kind of like eight octopus legs grabbing onto DRAM, which makes more sense to me. So you see the Pader list here. That's supposed to be the three hearts. Yeah. Total makes total sense, right? Make total second. Microphone number two, please. Yes. So my question is the initial boot loader of the food process and where is it actually stored? Is it like in flysharers 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 boot RAM, starts up, it's like slowly wipes each part, like, 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 for a USB EHCI port with a custom connector. Thanks. Yeah, great. Thank you again. Great applause for Ivan Luhet, David Lies. Thanks for watching.
 I was looking at 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 23C3. We had PlayStation Portable at 24C3. We had a lot more. It's a really,  really long list. And I'm really excited to have Yves-Henry and Davey 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 to hack it. Please give a warm applause to Yves-Henry and Davey.  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 Davey,  I'm Yifan. 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 want 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 know,  you'll like go through it and learn something anyways. So Davey will be presenting the software  side. And I will come back later on and enlighten you with some hardware stuff. And here's Davey.  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  process there. 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 GoPro  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 coprocessor. 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 the games and firmware updates are properly authenticated  and not authorized code is run. The food loader is more like the bit loader and the star up 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 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 about the name of food.  We actually got that from the elf headers of executables built for the MEP platform. You see the  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? Well, it's pretty much the same as anything else. You Google it. And what that  turns out is a bunch of data sheets. Some are in English, most are in Japanese. So Google translates  your best friend there. Yeah, 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. And thankfully, Red Hat have already ported the MEP platform to GCC and Binyo tools. So  straight off the back, we've got 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, like, 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  C calls to do some calculations or decryption or authentication or whatever. And then  afterwards you unload it because the applets follow a life cycle 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 life cycle a bit more detail.  Specifically, we'll start with applet loading. So, you see here, there's three regions here.  You see ARM, TRUSSONE, and FOOD. As I mentioned, TRUSSONE is 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 or failed or  something else. For applet RBC, it's mostly the same pattern here. It formats a request, sends  that over to the FOOD secure kernel. The 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 coprocessor has no secure features  whatsoever, so that's really handy. We know what the app lifecycle 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 will 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 the memory that we don't use virtual  memory, which is kind of ridiculous. So, there needs to be a barrier way, and so they have a  barrier way of doing this, and we'll come to that shortly. So, this is virtual memory, and this is  physical memory. You can see that we have page one through to page seven, and if you look at the  physical memory side, you can 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 applet specifically, the FOOD module is an  applet. What you can 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 can 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, so this  makes it useless, right? 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, right, if the data we're  pointing to in SRAM matches the expected data that we have in the applet, we'd 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  pointing to the private memory to one byte, and then simplify the Piatr list with the module to  more like this, where you have the first entry that is the first part of the file, the one element for  this point in the 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. The signature check 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  and also not 00. 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, yep, we find another one. Keep going. Keep going. We don't need to create the zeros. We already know  they're there. Then we get here again and we find another one. Then you could do the same thing again.  Apply it 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. 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 can read access. We can then do some further analysis. We can 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.  The FOOD loader is the boot stage. 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. I'm going to pass you back to Yfant. Thank you very much.  I 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 jump to  the error branch. And there's, you know, 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 we do, 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 manage 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  know, 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, you know, 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  the top gates 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, you know, like when you turn off a faucet, sometimes there's water that drips down, right? So you need something to  collect that. So what happens when we glitch it, right? So here's, you know, back to the one NAND zero example. When we say we  introduce a glitch, what we, or a voltage glitch, what we do is we essentially connect the voltage source down to ground or  zero volts. Essentially, you're, you know, you're, 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, you know, like I said, you  know, it's like a faucet, right? You turn it off and it doesn't immediately all get drained. So it's still flowing a little bit. But like a tiny  little bit later than 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, you know, an incorrect output, but only for a small amount of time because we have to turn it, we can't get away, it was  leaving it off. And because if we, you know, 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, you know, like a tree built from multiple NAND gates.  And, you know, 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, you know, created mistakes in about half the circuit. But that's  the ideal case. In reality, you know, it's a lot harder to determine like how the error is going to propagate because if you think about the truth table  for NAND logic, it's there's only one way of getting a one way of getting a one and three ways of getting a zero or the other way around.  But my point is that, you know, it's not even, even to get the right output that you want. The, you know, 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 the, like, you know, 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. Like, we are  injecting a voltage glitch manually, but glitches are a known thing in digital logic. And it 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, you know, one error propagates through much of the circuitry. And examples of that includes arithmetic instructions, AES hardware,  like, you know, branching, like in processors, anything where you can imagine like changing the input a little bit will create a lot of, you know, gears turning  metaphorically and result in like 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, you know, 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 Kermit 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 IOPADs 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, you know, 724 pins. But I can show you a way that we can go through this like manually. It's not easy per se, but it's doable. And it's doable over a weekend or  weekend. 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 like a commodity chip where you can just look up the  data sheet and see like 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 this auto mask gone, you 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 you know like they're part of a  sausage or what you guys call it here. Anyways, the the ones near the center is more likely to be power related, because if you think about like designing a chip, right, like you want to put your power sources near the center so they can  dissipate evenly and and it's the distance to each component should be relatively close. So what we want to do is we want to take like one random pin, and we want to see where it is connected like where what power source is connected  to and what other pins is associated with it. And to do that, we just, you know, we mark the pin. 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 metal layers, the two metal layers together. So when you have a vias that means there's an electrical connection from one layer to the other and for that specific copper pad.  So we go down one more and you see, you know, 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 via 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 like the actual, I guess the actual power, the 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 in red. So all of these are connected together on this layer. Now we can work backwards and do the same thing and basically find, you know, 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 this, 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 like layer one to layer two, there's like 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 like most other things are connected to.  So really there's only 269 pins left. It's not, you know, the best thing to be doing on a Friday afternoon. But you know, if you're me, what else do you have? Right?  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 do to find out, we just basically try each one, you know, brute forcing nine things isn't that bad.  We write a counter that increments like five different registers. And then we just, you know, 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, you know, creates a mistake in some computation.  So here, because like the most because of the how tight that loop is most of the work the processors doing is going to be increment or increment or decrementing these counters.  And when, you know, when the glitch hits, it will probably like hit one of the ALU operations, which will cause a mistake like this.  So, you know, 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, you know, 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 what the boot loaders look like decrypted.  So we don't really even know where the signature is. And we don't know if there's like other kinds of checks like and like shah hashing or anything like that.  So it was 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 doesn't work.  Instead, we looked at something that's that's easier to understand, which is the boot partition headers.  And the the boot partition contains a boot loaders. It's a special partition format that's not standard.  However, it is easy to understand it's unencrypted unsigned. And the fields, you know, 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 zero x blocks. We found this out through basically draw an error.  So we tried writing, you know, zero x ff and it didn't boot up. Then we tried writing, you know, zero x four zero and it worked.  Then we tried writing, you know, zero x, easy, and it didn't work. And then through this like kind of like manual binary search kind of thing, we found that this was the largest value before it doesn't boot up.  If you know if the check fails, it halts. And if it passes, then we can see that the the 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 you know why will you why do you check the size if you don't have a static buffer, right?  So the plan is we need to sniff the the storage controller traffic. And that's, you know, 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 for we need a FPGA to control that MOSFET because we need very precise like nanosecond level timing.  And the reason why is because so this is, you know, the the process to find the right parameters of glitch with the the important thing here is, you know, we wait until that boot partition header is read.  And we know that at some time, 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 the offset from reading the packet to when the size check is done.  Then we do the glitch and we, you know, hold the power off. We we short it for a M amount of time. And basically, the reason why we vary M is because remember when when we're glitching, we don't really know what results were causing.  So the longer you hold a glitch, the the results vary wildly. And if you hold it for too long, then the system shuts down.  So we basically, you know, just have a script that looks at every possible N and M value and, you know, 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. All 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 had a we designed a custom board. And the the only reason why is really to manage all the wires because, you know, we there's all the wires to the the different pins for the storage controller.  And then there's a couple of GPIOs for like 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, you know, 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 this 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 M and M 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 the final the final piece that put that we had to put together was actually help from someone in the X switch hacking community who told us to slow down the clock even more than what we already did.  And it turns out, you know, if you're running the clock too fast, it creates too much noise and that could disturb the glitching process.  So, you know, 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 shot 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 like a USB stack in it because that's crazy, right? And, you know, 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, you know, 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, you know, work in terms of security. Unfortunately, you know, can't speak to amount of games or market share.  Key reasons include the boot, the secure boot is pretty simple. All their, you know, cryptographic stuff is relatively simple compared to, you know, 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, you know, a lot of stuff like KASLR or kernel random address space,  the system is not standard. They implemented that, you know, way back in 2012. And they, you know, instead of trusting trustome, they have a dedicated crypto processor. But not everyone is perfect.  And 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, here's a little, like, let me pull back the cartons a little before we dump the boot ROM a couple months before our friend XYZ.  Now you can decide if he has nine IQ or nine million IQ. XYZ decided to brute force the AES 128 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 Zerfi who managed to get Linux running on the Vita last week,  which was very impressive. And now they're trying to, like, write all the drivers for it. So if any of you are interested in that and want to help,  I can put you in touch with them if you check us out at the Nintenbros 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.  So number five, I see somebody. So the double A is the root key for the boot, Ludo. Is this a joke? Since it's totally not effective at all in my mean.  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 we accidentally shipped a debug build or something, and that's where the key was from. But turns out it is the boot loader 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 like, you know, 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 like text pages or anything or any code. It's only available in this secret hardware crypto processor.  So maybe, you know, someone accidentally left the wrong key in or whatever, and 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. No, it's, I think the design here is mostly exclusive to the PlayStation video here. It's, 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, okay, 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 PLL 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 there's actually, 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?  Okay, sorry.  Since the hardware and software is really similar, does this apply to the PlayStation TV2 or just to the PlayStation beta?  Because PlayStation TV has HDMI output and USB input output.  So it will be, I don't know, cool just to do it on that console too.  So can you repeat that again?  The PlayStation TV is what we're talking about.  Yeah, it's all the same, yeah. It's just the same device.  Yeah, because both of them, they just so like, there is the error same sometimes with the PlayStation TV, even if it doesn't.  I actually have a question on TV, so if you come to their assembly later, we can...  Oh, okay, okay. I will, I will.  Okay, 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 Pader list is kind of like eight octopus legs grabbing onto DRAM, which makes more sense to me.  So you see the Pader list here. That's supposed to be the three hearts.  Yeah. Total makes total sense, right?  Make total second.  Microphone number two, please.  Yes. So my question is the initial boot loader of the food process and where is it actually stored?  Is it like in flysharers 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 boot RAM, starts up, it's like slowly wipes each part, like, 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 for a USB EHCI port with a custom connector.  Thanks.  Yeah, great. Thank you again. Great applause for Ivan Luhet, David Lies.  Thanks for watching.
35c3-9364-viva_la_vita_vida_0_59.png 35c3-9364-viva_la_vita_vida_60_107.png 35c3-9364-viva_la_vita_vida_108_1199.png 35c3-9364-viva_la_vita_vida_1200_1631.png 35c3-9364-viva_la_vita_vida_1632_1979.png 35c3-9364-viva_la_vita_vida_1980_2135.png 35c3-9364-viva_la_vita_vida_2136_2291.png 35c3-9364-viva_la_vita_vida_2292_2459.png 35c3-9364-viva_la_vita_vida_2460_2519.png 35c3-9364-viva_la_vita_vida_2520_6695.png 35c3-9364-viva_la_vita_vida_6696_7523.png 35c3-9364-viva_la_vita_vida_7524_11447.png 35c3-9364-viva_la_vita_vida_11448_16451.png 35c3-9364-viva_la_vita_vida_16452_23795.png 35c3-9364-viva_la_vita_vida_23796_29675.png 35c3-9364-viva_la_vita_vida_29676_29735.png 35c3-9364-viva_la_vita_vida_29736_30071.png 35c3-9364-viva_la_vita_vida_30072_30167.png 35c3-9364-viva_la_vita_vida_30168_33155.png 35c3-9364-viva_la_vita_vida_33156_42947.png 35c3-9364-viva_la_vita_vida_42948_61055.png 35c3-9364-viva_la_vita_vida_61056_61139.png 35c3-9364-viva_la_vita_vida_61140_62819.png 35c3-9364-viva_la_vita_vida_62820_63827.png 35c3-9364-viva_la_vita_vida_63828_65087.png 35c3-9364-viva_la_vita_vida_65088_65483.png 35c3-9364-viva_la_vita_vida_65484_67283.png 35c3-9364-viva_la_vita_vida_67284_69203.png 35c3-9364-viva_la_vita_vida_69204_70427.png 35c3-9364-viva_la_vita_vida_70428_72503.png 35c3-9364-viva_la_vita_vida_72504_72575.png 35c3-9364-viva_la_vita_vida_72576_72623.png 35c3-9364-viva_la_vita_vida_72624_72695.png 35c3-9364-viva_la_vita_vida_72696_72767.png 35c3-9364-viva_la_vita_vida_72768_72839.png 35c3-9364-viva_la_vita_vida_72840_72983.png 35c3-9364-viva_la_vita_vida_72984_73139.png 35c3-9364-viva_la_vita_vida_73140_73487.png 35c3-9364-viva_la_vita_vida_73488_73655.png 35c3-9364-viva_la_vita_vida_73656_74147.png 35c3-9364-viva_la_vita_vida_74148_74855.png 35c3-9364-viva_la_vita_vida_74856_75407.png 35c3-9364-viva_la_vita_vida_75408_75479.png 35c3-9364-viva_la_vita_vida_75480_76247.png 35c3-9364-viva_la_vita_vida_76248_76307.png 35c3-9364-viva_la_vita_vida_76308_77987.png 35c3-9364-viva_la_vita_vida_77988_79259.png 35c3-9364-viva_la_vita_vida_79260_79367.png 35c3-9364-viva_la_vita_vida_79368_79943.png 35c3-9364-viva_la_vita_vida_79944_80039.png 35c3-9364-viva_la_vita_vida_80040_80135.png 35c3-9364-viva_la_vita_vida_80136_80639.png 35c3-9364-viva_la_vita_vida_80640_80687.png 35c3-9364-viva_la_vita_vida_80688_81047.png 35c3-9364-viva_la_vita_vida_81048_81155.png 35c3-9364-viva_la_vita_vida_81156_81371.png 35c3-9364-viva_la_vita_vida_81372_82871.png 35c3-9364-viva_la_vita_vida_82872_83663.png 35c3-9364-viva_la_vita_vida_83664_83711.png 35c3-9364-viva_la_vita_vida_83712_84167.png 35c3-9364-viva_la_vita_vida_84168_84251.png 35c3-9364-viva_la_vita_vida_84252_84347.png 35c3-9364-viva_la_vita_vida_84348_84455.png 35c3-9364-viva_la_vita_vida_84456_84587.png 35c3-9364-viva_la_vita_vida_84588_84719.png 35c3-9364-viva_la_vita_vida_84720_84899.png
I was looking at 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 23C3. We had PlayStation Portable at 24C3. We had a lot more. It's a really, really long list. And I'm really excited to have Yves-Henry and Davey 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 to hack it. Please give a warm applause to Yves-Henry and Davey. 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 Davey, I'm Yifan. 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 want 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 know, you'll like go through it and learn something anyways. So Davey will be presenting the software side. And I will come back later on and enlighten you with some hardware stuff. And here's Davey. 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 process there. 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 GoPro 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 coprocessor. 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 the games and firmware updates are properly authenticated and not authorized code is run. The food loader is more like the bit loader and the star up 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 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 about the name of food. We actually got that from the elf headers of executables built for the MEP platform. You see the 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? Well, it's pretty much the same as anything else. You Google it. And what that turns out is a bunch of data sheets. Some are in English, most are in Japanese. So Google translates your best friend there. Yeah, 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. And thankfully, Red Hat have already ported the MEP platform to GCC and Binyo tools. So straight off the back, we've got 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, like, 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 C calls to do some calculations or decryption or authentication or whatever. And then afterwards you unload it because the applets follow a life cycle 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 life cycle a bit more detail. Specifically, we'll start with applet loading. So, you see here, there's three regions here. You see ARM, TRUSSONE, and FOOD. As I mentioned, TRUSSONE is 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 or failed or something else. For applet RBC, it's mostly the same pattern here. It formats a request, sends that over to the FOOD secure kernel. The 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 coprocessor has no secure features whatsoever, so that's really handy. We know what the app lifecycle 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 will 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 the memory that we don't use virtual memory, which is kind of ridiculous. So, there needs to be a barrier way, and so they have a barrier way of doing this, and we'll come to that shortly. So, this is virtual memory, and this is physical memory. You can see that we have page one through to page seven, and if you look at the physical memory side, you can 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 applet specifically, the FOOD module is an applet. What you can 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 can 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, so this makes it useless, right? 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, right, if the data we're pointing to in SRAM matches the expected data that we have in the applet, we'd 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 pointing to the private memory to one byte, and then simplify the Piatr list with the module to more like this, where you have the first entry that is the first part of the file, the one element for this point in the 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. The signature check 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 and also not 00. 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, yep, we find another one. Keep going. Keep going. We don't need to create the zeros. We already know they're there. Then we get here again and we find another one. Then you could do the same thing again. Apply it 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. 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 can read access. We can then do some further analysis. We can 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. The FOOD loader is the boot stage. 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. I'm going to pass you back to Yfant. Thank you very much. I 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 jump to the error branch. And there's, you know, 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 we do, 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 manage 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 know, 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, you know, 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 the top gates 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, you know, like when you turn off a faucet, sometimes there's water that drips down, right? So you need something to collect that. So what happens when we glitch it, right? So here's, you know, back to the one NAND zero example. When we say we introduce a glitch, what we, or a voltage glitch, what we do is we essentially connect the voltage source down to ground or zero volts. Essentially, you're, you know, you're, 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, you know, like I said, you know, it's like a faucet, right? You turn it off and it doesn't immediately all get drained. So it's still flowing a little bit. But like a tiny little bit later than 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, you know, an incorrect output, but only for a small amount of time because we have to turn it, we can't get away, it was leaving it off. And because if we, you know, 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, you know, like a tree built from multiple NAND gates. And, you know, 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, you know, created mistakes in about half the circuit. But that's the ideal case. In reality, you know, it's a lot harder to determine like how the error is going to propagate because if you think about the truth table for NAND logic, it's there's only one way of getting a one way of getting a one and three ways of getting a zero or the other way around. But my point is that, you know, it's not even, even to get the right output that you want. The, you know, 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 the, like, you know, 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. Like, we are injecting a voltage glitch manually, but glitches are a known thing in digital logic. And it 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, you know, one error propagates through much of the circuitry. And examples of that includes arithmetic instructions, AES hardware, like, you know, branching, like in processors, anything where you can imagine like changing the input a little bit will create a lot of, you know, gears turning metaphorically and result in like 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, you know, 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 Kermit 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 IOPADs 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, you know, 724 pins. But I can show you a way that we can go through this like manually. It's not easy per se, but it's doable. And it's doable over a weekend or weekend. 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 like a commodity chip where you can just look up the data sheet and see like 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 this auto mask gone, you 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 you know like they're part of a sausage or what you guys call it here. Anyways, the the ones near the center is more likely to be power related, because if you think about like designing a chip, right, like you want to put your power sources near the center so they can dissipate evenly and and it's the distance to each component should be relatively close. So what we want to do is we want to take like one random pin, and we want to see where it is connected like where what power source is connected to and what other pins is associated with it. And to do that, we just, you know, we mark the pin. 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 metal layers, the two metal layers together. So when you have a vias that means there's an electrical connection from one layer to the other and for that specific copper pad. So we go down one more and you see, you know, 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 via 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 like the actual, I guess the actual power, the 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 in red. So all of these are connected together on this layer. Now we can work backwards and do the same thing and basically find, you know, 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 this, 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 like layer one to layer two, there's like 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 like most other things are connected to. So really there's only 269 pins left. It's not, you know, the best thing to be doing on a Friday afternoon. But you know, if you're me, what else do you have? Right? 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 do to find out, we just basically try each one, you know, brute forcing nine things isn't that bad. We write a counter that increments like five different registers. And then we just, you know, 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, you know, creates a mistake in some computation. So here, because like the most because of the how tight that loop is most of the work the processors doing is going to be increment or increment or decrementing these counters. And when, you know, when the glitch hits, it will probably like hit one of the ALU operations, which will cause a mistake like this. So, you know, 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, you know, 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 what the boot loaders look like decrypted. So we don't really even know where the signature is. And we don't know if there's like other kinds of checks like and like shah hashing or anything like that. So it was 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 doesn't work. Instead, we looked at something that's that's easier to understand, which is the boot partition headers. And the the boot partition contains a boot loaders. It's a special partition format that's not standard. However, it is easy to understand it's unencrypted unsigned. And the fields, you know, 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 zero x blocks. We found this out through basically draw an error. So we tried writing, you know, zero x ff and it didn't boot up. Then we tried writing, you know, zero x four zero and it worked. Then we tried writing, you know, zero x, easy, and it didn't work. And then through this like kind of like manual binary search kind of thing, we found that this was the largest value before it doesn't boot up. If you know if the check fails, it halts. And if it passes, then we can see that the the 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 you know why will you why do you check the size if you don't have a static buffer, right? So the plan is we need to sniff the the storage controller traffic. And that's, you know, 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 for we need a FPGA to control that MOSFET because we need very precise like nanosecond level timing. And the reason why is because so this is, you know, the the process to find the right parameters of glitch with the the important thing here is, you know, we wait until that boot partition header is read. And we know that at some time, 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 the offset from reading the packet to when the size check is done. Then we do the glitch and we, you know, hold the power off. We we short it for a M amount of time. And basically, the reason why we vary M is because remember when when we're glitching, we don't really know what results were causing. So the longer you hold a glitch, the the results vary wildly. And if you hold it for too long, then the system shuts down. So we basically, you know, just have a script that looks at every possible N and M value and, you know, 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. All 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 had a we designed a custom board. And the the only reason why is really to manage all the wires because, you know, we there's all the wires to the the different pins for the storage controller. And then there's a couple of GPIOs for like 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, you know, 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 this 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 M and M 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 the final the final piece that put that we had to put together was actually help from someone in the X switch hacking community who told us to slow down the clock even more than what we already did. And it turns out, you know, if you're running the clock too fast, it creates too much noise and that could disturb the glitching process. So, you know, 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 shot 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 like a USB stack in it because that's crazy, right? And, you know, 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, you know, 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, you know, work in terms of security. Unfortunately, you know, can't speak to amount of games or market share. Key reasons include the boot, the secure boot is pretty simple. All their, you know, cryptographic stuff is relatively simple compared to, you know, 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, you know, a lot of stuff like KASLR or kernel random address space, the system is not standard. They implemented that, you know, way back in 2012. And they, you know, instead of trusting trustome, they have a dedicated crypto processor. But not everyone is perfect. And 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, here's a little, like, let me pull back the cartons a little before we dump the boot ROM a couple months before our friend XYZ. Now you can decide if he has nine IQ or nine million IQ. XYZ decided to brute force the AES 128 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 Zerfi who managed to get Linux running on the Vita last week, which was very impressive. And now they're trying to, like, write all the drivers for it. So if any of you are interested in that and want to help, I can put you in touch with them if you check us out at the Nintenbros 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. So number five, I see somebody. So the double A is the root key for the boot, Ludo. Is this a joke? Since it's totally not effective at all in my mean. 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 we accidentally shipped a debug build or something, and that's where the key was from. But turns out it is the boot loader 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 like, you know, 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 like text pages or anything or any code. It's only available in this secret hardware crypto processor. So maybe, you know, someone accidentally left the wrong key in or whatever, and 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. No, it's, I think the design here is mostly exclusive to the PlayStation video here. It's, 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, okay, 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 PLL 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 there's actually, 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? Okay, sorry. Since the hardware and software is really similar, does this apply to the PlayStation TV2 or just to the PlayStation beta? Because PlayStation TV has HDMI output and USB input output. So it will be, I don't know, cool just to do it on that console too. So can you repeat that again? The PlayStation TV is what we're talking about. Yeah, it's all the same, yeah. It's just the same device. Yeah, because both of them, they just so like, there is the error same sometimes with the PlayStation TV, even if it doesn't. I actually have a question on TV, so if you come to their assembly later, we can... Oh, okay, okay. I will, I will. Okay, 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 Pader list is kind of like eight octopus legs grabbing onto DRAM, which makes more sense to me. So you see the Pader list here. That's supposed to be the three hearts. Yeah. Total makes total sense, right? Make total second. Microphone number two, please. Yes. So my question is the initial boot loader of the food process and where is it actually stored? Is it like in flysharers 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 boot RAM, starts up, it's like slowly wipes each part, like, 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 for a USB EHCI port with a custom connector. Thanks. Yeah, great. Thank you again. Great applause for Ivan Luhet, David Lies. Thanks for watching.
bit about the hack of the PlayStation Vita. And we've developed rather than just show the software, the security architecture of the released in 2012. So we're already up to the system on chip for the Vita. This is called talk about the name of food. We actually got that So with a custom risk here, how do we find out Next thing we're going to talk about is the cycle a bit more detail. Specifically, we'll looks like. The secure coprocessor has no secure And the way that works is that one of the top weekend or weekend. And it's a process that some computation. So here, because like the most traffic. Also, we had a we designed a custom security mitigations as Aveda does. Great. hardware and software is really similar, does output and USB input output. So it will be, I what the top right port on the original Vita is