Hacking Sony PlayStation Blu-ray Drives
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 254 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/53207 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
36C3: Resource Exhaustion42 / 254
1
7
8
9
10
11
24
26
27
28
35
39
40
41
43
44
47
49
50
55
56
60
62
63
64
68
71
72
74
75
77
78
79
82
88
93
99
100
102
106
109
111
112
113
118
119
122
124
125
127
132
133
135
136
137
138
140
141
142
143
144
145
146
150
151
156
157
158
161
162
164
165
166
167
170
173
175
177
179
180
182
183
187
201
202
208
213
219
224
226
233
234
235
237
239
240
241
244
246
247
249
251
253
00:00
QuantenzustandPlayStationSoftwareBitComputerOpen SourceZählenSystemaufrufPlayStationBlu-Ray-DiscComputeranimationVorlesung/Konferenz
00:52
SinusfunktionSpielkonsoleReverse EngineeringKette <Mathematik>ComputervirusVarianzMailboxDemoszene <Programmierung>Digital Rights ManagementFokalpunktComputersicherheitGruppenoperationKette <Mathematik>FastringNichtlinearer OperatorÜberlagerung <Mathematik>AggregatzustandSoftwareentwicklerLesen <Datenverarbeitung>BitrateWorkstation <Musikinstrument>OrtsoperatorAusnahmebehandlungVorlesung/KonferenzComputeranimation
01:42
ModelltheoriePlayStationFirmwareProzess <Informatik>Reverse EngineeringCoxeter-GruppeComputersicherheitHypermediaTechnische OptikSpieltheorieMaschinencodeAnalysisKontrollstrukturPrototypingDigitalsignalKanalkapazitätSoftwareentwicklerDateiformatInformationsspeicherungTypentheorieInformationFlächeninhaltNormalvektorSeitenkanalattackeHardwareVersionsverwaltungMaß <Mathematik>Interface <Schaltung>Blu-Ray-DiscFlächeninhaltUmwandlungsenthalpieReverse EngineeringTypentheorieDifferenteDVD-VideoComputersicherheitDatenstrukturEndliche ModelltheorieMultiplikationCodeDateiformatPhysikalismusHypermediaGesetz <Physik>WellenlehreSpieltheorieMikrocontrollerEreignishorizontSoftwareschwachstelleSpielkonsoleComputerspielProzess <Informatik>PlayStationExploitAnalysisFirmwareBenutzerschnittstellenverwaltungssystemErwartungswertData MiningHilfesystemBildschirmmaskeMenütechnikOrtsoperatorKontrollstrukturHochdruckCoxeter-GruppeInformationsspeicherungWorkstation <Musikinstrument>MinimumSingularität <Mathematik>RichtungGamecontrollerNummerungComputeranimation
04:39
VersionsverwaltungHauptplatineModelltheorieInterface <Schaltung>FirmwareDemoszene <Programmierung>Flash-SpeicherAtomarität <Informatik>Formation <Mathematik>BootenComputerarchitekturBefehlsprozessorProdukt <Mathematik>Varietät <Mathematik>BetragsflächeBlu-Ray-DiscMultiplikationsoperatorGewicht <Ausgleichsrechnung>GamecontrollerInhalt <Mathematik>MultigraphResultanteDienst <Informatik>DifferenteWorkstation <Musikinstrument>AdditionSystemplattformOrtsoperatorOrdnung <Mathematik>Virtuelle MaschineBridge <Kommunikationstechnik>GradientWeb SiteFamilie <Mathematik>Textur-MappingModelltheorieDivergente ReiheEndliche ModelltheorieGreen-FunktionMikrocontrollerData MiningFlash-SpeicherComputerarchitekturSpeicherabzugBrowserBimodulÄhnlichkeitsgeometrieFirmwareMailing-ListeSchnitt <Mathematik>Atomarität <Informatik>Lesen <Datenverarbeitung>Computeranimation
07:49
HardwareComputerarchitekturZeiger <Informatik>Übersetzer <Informatik>CompilerVersionsverwaltungFirmwareFunktion <Mathematik>Message-PassingZeichenketteMaschinencodeSoftwareentwicklerGanze ZahlAnalog-Digital-UmsetzerSoftwareFlash-SpeicherReverse EngineeringDatenstrukturWeb SiteQuellcodeProzess <Informatik>Produkt <Mathematik>ProgrammbibliothekElektronische PublikationTuring-TestAlgorithmusAggregatzustandModul <Datentyp>Mailing-ListeInformationKrümmungsmaßDivisionOperations ResearchPhysikalisches SystemEchtzeitsystemKontrollstrukturTaskÄhnlichkeitsgeometrieArchitektur <Informatik>Web-SeiteParallele SchnittstelleSCSISchnittmengeSerielle SchnittstelleTechnische OptikMultimediaProtokoll <Datenverarbeitungssystem>Hierarchische StrukturInterface <Schaltung>Blu-Ray-DiscStereometrieNP-hartes ProblemClientWärmeausdehnungFestplatteWort <Informatik>KonditionszahlDifferenteVersionsverwaltungCompilerEinsDivergente ReiheTaskPhysikalisches SystemFunktionalanalysisMinkowski-MetrikInformationsspeicherungMathematische LogikProgrammbibliothekWeb-SeiteCASE <Informatik>Elektronische PublikationProjektive EbeneGruppenoperationSoftwareentwicklerMagnetbandkassetteComputerInformationIntelligentes NetzMultiplikationsoperatorQuellcodeDienst <Informatik>Sampler <Musikinstrument>ZeichenketteTransportproblemEchtzeitsystemParametersystemKontrollstrukturBlu-Ray-DiscProdukt <Mathematik>MenütechnikProtokoll <Datenverarbeitungssystem>OrtsoperatorReelle ZahlEINKAUF <Programm>Textur-MappingReverse EngineeringQuellencodierungFigurierte ZahlElektronische UnterschriftHierarchische StrukturVariableService providerWeb SiteEindringerkennungSCSIUmwandlungsenthalpieComputerarchitekturFirmwareHardwareLastFlash-SpeicherDatenstrukturSoftwareFestplatteMailing-ListeModallogikBenutzeroberflächeAlgorithmusSchnittmengeAblaufverfolgungWärmeübergangProzess <Informatik>SystemprogrammComputeranimation
13:25
BefehlsprozessorComputerarchitekturFirmwareInformationHardwareMathematische LogikReverse EngineeringZeichenketteDatenstrukturAdressraumHydrostatikAnalysisEmulatorMaschinencodeProgrammbibliothekStandardabweichungSimulationKonfigurationsraumDebuggingGraphische BenutzeroberflächeQuellcodeQuantenzustandPlug inFirmwareReverse EngineeringHardwareCodeForcingPunktGoogolProzess <Informatik>EntscheidungstheorieQuellcodeComputersimulationDatenflussMultiplikationsoperatorTextur-MappingSechseckDebuggingPlug inMailing-ListeComputerarchitekturComputeranimation
14:45
FirmwareGruppenoperationEmulatorWechselsprungProzess <Informatik>BildschirmfensterReverse EngineeringInformationsspeicherungSystemprogrammChiffrierungSoftware Development KitHardwareAdressraumCoprozessorZeichenketteStichprobeMereologieKryptologieOperations ResearchTelekommunikationFunktion <Mathematik>Ideal <Mathematik>MaschinencodeMaßerweiterungSchlüsselverwaltungModul <Datentyp>Patch <Software>ROM <Informatik>Innerer PunktProzess <Informatik>SchlüsselverwaltungInformationsspeicherungAdressraumFunktionalanalysisEntscheidungstheorieGamecontrollerKonditionszahlGRASS <Programm>OrtsoperatorEndliche ModelltheorieVerband <Mathematik>ZeichenketteKraftTelekommunikationFunktionentheorieAdditionSystemprogrammBlu-Ray-DiscSystemplattformSondierungInverser LimesMultiplikationReverse EngineeringLastBitMultigraphFirmwareMereologieCoprozessorWorkstation <Musikinstrument>CodePeripheres GerätMultiplikationsoperatorMikrocontrollerSpeicherabzugComputeranimation
17:05
Datenfeldp-BlockFirmwareCoxeter-GruppeComputerKontrollstrukturProtokoll <Datenverarbeitungssystem>WärmeübergangSCSIClientMaschinencodeExogene VariableOffene MengeBefehlscodeSoftwareentwicklerUmwandlungsenthalpieSpielkonsoleAuthentifikationAdressraumStichprobeComputersicherheitBefehlsprozessorROM <Informatik>Flash-SpeicherKryptologieInterrupt <Informatik>Operations ResearchPhysikalisches SystemZeiger <Informatik>VariableTaskRAMDynamisches RAMStatisches RAMGerichtete MengeInformationsspeicherungPufferüberlaufPrimitive <Informatik>Reverse EngineeringVirtuelle RealitätFunktion <Mathematik>DatenstrukturSignalprozessorInterface <Schaltung>SeitenkanalattackeFlächeninhaltStandardabweichungMereologieFunktionalanalysisExploitTypentheorieGüte der AnpassungPuffer <Netzplantechnik>Blu-Ray-DiscAdressraumDifferenteSchreiben <Datenverarbeitung>Lesen <Datenverarbeitung>Dynamisches RAMExistenzsatzBootenEchtzeitsystemImplementierungZeiger <Informatik>TabelleBenutzerfreundlichkeitFitnessfunktionSpeicherverwaltungFlash-SpeicherHalbleiterspeicherSoftwareschwachstelleInformationsspeicherungQuellcodePrimitive <Informatik>SpeicheradressePeripheres GerätPerfekte GruppeFirmwareMinkowski-MetrikVariableDickep-BlockVirtualisierungWärmeübergangStatisches RAMNichtlinearer OperatorHydrostatikReverse EngineeringProtokoll <Datenverarbeitungssystem>ParametersystemMereologieFehlererkennungHackerComputervirusVerschlingungCoxeter-GruppeMathematische LogikDialektHardwareStandardabweichungPhysikalisches SystemTaskClientCodeAnalysisVirtuelle AdresseSpielkonsoleRelativitätstheorieGemeinsamer SpeicherKeller <Informatik>OrtsoperatorRechter WinkelEndliche ModelltheorieComputersicherheitFlächeninhaltInterface <Schaltung>Arithmetische FolgeDatenstrukturReelle ZahlStreaming <Kommunikationstechnik>MultiplikationsoperatorWeb logArithmetisches MittelVerzerrungstensorAeroelastizitätNummerungURLStichprobenumfangMetropolitan area networkSystemaufrufComputeranimation
22:40
ROM <Informatik>Gerichtete MengeSpeicherverwaltungFlächeninhaltFirmwareAdressraumSignalprozessorGruppenoperationTuring-TestMultipliziererLesen <Datenverarbeitung>Schreiben <Datenverarbeitung>SCSIHardwareInstallation <Informatik>SpielkonsoleEinfach zusammenhängender RaumSchnittmengeWort <Informatik>RichtungReelle ZahlSpeicheradresseInhalt <Mathematik>Virtuelle AdresseZweiDynamisches RAMHardwareFirmwareCodeGruppenoperationInstallation <Informatik>DialektSpielkonsoleDifferenteHackerBitFunktionalanalysisFlächeninhaltGrenzschichtablösungUmwandlungsenthalpieRechter WinkelEinfügungsdämpfungDrall <Mathematik>InformationsspeicherungMAPWeb SiteDatensatzKonfiguration <Informatik>QuellcodeOrtsoperatorSchwebungSechseckARM <Computerarchitektur>Computeranimation
26:15
AdressraumSpeicherverwaltungSignalprozessorROM <Informatik>Betrag <Mathematik>ModelltheorieTuring-TestFirmwareMaschinencodeDatenstrukturp-BlockUniformer RaumSoftwaretestChiffrierungSchreiben <Datenverarbeitung>Orakel <Informatik>VersionsverwaltungAdressraumDivisionRechter WinkelEndliche ModelltheorieMinkowski-MetrikMultiplikationsoperatorInformationsspeicherungSoftwaretestHardwareFirmwareSpeicheradresseBenutzerfreundlichkeitp-BlockBlu-Ray-DiscDynamisches RAMBetrag <Mathematik>Physikalisches SystemAlgorithmische ProgrammierspracheHash-AlgorithmusWeb SiteBildgebendes VerfahrenDatenstrukturPuffer <Netzplantechnik>Mathematische LogikWikiProzess <Informatik>SpielkonsoleGewicht <Ausgleichsrechnung>ParametersystemSchlussregelMAPProjektive EbeneForcingBitARM <Computerarchitektur>VariableCASE <Informatik>Technische ZeichnungXMLFlussdiagramm
29:27
MaschinencodeSpezialrechnerMAPFirmwareDatenstrukturKonfiguration <Informatik>BootenHash-AlgorithmusFirmwareBildgebendes VerfahrenDatenstrukturDynamisches RAMHalbleiterspeicherSchlüsselverwaltungCASE <Informatik>DimensionsanalyseGüte der AnpassungValiditätBootenEDV-BeratungComputeranimationVorlesung/Konferenz
30:22
SignalprozessorFirmwareFunktion <Mathematik>SCSIFreewareChiffrierungMaschinencodeFaktor <Algebra>SchlüsselverwaltungInformationCoprozessorAuthentifikationKryptologieComputersicherheitHackerSpielkonsoleSoftwarepiraterieModelltheorieNP-hartes ProblemExistenzsatzSpieltheorieBimodulSchreiben <Datenverarbeitung>ComputersicherheitFirmwareFreewareFunktionalanalysisGamecontrollerUmwandlungsenthalpieDivergente ReiheGruppenoperationRichtungOrtsoperatorTopologieSystemidentifikationGüte der AnpassungBlu-Ray-DiscProgrammierungKonditionszahlAggregatzustandProzess <Informatik>ModelltheorieVariableFaktor <Algebra>SpieltheorieTelekommunikationInformationBildschirmmaskeArithmetische FolgeRechter WinkelMathematische LogikCASE <Informatik>Workstation <Musikinstrument>Hackerp-BlockCoprozessorMereologieSchlüsselverwaltungDämpfungSyntaktische AnalyseBrennen <Datenverarbeitung>KryptologieSpielkonsoleWort <Informatik>ChiffrierungCodePlayStationFahne <Mathematik>AlgorithmusComputeranimation
33:35
FirmwareSpielkonsoleComputersicherheitModelltheorieTelekommunikationCoprozessorKryptologieMathematikMaschinencodeLastService providerHash-AlgorithmusSchlüsselverwaltungMathematische LogikProgrammverifikationInnerer PunktReverse EngineeringHardwareMereologieProzess <Informatik>CoprozessorSpielkonsoleHash-AlgorithmusMereologieMathematische LogikTelekommunikationSchlüsselverwaltungKryptologieBitProgrammverifikationComputerspielLastHardwareCodeSpieltheorieData MiningSchwebungOrtsoperatorFehlermeldungFunktionentheorieVideokonferenzZusammenhängender GraphSchießverfahrenKugelkappeRechter WinkelFunktionalanalysisMathematikSchnittmengeComputeranimation
35:50
FirmwareARM <Computerarchitektur>ChiffrierungAlgorithmusDisjunktion <Logik>Flash-SpeicherHilfesystemFlash-SpeicherFirmwareARM <Computerarchitektur>Zusammenhängender GraphChiffrierungDemoszene <Programmierung>
36:28
Streaming <Kommunikationstechnik>Disjunktion <Logik>FirmwareWiederherstellung <Informatik>p-BlockChiffrierungMaschinencodeBootenKonsistenz <Informatik>Flash-SpeicherROM <Informatik>BefehlsprozessorField programmable gate arrayAdressraumWurm <Informatik>ZeichenketteSerielle SchnittstelleMailing-ListeEEPROMKryptologieCoprozessorUmwandlungsenthalpiePaarvergleichSchlüsselverwaltungGruppoidPufferüberlaufGanze ZahlSondierungMinkowski-MetrikQuaderSchlüsselverwaltungWarteschlangeTermMaskierung <Informatik>ComputerSchnittmengeQuellcodeCASE <Informatik>TorusPuls <Technik>IntegralBus <Informatik>Luenberger-BeobachterSpezielle FunktionResultanteMultiplikationsoperatorDifferenteProzess <Informatik>Serielle SchnittstelleBildschirmmaskeDisjunktion <Logik>Streaming <Kommunikationstechnik>HalbleiterspeicherBootenFirmwareWiederherstellung <Informatik>CodeFlash-SpeicherLesen <Datenverarbeitung>KryptologieEinsLeckMailing-ListeUmwandlungsenthalpieCoprozessorForcingLogikanalysatorPasswortZeichenketteComputeranimation
38:54
SystemprogrammierungPeripheres GerätAdressraumROM <Informatik>SignalprozessorComputersicherheitProgrammverifikationE-MailSinusfunktionZyklische RedundanzprüfungKryptologieCoprozessorGüte der AnpassungKontinuumshypotheseQuellcodeFunktionalanalysisEntscheidungstheorieDatenflussVertauschungsrelationPhysikalisches SystemEinsPufferüberlaufZeichenketteKryptologieProgrammierungMereologieMikrocontrollerBlu-Ray-DiscPeripheres GerätRechenbuchCoprozessorZusammenhängender GraphAdressraumDifferenteComputersicherheitProdukt <Mathematik>DatenfeldBildschirmmaskeFitnessfunktionVorlesung/Konferenz
40:29
AusnahmebehandlungModelltheorieComputersicherheitSinusfunktionExistenzsatzFirmwareHardwareKryptologieSeitenkanalattackeCoprozessorChi-Quadrat-VerteilungAnalysisStochastische AbhängigkeitInteraktives FernsehenInformationService providerVersionsverwaltungSoftwarePhysikalisches SystemHardwareTaskModelltheorieAusnahmebehandlungMereologieSoftwareschwachstelleExogene VariableCoprozessorComputersicherheitSeitenkanalattackePhysikalisches SystemInformationAnalysisWort <Informatik>Reelle ZahlWorkstation <Musikinstrument>ProgrammfehlerReverse EngineeringDienst <Informatik>OrtsoperatorGraphForcingRechenwerkQuaderSummengleichungBefehl <Informatik>Prozess <Informatik>Vorlesung/KonferenzComputeranimation
42:56
BORIS <Programm>VerschlingungTUNIS <Programm>CASE <Informatik>Web SiteMetropolitan area networkVorlesung/Konferenz
43:34
CASE <Informatik>DatensatzApp <Programm>Ultraviolett-PhotoelektronenspektroskopieNummerungEmulatorSpielkonsoleSchlüsselverwaltungTaskMereologieTelekommunikationCoxeter-GruppeCoprozessorKryptologieHardwareInformationKonditionszahlBildverstehenGruppenoperationQuick-SortComputersicherheitBenutzerfreundlichkeitVirtuelle MaschineModelltheorieMetropolitan area networkProzess <Informatik>Rechter WinkelVorlesung/Konferenz
45:45
Quick-SortARM <Computerarchitektur>NummerungMultiplikationsoperatorSampler <Musikinstrument>Coxeter-GruppeBlu-Ray-DiscVorlesung/Konferenz
46:25
Blu-Ray-DiscHardwareZusammenhängender GraphNP-hartes ProblemQuellcodeMereologieExistenzsatzProzess <Informatik>Mathematische LogikReverse EngineeringNichtlineares GleichungssystemVorlesung/Konferenz
47:21
SpieltheorieInternetworkingDatenmissbrauchBildschirmfensterComputersicherheitFächer <Mathematik>Schmelze <Betrieb>Kategorie <Mathematik>ComputerOrtsoperatorRechter WinkelVorlesung/Konferenz
48:32
Vorlesung/KonferenzComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:22
Please raise your hands. Xbox, yeah, one, two, three. OK. Who are PlayStation? I call that even. Computers don't count. They run open source software, so forget about that.
00:40
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.
01:01
My name is Boris Larin. I'm security research at Kaspersky. And at work, I'm doing the research engineering. Currently, my main focus is to find the zero days exploited in the world, and I help to report a few of them. All of them were used in attacks by cover criminals and national state actors. I'm also an original discoverer of a few large supply chain
01:20
attacks. Maybe you heard about our research, Operation Shandohama. It was released early this year. But some people might also know me as Sactaxor. I was active in the PlayStation 3 homebrew development community since 2011. And back then, I was mostly known for my work on freeing DRM-protected PlayStation 3 custom few areas, developing PlayStation 3 debugging tools,
01:40
and et cetera. And today, I'm going to talk about my two favorite subjects, which are video game consoles and hiking. So in this presentation, I'm going to talk about Blu-ray disc drives of Sony PlayStation 3 and Sony PlayStation 4. So games, they are distributed to optical media. So that's why drives should contain the best security possible.
02:01
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 the firmware. I will provide a depth analysis of vulnerabilities and the exploitation to achieve code execution on the multiple models of Sony PlayStation 3 drives. And I will talk about security features that are present there.
02:22
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 corporate law.
02:41
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 with convenient 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.
03:03
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 their success with the next game console, PlayStation 3. And it's really easy to descend that just by looking at the line of events. Like, specifications were finalized,
03:21
and the 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 patents. Those documents, they reveal what types of discs exist
03:41
and what areas are present on discs and how those 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.
04:00
And it's kind of an interesting question, and I was always wondering about that. So my initial thought was that maybe Driving Wave may reveal something else about that. So let's talk about Blu-ray drives, PlayStation. And there have been a lot of them. If you unpack PlayStation 3 firmware update, you will find 12 different,
04:22
I think, various or different drive modules, 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 microcontroller is produced by Sony.
04:40
And well, after some time, Sony decided to simplify design of PCB, and they switched to microcontroller of another company, Green South. And here you can see PCB of the first Blu-ray drive with a Green South microcontroller. And after that, Sony decided to switch between Sony microcontroller and the Green South microcontroller for each new drive module.
05:02
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 firmware update, you'll find firmware for six different drive modules.
05:21
And all of them were based on Green South microcontroller. And only recently, there was also a new addition to this family. It was a mid-attack microcontroller. So, as you see, Green South 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.
05:42
So, first of all, how did they get the firmware in the first place? Actually, this technique came out from Xbox 360. And here you can see a very famous picture of Kamikaze hack for Xbox 360 drive that was developed by a quite talented researcher, And this hack, it abused the fact that quite often firmware is stored on a flagship
06:02
that is a separate die inside the 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-cupsulate package. And here you can see de-cupsulated package of Green South microcontroller for PlayStation 3 drive.
06:23
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, first, you need to de-cupsulate your package. That can be done with acid. Then you cut bond wires, for example, with laser.
06:42
And then you need to rebound these wires to custom PCB. For example, with special wire-binding machine or with silver paint. And then you're able to read flash contents. And actually, all the steps, they were done not by me. They were done by more experienced researcher
07:00
who had much more experience with this kind of stuff, and he also did quite similar things with 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 was needed to start Russian engineering was to find out what architecture it's compiled for.
07:22
And I checked website of Green South. 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 Green South are actually based on H8S architecture.
07:43
And quite luckily, this architecture is supported by the browser. So it was very easy to start Russian engineering. And here is a few more words about this architecture. It's a nice, risky architecture, but it reminds me of x86. It's really easy to work with.
08:01
You can get three different compilers for it. And one fun thing is that each of them uses different kind of condition. And there is even differences in kind of condition between different versions of Hue, which is official compiler for this architecture. It's all very in size. And so I began Russian engineering,
08:21
and I need to mention that it was a quite challenging task because Fimbari, 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 Fimbari in this case, well, log trace functionality exists,
08:42
but it only takes an ID as an argument. And then these IDs are converted to strings inside special software the developer has. Most likely it was done this way due to size constraints. There are basically no extra space on Flash to store the strings. But maybe they were thinking about security,
09:02
but it complicates Russian engineering. And the first thing that you want to do in such cases when you start to reverse engineer some new firmware is that you want to download as much stuff as you can from the website of hardware manufacturer. You want to get source codes. You want to get libraries.
09:20
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 figures signatures for IDA Pro, and you also need definitions and structures or different hardware registers. And RinSAS, they provide a really huge list of stuff
09:42
in the load. But essentially, any DVD, Blu-ray-related stuff is not available publicly, and it's really complicated, the whole project. I had to reverse engineer all of it. And RinSAS also provides dozens of different real-time version systems. So some are available in the load. You can get them. And also official compiler
10:02
is available in the load. So you get a compiler that was likely used to compile a few variables 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
10:21
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 IDA Pro Flex signatures.
10:41
And many of these functions that were used by firmware of that data got, and it was a really useful finding. And the next step that I would usually do when analyzing any firmware is that I tried to find out functions of real-time version system. It's a really important thing to do, because control flow and data, it might be passed between different tasks
11:02
that are running at the same time. And you really need to follow that during the reverse engineering. So I got many real-time version 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.
11:20
So in the end, nothing really closely matched real-time version systems 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 a Japanese company is that it most likely will follow micro-industrial transportation. And this specification, it's a real lifesaver,
11:41
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,
12:01
it communicates through ATA protocol, and here provide hierarchy of ATA protocols. So at the bottom, we have physical interfaces. We have PETA, that was previously known as just ATO-ED. It's a obsolete version of this protocol. And then we also have a SATA. And on top of that, we have two distinct command sets.
12:22
We have ATA command set. It's used for hard disk drives. And we have ATAPI command set. It's used in all of the 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,
12:42
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-engineer in such few areas. So primary command set, it implements inquiry command, and it provides some basic information about hardware,
13:03
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 hundred of SCSI commands. And then you're good to go from there. You just get a specification
13:20
and reverse-engineer some commands that looks interesting for you. So basically, this is a roadmap that I'm usually trying to follow when reverse-engineering some new firmware. And it will be also awesome if we had a way to emulate our firmware, because this way, we can analyze it much more better. And also, getting code execution will be nice,
13:41
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.
14:01
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, hex race 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.
14:23
So at some point, I decided to write my own GDB Debugger plugin to work with IDA Pro. And actually, it was a quite good decision, because it didn't take too much time to make, but it saved a lot of time while debugging this firmware and some other spinwares. For example, GDB support for X64 targets
14:41
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 engineer in firmware of the station, I was a reverse engineer in multiple thinwares, because it appeared that there exists
15:01
some Blu-ray drives for PC that had a microcontroller produced by Renaissance. 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 thinwares. It's clear that the PC thinwares
15:20
and the station thinwares are very different, but they're built using the same SDK. I can tell that because many Blu-ray had very related functions as the same. All peripheral devices are located at the same addresses and assessed exactly the same. PC thinwares uses the same cartographic processor,
15:41
and PC thinwares also contains a little bit more debug strings. It kind of reveals the name of this RNSAS platform for Blu-ray disc drives. It's called Indigo3 internally. So at the previous slide, I mentioned the cartographic processor. So when I began reverse engineering
16:00
in the firmware of the station, I found out that a really huge part of it is compiled by crypt-related functions. And these crypt-related functions, they are used for communication with the dedicated cartographic processor. And it effectively protects all the secrets. So you are not able to just dump firmware and reverse engineer all of it.
16:22
Cartographic processor protects it. And the communication process is really complicated and obscure. Here provides some graphs of such crypt-related functions. And actually, for me, it's much more easier to reverse LLVM obfuscated binary understand logic of such functions.
16:41
And here provides 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
17:00
to see what happens. But you need code execution for 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 CanciQuest titled Hacking Immigrant Polyphenol Virus through USB. You can find more details by the following link. But in that research, I examined how awesome is a user protocol for exploitation.
17:23
And I believe that a CSI protocol might be even more awesome, but it's less common for sure. So how does it work? Our client sends a common descriptor block to device. I will call it just a command. And such commands, usually device supports a lot of them,
17:40
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 and some logical block address.
18:01
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 Fimbari itself was developed by some third-party company. And then when it was ready, it was handed to Sonya to add console-specific stuff.
18:22
And I can tell that because all general SCSI commands, they are looking kind of fine, but no commands implemented by Sonya. They doesn't seem to have boundary checks. Like one of the examples of vulnerable commands has operation called E1, and this command is used for notification
18:41
of Blu-ray drive in video game console. So the main target of it is to implement security. But it has auto-bond write because transfer length is not checked. So we are able to write this buffer that is located somewhere over here, but what memory doesn't belong? So to find out this answer,
19:02
let's take a look at memory map that I was able to come up with while reverse engineering Fimbari PlayStation. So at first, we have normal without memory. We have a ROM with bootloader. We have flash with mind Fimbari. Then we have our dial memory. We have SRAM and DRAM, and it's clear that address
19:20
that we are able to write, it belongs to DRAM. And we also have registers of peripheral devices. So let's start with SRAM. It's a static random access 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 precision system.
19:41
It contains some important variables, pointer structures, and it also contains stacks of tasks. And we also have DRAM, which is dynamic random access memory. It's large in size, eight megabytes to be precise, and initially exact memory location was unknown, because most of the time, it's accessed through direct memory access.
20:02
And it contains data from disk, it contains data from a CSI client, and it also contains data that do not fit SRAM, because SRAM, it's really small, and Fimbari is really huge. It needs a lot of space to store its variables, so why not store them in DRAM? And actually, one of such regions is used only for that,
20:23
to store variables that do not fit to SRAM. And I also found out about the existence of another region. It's actually an unused implementation firmware, but I found out that it exists from firmware of Hitachi-LG Data Storage Drive. So we are able to write some data
20:41
that's located inside this buffer. How to exploit that? And well, exploitation turned out to be very difficult, because all variables, they are allocated as static addresses, and the heap exploitation techniques, they are not working there. And first, you need to find a very good exploitation primitive, and you might need to write a lot of different data
21:03
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 really large portions of firmware. So in the end, I ended up reverse engineering all functions that assess data in this region.
21:24
And there are no virtual function pointers, so there are no good candidates for your write. And there are a lot of buffers, 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 develop exploit.
21:41
But actually, I never finished this exploit, because while writing it, I was able to find a new source for vulnerabilities. So DSP registers are very interesting. They are responsible for the most of this drive-related functionality, like a type interface, LASER, SERO,
22:02
disk data demodulation, DSP firmware loading, and et cetera. It will be so nice if we had access to it. And actually, we do. Like, the whole area of DSP region is available for read and write through special SCSI commands, and those SCSI commands exist for doing just that.
22:21
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 technology functionality, because exactly the same functions are also available in Hitachi-LG data storage firmware.
22:41
So do you remember when I said that DRAM is accessed mostly through DMA? Several registers available in DSP area are responsible for copy data from in the DRAM and mapping DRAM offsets to some memory addresses. So it appeared that these regions
23:01
that are used to store firmware data, they are actually mapped using these registers available in DSP region. And we have access to them with SCSI commands. So here I explain how does it work. We have four groups of memory mapping registers,
23:21
and the two groups are set like showed on this slide. And I do not show others too, because they are set frequently by different functions. They are set by two different values. But these two are utilized earlier during startup, and they are set to these specific values
23:40
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 you can see to which memory addresses which offsets are mapped. And DRAM offset is calculated like this.
24:00
Our 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 bit that is set. But that's not all. We have specially dedicated registers that allow us to read and write double word
24:23
to any offset of DRAM. And here provide a set of code for doing just that. So we have access to DMI registers with SCSI 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
24:45
to some other DRAM offset, and 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.
25:01
And we're also able to use DMI registers to write our data directly. 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
25:22
on real hardware. And there are two ways of doing that. First of all, you are able to drill break your console. You can install Linux on it, thanks to fellow RFO. And you can communicate with B-Ray drive. Another option, you can disconnect your B-Ray drive from console and connect it to PC.
25:40
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 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're just used in different FFC connectors.
26:01
But difference is not that big, because I was able to modify FFC cable of PlayStation 4 with scissors, and it worked with public solution for PS3 drive. So this is basically how my hacking setup looked like, and it's the drive of PlayStation 4 by the way.
26:22
So the first thing that I did was to dump the whole DSP region, and it was quite a surprise. But the address of the request and the value of the request, they were set to zeros. And it will indicate only one of two things. It's either inside my model,
26:41
had a revision that I've got, DMI registers are not present at all, or they're just unused. And they were just unused. So in new models, Sony accidentally stopped to use DMA to access ZRAM. They started to use absolute memory addresses. And it grants us a full read-write access
27:04
to the old RAM. 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.
27:22
And the procedure of the drive firmware update for PS3 is well documented. You can find it on our wiki. And this procedure is exactly the same between PlayStation 3 and PlayStation 4. But here, I tried to explain how it looks like from the site of Blu-ray drive. So at first, block is often where it is received
27:42
with the right buffer command. And firmware checks, is it the first block? If it's the case, then it will initiate a special structure. And we will store this block to DRAM. And then it checks if all our blocks are received.
28:00
If all blocks are received, then it will try to validate 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 testing 3D command
28:20
to check if firmware was already decrypted. And there is a special logic inside that checks if it was decrypted, then it will copy a firmware update to SRAM and executes it. So do we see a problem here? Well, basically, it's time of check
28:40
to time of usability. 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.
29:00
And we are also able to modify firmware image after validation, and we are also able to change some structures that are 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,
29:22
and this one, and it's PlayStation 4 by the way. And I've got even more. So at 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.
29:42
And when you exploit such devices, usually you need to be extremely careful, because this device 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 a new device and do your experiments all over again. But actually, in this case,
30:02
I need to mention that a special mini firmware exists. It's called emergency boot, and well, during boot, bootloader checks if your mind firmware has a valid hash, and if it's not the case, then this special firmware will be executed. So you will still be able to un-brick your device.
30:22
So why did it happen? Most likely scenario is that when firmware was handed to Sony to control specific stuff, engineers didn't really understood the functionality that is available through dispute registers. And since the commands to read and write dispute registers, they were left for the agnostic proposal for sure.
30:43
But security risks represented by free use of dispute registers, they were not really considered. So with code execution, I was able to do some experiments. The community always wondered, what is this mastery block data that Sony puts to disk
31:02
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 XV, 4x4, and at first there are just 16 random bytes. It's just a padding, then not used anyhow,
31:22
and then just a few flags to set some drive identification states. And for me, it also was interesting to see how disk keys are obtained, because this information should be somehow related to the way how disks are verified. And for PS3, there are two disk keys.
31:42
One is used for decryption of disk data, and another one is used for encryption of safe data. And all this is about the same for PS4. And I found out that disk keys are returned from cryptographic processor, but it happens only in the case of drive identification. So, initially I was thinking that this logic,
32:02
to reconstruct this case, it should be located there inside cryptographic processor. So, here are a few more words about drive identification. So, the drive identification and the drive cryptographic processor, it's the main things behind optical disk drive security of Sony PlayStation.
32:21
And drive identification is secure and performed with pure console keys, and I know only two ways to obtain those keys. You either need to hack cryptographic processor with your game console. It's called a spoof for PS3 or some of PS4. Or you need to hack cryptographic processor of Blu-ray drive. And it's very hard to achieve such hacks.
32:40
So, security model is very effective against widespread parsing. Much more simple ways to part games always exist. For example, if you hack mind from where of PlayStation, you can part games. But if you hack from where of PlayStation you drive, you can't part games. And I was thinking how to better illustrate the security model.
33:01
And it's the best what I was able to come up with. So, imagine we have two floating islands, and it's actually thinwares. And those thinwares, they support white castles, and these white castles are cryptographic processors. And please take a notice that there are no entrances to those castles.
33:20
So, you are not allowed to get in from thinwares. 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 hack thinwares of video game console, you are able to bypass the secure communication.
33:42
You just take this data that comes out of it, and you just run it on your console. So, you part games. But if you hack thinwares of the 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 part.
34:03
And I also was able to play with the processor. It was initially the reason why I needed code execution. And I did some experiments. I was able to load crypto thinwares of PlayStation 3 drive to PlayStation 4 drive. And PlayStation 4 drive, the crypto drive processor
34:23
started to behave exactly like it should on PlayStation 3. Even some offsets of some crypto drive registers, they have changed. So, it proves my idea that it runs some kind of thinwares. And, like, as you know, I mentioned that communication process is quite complicated,
34:42
and I wanted to try to change some values. So, I wrote a specially navigated phaser 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, crypto drive processor returns error. And after a few errors, crypto drive processor hangs,
35:02
and you need to reset the device. So, allegedly, I think that logic of such crypto drive 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 these commands.
35:21
And in the end, these commands, they are verified and executed. And I played a little bit more with crypto drive processor, but eventually I lost interest, because breaking copy protection was never a goal. And more reverse engineering, it revealed that most likely, crypto processor exists only for doing crypto stuff.
35:42
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.
36:02
It's a microcontroller, produced by Sony. It has ARM support. And we also have a one-megabyte NOR flash with firmware by Spencer. So, one-megabyte NOR flash with firmware. So, actually, firmware is executed from external flash.
36:22
And that is decrypted on-fly. And of course, a encryption algorithm is based on XOR. So, we have some sourcing 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, a few by zeros,
36:44
and we are able to partitionly 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.
37:03
So, 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 the boot external flash with logic analyzer. We are able to modify accesses with FPGA.
37:22
And we can write some uploads that encrypts. We can encrypt it with recovery XOR stream. And we can modify some memory accesses from the pool after firmware is verified to execute this small upload. So, without upload, we can read plain text and leak it.
37:42
So, we get code execution and firmware dump. And this firmware was quite interesting, because unlike Princess 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.
38:01
You see peak, dump, poke, and much more. And, but you need some special password to access it. I need to mention that. Also, crypto processor is, these drive force has it, but it's very simple, very different from the ones that was used in the resource.
38:21
It's also much more simple. You just set keys, data, size of data to some specific offsets in crypto region. And then you initiate operation. And, like, if you try to read the crypto region from the flash, you will be not able to do that.
38:42
You will get only garbage to the pool registers. It was intended to work like you need to use special functions that are present in the bootloader to set only specific offsets inside this crypto region. But, of course, you can bypass it with the return to the programming.
39:01
And also, all these functions, they have integral overflows. So, this check, I think it's useless. You are able to read the whole crypto region anyway. And if you do that, there'll be one interesting string at the start, others of this crypto region. And it should be not possible to read it otherwise.
39:21
And Sony Microcontroller and the RNSAS Microcontroller, they are completely different systems. And it means that all peripheral devices should be different and they should be accessed differently. But I found out one peripheral device that accessed exactly the same. So, it means that one particular peripheral device
39:41
is exactly the same in both, in different hardware, such as Sony and RNSAS Microcontrollers. There's only difference in addresses. In Sony Microcontroller, those registers are allocated inside special region. And in RNSAS, they are accessed through individual disk registers.
40:02
So, I believe this peripheral device is actually a disk security component. And it performs some interesting things. Like, if you are to calculate 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
40:22
will not be able to return this key. So, I know one part of this verified process, but found out the rest will be a really challenging task if it implemented purely in hardware. And one more fun fact, Nokia is short for Inoki,
40:40
which is a very tasty mushroom in Japanese cuisine. So, let's make a conclusions. I think that Sony and partners, they did exceptional work. Security model is really good and has proven itself. Imagine, a plastician drives, they existed since 2006, but no public hack since then.
41:02
But many have tried according to rumors. So, here is one lesson that we also can learn from this example. Fumari can be hacked. So, put all your secrets to hardware. In this case, guys like me, they will have some problems in reverse engineering it. And also believe that cryptographic processor might be an interesting real world target
41:22
if you're into glitching and side channel 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 the SASHME Red drives. And I want to say thank you, Nokia. This research will be not possible without you.
41:42
And here's a few more words about responsible discussion. So, on November 2008, 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?
42:02
Well, yeah, sure. I provided information regarding my vulnerabilities. And it was quite a surprise what happened next. Like, it was totally not expected. But the security team invited me to join
42:20
a recently launched bug volunteer. And they trashed all my vulnerabilities. They told me that it's high and two medium security bugs. They told me that it's not critical in Norway. And all my vulnerabilities were fixed in the latest system that come out just nine days ago.
42:46
So it seems that I have become a first researcher who won a bounty of hopefully station bug.
43:02
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 do that in the future. So, all my slides, they will be uploaded by the following link.
43:22
And I want to say thank you. Thank you very much. If you have questions, you know how it works. The interwebs has questions already.
43:41
There are microphones. Microphones one to seven and two to eight. Please make a perfect row and we will cue you. So, the interwebs, first question. The interwebs is asking, is the USB to SATA adapter just a common chipset
44:01
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.
44:20
Short answer. Microphone number one, please. So, I think there are some first party like 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?
44:44
So, like I mentioned, for doing that, you need a way to bypass the secure communication, right? And for doing that, this secure communication is secure. You need to get their console keys. And to get those keys, it's a really challenging task.
45:04
Maybe you remember the presentation of failoverflow. Like when, many years ago, when they were able to break a spool, right? We have not seen something like that for some which is a cryptographic processor of PS4. But still, even for PS3, Sony,
45:22
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 their console keys are used.
45:45
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?
46:02
Actually, I don't know. I have spent the most of time of my research on looking at stuff. And I actually never had a chance to take a look at Toshiba PSP stuff. So I'm actually not able to tell you for sure.
46:23
Okay, 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.
46:42
So I believe that a specially dedicated component exists. And disks, they are verified by this component. And this logic, it's implemented by hardware. And I know that some parts exist, like to set some data from software,
47:00
like this one where it calculates CRC 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. Okay, thanks.
47:21
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, like people like Playstations
47:45
because they got exclusives, right? And well, also, well, 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,
48:02
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 the internal property. And they also add some special stuff, like some new techniques, some novel ideas.
48:23
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.
48:40
Please, with a very warm applause, Boris Lein. Thank you.