Editing Bugs & Vulnerabilities

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
== Theoretical Hardware Attacks ==
== Unknown / unpatched ==
=== (BattleCars Exploit-Rocket League) ===
Buffer Overflow- [Current system software, Most recent version of application(SYSSW 2.57)/(Rocket League 1.03)]


We already know for certain someone out there has hacked the SAMU or stolen Sony's keys because of leaked decrypted kernels. These are some end-all hardware solutions to hack the PS4, theorized by golden. I give a score out of 10 for each.
First block all requests from:https://patch103-dot-psyonix-rl.appspot.com/


=== Power analysis against SAMU 9.9/10 ===
When you launch Rocket League it gets a stub file from:
http://psyonix-rl-529970.c.cdn77.org/BC2/versions/103/config/BattleCars_Prod/client.bin


There are theories that this won't work because...
You can redirect that to load a huge file and/or a specifly crafted payload instead of the stub. If you use the proper file, it doesn't need to be that large, the example below is under 9mb.
* SAMU silicon spoofs hamming weight (prevents differential power analysis and EM analysis)
* It is running too fast and not feasible since cost is too high
* You cannot slow down the SAMU clock since it is internally checked
* Some more issues?


If there is some sort of main CPU/SAMU PLL bypass we might be able to slow the clock down really easily, otherwise we must inject our own clock signal. I believe the SAMU clock is controlled by syscon? If the check is in syscon then we can just patch it out. Maybe write a custom Linux fork that never loads into usermode but just sits and constantly decrypts different self/sprx files. We could communicate with this Linux fork over UART. This attack only needs to work once to recover some keys.
Your file will be loaded into memory, when the file is large enough/a game is played and/or you wait enough time you can consistently cause a buffer overflow and the application will crash.


=== SAMU power/clock glitch fault injection 5/10 ===
Depending on how you craft your payload, you may or may not have to do any of that get it working. There are no checks performed at all on file size, content, ect.


During an AES round we might be able to do some SCA by injecting faults. See the paper from umass.edu in the section below. We would write a minimal operating system to reboot into after exploiting an older firmware. This 'operating system' will simply shutdown most of the CPU cores and pin one core. This code would communicate with the SAMU and do everything the normal SCE SAMU driver does for decryption. We can then use UART output from CPU to time our glitch attacks. The faulty data retrieved by our custom SAMU driver might be able to reveal secret key data. This attack only needs to work once to recover some keys.
Staying on the start screen for long enough can also trigger it.  
If your payload isn't created properly it will take much longer to execute.


=== SAMU backside UV/IR fault injection 3/10 ===
If you are having problems getting this working, you can use the example file, causing an almost instant buffer overflow upon launch of the application.


Just as the title states. Very expensive to setup and do properly. If we can flip an even number of bits it the encrypted SAMU SRAM region of the chip (even since ECC parity bit), then some sort of side channel analysis might be able to be done to recover key material. Some silicon reverse engineering would be involved to find the SRAM region on die.
http://sceecatalogs.vidzone.tv/469/vidzone_469_US.db.psarc


