Yep, that's the one I used. The downloaded zip is called psfreedom-iphone3g-hermes.zip and the containing zImage and android.img.gz are both timestamped Sep 21, 2010.
Originally Posted by kachijs
at RiPPERD: Sucks big time. I didn't even use my BD-drive that often. It was X-Mas and I bought a new game for the holidays (Buzz). Switched the PS3 on, forced to update to 3.0 and halfway during the start of the game the drive froze. From then on it's been busted. Happy X-Mas from Sony. Seems there's already a class action suit going on. Check the Wikipedia article on PlayStation 3 system software (sorry, I'm not allowed to post URLs yet due to forum policy)
As far as my attempts go to fix the /app_home/PS3_GAME error, I've hit a dead wall.
I replaced the android.img.gz and zImage files in /private/var and JB'd my PS3. Jailbreak works fine, but still getting the error after I select a game in Open Manager and then select /app_home/PS3_GAME/. There is also no game artwork whatsoever visisble when the /app_home/PS3_GAME menu entry is highlighted.
I even went as far as unzipping android.img.gz and mounting it on my Linux box. There I found that the payload is called by a script in /bin/psf.sh:
Here we see the exploit being started by insmodding psfreedom.ko. There's a payload.bin located in /lib which used to be copied to /proc/psfreedom/payload but is now commented out.
# cat bin/psf.sh
#cat /lib/payload.bin > /proc/psfreedom/payload
if [ `cat /proc/psfreedom/status` == `echo DEVICE5_READY` ]; then
#rmmod -f psfreedom.ko
/lib/payload.bin contains the following strings:
NOTE: I had to remove 2 at-symbols from the output above and below, because the forum is interpreting them as part of an URL, which I'm not allowed to post yet, because I'm a new forum user.
# strings payload.bin
I got the payload_dev_no_bdemu.bin from PSFreedom's Github repo (where it's actually called payload_dev_nodbemu.bin). It's different from the original payload.bin:
In order to make sure the dev_noBD payload would get loaded I replaced payload.bin with payload_dev_nodbemu.bin and uncommented the line in the psf.sh script which copies payload.bin to /proc/psfreedom/payload. I then gzipped the android.img again and uploaded it to /private/var on my iPhone 3G. Jailbroke my PS3, but still the same problem when I try to launch a game using a Backup Manager and the /app_home/PS3_GAME menu item: Error 80028f14.
# strings payload_dev_nodbemu.bin
Now, either the psfreedom.ko ignores the payload.bin in /lib/ (why is it commented out?) and it has its own payload compiled in which it blasts over /proc/psfreedom/payload or I'm simply screwed and the broken BD drive in my PS3 is causing this not to work. I'm certain that psf.sh is being executed because I put some debugging echo's in there that I see appearing on my iPhone when it boots.
I think I've really exhausted my options now. I'll see if I can visit my cousin somewhere this week to see if the exploit works on his FAT PS3. His BD drive is still functional. If it works on his PS3 at least I'll be fairly certain it's my dead drive. I know I could try and buy a replacement laser or a new PS3, but it's become a matter of principle for me now. I just want to be able to play the games I paid for that Sony screwed me out of when they blasted my BD drive. I'm never ever buying a product from that company again. (Until the PS4 comes out with GT6, then I'll be Sony's bitch again).