I posted this here also, but it probably fits better in this thread so here goes:
Thanks for the links guys (although I doubt this program will help us, but who knows)
Reporting in (Maybe someone had already done this and this is no big news, still, anyways):
0. I studied Paradox's EBOOT from portal 2 from the links on the second post (http://www.mediafire.com/?dt9a3biyr4uzyyd)
1. EBOOT.BIN supplied is fself (debug self?), 0x8000 maker at the 8th byte from the beginning.
2. SCEverifyrefused to read eboot's info, said that it's "devkit file"
3. readself gave next results:
Everything seems like fself, not compressed, seems like I was right few posts ago about the 80010009 error, seems like something similar to old good algo "3.41 to 3.55 manual patching" was used (decrypt self, copy unencrypted data to encrypted eboot, change headers to fself, change bits to "uncompressed")
4. fail0verflow's Unself gave error "segmentation fault (core dumped)", here's a dump:
Parts of eboots, that were decrypted seems like junk.
5. Tried unselfing in Magic PKG, it wrote "Decrypted successfully...", but this is BS, the output file is the same as above, there was an error, and eboot is the same junk as using fail0verflow's unself (checked md5).
6. Deank's EBOOTMod gave the same results.
CONCLUSION: EBOOT can't be decrypted.
Seems like sections of EBOOT are ALREADY DECRYPTED like in old 3.55 to 3.41 patches.
My guess, is TRUE BLUE payload switches PS3 to read fselfs/unencrypted data, just the same way as original 3.41 PSJailbreak done on PS3.
But 3.55 kmeaw can't read those files without True Blue. Maybe we should makefself this eboot?
Also, have anyone on 3.41 tested those releases? It may work if used creating pkg with "magic pkg's" "3 method (no edit)"
Oh, consider the time when my post was originally posted - before this update.
I thought that markers said it wasn't encrypted, so it shouldn't be encrypted, but RikuKH3 provided idea, that it can be encrypted with masterdisk, which I haven't thought about. So, take it with a grain of salt
Originally Posted by Krachwas
Sounds good to me. So change the version number in the eboot (it was in the eboot wasn't it?) and try to make a "self" eboot with the 3.55 keys.
Why it should not work?
It is in Param.SFo and sometimes as .sys_proc_param in eboot in some games. In portal 2 I haven't found it (maybe because of some kind of encryption or obfuscation?).
And another crazy idea, since 3.56-MA DH-JFW has ability to natively run fselfs (am I not mistaken?), if anyone is on this FW, you can make NPDRM (pkg) package of the patched TB game and try to run Obviously, if you're not on this FW, do not install this just for stupid test. This will say for sure, if some type of encryption/obfuscation implemented in TB releases.
Last edited by Tidusnake666; 11-17-2011 at 04:33 PMReason: Automerged Doublepost
I think, this "masterdisc" are used on kiosk consoles (Demo consoles that you regularly seen on Video Game Shop) to play games that is particularly compiled directly by developers, so they can just give a copy on these kiosk console and begin demo playing them.
Somehow they manage to work it on official games, I don't know how it exactly works, but the important is, you can play 3.6x games using this.
So to us common folk, what exactly can we do with this? i'm a complete noob at this myself but i suppose you have to throw the payload in a compatible dongle and it works kinda like an update/modification to the dongle, but what about people such as me who only use CFW 3.55 with multiman, can we just wait for a multiman release that includes a true blue payload THAT DOES NOT require a dongle to work?