- Following up on the previous PS3 EDAT File Name Restorer
utility, today PlayStation 3 homebrew developers Snowydew
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
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.
: 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.
: 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.
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.