 Please raise your hands. Xbox, yeah, one, two, three. Okay, who are PlayStation? I call that even. Computers don't count. They run open source software, so forget about that. Our next speaker, Boris Lavin, will tell you a little bit more about hacking Sony PlayStation Blu-ray drives. Please welcome, with a very warm applause, Boris. Hello, everyone. So let's start. My name is Boris Lavin. I'm security search at Kaspersky. And at work, I'm doing reverse engineering. Currently, my main focus is to find the zero-dase exploited in the world. And I helped to report a few of them. All of them were used in attacks by cyber criminals and national state actors. I'm also an original discoverer of a few large supply chain attacks. Maybe you heard about our research, Operation Shadow Hammer. It was released early this year. But some people might also know me as Saktaksor. I was active in PlayStation 3, I've been redeveloping community since 2011. And back then, I was mostly known for my work on freeing the RAM protected, PlayStation 3 custom fee barriers, developing PlayStation 3 debugging tools, and et cetera. And today, I'm going to talk about my two favorite subjects, which are video game consoles and hacking. So in this presentation, I'm going to talk about re-recorded drives of Sony PlayStation 3 and Sony PlayStation 4. So games, they're distributed to optical media. So that's why drives should contain the best security possible. But it also makes it a very interesting subject for security research. And in this presentation, I'm going to discuss a process of obtaining and reverse engineering in the firmware. I will provide a depth analysis with vulnerabilities and the expectation to achieve code execution on the multiple models of Sony PlayStation 3 drives. And I will talk about security features that are present there. But before I continue with my talk, I need to give the following disclaimer. First of all, this research doesn't have nothing to do with my employer, and this research is done purely after curiosity and presented for educational purposes. This research doesn't anyhow help, support, enable, or endorse to break the copyright law. I will be talking about security vulnerabilities, but as far as I'm aware, they do not lead to full compromise of security, and it's not possible to use them to circumvent copy protection. And that's the reason why I'm even talking about that. So probably all of you are quite familiar with what Blu-ray disc is. Sony, they did extremely well with PlayStation 2. It was the very first game console that supported DVD discs, and people were buying it to watch DVD movies. And Sony, they wanted to repeat the XSS with the next game console, PlayStation 3. And it's really easy to understand that just by looking at the line of events. Like specifications were finalized and first commercial Blu-ray drives, they were released just a month prior to release of PlayStation 3. And actually Sony succeeded. Now even Xbox uses Blu-ray discs. And actually physical format of Blu-ray discs is very well documented in white papers and patterns. Those documents, they reveal what types of disc exists and what areas are present on discs and how these areas are different from each other and what structures are stored there. So if you're really interested in the subject, I recommend you to read these documents. But these documents, they do not reveal one simple thing, how PlayStation discs are verified. And it's kind of an interesting question, and I was always wondering about that. So my initial thought was that maybe Drive Invade may reveal some details about that. So let's talk about Blu-ray drives, PlayStation. And there have been a lot of them. If you unpack PlayStation 3 Invade update, you will find 12 different various for different drive models, which is a really huge number. And here you can see the first ever, PCB of the first ever Blu-ray drive for PlayStation 3. Design is quite complicated, but the minor microcontroller is produced by Sony. And well, after some time, Sony decided to simplify design of PCB and they switched to microcontroller of another company, GreenSauce. And here you can see PCB of the first Blu-ray drive with a renaissance microcontroller. And after that, Sony decided to switch between Sony microcontroller and renaissance microcontroller for each new drive model. Well, I actually don't know what they were thinking, but maybe they wanted to diversify this platform to make hacking much more harder. And Sony was much more consistent with the Blu-ray drives for PlayStation 4. If you unpack PlayStation 4 Invade update, you'll find things various for six different drive models. And all of them were based on renaissance microcontroller. And only recently, there was also a new addition to this family, it was a mid-detect microcontroller. So as you see, renaissance is the most common chip for Blu-ray drives across PlayStation 3 and PlayStation 4. And that's why it's the main subject of this talk. So first of all, how did they get the firmware in the first place? Actually, this technique came out from Xbox 360 scene, and here you can see a very famous picture of Kamikaze hack for Xbox 360 drive that was developed by a quite talented researcher, Jeremyia. And this hack, it abused fact that quite often firmware is stored on a flash chip that is a separate die-insider package. And this way, it's much more easier for manufacturer to produce such chips. But at the same time, it also makes it somehow easy to read flash contents with external tools if you are able to de-capsulate package. And here you can see de-capsulated package of renaissance microcontroller for PlayStation 3 drive. You can see that flash chip is also separate die, and it's located on the top of mine chip. So how are you able to dump firmware using this technique? So at first, you need to de-capsulate your package. That can be done with acid. Then you cut bond wires, for example, with laser, and then you need to rebound this virus to custom PCB, for example, with special wire-binding machine or with sealer-pend, and then you are able to read flash contents. And actually, all the steps, they were done not by me. They were done by more experienced researcher who had much more experience with this kind of stuff, and he also did quite similar things with the Xbox 360 drive. But it was a quite friendly researcher because he shared his dump with me and with a few other researchers from our community, just free of charge. And the only thing that I was needed to start Russian engineering was to find out what a heat texture it's compiled for. And I checked website of renaissance. They got a really huge list of different microcontrollers. And luckily, there was also some documents on this website that revealed that microcontrollers for Blu-ray drives and DD drives produced by renaissance are actually based on H8S architecture. And quite luckily, this architecture is supported by the Pro. So it was very easy to start reverse engineering. And here is a few more words about this architecture. It's a nice, risky architecture, but it reminds me X86 a little. It's really easy to work with. You can get three different compilers for it. And one fun thing is that each of them uses different combination and there is even differences in combination between different versions of HUE, which is official compiler for this architecture. It's all Barin's house. And so I began Russian engineering and I need to mention that it was a quite challenging task because it's a really large in size, almost two megabytes. And there are only 40 strings for the whole amount of data. And in case you are wondering how the developers were able to debug the thing where in this case, well, locked-race functionality exists, but it only takes an ID as an argument and then these IDs are converted to strings inside special service developer has. Most likely it was done this way due to size constraints, so basically no extra space on flash to store the strings. But maybe they were thinking about security, but it complicates reverse engineering. And the first thing that you want to do in such cases when you start to reverse engineer some new thing there is that you want to download as much stuff as you can from the website of hardware manufacturer. You want to get source quotes, you want to get libraries, you want to get compilers and you need all of that to make the process of reverse engineering much more easier. Like you might want to generate three signatures for Adobe Pro and you also need definitions, the structures of different hardware registers. And Rinsas, they provide a really huge stuff, a really huge list of stuff in the load. But essentially any DVD Blu-ray related stuff is not available publicly and it's really complicated as a whole project. I had to reverse engineer all of it. And Rinsas also provides dozens of different real-time processing system. So some are available in the load, you can get them. And also official compiler is available in the load, so you get a compiler that was likely used to compile firmware we are going to analyze. And when I was looking through the files of QCompiler, I was not able to find any sources of libraries because it appeared that all of them are stored inside special packages and only necessary files unpacked during compilation. But what I did was just, I found out where this algorithm is located and I wrote my own utility to unpack all these files. And I was not able to find any useful information about hardware there, but it was possible to generate IDAPRO-Flick signatures. And many of these functions that were used by firmware that I've got, and it was a really useful finding. And the next step that I would usually do when analyzing a new firmware is that I try to find out functions of real-time processing system. It's a really important thing to do because control flow and data, it might be passed between different tasks that are running at the same time. And you really need to follow that during real-time engineering. So I got many real-time processing systems from the website of Renaissance and all of them were kind of similar, but still had some differences. And in most of the cases, they were written in assembly for different architectures. So in the end, nothing really closely matched the real-time processing system that was used in PlayStation firmware. So in the end, it was not useful. But the best thing about reverse engineering in firmware developed by Japanese company is that it most likely will follow micro-industrial-trans specification. And this specification, it's a real life saver because it defines name of the functions, the arguments, and et cetera. There are more than 300 pages and it simplifies reverse engineering a lot. And the next step that I would usually do is that I try to understand how I can communicate with my target and what logic I am able to interact with. And Blu-ray disk drive it communicates through ETA protocol and here provide hierarchy of ETA protocols. So at the bottom, we have physical interfaces. We have PETA that was previously known as just ETA or EDE. It's an absolute version of this protocol. And then we also have a SATA. And on top of that, we have two distinct command sets. We have a TA command set. It's used for hard disk drives. And we have an ATAPI command set. It's used in all other cases. And basically it's just a transfer for SCSI commands. And different devices, they may have different command sets because we have a primary command set which is common for all devices. And then we have device specific command sets. And for optical disk drives, we even have two competing specifications. And you need to be aware of that when you reverse engineering such thing various. So primary command set, it implements inquiry command and it provides some basic information about hardware like name of the vendor, name of the product. It's basically what you're going to see if you connect such device to a computer. So what you do, you just look for such strings inside firmware and you will find a handler of SCSI commands. And then you're good to go from there. You just get specification and reverse engineer some commands that looks interesting for you. So basically this is a roadmap that I usually try to follow when reverse engineering some new firmware. And it will be also awesome if we had a way to relate our firmware because this way we can analyze it much more better and also getting code execution will be nice because we can actually do some experiments and it also helps to analyze hardware and firmware. And GDB, it actually provides a simulator for this architecture. So you can compile it, convert firmware to the L file and then you're good to go. You can debug some snippets of code. But I actually like using IDA Pro as debugger UI but it has some flaws of course. So first of all, GDB debugger plugin that comes with IDA, it's closed source. And recently he expressed improved it a lot but back then it was quite buggy and it supported only a few targets. And of course, this architecture was not in the list. So at some point I decided to write my oven, GDB debugger plugin to work with IDA Pro and actually it was a quite good decision because it didn't took too much time to make but it saved a lot of time while debugging this firmware and some other firmware. For example, GDB support for X64 targets was added only in IDA Pro 6.9 and it was not that long ago. And here's just a screenshot of how it looks like. I leave it just for the reference. So actually while I was a reverse engineering firmware of PlayStation, I was a reverse engineering multiple of the various because it appeared that there exists some Blu-ray drives for PC that had a microcontroller produced by Rinsas and they were produced by Hitachi-LG data storage. And you can get not encrypted firmware from firmware update utility. And I compared these two firmware. It's clear that the PC firmware and PlayStation firmware are very different but they're built using the same SDK. I can tell that because many Blu-ray hardware-related functions are the same. All peripheral devices are located at the same addresses and assessed exactly the same. PC firmware uses the same geographic processor and PC firmware also contains a little bit more debug strings. It kind of reveals the name of this Rinsas platform for Blu-ray disk drives. It's called Indigo 3 internally. So at previous slide, I mentioned the cryptographic processor. So when I began reverse engineering firmware of PlayStation, I found out that a really huge part of it is supplied by cryptrelated functions. And these cryptrelated functions, they are used for communication with a dedicated cryptographic processor. And it's effectively protects all the secret. So you are not able to just dump firmware and reverse engineer all of it. Cryptographic processor protects it. And the communication process is really complicated and obscure. Here provides some graphs of such cryptrelated functions. And actually for me, it's much more easy to reverse LLM-abuscated binary GM understand logic of such functions. And here provide a small snippet of one of such functions. And it's clear that cryptographic processor runs some kind of firmware and you are able to load additional models and additional keys. And what I wanted to do, I just wanted to play with this cryptographic processor. I just wanted to try to change some of these values to see what happens. But you need code execution of that. And now it comes the time to talk about code execution and how it was achieved. So early this year, I gave a presentation at ConceqVest titled Hacking Micron Trollifium Virus to USB. You can find more details by the following link. But in that research examined how awesome is the USB protocol for exploitation. And I believe that SCSI protocol might be even more awesome, but it's less common for sure. So how does it work? Our clients sends a common descriptor block to device. I will call it just a command. And such commands usually device supports a lot of them and they can be used to transfer data from and into device. And device also provides status of command and also provides error code. And quite often such commands, they have such parameters as size of the data in some logical block address. So all of that makes this protocol perfect for target for fuzzing, I believe. But I actually found my vulnerabilities through static analysis. So it seems that firmware itself was developed by some third party company. And then when it was ready, it was handed to Sonya to add console specific stuff. And I can tell that because all general SCSI commands, they are looking kind of fine, but no command supplemented by Sonya. They doesn't seem to have boundary checks. Like one of the samples of vulnerable commands has operation code E1. And this command is used for notification or Blu-ray drive in video game console. So the main target of it is to implement security. But it has auto-borne to write in because transfer lens is not checked. So we are able to write this buffer that's like it's somewhere over here, but what memory does it belong? So to find out this answer, let's take a look at memory map that I was able to come up with while reverse engineering firmware of PlayStation. So at first we have no more auto-memory. We have a ROM with bootloader, we have flash with mining firmware. Then we have auto-memory, we have SRAM and DRAM. And it's clear that address that we are able to write is belongs to DRAM. And we also have registers of peripheral devices. So let's start with SRAM. It's a static condom and SAS memory. It's small in size, it's executable, but it's configurable. And it contains interrupt vector table, it contains code of real-time pressure system, it contains some important variables, pointers, structures, and it also contains stacks of tasks. And we also have the DRAM, which is dynamic condom SAS memory. It's large in size, 8 megabytes to be precise. And initially exact memory location was unknown because most of the time it's accessed through direct memory access. And it contains data from disk, it contains data from SSI client, and it also contains data that do not fit SRAM. Because SRAM is really small and firmware is really huge. It needs a lot of space to store its variables. So why to not store them in DRAM? And actually one of such regions is used only for that. Store variables that do not fit to SRAM. And I also found out about existence of another region. It's actually unused in PlayStation firmware, but I found out that it exists from firmware of Hitachi LG data storage drive. So we are able to write some data that is located inside this buffer. How to exploit that? And well, exploitation should now be very difficult because all variables, they are located as static addresses and the heap exploitation techniques, they are not working there. And at first you need to find a very good exploitation primitive and you might need to overwrite a lot of different data upon reaching this primitive and you need to do that without crashing the device. And I need to mention that debugging is complicated. We are not able to debug it on real hardware. So we need to relate, understand a really large portions within there. So in the end, I ended up reverse engineering all functions that access data in this region. And there are no virtual function pointers, so there are no good candidates for your right. And there are a lot of buffer structures variables. Pointers exist, but there are not too much of them. But eventually I was able to find the good exploitation primitive. And I started to help exploit. But actually I was never, I never finished this exploit because while writing it, I was able to find a new source for vulnerabilities. So GSP registers are very interesting. They are responsible for the most of this drive related functionality. Like a tap interface, laser, servo, disk data demodulation, GSP framework loading, and et cetera. It will be so nice if we had access to it. And actually we do, like the whole area of GSP region is available for reading write through special SSI commands. And those SSI commands exist for doing just that. And here they are. It's actually a read buffer and write buffer commands with special parameters. And it seems that these functions are part of standard diagnostic functionality because exactly same functions are also available in Hittachilji data storage from there. So do you remember when I said that DRAM is accessed mostly through DMA? Several registers available in GSP area are responsible for copied data from and into DRAM and mapping DRAM offsets to some memory addresses. So it appeared that these regions that are used to store firmware data, they are actually mapped using these registers available in GSP region. And we have access to them with SSI commands. So here explain how does it work? We have four groups of memory mapping registers and two groups are set like short on this slide. And I do not show others too because they're set frequently by different functions. They're set to different functions, by two different values. But these two are utilized earlier during startup and they're set to these specific values and not touched after that. And each group of these registers they map specific amount of data from DRAM offset to some predefined memory address. And here also can see to which memory addresses which offsets are mapped. And DRAM offset is calculated like this. Value of region register, it's multiplied by 4,000 in hex. And then this value is added to either first half or second half of DRAM depending on the bid that is set. But that's not all. We have specially dedicated registers that allow us to read and write double what to any offset of DRAM. And here provide offset code for doing just that. So we have access to DRAM registers with SSI commands. Are we able to manipulate contents of DRAM? There are multiple ways of achieving this. For example, we are able to remap this special region to some another DRAM offset and we can write, we can use our exploit to write some data that will be not reachable otherwise. But it may lead to a different behavior and I will need to mention again that debugging is really complicated. And we also are able to use DRAM registers to write our data directory. But actually it's not true because these registers they are in use by firmware. And if we will try to do something it will lead to different behavior as well. But still I was believing that I may exploit that and I only needed a way to test my ideas on a real hardware. And there are two ways of doing that. First of all, you are able to jailbreak your console. You can install Linux on it, thanks to fail or flow and you can communicate it to B-ray drive. Another option you can disconnect your B-ray drive from console and connect it to PC. And I decided to go with the second route because it's much more convenient and likely it was possible to buy a ready made solution for Jew doing just that. I actually wanted to test my ideas on PlayStation 4 drive because PlayStation 3 drive and PlayStation 4 drive they are very the same. They just using different FFC connectors. But different is not that big because I was able to modify FFC cable of PlayStation 4 with scissors and it worked with public solution for PlayStation 3 drive. So this is basically how my the whole hacking setup look like and it's drive of PlayStation 4 was away. So the first thing that I did was to dump the whole display region and it was quite surprise but address of DMI request and value of DMI request they were set to zeros and it will indicate only one of two things. It's either inside my model had our revision that I've got DMI registers are not present at all or they are just unused. And they were just unused. So in new models Sony accidentally stop to use DMI to access DRAM they started to use absolute memory addresses and it grants us a full read write access to the whole drum. Yeah. So doing cool stuff with full access to DRAM. Usually DRAM is full of this data but when there is no disk inside there are a lot of unused space and this space is used to store firmware during system update and the procedure of Blu-ray drive firmware update for PS3 is well documented. You can find it on our wiki and this procedure exactly the same between PlayStation 3 and PlayStation 4. But here I try to explain how it looks like from the site of Blu-ray drive. So at first block is often very received with a bright buffer command. And firmware checks. Is it a first block? If it's a case then it will initiate a special structure and we'll store this block to DRAM. And then it checks if all blocks are received. If all blocks are received then it will try to re-date the hash. And if hash is correct it will start to decrypt firmware. But this process of decrypting firmware it may take some time. And how this logic was intended to work is video game console should send a test unit re-decomment to check if firmware was already decrypted. And there is a special logic inside that checks if it was decrypted then it will copy firmware update code to SRAM and executes it. So do we see a problem here? Well basically it's time of check to time of user vulnerability because when it starts to decrypt firmware what we are able to do? We are able just to send our firmware to Blu-ray drive wait until it's been decrypted and when it will be decrypted we are able to use our DMA trick to just dump the whole DRAM. And we also able to modify firmware image after validation and we also able to change some structure to that I stored there. So at the first I had only firmware for this particular drive hardware revision. But I've got this one and then I've got this one and this one and it's PlayStation 4 the way and I've got even more. So on this stage manipulation of firmware image to get execution is trivial and all update structures are stored in DRAM it's basically a hint for those who want to repeat my steps at home. And when you exploit such devices usually you need to be extremely careful because this device it has internal memory if you corrupt something there you will turn your device into brick so you will have to spend a lot of money to buy just new device and do your experiments all over again. But actually in this case I need to mention that a special mini firmware exists it called emergency boot and while during boot it would load the checks if your main firmware has a valid hash and if it's not the case then this special firmware will be executed so you will be still be able to unbrick your device. So why did it happen? Most likely scenario is that when firmware was handed to Sony to add console specific stuff engineers didn't really understood functionality that is available through dispute registers. And CSE commands to read and write dispute registers they were left for diagnostic proposals for sure but security risks represented by free use of dispute registers they were not really considerate. So with code execution I was able to do some experiments like community always wondered what is this mastery block data that Sony puts to disk when it's processed at factory because algorithm to decrypt it was nowhere to be found and I was able to decrypt it and actually there are nothing interesting inside here you can see final fantasy 15 four plus four and at first there are just 16 random bytes it's just a padding they're not used anyhow and then just a few flags to set some drive identification states. And for me it was also interesting to see how disks are obtained because this information should be somehow related to the way how disks are verified. And for past three there are two disk keys one is used for decryption of disk data and another one is used for encryption of saved data and all of this is about the same for past four. And I found out that disk keys are returned from cryptography processor but it happens only in case of drive identification. So initially I was thinking that this logic to read and construct disk keys should be located there inside cryptographic processor. So here are a few more words about drive identification. So the drive identification and drive cryptographic processor it's the main things behind optical disk drive security of Sony PlayStation. And drive identification is secure and performed with peer console keys and I know only two ways to obtain those keys. You either need to have cryptographic processor with your game console it's called a spool for past three or some of past four or you need to have cryptographic processor of the radar drive and it's very hard to achieve such hacks. So security model is very effective against widespread parsing. Much more simple ways to park games always exist. For example, if you have mine from very off PlayStation you can park games but if you have from very off PlayStation drive you can't park games. And I was thinking how to better illustrate the security model and it's the best was what I was able to come up with. So imagine we have two floating islands and it's actually thin varies. And those thin varies they support white castles and these white castles are cryptographic processors. And please take a notice that there are no entrances to those castles. So you are not allowed to get in from thin ware. But there is also secure communication happens between these castles. Well, it was the best that I was able to come up with. And like if you have thin ware of video game console you are able to bypass the secure communication. You just take this data that comes out of it and you just run it on your console. You saw you powered games. But if you have thin ware of the radar drive you are not able to put your data in the secure communication. You are not able to send this key. So you are not able to power it. And I also was able to play with cryptographic processor. It was initially, it was the reason why I needed code execution. And I did some experiments. I was able to load cryptic firmware of PlayStation 3 drive to PlayStation 4 drive. And PlayStation 4 drive, the cryptographic processor started to behave exactly like it should on PlayStation 3. Even some of sets of some cryptographic registers they have changed. So it proves my idea that it runs some kind of firmware. And as I mentioned, that communication process is quite complicated. And I wanted to try to change some values. So I wrote a specially created vasa to flip some bits of these values that are set to registers. And it was completely useless. Because if you change any of such values, cryptographic processor returns error. And after a few errors, cryptographic processor hangs and you need to reset the device. So allegedly, I think that logic of such cryptographic functions, it works like this. At first, you provide some seed of the hash. Then you provide commands. Then you provide data and keys. You provide hash to verify the commands. And in the end, these commands, they are verified and executed. And I played a little bit more with cryptographic processor. But eventually, I lost interest. Because breaking copy protection was never good. And more reverse engineering, it revealed that most likely, cryptographic processor exists only for doing crypto stuff. And there exists a specially dedicated component that verifies disks. But most likely, it's performed purely in hardware. I was able to find out about that with the help of the first ever PlayStation 3 retail drive. So it has a few components. But the main components are these two. It's a main migranator, produced by Sony. It has ARM, it's a pull. And we also have one megabyte on NorthLash with firmware by Spencer. So one megabyte NorthLash with firmware. So actually, firmware is executed from external flash. And that is the crypton fly. And of course, encryption algorithm is based on XOR. So we have some XOR team of specific size. But firmware is much more larger. And what we do, we do what we always do in such cases. We just look for some space in firmware filled by zeros. And we are able to partially recover XOR stream. And now it can be used to encrypt or decrypt some pieces of firmware. Not all of that, but some pieces. So I mentioned that code executed from external flash. But integrity of firmware is checked at boot. So it seems like we are not able to do something with that, right? Well, actually no. Because we are able to observe all memory accesses and reads from typo to external flash with logic analyzer. We are able to modify these accesses with FPGA. And we can write small payloads that encrypts. We can encrypt it with recovery XOR stream. And we can modify some memory accesses from typo after firmware is verified to execute this small payload. So with our upload, we can read, plan text, and leak it. So we get code execution and firmware damp. And this firmware was quite interesting. Because unlike Rinses firmware, it contains a lot of debug strings. It even has a special serial monitor with huge list of commands. And some of these commands are looking interesting. You see peak, dump, poke, and there are much more. But you need some special password to access it. I need to mention that. Also, CryptoProcessor is a very different from the ones that was used in Rinses. It's also much more simple. You just set keys, data, size of data, to some specific of sets in CryptoRegion. And then you initiate operation. And if you try to read this CryptoRegion from the flash, you will be not able to do that. You will get only garbage to CPU registers. It was intended to work like you need to use special functions that are present in the bootloader to offset only specific offsets inside this CryptoRegion. But of course, you can bypass it with the RetroNet programming. And also, all these functions, they have integral overflows. So this check, I think it's useless. You are able to read the whole CryptoRegion anyway. And if you do that, there will be one interesting string at the start, others of this CryptoRegion. And it should be not possible to read it otherwise. And Sony, Microcontroller, and Rinses, Microcontroller, they are completely different systems. And it means that all peripheral devices should be different, and they should be assessed differently. But I found out one peripheral device that assessed exactly the same. So it means that one particular peripheral device is exactly the same in both, in different hardware, such as Sony and Rinses, Microcontrollers. There are only different differences in addresses. In Sony, Microcontroller, those registers are located inside special region. And in Rinses, they are assessed through Indigo DSP registers. So I believe this peripheral device is actually a deep security component. And it performs some interesting things, like it simulaculate CRC of disk title, source it with a string Nokia, and puts it into registers of this device. And if you modify it, then cryptographic processor will not be able to return this key. So I know one part of disk verify process, but find out the rest will be a really challenging task if it implemented thrilling hardware. And one more fun fact, Nokia is short for Inoki, which is a very tasty mushroom in Japanese cuisine. So let's make a conclusion. I think that Sony and partners, they did exceptional work. Security mental is really good and has proven itself. Imagine our PlayStation 2 Redrives, they existed since 2006, but no public hacks since then. But many have tried according to rumors. So here is one lesson that we also can learn from this example. Fever can be hacked. So put all your signatures to hardware. In this case, guys like me, they will have some problems reverse engineering it. And also I believe that cryptographic processor might be an interesting real-world target if you're interglitching and such an analysis. But it will be a tough one, I believe. And I want to give my respects to everyone who also ever worked on this subject of hacking PlayStation 2 Redrives. And I want to say thank you, Nokia. This research will be not possible without you. And here's a few more words about responsible disclosure. So on November 2008, a security team at Sony Interactive Entertainment reached out to me and said, we saw your presentation. You're going to talk about it at CCC. Can you give us some information about that? Well, yeah, sure. I provided information regarding my vulnerabilities. And it was quite a surprise what happened next. It was totally not expected. But the security team invited me to join a recently launched bug volunteer. And they trashed all my vulnerabilities. They told me that it's high and two medium severity bugs. And they told me that it's not critical in no way. And all my abilities were fixed in the latest system saturation that come out just 10, 9 days ago. So it seems that I have become a first researcher who won a bounty of HLB. So please stay tuned. Sony is about to announce something really awesome. I'm sure that all of you are going to like that. And actually, I had a very pleasant experience with working with them. And I can recommend you to that in the future. So all my slides, they will be uploaded by the following link. And I want to say thank you. Thank you very much, Boris Lain. If you have questions, you know how it works. Ah, the interwebs has questions already. There are microphones. Microphones 1, 2, 7, and 2, 2, 8. Please make a perfect row, and we will queue you. So the interwebs, first question. The interwebs is asking, is the USB to SATA adapter just a common chipset with a FFC connector? Yep, that's the case. So just some common parts that you are able to get. And you can solder it yourself. But for me, it was convenient to just buy one because it was freely available. Short answer. Microphone number one, please. So I think there are some third party drive emulation hardware available in the market. Do you know something about it? Have you hacked something? Or is it not secured from that way that you can replace the hardware with your own basically emulation device? So like I mentioned, for doing that, you need a way to bypass this secure communication. And for doing that, this secure communication is secure. You need to get per console keys. And to get those keys, it's a really challenging task. Maybe you remember the presentation of fellow overflow. Like many years ago, when they were able to break a spool. We have not seen something like that for SAMU, which is a cryptographic processor of PS4. But still, even for PS3, Sony, they were able to fix these bugs. And in newer hardware revisions, there were no such bugs. And that's why it's a challenging task to make some hardware emulation devices. That's all because per console keys are used. Thank you very much. And microphone number seven, I think. Is the Sony MCU some sort of a derivative of Toshiba MCUs, the Toshiba ARM MCUs like in the PS Vita? Or is it something else? Actually, I don't know. I have spent the most of my research on looking at arena stuff. And I actually never had a chance to take a look at Toshiba PSP stuff. So I actually am not able to tell you for sure. OK, thanks. Microphone number two, please. Have you looked at how the drive verifies whenever a disk is a real PS3 or PS4 disk from the manufacturer? Or is it just a home-burned disk? So yeah, it actually was present in my presentation. So I believe that a specially dedicated component exists. And disks, they are verified by this component. And this logic, it implemented by hardware. And I know that some parts exist, like to set some data from software, like this one where it calculates seriously of disk title and source it with some magic value. I'm sure that this is part of disk verify process. But the rest of the magic, it's unknown, because it is hardware. You need to reverse engineer this. Yeah, and this kind of hard. OK, thanks. The internet. The internet has a more complex question for you. Why is there more interest in hacking PS3 or 4 than Xbox? Maybe because there's no need to privacy, because every Xbox game is a Windows game? No, well, you know, people like PlayStation because they got exclusives, right? And also, Xbox security is kind of very good. I mean, I actually believe it's better than the PlayStation security. Some of my friends had experience with it. And it's really painful to work with that. Because, well, Microsoft, they protect your computers. So they protect your computers. And they have technologies that they can use to protect their intellectual property. And they also add some special stuff, like some new techniques, some novel ideas. And they use all of that to make hacking even much more harder than to hack a computer. Thank you for that. And as far as I can see, and no one is shaking and waving hands, we have no more questions left. Please, with a very warm applause, Boris Lein. Thank you.