"Moreover, it is no longer possible to hit a single SRAM cell with the current etching technologies, since the width of the gate dielectric is now more than 10 times smaller than the shortest wavelength of visible light." To get an idea of the cost of this equipment... "A class of threats which cannot be ignored if the attackers have access to a larger budget (above the aforementioned $3000 and up to millions of dollars)" (http://euler.ecs.umass.edu/research/bbkn-IEEEP-2012.pdf)
If your payload is crafted properly, you should be able to get it working withing 10-20 seconds of launching the application
.
A carefully crafted file may be able to exploit this or similar issues to gain code execution, among other things.
It may also be possible to alter gameplay via similar methods.


The fault injection is all infeasible unless some elite hackzor came out of the woodwork. We only need to have this work once.
No payload will be provided at the moment because this is very experimental.  


=== SEM/FIB/microprobes 2/10 ===
=== VidNow (TCP Buffer Overflow) ===


We might be able to readout the bootrom with some microprobes? Sniff data lines somewhere? The SAMU SRAM memory is encrypted so we would have to probe the LM32 instruction bus or something... infeasible but possible.
A possible exploit has been found in VidNow app from the PSStore App.


=== USB ===
PATCHED: Sony has hotfixed this exploit via content hashing the file while in transit. Some people have managed to reverse the hotfix but the method is not known - the PS4 checks the content. hash HTTP header from the HMAC header.


The FreeBSD USB stack has been theorized, by a well know security researcher, to contain some high profile bugs. A dongle might just be possible. For example, last year someone ran a fuzzer on the Linux USB stack and found some crazy bugs: https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs_usb.md
When you launch Vidnow for the first time it gets http://sceecatalogs.vidzone.tv/386/vidzone_386_US.db.psarc. This file is 5mb.
This file loads into a 60k tcp buffer. No checks are done at all on the files size/hash/contents. Therefore, it is possible to redirect Vidnow to load a substitute file. When vidnow is redirected to load a large enough file the TCP Window buffer is overrun,somewhere between byte 34,125,000 and 35,000,000 of the substitute file. Despite the buffer overflow and crash, the substitute data is still transmitted and the application only throws the exception when another tcp packet is sent. As a result, the application crashes and the console locks up for a minute. Directly before the console resumes normal operations after the crash, an unusually large number of tcp (RST) packets are sent. While no exploit that makes use of this crash is currently available, a carefully crafted file '''may''' be able to exploit this or similar issues to gain code execution, among other things.


=== Bluetooth ===
==== Crash Timeline ====
17:17:39.899984000 Request
17:17:40.000655000 Request
17:17:40 (System locks up) Crash
17:17:44.957274000 Response
17:17:48.500481000 Response
17:17:48.500567000 Response
17:17:50.356427000 (System no longer locked up) Console Regains Control (74 byte packet sent)
17:17:50.357555000 Contacts Crashlog Server/System Operation Resumes


Look at Blueborne and CVE-2017-0781. There are probably some bugs in the Sony/FreeBSD Bluetooth stack. Sony has a habit of ruining their own copy and paste. One of the reasons fail0verflow decided to attack the DS4 controller firmware was because it had a nice interface to the kernel which could contain bugs.
=== Sandbox Exploitation ===
For some reason the system fails to perform any checks/verify certain sys library's before installing them. This allows you to replace those library files with your own binary. The system will install your packaged binary to the HDD as if it were a regular update. In order to run this binary, you need to meet all the requirements listed below.


== Software Bugs ==
''Running your own code in sandbox requires 4 things:''


=== SnagFilms ===
1.''Disabling SHA-1 Checksums'' '''✔'''
useSha1Checksums = "false"
OR
-Change SHA-1 checksums to match modified pkg


A possible exploit has been found in the SnagFilms app in the PS Store app.
2.''Generate a valid signature/disable or bypass signature authentication'' '''✖'''
Hash of container + Magic Number form signature
-Hash can be computed from modified files
-Magic Number = '''''???'''''


Arbitrary code execution in memory has been demonstrated, although so far the system will throw an exception in the programs memory before the payload finishes loading.
3.''Repacking Containers'' '''✔'''
Lib pkg not signed or encrypted. You can modify everything as long as you don't change the structure.


If you craft a small enough payload and/or a payload that loads without causing an exception in program memory, you can most likely get usermode code execution.
4.''Crafting proper binary'' '''✔'''
Binary files in sandbox aren't signed or encrypted.
If you use the proper version of the compiler (Get the ver info from the original binarys) you
can craft a binary that's accepted as valid.


https://www.psdevwiki.com/ps4/File:5OrSFCa.jpg
Assuming you can get code running disabling sandboxing is trivial.  


=== BattleCars Exploit (Buffer Overflow in Rocket League) ===
=== Leap second 23:59:60 bug ===


Back in time, it affected the latest System Software version (2.57) and the most recent application version (1.03).
http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat Leap second 2015 June 30, 23h 59m 60s should theoretically not be a problem, since PS4 is based on BSD which can implement 23:59:60.


First block all requests from:https://patch103-dot-psyonix-rl.appspot.com/
== Patched ==


When you launch Rocket League, it gets a stub file from:
=== Decryption of any post-prototype and low FW PUP ===
http://psyonix-rl-529970.c.cdn77.org/BC2/versions/103/config/BattleCars_Prod/client.bin


You can redirect that to load a huge file and/or a specifly crafted payload instead of the stub. If you use the proper file, it does not need to be that large, the example below is under 9MB.
* Discovered by flatz.


Your file will be loaded into memory, when the file is large enough/a game is played and/or you wait enough time, you can consistently cause a buffer overflow and the application will crash.
* A bug in the handlers of PUP decryption allows a PS4 on 1.62 or below to decrypt any PUP (retail, testkit, devkit, beta, prototype) with a version above 1.00 (post-prototype) or any PUP <= current PS4 FW.


Depending on how you craft your payload, you may or may not have to do any of that get it working. There are no checks performed at all on file size, content, etc.
* SM code doesn't reset state after SMI checks failure, so to decrypt arbitrary PUP, you need to ignore mailbox error after PupDecryptHeader cmd (1).


Staying on the start screen for long enough can also trigger it. If your payload is not created properly, it will take much longer to execute.
* Fixed around 1.70.


If you are having problems getting this working, you can use the example file, causing an almost instant buffer overflow upon launch of the application.
=== Decryption of any userland SELF from 1.00 to 3.70 ===


http://sceecatalogs.vidzone.tv/469/vidzone_469_US.db.psarc
* Sony reused keys from 1.00 to 3.70 on userland modules. as a result, any userland module from those versions can be decrypted on a PS4 between 1.00 and 3.70.


If your payload is crafted properly, you should be able to get it working within 10-20 seconds of launching the application.
* Fixed in 4.00 with the introduction of new keyset.


A carefully crafted file may be able to exploit this or similar issues to gain code execution, among other things. It may also be possible to alter gameplay via similar methods.
=== Internal table of symbols kept in kernel on very low versions ===


No payload will be provided at the moment because this is very experimental.
* Sony used to have two tables of symbols on very low versions: internal and external (internal had all symbols, external had 75% of them).


=== VidNow (TCP Buffer Overflow) ===
* Seen in 1.01 kernel. Patched somewhere around 1.05.


A possible exploit has been found in VidNow app from the PS Store App.
=== External table of symbols kept on low versions ===


PATCHED: Sony has hotfixed this exploit via content hashing the file while in transit. Some people have managed to reverse the hotfix but the method is not known. The PS4 checks the content hash HTTP header from the HMAC header.
* After Sony removed internal table, they still kept the external one.


When you launch Vidnow for the first time it gets http://sceecatalogs.vidzone.tv/386/vidzone_386_US.db.psarc. This file is 5MB.
* Seen in 1.01-1.76 kernels. Patched somewhere around 2.50.
This file loads into a 60k tcp buffer. No checks are done at all on the files size/hash/contents. Therefore, it is possible to redirect Vidnow to load a substitute file. When vidnow is redirected to load a large enough file the TCP Window buffer is overrun,somewhere between byte 34,125,000 and 35,000,000 of the substitute file. Despite the buffer overflow and crash, the substitute data is still transmitted and the application only throws the exception when another tcp packet is sent. As a result, the application crashes and the console locks up for a minute. Directly before the console resumes normal operations after the crash, an unusually large number of tcp (RST) packets are sent. While no exploit that makes use of this crash is currently available, a carefully crafted file '''may''' be able to exploit this or similar issues to gain code execution, among other things.


====  Crash Timeline ====
=== IDPS leak in sceSblAuthMgrDriveData on low retail versions ===


17:17:39.899984000 Request
* Discovered by flatz
17:17:40.000655000 Request
17:17:40 (System locks up) Crash
17:17:44.957274000 Response
17:17:48.500481000 Response
17:17:48.500567000 Response
17:17:50.356427000 (System no longer locked up) Console Regains Control (74 byte packet sent)
17:17:50.357555000 Contacts Crashlog Server/System Operation Resumes


=== Leap second 23:59:60 bug ===
* Dumping IDPS from 2 EID blocks from kernel: sceSblAuthMgrDriveData(0, in_buf, 0x160, out_buf, 0xA4, 1). Pass 0x160 bytes at 0x90C00 from sflash0s1.crypt into `in buf` and dump buffers.


[http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat Leap second 2015 June 30, 23h 59m 60s should theoretically not be a problem, since PS4 is based on BSD which can implement 23:59:60].
* It's possible because someone from sony forgot to encrypt output, that's how it was patched later.


=== 6.20+ DevKit Specific Bug ===
* Patched between 1.76 retail and 4.05 retail. Works on any TestKit/DevKit FW.


<pre>
=== Crashdumps encryption using symmetrical key and same key across fw ===
The Development Kit comes with breakpoint feature that can pause the execution of an application program when the application program accesses a certain location in memory. This data breakpoint is only triggered when an application program accesses memory, but, because of a bug that occurred in version 6.00 of the system software, such breakpoints may be triggered when the kernel accesses the memory of an application program. When this happens, the PlayStation 4 system determines that a serious error has occurred and automatically shuts down the Development Kit.
</pre>


=== 6.50 DevKit Specific Bug ===
* [https://fail0verflow.com/blog/2017/ps4-crashdump-dump/#crashdump-decryptor see FoF article]


<pre>
* Patched on 4.50. Tested between 1.01 and 4.07.
This bug occurs regardless of the method used to set the data breakpoint (occurring both when a breakpoint is set with the host tool and when it is set with the sceDbgSetHardwareBreakPoint() API). Version 6.50 of the system software will be fixed so that data breakpoints are not triggered when the kernel accesses an application program's memory (thus returning to the behavior of versions of the system software prior to version 6.00).
</pre>


== Reference sites ==
== Reference sites ==
* http://www.vulnerability-lab.com/
* http://www.vulnerability-lab.com/
* http://seclists.org/
* http://seclists.org/
Line 121: Line 131:
* http://www.cvedetails.com/vulnerability-list/vendor_id-6/Freebsd.html
* http://www.cvedetails.com/vulnerability-list/vendor_id-6/Freebsd.html
* http://www.cvedetails.com/vulnerability-list/vendor_id-6/cvssscoremin-9/cvssscoremax-/Freebsd.html
* http://www.cvedetails.com/vulnerability-list/vendor_id-6/cvssscoremin-9/cvssscoremax-/Freebsd.html
* http://www.doxed.site
 


{{Reverse Engineering}}<noinclude>[[Category:Main]]</noinclude>
{{Reverse Engineering}}<noinclude>[[Category:Main]]</noinclude>
Please note that all contributions to PS4 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS4 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps4/Bugs_%26_Vulnerabilities"