Open CTurt opened 4 years ago
This should be somehow related: https://www.psx-place.com/threads/update-2-meet-freedvdboot-by-cturte-now-supports-every-pstwo-slim-model.30204/page-4#post-248876, https://www.psx-place.com/threads/update-2-meet-freedvdboot-by-cturte-now-supports-every-pstwo-slim-model.30204/page-4#post-248904, https://www.psx-place.com/threads/update-2-meet-freedvdboot-by-cturte-now-supports-every-pstwo-slim-model.30204/page-5#post-248923.
Probably even for PS4: https://www.psx-place.com/threads/update-2-meet-freedvdboot-by-cturte-now-supports-every-pstwo-slim-model.30204/page-5#post-249116.
Not exactly ps2 or ps2 but do you think this would work on the PSX-desr (dvr) consoles? as from what I can tell uses ps2 hardware but also xmb?
You guys have probably already thought about this, but I'll say it just incase. Its highly probably that when you guys find the full exploit and make it public, Sony will release a new patch/firmware that breaks it and they might not leave any exploit areas this time. According to this page they updated the PS3 system software as recently as late March this year.
The only ways I can see this not being patched are:
Either way, I hope this adventure goes well and even if Sony patches it out it will be cool while it lasted.
Yeah, I didn't realize PS3 still gets updates. The bug is already public, so not much harm in keeping this thread in case anyone wants to look into it further, but personally I'll probably just wait and see if it gets patched before investing any effort.
IF it ever gets patched, the HFW and a CFW could still use the old module.
Hey CTurt When I was attempting to pop in Freedvdboot into the PS4 I think there are some vulnerability’s in the 7.50 firmware I’m on
I thought update release was over for PS3,besides even if they patch the firmwares it’s still gonna be breached at somehow even if they try to make a big attempt it’s never gonna yet be patched so Sony thinks, they will always make fail attempts even if they think 🤔 they patched the firmwares! And not make the codes excutable.💁🏾♂️
I wanted to make a thread about hacking the PS3 DVD player since it was determined that the PS3 seems vulnerable to the same bug. Please be aware that this will be a long term project, and that I don't actually even own a PS3 currently - so collaboration here would be much appreciated.
Motivation:
I'm aware that there already exist convenient personal use exploits for the latest PS3 firmware triggered through the web browser, however the goal I'm interested in is different from just a personal use exploit: Instead, this would allow developers to easily distribute their own homebrew games in physical media format, which would be 100% compatible with all unmodified PS3s (I assume it is a reasonable requirement to request users to update to the latest firmware, which most official games also did when released), ultimately making the PS3 a completely open platform, similar to what the Dreamcast scene achieved.
Method:
I've discussed with developers of the RPCS3 emulator project, and the outcome was that that emulator won't be able to support the DVD player any time soon, so all reverse engineering will have to be static analysis, and all testing will have to be done on real hardware. This is unfortunate, but not a deal breaker.
The PS3 DVD player lives at
dev_flash\bdplayer\bdp_BDVD.self
, and can be decrypted and decompressed to an ELF with fail0verflow'sunself
utility.I was pointed to these Ghidra scripts to help load and analyse the binary.
Current status:
Searching for the VIDEO_TS.IFO header magic string
"DVDVIDEO-VMG"
I was able to find amemcmp(ifoHeader, "DVDVIDEO-VMG", sizeof("DVDVIDEO-VMG") - 1)
call in the function at0x25ac48
which lead me in the right direction to the IFO parsing code.I think I've identified where the vulnerability I exploited on PS2 is in the PS3:
Recall that the PS2 bug was a call to
getDiscData
where the size was(getU16() + getU16() + getU16()) * 8
?It's hard to say for sure, but the code at
0x260f04
seems like a possible match; it computes a variable by adding 3 consecutive 16-bit integers and multiplying by 8 (and then also adding 7 - which is new):This value is then passed to the function at
0x216014
, which looks like a possible candidate for agetDiscData
-like function as it contains a loop and uses the constant value0x800
(sector size).If anyone else is interested in helping out, please feel free to post any other notes on reversing this code!