search

PaulJenkin / PS4RaspberryPi

PiZero to host a server and emulate USB loading when necessary
230 stars 45 forks source link

v8 and v9 wont disconnect USB emulation after injecting the code #18

Closed nostradiel closed 2 years ago

nostradiel commented 2 years ago

Hallo,

I am not a developer I just wanted to let you know few issues I encountered since v8. I tried it on PiZero W and PiZero 2 W and both have the same issue for me.

When the USB emulation has happened and I press ok to close the dialog (after the notification disappears) it freezes my PS4 Slim. I figured out that is most likely the USB emulation still happening so when I disconnected the Pi after notification popup disappeared but before I close the dialog it works fine. Same issue in v9 build as well so I back-rolled to v7 which works fine for me. Also I found out that after inserting the WIFI password the pi needs to be rebooted (not just plugged off, or PS4 restart) in order to connect to home network.

Thank you very much for your hard work to create such an amazing way to JB our PS4.

PaulJenkin commented 2 years ago

@nostradiel

  1. The Screen freeze do occur randomly, when you move on to V9 please clear the cache and website date and Try. If ti freeze restart the PS4 and try again and let me know

  2. Assumption is on restarting the PS4 the power supply port of the pS4 goes off , So practically Pi also should be turned off and turned on when PS4 boots, V7 had shutdown issues so its could also be a reason

nostradiel commented 2 years ago

So I tried it like you adviced and unfurtunately it still freezes. I found out that if I pres home button after closing the dialog it sort of works to (2 out of 3).

I was thinking if it cannot be because I made small changes in one db file in PS4 to hide playstation apps from homescreen.

Btw, thank you for your response.

codefaux commented 2 years ago

Regarding the password not saving - like any modern device running an operating system, the RPi must reboot to guarantee its filesystem is flushed and synced after configuration changes. Unplugging it before it can do so, like any modern device, can cause filesystem corruption, and is not recommended. Every device for the last generation or two more complicated than a kitchen appliance requires proper rebooting and proper shutdown, and complains about simply yanking its power, for this explicit reason. Perhaps, however, the script could be modified to force a buffer flush and filesystem sync after updates, to manually skirt bad user behavior such as this. (Perhaps it could run mounted read-only, and explicitly remount read-write for the duration of the update, and then remount read-only, as a "proper paranoid" solution to user misuse?)

Regarding the presumed USB emulation disconnect issue;

PS4 kernel (and nearly every other nowadays) has a module called ASLR. Address Space Layout Randomization. To oversimplify -- in the PS4's memory, it randomizes the locations of software as it is loaded and accessed.

As for what this means for the exploit user, exploits have to try to guess where they should write their code, and it often is wrong. This is what causes exploit instability - sometimes it'll work for a dozen boots, then not work for two, then work for a full month, then not work for several days -- it's random, definitionally.

@nostradiel Specifically, how did you isolate that the USB emulation isn't stopping after code injection? How did you check that the exploit succeeded to the stage where USB emulation should be disconnected, and how did you verify that it was not disconnected at that stage? How did you verify that it works with other exploits, and isn't your specific PS4?

If you truly believe this is caused by the exploit not disabling USB emulation, it's dead simple to test. 1 - Power the RPi Zero from a USB power supply on the Pwr In port 2 - Connect the RPi Zero's OTG port to the PS4. 3 - Run the exploit as normal 4 - When you assume the RPi "should have disconnected USB" -- just unplug the USB.

If it works, repeatably and consistently (literally no less than ten times in a row) when you're pulling OTG --AND-- if it fails, repeatably and consistently (literally no less than ten times in a row) when you're NOT pulling OTG -- report back that there's a problem. You'll have to clarify how "it sort of works" if you want us to delve deeper there.