Sponsored Links

Sponsored Links

Page 76 of 87 FirstFirst ... 2666747576777886 ... LastLast
Results 751 to 760 of 861

  1. #751
    Junior Member WTF Name's Avatar
    Sponsored Links
    Sponsored Links
    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?!

  2. #752
    Contributor tapion64's Avatar
    Sponsored Links
    Sponsored Links
    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.

  3. #753
    Banned User
    Sponsored Links

    Modding TBv2 CFW

    Sponsored Links
    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?
    Last edited by spunkybunny; 02-22-2012 at 08:07 AM Reason: Automerged Doublepost

  4. #754
    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?

  5. #755
    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.

  6. #756
    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 09:31 PM Reason: Automerged Doublepost

  7. #757

    OpenPS3Ftp and TruBlue CFW ?

    Hi all,

    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?

  8. #758
    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.


  9. #759
    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.

  10. #760
    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


Sponsored Links
