02-21-2012 #751WTF Name Guest
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?!
02-22-2012 #752tapion64 Guest
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.
02-22-2012 #753spunkybunny Guest
Modding TBv2 CFW
It looks like I have to install TBv2 so the latest cracks work. (DRM dongle)
My question is if I install TBv2 CFW can I still edit the files for ReACTpsn and Spoofers to work or will that cause the TB to brick?
02-22-2012 #754WTF Name Guest
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?
02-22-2012 #755JonahUK Guest
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.
02-22-2012 #756WTF Name Guest
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..
02-23-2012 #757IHM Guest
OpenPS3Ftp and TruBlue CFW ?
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?
02-23-2012 #758mrlowalowa Guest
Maybe an huge external HDD? If the games are too big for FAT32 you could use the NTFS drivers from multiman
It's so much faster.
02-24-2012 #759WTF Name Guest
i just know that the dev for hod overkill, own a dex , i think the way to decrypt came from that, not possible in 355cfw.
02-24-2012 #760Mystic Racer Guest
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