Hey there.

So... you use an ad blocker. That's cool. Sometimes we do too.

But without ad revenue, we wouldn't even be here. And we might not be here much longer.

Please disable your ad blocker and click to continue.

Page 1 of 11 12 ... Last
  1. #1
    Join Date
    Apr 2005

    PS3 EDAT NPDRM Decryption / Re-Encryption Tools Are Released

    Following up on the previous PS3 EDAT File Name Restorer utility, today PlayStation 3 homebrew developers Snowydew and KDSBest have made available some PS3 EDAT NPDRM Decryption / Re-Encryption Tools.

    Download: PS3 EDAT NPDRM Decryption / Re-Encryption Tools / PS3 EDAT NPDRM Decryption / Re-Encryption Tools (Mirror #1) / PS3 EDAT NPDRM Decryption / Re-Encryption Tools (Mirror #2) / PS3 EDAT NPDRM Decryption / Re-Encryption Tools (Mirror #3) / PS3 EDAT NPDRM Decryption / Re-Encryption Tools (Mirror #4)

    To quote: Over on gotbrew irc we were dropped off some stuff from snowydew.

    The tools allow for decryption and re encryption of edat, can perform iso.bin.edat extraction, can further decrypt eboot.pbp's / eboot.bins for further game modifiying.

    Decryption of act.dat and rif keys, the re encryption part however isn't 100% since we are missing a variable or two, but we can resign them as free npdrm without Sony tools.

    A large portion of npdrm right here. It "CAN" do it, it's not implemented just yet. It requires testing though. The encrypton process is a PoC until bytes 0xb0 - 0x100 are figured out.

    There is some goodies in the files, check it out if interested in PSP, PS1, etc on your PS3.

    [@Snowydew] so very well yes, if you can use the key, find the way to decrypt what's in them, then you could very well sign it with a seperate key / patched ldr to read it as a "proper" signing, and play other ps1 games off the hard drive. It's possible, but i'm currently not seeking it out atm. However all the tools are available to the public to do so
    [@Snowydew] "if anyone wants to figure out what the bytes are for 0xb0 to 0x100 that would also massively help us since we've been a bit too busy, or if someone wants to test some things we might be able to go a bit further.
    [@Snowydew] so the decryption as it stands right now, an do iso.bin.edat, requires idps, rif and act.dat for the games. re encryption I believe it needs the “fake” signed ones, as well as an idps (not sure on the idps) however the second method only requires the idps and the .rap file. This does not cover licenseing games i believe (It could, but we haven’t tested it). The re encryption algo is in the encryption one, but again haven’t been able to test it completely (reason I was asking around on twitter awhile back).

    From Twitter: Welp, time to stop sitting on projects. Multiple versions KDSBest thanks for porting it over and helping Binaries and sources included for all decryption and encryption processes. It's a PoC, but usable.

    According to Snowydew, it could leave to people resigning PS1 games into the eboot.pbp's to run PS1 games , but the iso.bin.edat still needs studying:

    We haven't fully documented much of it (because the need for "Examples" to see what are in there for a variety of tests). However sandungas might be able to help if he still has that txt file from way back somewhere, there are other smaller things we haven't fully documented, however we would like that if anyone does, please post it on the wiki for others.

    The only things I have personally looked at with the few others were the iso.bin.edats and that they're .cue files with a header, which is the most likely the decryption key for the eboot.pbp / bin (depends from what I've actually seen) and the rest calls the emulator with flags, for what exact I'm not sure just yet.

    As juan said, currently this only fully supports decryption of PSOne games (Simple fix to add others through klicense keys). the encryption process isn't 100% tested, but if people want to help we can go from there. the headers from 0xb0 to 0x100 as kdsbest said. We currently don't fully know what these are so if anyone wants to help with that, that would be awesome.

    From JuanNadie: Congrats snowydew and KDSBest. Good job (specially for providing source code).

    I ran the app and there is no text field for klicensee so I assume that this release is only for PSX games.

    For those asking this tool (once improved) will allow you to do what EXE.trim.ALL did months ago... freeing DLC, PSX, PS2 and some PSN game. However my favorite use is SDAT. A lot of developers encrypt resource files on SDAT... now we can do our own mods/translation

    BTW if you have a RAP you don't need the IDPS nor act.dat nor RIF...

    PS: For devs, if any of you knows how an isolated SPU reads the config ring please contact me.

    From sandungas: Its poorly explained in the thread, but this tool is not focused in psn, but in rebuilding PS1 games in ps3 format from a copy of the original disc.

    The fact is there is an .iso inside all "ps1 classic" games and "psp minis" games... and probably "ps2 classic" games. There are firmware modules (the ones labeled 9660) that can read this .iso format that is an standard of the industry.

    So theorically, if you can provide an .iso in the correct format (with the extended track info)... and with the ability of recreating his header and the rest of his structure you have a way to boot any ps1 game in any ps3 model.

    *obiously there is no 100% compatibility in the emulators itself, so some games will not run, but expect a big number to work

    With "PSP minis"... there is no use because there are no minis discs to make a backup in .iso format.

    With "PS2 classics" probably has some things in common with PS1... but also some different things... can be a bit more complicated (and compatibility very low with ps3 slims).

    The file structure of a decrypted iso.bin is divided in "blocks" and "clusters":

    [Register or Login to view code]

    First you have the header (1 block) <--- this header can be considered "patched" to the start of the file, doesnt count as part of first cluster... clusters are used only inside the "discs" areas.

    Then the "disc 1" starts (1024 blocks, 64 clusters)
    Then the "disc 2" starts (another 1024 blocks, 64 clusters) etc...

    Inside the first clusters of each disc (this cluster can be considered another header specific for this disc) you have the "magic" PSISOIMG0000 that is different for "psp minis" (I don't remember)... and probably another for "ps2 classics" (speculation)

    Also the "game_id"... "number of clusters"... some unknown counters... (probably blocks used or similar). But the most important area of this cluster is the 32 bytes (seems to be a key) displaced 0x800 bytes from the start of the cluster.

    Then there is a block of padding, and in the second cluster it begins the "file_table"... this table last to the end of the "disc 1" (and not-used clusters contains a checksum of 16 bytes)

    The file_table is composed of entries of 32 bytes each. In each entry you have... the displacement from start of table, file size ?, cluster number (inside the iso) ?... etc...

    Well... this file_table is pointing to the disc in iso format, and probably to "sectors" of the disc... it can be a TOC. And here is where is important to take in account the track data mode of the old ps1 discs, because it had an special track (known as MODE2)

    The positions are always fixed, so for a game with 4 discs the important stuff is at this offsets:

    [Register or Login to view code]

    I just created a new wiki page: ps3devwiki.com/wiki/Iso.bin.edat

    All the iso.bin offsets are mapped, some of them are still unknown, but his positions are clear. With this tables can be done a program to "read" iso.bin files to give an output list of all the positions, information, etc... (in a semi-human-readable format)

    Now its needed to identify the "unknown" areas by understanding the relationship with the real .iso structure. The next step is to be able to generate this iso.bin files. Feel free to help updating the page if you find something.

    The names i used for the tables or areas... are a bit confusing (if anyone understand this better feel free to clarify them) But because i don't know exactly what they are... i found no better names

    All that i added to the page is from a iso.bin.edat decrypted from a retail game... i just removed the extension .edat to difference it from an encrypted one

    And well... in resume... this iso.bin is pointing to areas of another .iso file. This areas obviously are "sectors of a disc"... and probably related with the TOC of the disc (table of contents)

    And for the decryption of each disc (or each disc header)... i think the key is the one i marked as "disc_key" (doesn't seems to be a checksum, and is the only one with 32 bytes) At the end of the file there is an area of 40 bytes a bit strange that i have no idea if is related with encryption.

    From PatrickBatman comes a Tutorial to Decrypt NPDRM as follows:

    Well I guess I can tell you how the EASY WAY (After figuring this out I saw moogie figured it out also). This the easy way so ill tell you how to do that (I haven't looked for extensively/found the latest NPDRM keys like what duplex uses or whatever)

    Basically you can make ebootMOD do this (this is the easy way instead of cygwin or linux)

    1) Get deank's ebootMOD
    2) Keys: get app-iv-102f, app-key-102f, app-pub-102f, app-priv-356, free_klicensee-key, klic-key, npdrm-const and rif-key
    3) Get the unself that is 139KB allows NPDRM decryption
    (to get items 2 and 3 search for PS3_Tools_NPDRM_v3)
    4) Put keys in ebootMOD's .ps3 folder
    5) Replace ebootMOD's unself (132 KB) with the 139KB unself (allows NPDRM decryption)
    6) Drag and drop NPDRM eboot over ebootMOD icon
    7) EbootMOD will make MODIFIED_EBOOT.BIN at the same location as original NPDRM eboot

    Also, you can use the tools with PS3_Tools_NPDRM_v3 to unpkg update pkg files but you need working knowledge of cygwin/linux.

    Or the easy way: get Unpkg GUI by Team SOS (I just extracted Skyrim 1.03 update with this, but of course can't decrypt eboot cause its using higher NPDRM keys or has EDAT, haven't checked anyway EDAT uses several keys,

    [Register or Login to view code]

    Finally, from zecoxao comes some precompiled tools for Edats in general (Minis and PSX Classics ONLY!) and the executable is located in the bin folder of each VS project. He also recently set up a ps3_decrypt_tools GIT for interested PlayStation 3 developers.

    To quote: In case you haven't noticed, ps3devwiki.com/wiki/Iso.bin.edat is more complete because i have had some help in decrypting the stuff. There's also a new thing i've found. They are some differences between a 1 CD PSX Classic like Abe's Oddysee, and Multi-Disk PSX Classics like FF VII and FF VIII. I would appreciate if someone took the care into documenting those differences.

    More PlayStation 3 News...

  2. #2
    StanSmith Guest
    Hopefully this leads to something good like a new way to get games working without any dongles.

  3. #3
    Ozz465 Guest

  4. #4
    dok2033 Guest
    Great job, so (if i am not misunderstood this post) this will make a signed eboot.bins, and why not *.pkgs ... or still we hv to wait kakaroto get a solution?! & sorry for my EN.

  5. #5
    niwakun Guest
    someone compile it please.

  6. #6
    IndyColtsFan84 Guest
    Quote Originally Posted by StanSmith View Post
    Hopefully this leads to something good like a new way to get games working without any dongles.
    Games without dongles has already been done, why do we need a "new way"?

    Quote Originally Posted by niwakun View Post
    someone compile it please.
    It's already been compiled, try looking in the "bin" folder.

  7. #7
    elser1 Guest
    i guess they mean the new games that don't work on cfw without a dongle.

  8. #8
    Xplic1T Guest
    hahah, obviously ^

  9. #9
    niwakun Guest
    ok I tried it, i cant manage it to work unless I click the "Test PACKING" which will convert edats into free license, and it wont work without the idps+act+rif files, rap files alone doesn't work.

  10. #10
    cfwprophet Guest
    Just to clarify... snowy doesn't have developed it. Some anonymous have developed it and KDSBest convert that code from java to C#

Page 1 of 11 12 ... Last

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Log in