Viva la Vita Vida
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 |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 165 | |
| 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/39333 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
35C3 Refreshing Memories33 / 165
2
5
6
7
8
9
10
11
12
13
15
16
17
22
26
29
30
31
33
37
38
39
40
44
45
48
49
53
54
55
57
59
60
62
65
66
69
70
72
73
74
77
80
82
83
84
85
86
87
89
92
94
100
104
105
106
107
108
111
113
114
115
116
117
119
121
122
123
124
127
132
133
136
139
141
143
144
145
146
148
149
150
154
155
156
157
158
159
160
161
162
163
164
165
00:00
HypermediaSpielkonsoleBitMailing-ListeHackerVorlesung/Konferenz
00:48
HalbleiterspeicherHecke-OperatorNintendo Co. Ltd.SpielkonsoleVorlesung/Konferenz
01:40
ATMSoftware Development KitARM <Computerarchitektur>ZeitzoneHalbleiterspeicherComputersicherheitArchitektur <Informatik>HardwareHackerSoftwareResultanteMereologieHardwareSoftwareComputerarchitekturVideokonferenzComputersicherheitTeilmengeCodeCoprozessorComputervirusComputeranimationVorlesung/Konferenz
03:04
Physikalisches SystemProzess <Informatik>ARM <Computerarchitektur>Kernel <Informatik>ZeitzoneBootenATMJust-in-Time-CompilerComputersicherheitKernel <Informatik>MAPProxy ServerSpielkonsoleMultiplikationsoperatorCoprozessorBootenComputeranimation
03:47
SchlüsselverwaltungInhalt <Mathematik>SpieltheorieKernel <Informatik>BootenMeta-TagArchitektur <Informatik>HardwareInformationSoftwareImplementierungFlächentheorieSoftwareDigital Rights ManagementComputerarchitekturPhysikalisches SystemHardwareGruppenoperationAutomatische HandlungsplanungMAPComputersicherheitProzess <Informatik>BootenCodeSpieltheorieCoprozessorKernel <Informatik>SchnittmengeFolge <Mathematik>FirmwareBitInformationFitnessfunktionBlockdiagrammComputeranimation
05:01
Dynamisches RAMKryptologieHIP <Kommunikationsprotokoll>Statisches RAMProzess <Informatik>GoogolHypermediaE-MailPatch <Software>Suite <Programmpaket>Physikalisches SystemBitARM <Computerarchitektur>IdentifizierbarkeitElektronische Publikationsinc-FunktionPerfekte GruppeCoprozessorSystem-on-ChipBefehlsprozessorRISCBlockdiagrammSystemplattformSchnittmengeInformationKryptologieComputersicherheitProzess <Informatik>E-MailNotepad-ComputerStatisches RAMTranslation <Mathematik>MAPCompilerHalbleiterspeicherCASE <Informatik>Computeranimation
07:38
EmulatorSpeicherschutzVirtuelle RealitätROM <Informatik>ComputersicherheitSoftwareInterface <Schaltung>CompilerEmulatorProxy ServerQuick-SortFunktionalChiffrierungElektronische UnterschriftPhysikalisches SystemRechenbuchARM <Computerarchitektur>Endliche ModelltheorieLastZeitzoneKernel <Informatik>SoftwareProzess <Informatik>CodeAuthentifikationSchnittmengeBrennen <Datenverarbeitung>DialektSpeicherschutzLaufzeitfehlerComputersicherheitDateiformatAuswahlaxiomBitHalbleiterspeicherHardwareSpitze <Mathematik>Gesetz <Physik>ComputerspielDreiecksfreier GraphDigital Rights ManagementWorkstation <Musikinstrument>SichtenkonzeptMultiplikationsoperatorVirtuelle AdresseComputeranimation
10:01
ROM <Informatik>ChiffrierungARM <Computerarchitektur>Prozess <Informatik>KryptologieFormale GrammatikRPCLastElektronische UnterschriftHalbleiterspeicherResultanteDateiformatARM <Computerarchitektur>Kernel <Informatik>ComputersicherheitErwartungswertResolventeLeistung <Physik>Computeranimation
10:55
KontrollstrukturEin-AusgabeROM <Informatik>ComputersicherheitRPCHasard <Digitaltechnik>ChiffrierungGruppenoperationStatisches RAMARM <Computerarchitektur>ProgrammverifikationDreiecksfreier GraphLastSystemaufrufProzess <Informatik>ComputersicherheitComputerspielAnalysisElektronische UnterschriftPhysikalisches SystemOrdnung <Mathematik>Endliche ModelltheorieE-MailHalbleiterspeicherEin-AusgabeQuick-SortBitCodeLesen <Datenverarbeitung>FehlermeldungVorzeichen <Mathematik>BlackboxWürfelApp <Programm>Computeranimation
12:50
ARM <Computerarchitektur>Virtuelle RealitätROM <Informatik>TransaktionWeb-SeiteMailing-ListeHalbleiterspeicherARM <Computerarchitektur>Virtuelle AdresseVirtualisierungURLElement <Gruppentheorie>Web-SeiteAdressraumPhysikalismusMailing-ListeEinsEndliche ModelltheorieMessage-Passingp-BlockWeb SiteRechter WinkelOrdnung <Mathematik>Computeranimation
14:26
Mailing-ListeBimodulBimodulDynamisches RAMWärmeübergangZweiMailing-ListeTransversalschwingungEndliche ModelltheorieHalbleiterspeicherComputeranimation
15:11
Statisches RAMMailing-ListeROM <Informatik>Kernel <Informatik>LeckElektronische UnterschriftNormalvektorPunktInhalt <Mathematik>BitLeckE-MailElektronische UnterschriftMessage-PassingStatisches RAMOffice-PaketRechter WinkelHalbleiterspeicherComputeranimation
16:14
Statisches RAMMailing-ListeEbener GraphBimodulMailing-ListeHalbleiterspeicherPunktElement <Gruppentheorie>AbfrageFitnessfunktionBimodulMultiplikationsoperatorElektronische UnterschriftMereologieEndliche ModelltheorieElektronische PublikationComputeranimation
17:40
BimodulMailing-ListeStatisches RAMEndliche ModelltheorieEinsHalbleiterspeicherMailing-ListeComputeranimation
18:25
Statisches RAMKernel <Informatik>Prozess <Informatik>Physikalisches SystemJust-in-Time-CompilerARM <Computerarchitektur>ZeitzoneBootenATMEndliche ModelltheorieStatisches RAMFünfKernel <Informatik>MAPMultiplikationsoperatorSoftwareschwachstelleAnalysisHardwareFlächentheorieSoftwareFormation <Mathematik>BootenLaufzeitfehlerComputeranimation
19:36
HackerHardwareHalbleiterspeicherSoftwareComputermusikFokalpunktCodeFehlermeldungProxy ServerProzess <Informatik>Mathematische LogikVerknüpfungsgliedQuellcodeFunktion <Mathematik>Physikalisches SystemFormation <Mathematik>SoftwareSoftwareschwachstelleFokalpunktHardwareHackerWort <Informatik>MultiplikationsoperatorLeistung <Physik>BitSchlüsselverwaltungComputerWahrheitstabelleVerknüpfungsgliedRechter WinkelMomentenproblemMereologieWasserdampftafelSpannungsmessung <Mechanik>StrömungsrichtungMinimumDifferenteEinsTypentheorieDiagrammFunktion <Mathematik>LeckPhysikalisches SystemVerzweigendes ProgrammResultanteFastringPunktQuellcodeMAPFehlermeldungCodeLineare OptimierungMathematische LogikComputeranimationVorlesung/KonferenzDiagramm
26:17
Ein-AusgabeMultiplikationWahrheitstabelleFunktion <Mathematik>CASE <Informatik>FehlermeldungTopologiePunktVerknüpfungsgliedMathematische LogikIdeal <Mathematik>DigitaltechnikComputeranimation
27:12
Funktion <Mathematik>Physikalisches SystemIdeal <Mathematik>FehlermeldungOperations ResearchAdvanced Encryption StandardHardwareProzessautomationQuellcodeBefehlsprozessorSpezialrechnerMultiplikationsoperatorDigitaltechnikCASE <Informatik>VerknüpfungsgliedMereologieGraphiktablettPersönliche IdentifikationsnummerBitDifferenteAggregatzustandProzess <Informatik>Leistung <Physik>Physikalisches SystemMultifunktionMapping <Computergraphik>Ein-AusgabeDigitalisierungFunktion <Mathematik>SpezialrechnerComputerFehlermeldungHardwarePhysikalische TheorieUmwandlungsenthalpieQuellcodeComputeranimation
30:22
SpezialrechnerLie-GruppeRechenwerkQuellcodeMultifunktionLeistung <Physik>Einfach zusammenhängender RaumPersönliche IdentifikationsnummerGraphiktablettNetz <Graphische Darstellung>VerdeckungsrechnungAutomatische HandlungsplanungFontPartikelsystemUmwandlungsenthalpiePortscannerZusammenhängender GraphDifferenteAbgeschlossene MengeGraphfärbungEinsMereologieAbstandSpezialrechnerRechter WinkelWhiteboardComputeranimation
35:05
CodeElektronische UnterschriftStichprobeBootenPartitionsfunktionE-Mailp-BlockInformationsspeicherungField programmable gate arraySmileyGruppenoperationBootenPhysikalische TheoriePufferüberlaufProzess <Informatik>Puffer <Netzplantechnik>Nichtlinearer OperatorGamecontrollerAutomatische HandlungsplanungInformationsspeicherungDatenfeldBinärcodep-BlockRechter WinkelFehlermeldungProxy ServerNP-hartes ProblemDateiformatPartitionsfunktionDifferenteHook <Programmierung>ComputerE-MailLoopLeistung <Physik>Persönliche IdentifikationsnummerElektronische UnterschriftMAPMultiplikationsoperatorMechatronikHydrostatikField programmable gate arrayChiffrierungComputeranimation
39:32
Leistung <Physik>PartitionsfunktionBootenE-MailWärmeausdehnungParametersystemE-MailMultiplikationsoperatorBootenPartitionsfunktionRechter WinkelLeistung <Physik>ResultantePhysikalisches SystemSkriptspracheEins
40:46
Open SourceHardwareSystemplattformKontrollstrukturField programmable gate arrayMusterspracheInformationsspeicherungWhiteboardATMWhiteboardOpen SourceInformationsspeicherungSkriptspracheWurm <Informatik>Prozess <Informatik>HardwarePersönliche IdentifikationsnummerGamecontrollerIndexberechnungSystemplattform
41:52
Open SourceMagnetbandlaufwerkResultanteParametersystemHash-AlgorithmusProzess <Informatik>HilfesystemRauschenLoginSoftwareschwachstelleBooten
43:33
Prozess <Informatik>Physikalisches SystemBootenKernel <Informatik>ZeitzoneARM <Computerarchitektur>ATMJust-in-Time-CompilerKryptologieCodeSchlüsselverwaltungFaktorisierungSingularität <Mathematik>FlächentheorieDatenmodellComputersicherheitAuswahlaxiomChiffrierungZufallszahlenLokales MinimumWhiteboardReverse EngineeringKette <Mathematik>WikiAggregatzustandMereologiePhysikalisches SystemBootenFlächentheorieCodeRechter WinkelSchlüsselverwaltungEinfache GenauigkeitHackerForcingComputersicherheitKryptologieSpieltheoriePublic-Key-KryptosystemMaschinenschreibenReverse EngineeringSchreiben <Datenverarbeitung>ARM <Computerarchitektur>Prozess <Informatik>AdressraumTermRandomisierungDeskriptive StatistikMomentenproblemKernel <Informatik>Vorzeichen <Mathematik>TeilbarkeitFirmwareKlassische PhysikGemeinsamer SpeicherPufferüberlaufWikiTreiber <Programm>ViewerAdvanced Encryption StandardStandardabweichungVorlesung/KonferenzComputeranimation
48:17
HalbleiterspeicherFormation <Mathematik>ZahlenbereichGeradeProzess <Informatik>MultiplikationsoperatorGebäude <Mathematik>HardwareKryptologieSchlüsselverwaltungWeb-Seitesinc-FunktionInternetworkingArithmetisches MittelBootenAdditionChiffrierungGrenzschichtablösungCodeVorlesung/Konferenz
50:16
SichtenkonzeptQuick-SortComputersicherheitÄhnlichkeitsgeometrieCoprozessorCodeVideokonferenzProzess <Informatik>ÜbertragungsfunktionFrequenzMultiplikationDivisionExogene VariableMathematikBitPhasenumwandlungMethode der partiellen kleinsten QuadrateFrequenzgangRauschenDateiverwaltungMereologieVorlesung/Konferenz
52:50
SoftwareHardwareHyperbelverfahrenSpielkonsoleDemoszene <Programmierung>FehlermeldungFunktion <Mathematik>Ein-AusgabeZeitrichtungVorlesung/Konferenz
53:45
HalbleiterspeicherDualitätMailing-ListeAdressraumExploitVorlesung/Konferenz
54:46
Statisches RAMMailing-ListeBimodulHalbleiterspeicherTotal <Mathematik>Rechter WinkelZahlenbereichBootenHardwareHalbleiterspeicherMereologieDerivation <Algebra>Flash-SpeicherFlächeninhaltProzess <Informatik>SchlüsselverwaltungWhiteboardComputeranimationVorlesung/Konferenz
55:47
HalbleiterspeicherKartesische AbgeschlossenheitWendepunktZahlenbereichHardwareRechter WinkelFigurierte ZahlFormation <Mathematik>Vorlesung/KonferenzDiagramm
Transkript: Englisch(automatisch erzeugt)
00:05
I was looking at media.ccc.de today to check out how many talks of console hacking we
00:25
already had at the Congress. And it's quite a long list actually. So we had the Xbox 360, PlayStation 3 at 23, C3. We had PlayStation Portable at 24, C3. We had a lot more. It's a really, really long list.
00:41
And I'm really excited to have Yifan Liu and Davy here today. And they're going to tell us a little bit about the hack of the PlayStation Vita. And yeah, let's see how they hack it. Please give a warm applause to Yifan and Davy.
01:08
So thanks, everyone, for coming today. So I know some of you did this already. But show of hands, how many of you own a PlayStation Vita? Yeah. OK, that's a few of you. How many of you own a Nintendo 3DS?
01:23
OK, so that's the audience. Well, I'm hoping by the end of this talk, I can convince you to come to the better console. So who are we? We are Team Molecule. This is our mascot.
01:42
And Davy, I'm Yifan. For the lawyers, I'm XYZ. And there's also Proxima, who is not here today. We've been hacking PlayStation Vita since the very beginning. And we've done a lot of stuff on it.
02:00
So overview of the talk today. So this is a foundational talk. So we wanted to focus more on the techniques that we've developed rather than just show the results. So some of the parts, for those of you more experienced, might find it a little bit tedious. But I'm hoping that you'll go through it
02:21
and learn something anyways. So Davy will be presenting the software side. And I will come back later on and enlighten you with some hardware stuff. And here's Davy.
02:40
Hello. So I'm going to be talking about the software side of hacking the PlayStation Vita. And specifically, I'm going to be talking about a certain subset of the Vita. And that's the security coprocessor. So first thing I need to talk about first is the software, the security architecture
03:01
of the PlayStation Vita. It kind of looks like this. These are the basic privilege levels for the console. And we've already worked on the PlayStation Vita for a long time now. It was released in 2012. So we're already up to the TrustZone level. What's quite interesting about TrustZone on the Vita
03:22
is it's not actually trusted at all by Sony. It only works as a proxy to the security coprocessor. So we can simplify this privilege level down to this. So really, what I want to talk about today is how I'm going to go about breaking
03:41
into the food kernel and the food loader at levels. So food, I just said that. What is it? It's a security coprocessor. And it's a special processor in that it's running a proprietary instruction set. We'll come back to the actual details of the hardware itself. But let's first talk about the two privilege levels
04:01
I was talking about. The food kernel is the DRM layer of the system. It makes sure that games and firmware updates are properly authenticated and not authorized code is run. The food loader is more like the bit loader and the startup
04:21
sequence. And it just makes sure that the food kernel itself is valid. So if we want to break into these, we need to think of a plan on how to attack this. And with a proprietary processor, we really need to start getting more information on it. So first thing we need to look at is the hardware architecture behind it.
04:45
Then afterwards, we're probably going to have to look at the software that's actually running on the processor. And from that, we can start to think of a plan of action to break into it. So first, I'm going to talk about the architecture of the system.
05:01
This is the block diagram for the main system on chip for the Vita. This is called Kermit, actually named after the frog. They sort of tend to name their systems, the main processors and stuff off of, in this case, on the Vita, they name after the Muppets. There's also Ernie.
05:23
There's no Bert, though, which is disappointing. On the PSP, for example, they had Kirk and Spock and Paul. So only those two on this. And we don't really care about the rest here, the CPU, the GPU. We really want to focus on food.
05:41
And you can see inside food, there's the MEP C5 processor. MEP is actually a custom RISC from Toshiba. And I'll talk a bit about the name food. We actually got that from the ELF headers of executables built for the MEP platform. You see, the ELF identifier is F00D.
06:02
So we just ran with that, named it food. And it's been history since. The MEP processors are normally used in parking assist cameras or security solutions. But in this case, they have decided to use it for the security coprocessor.
06:20
There's a bunch of other stuff belonging to food, such as the crypto engine and the key slots. Not very important for this talk, but it also has its own private memory, the secure SRAM here. Only 128 kilobytes, but it cannot be accessed from ARM or, in fact, any other subsystem in the system.
06:42
So with a custom RISC here, how do we find out information about it? Well, it's pretty much the same as anything else. You Google it. And what that turns up is a bunch of data sheets somewhere in English. Most are in Japanese. So Google Translate's your best friend there.
07:05
So following that, a couple of Google searches gives you the data sheets. So from there, we can learn about the instruction set. We can learn about some of the quirks. And thankfully, Red Hat have already ported the MEP platform to GCC and Binyu tools.
07:22
So straight off the bat, we've got a compiler. We've got tools to analyze L files. Perfect. But really, we want to learn more. And the best way to learn, for us at least, is to get a little hands-on. So we've built an IDA plug-in for it. We've built an emulator, which was really useful because it
07:41
helped us learn some of the weird quirks behind it. And we even have a decompiler for this. So overall, what we've learned about the hardware is that the instruction set is heavily inspired by MIPS. It doesn't have any of the weird delay slot or anything like that, but the actual instruction format
08:01
is pretty much the same. There's no virtual memory, and there's no memory protection whatsoever. So it runs purely on physical memory. It's not hardened for security, so this is very interesting. There's no SLR. There's no execute bits. Odd choice for a secure code processor. We thought that it wasn't very secure.
08:22
So whatever. Next thing we're going to talk about is the actual software running on food. And at runtime on the PlayStation VIA, there's this secure kernel that's running at all times. And the main purpose of that is to load applets, which are executables that
08:43
encapsulate some sort of functionality on the system. Examples of this are encryption, signature checks, DRM, and whatever you want to use, like some feature that needs to be authenticated, what you do is you load it.
09:00
And once you load it, you can then do some sort of RPC calls to then do some calculations or decryption or authentication or whatever. And then afterwards, you unload it, because the applets follow a lifecycle where you load an applet, you do your stuff, you unload it, and only a single applet can be loaded at once.
09:22
And unfortunately for us, the applets are signed and encrypted. So we can't just create our own one, load it, and then have access to the food. So let's look at the lifecycle in a bit more detail. Specifically, we'll start with applet loading. So you see here, there's three regions here.
09:41
You see ARM, trust zone, and food. As I mentioned, trust zone is mostly useless. It only works as a proxy between ARM and food. So we can simplify this model down, and we can start talking about how the applet loading works between ARM and food. So ARM will start off.
10:01
It will read the applet into memory. It will then transfer the applet over to food. Then in food, it will then check the signature of it, make sure it's a valid applet, and then it will start decrypting and loading it. Once done, it will return the result, whether that was successful, it failed, or something else. For applet RPC, it's mostly the same pattern here.
10:23
It formats the request, sends that over to the food secure kernel. The secure kernel will then forward that to the applet. Then the applet will run whatever command's needed, and the result will be sent back to ARM. Unloading, pretty much the same thing as you'd expect.
10:41
What happens is the request is unloaded. You request an unload, food will oblige, and you'll get the result back, whether that was successful. So knowing this, we need to start thinking, how can we actually go about attacking this? So let's summarize what we know first. We can control all the input into food,
11:01
and importantly, none of this input's checked at all. TrustZone doesn't do it, so we can pass in as much or as little malicious data as we want. We know the memory layer of food. This is mostly inferred from the data sheets we got. But also, interestingly, the applets have an ELF header, and they have segment headers in there
11:22
which say which address it loads to. So we can build a pretty good model of what the internal memory looks like. The security code processor has no security features whatsoever, so that's really handy. We know what the applet life cycle is. We know that they're loaded.
11:40
We know we can then do some RPC calls. And then we can then query those RPC calls for any sort of issues. What we need to watch out for is there's a signed executable, so we can't modify any of these executables. Otherwise, we'll get thrown back with an error.
12:03
We can't read these executables. They're all encrypted, so we can't do any analysis of them beforehand. And this basically makes the system a black box here. So ideally, what we're after, in order to proceed any further, is some sort of read primitive that will allow us to go ahead,
12:20
inspect the food private memory, and then from there, we can start looking at the code, and we could establish a more precise attack on it. So I'm gonna go back to applet loading here. We're gonna try and discuss in detail what's happening. It's because, specifically, we know that the applet's read into memory,
12:40
and it's transferred over to food, where it does a signature check, and then does the rest of the loading. But what happens for this little bit in between here? And there's two problems here. First one is that ARM operates with virtual memory, and food does not. So this is a problem
13:02
because virtual memory is not guaranteed to be backed by contiguous physical memory. So whenever we want to send data to food, we're gonna have to make sure that it's either copied to that, or that we don't use virtual memory, which is kinda ridiculous. So there needs to be a better way, and so they have a better way of doing this,
13:22
and we'll come to that shortly. So this is virtual memory, and this is physical memory. You can see that we have page one through to page seven. And if you look at the physical memory side, you can see that the pages aren't in order. So if we were to pass page one's physical address to food, it won't receive the right data. It will receive page one, some unknown data,
13:42
page four, page three, not intended. What Sony do here is they add a physical address list, this P adder list. Instead of passing the data, all it does is you pass the P adder list to food, and it will query the list, which has the first element is the location
14:02
of the page that we want. So you can see the first element here points to page one. The second element in that list is the size. So what food will do when it wants to read an executable is it will walk this list and build the model up from inside. And this is the way they can get around
14:21
having to copy virtual memory to a contiguous block. So applying this to food, and to the applet specifically, the food module is an applet. What you can see here is that the first three bytes of this food module is represented by the first entry of the P adder list. The second is the second of the P adder list,
14:42
and so forth. And you can see that all these data is backed in DRAM. This solution fixes the copying, and then we've learned how data is passed to food, and this is consistent throughout transfers to food. There's a problem though.
15:00
If we go back to this model here, and we can see that all the data is backed in DRAM, what happens if we modify one of these P adder list entries to then point to the food private memory? Well, as it turns out, food does not blacklist its own private memory.
15:22
Useful, maybe. Okay. Not here, because the internal memory, food keeps all its data internal, so it doesn't copy anything out with this header, so no leak, but data is also signature checked, the applet is also gonna be checked,
15:41
so this makes it useless, right? Because we're passing in to unknown data, it's doing a signature check, it's obviously just gonna fail. Or is it? Because if we make an assumption, right, if the data we're pointing to in SRAM matches the expected data that we have in the applet,
16:01
we'd expect the signature check to succeed. And then we can make a deduction here that if that signature check succeeds, we know the contents of the SRAM. So let's do this a bit better here. If we reduce the P adder list entry point into the private memory to one byte, and then simplify the P adder list with the module,
16:24
more like this, where you have the first entry that is the first part of the file, the one element for this point into private memory is the 00 byte, so we're interested in finding, in private memory, where all the 00 bytes are,
16:40
so every time we pass in this P adder list, what we would expect is, whenever there's a 00 point in this element here that's in SRAM, that the signature check would succeed. So if we start by going through this, so we have the element pointing at the first byte
17:02
in the private memory, and we can then pass it into food, it fails, the signature check fails. So what we've learned here is that that byte in memory is not 00. We can go on, we can go to the next byte and query that, also not zero, and we can do this so on, and so on, and so on,
17:22
until eventually we should expect to see a success. So the module was loaded, and what we've learned from that is that byte there is 00. It matches the one in food, the food applet, so yeah, we've learned that that's 00. We can then go ahead and apply this all the way through the rest of food private memory,
17:41
and there we go, we've built up a model where all the zeros are. So we've learned where the zeros are, not very useful. What we wanna do now is look for the 01s. So if we then rearrange the p adder list, so the missing byte in the food applet is 01, we can then do the same thing again. We point our entry into the food private memory
18:02
to the start, we start querying, eventually we find another one. Keep going, keep going. We don't need to query the zeros, we already know they're there. Then we get here again, and we find another one. Then you could do the same thing again, apply it all the way down to the end of memory,
18:21
and you find all the ones. So imagine we've built this model, so what we wanna do now is then apply it to all the 02s, then all the 03s, and all the 04s, and all the 05s, all the way up to the FFs. And once you've done that, you build a model of the food SRAM, and you get the plain text of the kernel.
18:51
This is what we're calling the octopus exploit. Don't ask why. So with this, we now have the food kernel.
19:03
We've got read access, we can then do some further analysis, we can start looking for more precise vulnerabilities. We won't go into that, but we've got the food kernel, so what's next? It's the food loader. And the food loader is the boot stage, and because it's the boot stage,
19:22
it doesn't last very long. It doesn't persist through runtime. That makes the software attack surface very small. So to deal with that, what we're gonna have to do is look at hardware, and I'm gonna pass you back to Yifan, and thank you very much.
19:46
Told you I would be back. So we ran into the situation where the weak little software hackers have to be rescued by the hardware master race. So what I'm gonna focus on today is glitching,
20:02
and I know that word is kind of a buzzword these days. Many of you have heard it. I think even at Congress, there were a couple of talks on it, but instead of just saying, hey, we glitched it, I wanna kinda go into the details of what is glitching, how does it work, and why does it work? So in short,
20:21
a hardware glitch allows you to create a software vulnerability when none exists, and there's many ways of doing so, but we're really gonna focus on one of these methods today which is voltage glitching, and the reason is because the other ways are much more difficult and expensive to pull off,
20:41
and some of them are only theoretical. So to show a concrete example, I have a bit of C code, so this code just does a size check, and then it processes data if the check passes, and I went ahead and compiled it into MIP assembly, so if you haven't seen MIP assembly before,
21:02
and why would you? This is what it looks like, and then I will just execute it for you as the computer, so here we load the size value, and then SLTU3 basically is less than unsigned, and it sets R0 to the result of that,
21:23
so here it's set to zero because it was not less than, and because of that we jump to the error branch, and it's fully secure, there's no way of hacking it, just give up, but if we introduce a voltage glitch at this point,
21:42
what happens is that this will create a mistake in the computation, so as you can see here, R0 is supposed to be set to zero, but because of the voltage glitch, it's now one, which propagates the next instruction when we're taking a branch base off of that result,
22:02
and we manage to bypass this check. Why does it work, though? This is something that's near and dear to my heart, because I'm the kind of person who, you know, you can tell me the high level ideas, but I'm not really satisfied until I know the low level details,
22:21
so to explain that, we unfortunately have to look at transistors and logic gates, so if you don't remember this, don't worry, I'll explain it as well, so this is NAND, or not and, and here's a truth table,
22:42
and we are gonna implement this in modern transistor technologies, or CMOS, it's a complementary transistor technology, what that means is there's two different types of transistors that implements the gate, one is, as you see on top,
23:01
is used on the, I guess, the top part of the diagram, I'll show you the diagram later, it'll make more sense, but basically, this acts as a switch, the gate activates, and then the current will flow from the source to the drain, so kind of like a light switch, but instead of using your fingers,
23:21
it's controlled by the voltage at the gate, the only difference between these two is that the voltage to turn on the top gate is low, so when there's no voltage, the top gate turns on, and on the bottom one, it turns on when it's high, so when there is voltage, it turns on, and that's what make them complementary, because one must always be on when the other one's off,
23:44
so here's what the NAND gate looks like, so you see the bottom gates are off, the top gates are on, because zero NAND zero is one, and you see current flowing from the source to the output, now one NAND zero is still one,
24:02
and the way that works is that one of the top gates is turned off, but the other one is still on, so it's still flowing through, the bottom one, one of them is turned on, but that doesn't matter because the second one is turned off, so it doesn't leak down to the bottom port, now one NAND one is zero,
24:22
and you can see it's because the two are turned off, now why are the bottom two turned on? Because when you turn off a faucet, sometimes there's water that drips down, so you need something to collect that, so what happens when we glitch it, right?
24:42
So here's, back to the one NAND zero example, when we say we introduce a voltage glitch, what we do is we essentially connect the voltage source down to ground or zero volts, essentially you're disabling the power source,
25:03
and immediately that doesn't do anything, so you can see here there's still a little bit of leakage current flowing to the output, and that's because, like I said, it's like a faucet, you turn it off and it doesn't immediately all get drained, so it's still flowing a little bit,
25:22
but a tiny moment later, then the output goes to zero, and that is incorrect, because one NAND zero should be one, however, here's the important part, you have to then turn it back on and restore the value, otherwise, if you keep it off,
25:41
then all the transistors in the system are gonna turn off and your system just powers down and you can't do anything useful, so the key here is that we have an incorrect output, but only for a small amount of time, because we have to turn, we can't get away with leaving it off, because if we leave it off
26:03
for too long, then it turns off, but not all hope is lost, because that mistake for that tiny amount of time will actually propagate if it's done at the right place, so here's like a tree built from multiple NAND gates,
26:22
and let's say the voltage glitch caused this output to be incorrect, but that's an input for these two gates, which is an input for these two, and these two are inputs for that one, so you effectively created mistakes in about half the circuit, but that's the ideal case. In reality, it's a lot harder to determine
26:43
how the error's gonna propagate, because if you think about the truth table for NAND logic, there's only one way of getting one and three ways of getting a zero, or the other way around,
27:03
but my point is that it's not even to get the right output that you want. The upshot, though, is that we can cause an incorrect output for a short amount of time,
27:21
we have to wait for it to propagate, and like I explained before, because these logic gates aren't completely symmetric, it's easier to reach one state than the other, the system can correct itself, and this is actually by digital system design. One of the reasons why your computer is so robust
27:41
is because it can correct mistakes like this. We are injecting a voltage glitch manually, but glitches are a known thing in digital logic, and a lot of times it happens without any external sources, so circuits are designed to correct itself,
28:00
which is why we need to find specific targets with a voltage glitch to actually get them to really do what we want, and the ideal case is that one error propagates through much of the circuitry, and examples of that includes arithmetic instructions,
28:20
AES hardware, like branching in processors, anything where you can imagine changing the input a little bit will create a lot of gears turning metaphorically and result in a widely different output. So that's a theory, you guys can wake up now.
28:41
We're going to get to the actual practical part, which includes finding out where to attack, what to attack, and a little bit of automation, and that'll make more sense when we get to it. So what do I mean by where to attack?
29:01
So this here is an image of the PCB where the Vita's main system chip Kermit is laid on top of, and with anything as complicated as this, there's dozens of different voltage rails that power different parts of the chip, including like DRAM and IO pads and so on,
29:22
but we only care about the power pins that go directly to the transistors, so we need to find which pin that corresponds to. To make things worse, each power voltage rail is actually connected to dozens of pins, so it's not just like one pin corresponding to one thing,
29:43
and there's 724 pins. But I can show you a way that we can go through this like manually. It's not easy per se, but it's doable, and it's doable over a weekend or two.
30:04
And it's a process that involves mapping out the pins on a PCB. And so to back up, of course, we don't have a data sheet, I think it's a lot easier if you have like a commodity chip where you can just look up the data sheet and see like where each pin corresponds to,
30:22
but if you have a system with a completely custom-designed chip, you won't have that resource. So one thing that you have to do though is what's called PCB de-layering, and I think there's been talks about in the past, which I think I recommend you guys look up,
30:40
but the takeaway is that it's relatively inexpensive and anyone can do in their own home with the right tool. Fortunately, someone by the name of Bytefull uploaded full PCB scans of the Vita's board, and that's fortunate for me
31:01
because I don't have to breathe the fiberglass particles when you start removing the solder mask. So with the solder mask gone, you see the copper layer corresponding to the different pins here. And one thing I want to point out here is
31:21
you can see that some of the pins look like pins and other ones look like they're part of a sausage or what do you guys call it here? Anyways, the ones near the center is more likely to be power related
31:42
because if you think about designing a chip, you want to put your power sources near the center so they can dissipate evenly and the distance to each component should be relatively close. So what we want to do is we want to take one random pin
32:02
and we want to see where it is connected, what power source is connected to and what other pins is associated with it. And to do that, we just mark the pin. So the convention I'm going to be using is I will be marking one layer in red and then I will go down another layer
32:20
and then I will use orange to show a new marking on that layer. So here you see a bunch of these small dark holes. These are called vias. They're used to connect the metal layers, the two metal layers together. So when you have a via, that means there's an electrical connection from one layer to the other
32:42
and for that specific copper pad. So we go down one more and you see the vias on this layer are a bit bigger than the last one. And then we can just keep going down until eventually we reach a copper plane that this via is connected to. And I'll put an outline around this so it's more clear.
33:05
So this is where the source for that power pin comes from and I'm not going to show you the actual, I guess the actual power, the chip that powers that plane
33:20
because it's off this image. What's important here is that there's many of these other vias on this plane that I've highlighted in red. So all of these are connected together on this layer. Now we can work backwards and do the same thing and basically find where it's connected each time
33:41
and highlight the copper that's associated with. And then we get to the top and we see that all of these little sausages are connected together. And these are 35 pins that are corresponds to one voltage rail and that means
34:02
we only have 689 more to go. But the good news, 245 of them are not connected and you can just see that by looking at layer one to layer two, there's no connections. 175 of them are ground, which means on the first
34:21
or second layer, you can just easily see they connect to the large copper pad that most other things are connected to. So really there's only 269 pins left. It's not the best thing to be doing on a Friday afternoon, but if you're me,
34:42
what else do you have, right? So this is what the chip looks like fully mapped out. The red ones are the different voltage rails. The different shades corresponds to the different voltage rails. And the other colors are data pins
35:00
that are not really relevant here. I just did it for extra credit. So we found nine different voltage rails. How do we know which one's the right one? And to find out, we just basically try each one. Brute forcing nine things isn't that bad.
35:22
We write a counter that increments like five different registers. And then we just hook it up to the computer and we just try voltage glitching each one until we see one of these counters change.
35:40
So why does that work? Well, remember, when we create a voltage glitch, it effectively creates a mistake in some computation. So here, because of how tight that loop is, most of the work the processor is doing is going to be incrementing or decrementing these counters.
36:01
And when the glitch hits, it will probably hit one of the ALU operations which will cause a mistake like this. So we have this tool that we found which is a voltage glitch.
36:23
We found the right power rail. We can arbitrarily create mistakes in the computation, but what can we do with it? So from previous talks and from other resources, the clear way to go is to bypass signature checks.
36:44
However, on the Vita, that's a bit hard for us to do. And some of the reasons include we don't really have examples of what the boot loaders look like decrypted. So we don't really even know where the signature is. And we don't know if there's other kinds of checks like SHA hashing or anything like that.
37:02
So it's just hard for us to tell if our glitch worked and it bypassed the signature, but something else failed, or if the glitch didn't work. Instead, we looked at something that's easier to understand, which is the boot partition headers.
37:20
And the boot partition contains the boot loaders. It's a special partition format that's not standard. However, it is easy to understand. It's unencrypted, it's unsigned. And the fields, you know, you are not that many and you can kind of guess what they mean. We'll just focus on looking at the header size field
37:43
because spoilers, it worked. And the size field is checked to be less than 0xde blocks. We found this out through basically a trial and error. So we tried writing 0xff and it didn't boot up.
38:04
Then we tried writing 0x40 and it worked. Then we tried writing 0xe0 and it didn't work. And then through this kind of manual binary search kind of thing, we found that this was the largest value before it doesn't boot up.
38:24
If, you know, if the check fails, it halts. And if it passes, then we can see that the actual boot loaders are read from the storage. So what happens if we manage to bypass the size check?
38:42
Well, the theory is that it will overflow some buffer because, you know, why do you check the size if you don't have a static buffer, right? So the plan is we need to sniff
39:00
the storage controller traffic. And that's, you know, just some external pins. We have a MOSFET, which is basically just an electrically controlled switch that will do the shorting that we discussed earlier. And for, we need a FPGA to control that MOSFET
39:21
because we need very precise, like nanosecond level timing. And the reason why is because, so this is, you know, the process to find the right parameters to glitch with. The important thing here is, you know, we wait until that boot partition header is read
39:42
and we know that at some time, some short amount of time after the header is read, it will do that size check. But we don't know when that is. So that's what parameter N represents, is the offset from reading the packet to when the size check is done. Then we do the glitch and we, you know,
40:03
hold the power off. We short it for an M amount of time. And basically, the reason why we vary M is because, remember, when we're glitching, we don't really know what results we're causing.
40:21
So the longer you hold a glitch, the results vary wildly. And if you hold it for too long, then the system shuts down. So we basically, you know, just have a script that looks at every possible N and M value and, you know, try different ones.
40:43
So how do we actually implement this? So I use the ChipWhisperer, which is a open source hardware hacking platform. And one of the reasons why it's so nice is because you can use Python to script all that process that I talked about earlier.
41:02
Has an FPGA and a MOSFET, which is the only thing you really need. And we added a custom trigger for monitoring the storage traffic. Also, we designed a custom board.
41:20
And the only reason why is really to manage all the wires because, you know, there's all the wires to the different pins for the storage controller. And then there's a couple of GPIOs for like status indicator and stuff. So it's easier to just put them all on a board. And we also use this board to dump and flash
41:44
the storage to, you know, put our payload on. And it connects directly to the ChipWhisperer. Here's what it looks like hooked up. I made very liberal use of transparent tape.
42:01
And one thing I want to point out here that I haven't mentioned before is that we actually connected, we removed the clock of the Vita and we connected it directly to the ChipWhisperer. And the reason why is that we found that if you synchronize the two clocks, the device's clock and the ChipWhisperer's clock,
42:22
then when we are searching for those M and N parameters, there's less drift and it makes the results more repeatable. So this is what it looks like hooked up. Once again, I love tape.
42:41
And so the final piece that we had to put together was actually help from someone in the X switch hacking community who told us to slow down the clock even more than what we already did.
43:00
And it turns out, you know, if you're running the clock too fast, it creates too much noise and that could disturb the glitching process. So, you know, take away. If it's not working, try slowing down the clock. So ran this all night and woke up the next morning, looked at the logs and we found a vulnerability.
43:22
And this is the boot ROM SHA-256 hash. So state of the Vita in 2018.
43:41
We managed to dump every part of it. The boot ROM unfortunately is not too interesting. They don't have any keys in it. They don't have anything that's, the attack surface is just so tiny. They don't have like a USB stack in it because that's crazy, right?
44:03
And, you know, we've managed to dump all the code we can find on the system. So what have we learned? So let me get a little philosophical for a moment. Sony had a history of crypto failures.
44:23
I think most of you here know about all of these, but if not, you know, history lesson, PSP didn't check code signing in the beginning. PS3, the infamous fail overflow, ECDSA factoring.
44:41
And recently we found on the PlayStation Classic, they shipped the private keys for the firmware updates on every single device. But the Vita is actually a very nice, you know, work in terms of security. Unfortunately, you know, can't speak
45:02
to amount of games or market share. Key reasons includes the secure boot is pretty simple. All their, you know, cryptographic stuff is relatively simple compared to, you know, other Sony devices.
45:23
We didn't really touch on the ARM processor at all, the main one that your games run on. But they do implement most modern exploit mitigation. And this was back in 2012, which where, you know, a lot of stuff like KASLR or kernel random
45:42
address space randomization isn't standard. They implemented that, you know, way back in 2012. And they, you know, instead of trusting TrustZone, they have a dedicated crypto processor. But not everyone is perfect.
46:00
There is a slight issue with how they chose their bootloader description keys. And to be clear, this key protects every other key in the system. Now, after we dumped the boot ROM, naturally, the next thing we did was find this key.
46:21
And it is a single byte repeating. But here's a little, let me pull back the curtains a little. Before we dumped the boot ROM, a couple months before, our friend XYZ, now you can decide if he has nine IQ or nine million IQ.
46:43
XYZ decided to brute force the AES128 key. And for legal reasons, we won't share with you. But let's just show you an unrelated picture
47:00
I found on Amazon. So, lots of people to thank. These are just a few.
47:23
I want a special shout out to Zerpe, who managed to get Linux running on the Vita last week, which was very impressive. And now they're trying to write all the drivers for it. So if any of you are interested in that and want to help, I can put you in touch with him
47:43
if you check us out at the Ninten Bros assembly later on. Everything I talked about will be posted on GitHub. If you want to know more about Vita hacking and reverse engineering, the Henkaku Wiki is a good resource.
48:02
And if you want to write Vita Homebrew, the Vita SDK, which we helped with early on, is a good resource. With that, I would like to open up the questions.
48:25
Hey, great. Thanks a lot. Great to see how much fun you guys had hacking the thing. Really cool. We have five to seven minutes for Q&A, so please line up at the microphones. And we have some questions, probably.
48:42
So I think microphone number five, I see somebody. It's the same, yeah. So the AA is the key for the bootloader. Is this a joke? Since it's totally not effective at all in my mean.
49:03
So yeah, this was interesting. So at first when we found this, we thought for a long time that we actually, so we thought we accidentally had a debug build. So we thought they accidentally shipped a debug build or something and that's where the key was from. But turns out it is the bootloader
49:23
that is used on retail devices. I think the reason why it slipped out of checks is because they only ever use this key encrypted. They have a crypto processor.
49:41
So in addition to food, there's a separate crypto processor that only food can communicate with. And it's the one that does all the encryption. So this key is never found in any text pages or anything or any code. It's only available in this secret hardware crypto processor.
50:03
So maybe someone accidentally left the wrong key in or whatever and nobody found out because it was hidden so well. Great, we have a question from the internet. Signal Angel, please. Thank you. Can your findings be reused in some ways for the PS4?
50:25
Probably not. No, I think the design here is mostly exclusive to the PlayStation video here. It's, I think the PS4 has some sort of similar security code processor, but it's not the same.
50:41
Also, PS4 doesn't implement as many security mitigations as Evita does. Great, microphone one, please. For your work and for your talk, you talked about you control the clock on the processor via the chip whisperer. Did you also try to clock glitch it?
51:00
Sorry, what was the last part? Did you try to clock glitch it? So I guess, okay, I didn't wanna talk into this because it's a bit technical, but clock glitching actually doesn't work on most modern processors because they use something called a phase lock loop, or PLL, which derives the internal clocks.
51:21
And when you glitch the external clock, it will be filtered out by the PLL. So most modern devices have a PLL now, which makes clock glitching not really useful. Yes. Thanks, microphone three, please. My question is very similar and I'm not quite sure whether my understanding
51:42
of PLLs is wrong, but as far as I understand, they only do clock multiplication and division. So if you change the external clock, then the internal clock should also change. And I was just curious by how much you changed the clock.
52:02
Right, so there's actually, that is true, but if you look at the very precise response function, the transfer function of most PLL, there is something, I don't remember the technical name, but it's like a delay response.
52:21
So your changes in the frequency is not instantaneous, and most PLLs are designed to not change quickly with the clock frequency. And it's a feature that they call filtering out jitters because sometimes your external clock can be a bit noisy and you don't want your internal clock to follow that noise.
52:42
So most PLLs are also designed specifically to not respond quickly to frequency changes on the outside. Thank you, we continue with microphone one, please. Since the hardware and software is similar. Can you come closer to the microphone? Okay, sorry. Since the hardware and software is really similar,
53:02
does this apply to the PlayStation TV 2 or just to the PlayStation Vita? Because PlayStation TV has HTML output and USB input output, so it will be, I don't know, all just to do it on that console too. Sorry, could you repeat that again?
53:21
The PlayStation TV, is it, is what we're talking about? Yeah, yeah, yeah. Yeah, it's all the same, yeah. It's just the same device. Yeah, because I have both and I just saw like, there is the error scene sometimes with the PlayStation TV, even if it doesn't. I actually have a PlayStation TV,
53:41
so if you'll come to the assembly later, we can. Oh, okay, okay, I will, I will. Okay, so invitation to the assembly later. We go to microphone three, please. Hi, thank you for the talk, very interesting. Would you care to explain why it's called the Octopus Exploit?
54:02
I'll give two quick explanation. I'll give XYZ, who found the exploit, his original explanation is that an octopus has three hearts and somehow when we have these three little pieces of the P address table, one piece pointed correctly,
54:23
one piece pointing to the food private memory and one piece pointing to the correct data, that's like three hearts. That doesn't make any sense to me. I retconned an explanation, which is the P address list is kind of like eight octopus legs
54:41
grabbing onto DRAM, which makes more sense to me. So you see the P address list here, that's supposed to be the three hearts. Yeah, total, makes total sense, right? Makes total sense. Microphone number two, please. Yeah, so my question is the initial bootloader
55:00
of the food processor, where is that actually stored? Is it like in Flash or is it in ROM or what is that? This is actually a very interesting question. I didn't want to get into it, but the boot ROM is never mapped anywhere in memory. So what the Vita does is on boot up, it copies the instructions for the initial boot stuff
55:23
from some secret hardware area that's never accessible through memory into the SRAM and then as the boot ROM, we call it boot RAM, starts up, it slowly wipes each part of the key derivation and other stuff as it's executing.
55:43
So yeah, it was kind of a pain to get. Wow, interesting. Last question, microphone number one, please. So while taking apart the hardware, did you figure out what the top right port on the original Vita is for? Is it used anywhere? We found this out a while ago. It's actually just a USB host port,
56:00
a USB EHCI port with a custom connector. Thanks. Yeah, great, thank you again. Great applause for Ivan, Lou and Davey, please. Thank you.
Empfehlungen
Serie mit 11 Medien