PS3 3.55 keys revoked in higher firmware help?
Hi Guys, Just wondering if this is an oversight. If the 3.55 keys were blacklisted in newer firmwares and we're modifying the firmwares anyways, could we not take out the blacklists ?? Probably easier said than done, I'm just thinking like an old school hacker...
That seems to be people's biggest issue with upgrading to newer CFW. A little (or a lot) of labor.
issues got only those with modified files...
If you've got all original files, i dont think you get an issue on i.e. REX 4.21.1
Certainly sounds possible. Must be a "if signed with xxx key" then error message. Guess if it was easy then rogero would of done it already. I remember a post once saying that the dongle cfw still ran 3.41 eboots which should of been banned, so maybe its possible.
Wonder how many lines of code the ofw is? Then remember they don't have the source code, maybe multiple levels of encryption also.
I was hoping that rogero's demo of 3.55 with higher keys inserted would work but seems to be forgotten.
Sent from my GT-I9000 using Tapatalk 2.
As far as I know the revoke list is already mooded in REX !
They keys are not blacklisted or no 3.55 games would work. And in Rebug they removed the white list so most 3.55 games should work.
And in Rogero, you only need replace orignal files or update the game. PSN games that were patched also need to be resigned to work in newer CFW..
Just test each game first and do one at a time. Lol its not really hard labor.
You just can't have modified files.
as far as I know, they only blacklisted Geohot's psuedo-NPDRM keys but not the APP keys or every blu-ray games will not work. But yes, if the app is signed with proper 3.55 private keys either if its NPDRM or APP. Then it will work above 3.55, even the latest 4.31
I tried doing this by transferring games that I converted from BD to PSN, tested using E.X. Troopers, edited the eboot to redirect every dev_bdvd to dev_hdd0 and resigned the eboot using 3.55 private keys using scetool. Transferred the game via PS3 backup and whola. It just works!
And m sure that the appldr from 4.xx CFW is not patched on all CFW that is available today, that's why most of the homebrews doesnt work after it was upgraded to 4.xx CFW. appldr is doing its job to block any non-legit eboots. But yes, this method is easy to be patched by updating the appldr to scan the eboot if SCE header is still present, if not then they going to block it. As of now, scetool cant do sign eboots while preserving the sce header.
All keys are still working - just added 3.56* and higher. And since we cannot sign proper, we patch out ECDSA checks, hence all keys work, even 0x000000000000000000 also, appldr doesnt need much patching if lv1 and lv2 are already patched because you can do it on the fly, using poke