i am assuming the structure of eboot and metainfo or data didnt change.
except the key to decrypt these.. since the chain of trust is changed, everything came from lvl0, so we seem cant solve the encryption from start, then that is why i suggesting solve the symmetric ase128 from some given bytes.
btw, npdrm doesn't go to every games. i think most retail disc eboot.bin doesn't have ! only those from psn is npdrm?!
sammojo via Blade86's comment, no, you can't just 'cut out' the NPDRM stuff. The NPDRM stuff is what decrypts the rest of the SELF. A debug eboot is only useful because its contents isn't NPDRM encrypted, so we can use sony's SDK tools to unfself and some other tools to resign it. But the sdk tools wouldn't work on NPDRM eboot, with or without the NPDRM header.
WTF Name, we don't know the first 4 bytes. Those 4 bytes are the first 4 bytes of the SCE header, not the metadata info. We have absolutely no information about metadata info encryption until we have appldr keys I believe. Also they're encrypted with aes256. I think both disk and psn stuff can use NPDRM, but they don't always? If you're talking about clandestine, no they don't have the keys.
Actually I don't think any of the scene release groups have the keys or we'd be getting fixes just as reliably as 360's scene. I'm assuming only kakaroto and mathieulh have the keys along with a select few others who aren't about to share. Scene groups usually rely on waiting for debug eboots to be found and resigning them, or in cases like Uncharted 3 and Sonic, they actually try to patch make an eboot that will work from scratch.
Both methods can take awhile since Sony's more strict about securing down those eboots now. The exception is with however TB/Paradox gets theirs. Also, JB2 (or TB/True Blue) is 3.55 cfw, they just find debug eboots, sign them to 3.55, then encrypt them with another layer of DRM stuff to protect themselves.
i doubt it for example , the first encrypted section started at offset 0x980 (seem to be always true) , after unself.exe the 3.55 eboot,
this section decrypted n give first few bytes of .ELF, this is not simply the header, it came from original encrypted section at 0x980
if the section is encrypted by aes128, and we know the first block decrypted, then i think it possible to brute force the key to decrypt meteinfo
btw. even payload of jb2, found, ppl may rewrote it to allow non jb2 user, whats the point if we cant make 3.6+ to work backward on new cfw?
WTF Name 980 is where the ELF data begins. It is not the ELF data you should be looking at but rather the metadata info. The offset to the metadat info is in the header so once you know that offeset, you can find where the metadat info starts.
It is a static key stored within the metadat info that decrypts the first 40 bytes of the metadata and once you have that first 40 bytes, this 40 byte key is then used to decrypt the rest of the eboot sections.
Thas as far as I understand it anyway. As the metatdat info key is encrypted, we can't get the 40 byte key to decrypt the rest.
When you run unself on a self, it strips the header completely BUT only after decrypting it using the 40 byte value gained by decrypting the metadata info.
sorry, i mesh up those.. got another idea if new 3.6,3.7 eboot.bin use diff. method to decrypted, then may be we can focus on chaning metadata, not the segment data, so let the 355cfw to decrypt meta. then the key become the right key to decrypt the rest.
so we should encrypt meta by 355key?
this make easier, i think, just brainstorming..
Last edited by WTF Name; 02-22-2012 at 08:31 PMReason: Automerged Doublepost
i have a TrueBlue and CFWv2, but i have only just noticed that OpenPS3FTP does no longer load, it just returns to the XMB, am i supposed to do something else?
But he said that his method requires to change a the signature of the eboot.bin into a devkit, changing the part of the signature, but no all, the most important part is the decrypted elf, if he has the method to decrypt 3.6+ games, he must share with us, i think this method is not very simple but all we can try to decrypt the 3.6+ games
Reply With Quote
