[Octopus]

@granberro Thats because the real klicensee for each game are in elf.

[JuanNadie]

Actually an EDAT has several keys. One is in the SELF, others are at the rif and others on firmware. That an EDAT works on lower firmware only proves that the firmware has those keys.

BTW I have tricked the PS3 into decrypt an EDAT (Buzz). The procedure involves knowing how the NPD element is used (most of this is already published).

   struct {
     uint32_t magic;
     uint32_t unknown2;
     uint32_t license; /* 1 network, 2 local, 3 free */
     uint32_t type; /* 1 exec, 21 update */
     uint8_t content_id[48];
     uint8_t digest[16];
     uint8_t titlefilenameHash[16];
     uint8_t headerHash[16];
     uint64_t unknown3;
     uint64_t unknown4;
   } npdrm;

The NPD has 3 different hashes:
- The first (digest) is a hash of the decrypted data. I don't know the algorithm nor if it is checked.
- The second is a CMAC. The key is npdrm_omac_key3, and the message is the titleID (0x30 bytes) concat to the filename (excluding path and case sensitive),
- The third is again a CMAC. This time the message is the whole NPD from NPD magic to the second hash both included. The key for SELFs launched from the VSH is npdrm_omac_key1 xored with npdrm_omac_key2

But for the rest (Selfs executed inside a program and EDAT) instead of using npdrm_omac_key1 another key is used. That key is called the klicensee (however as that name is already used I would call it devklic (developer klicensee),

That key is selected randomly by the developer(activision, ea, ubisoft, square...) and it is a parameter used when creating a pkg. So for EDAT the key for the third hash is devklic xored with npdrm_omac_key2.

If we are going to recrypt an EDAT we need that key. There are several procedures to obtain it:

- Decrypt the SELF and use RCE to get it. We'll need an idc that locates the call. Very slow, tricky, requires large knowledge but always work.
- Hook the call that opens EDAT. Then we retrieve it on parameter r3. Faster, requires modifying the firmware. Always work
- Brute force it: Decrypt the self and try every combination of 16 sequential bytes on the file. I obtained using this method the key on Buzz and LBP. It faster than RCE but it does not always work (the key could be in other file or obfuscated).

I repeat we will need that key to encrypt an EDAT.

We SONY uses this key? To avoid the following ¿exploit?:

-Obtain the devklic.
-On a PS3 where the EDAT is authorized write a program with the following command;
sceNp....Open(devklic, "PATH_TO_FILE",READ_ONLY,fd,NULL,0);

That will create a file descriptor. The read of it will be on clear... and we can then write it to an output file.

How I think this works? Well, you provide the correct klicense, so the system will validate the NPD and send a request to LV2 to set the decryption key (This would be related to rif for paid or to the devklic if free). Then when reading if the LV2 Will ask the appldr to decrypt it).... Note that seek works so probably the decryption can be made by blocks

BTW something similar was done on PSP

How can we use this?
-First is good to have the plain text of something you0re trying to reverse so for devs it could be useful to reverse EDAT algorithm
-Second you can replace the original file and patch the EBOOT to not use encryption.
-Third you can create a debug EDAT and path lv2 to accept debug files.

However IMHO any warez release that uses those tricks should be NUKED as that is not the correct procedure (that would be reencrypt the EDAT as free).

Other things:
-The first hash of NPD needs to be obtained
-The first 0x80 encrypted bytes of an EDAT (0x90-0x10F) contains a key for decrypting the rest of the file. I think that key is constant for the rest of the file. Reason: the 2 EDAT I decrypted from Buzz has the same contain... which means hash1 is the same (2 and 3 are different cause the filename is different), but the encrypted content in the metadata section changes. Perhaps a signature but I think there is a different key there (the data also changes)


@granberro Buen trabajo. I saw your work at elotrolado allowing the use of non static keys on a NPDRM.

@mathieulh thanks for the compliments on type 2 NPDRM. I also think that someone should modify make_self_npdrm to make SELFs that work "at least" on 3.55 official firmware...

[Octopus]

When we think devklic = decklic, we (our team) are tried decrypt EDAT by this way:

Originally Posted by JuanNadie -Obtain the devklic. -On a PS3 where the EDAT is authorized write a program with the following command; sceNp....Open(devklic, "PATH_TO_FILE",READ_ONLY,fd,NULL,0);

And get 0x80029530 Error.
We can do this now, but we will not decrypt ISO.BIN.EDAT or p3t.EDAT thats way, they don't have self...
maybe if we will

Originally Posted by JuanNadie - Hook the call that opens EDAT. Then we retrieve it on parameter r3. Faster, requires modifying the firmware. Always work

this will work

[alphaomega]

So crysis 1 soon? Nice work guys you are HEROES

[tiefputin2]

That key is selected randomly by the developer(activision, ea, ubisoft, square...) and it is a parameter used when creating a pkg. So for EDAT the key for the third hash is devklic xored with npdrm_omac_key2. If we are going to recrypt an EDAT we need that key. There are several procedures to obtain it: - Decrypt the SELF and use RCE to get it. We'll need an idc that locates the call. Very slow, tricky, requires large knowledge but always work. - Hook the call that opens EDAT. Then we retrieve it on parameter r3. Faster, requires modifying the firmware. Always work - Brute force it: Decrypt the self and try every combination of 16 sequential bytes on the file. I obtained using this method the key on Buzz and LBP. It faster than RCE but it does not always work (the key could be in other file or obfuscated).

look out for klicensee.py
developer klic is within the .pkg at offset 0x60 or so too

[Saimin]

Originally Posted by tiefputin2 look out for klicensee.py developer klic is within the .pkg at offset 0x60 or so too

I haven't had any luck using the KLicensee generated by that. I can verify the title/filename hash for all 16 edat files in the Dunamis15 demo, but trying to generate the header hash using the KLicensee from the pkg and JuanNadie's description always gives me something different from the hash in the edat.

I haven't tried any of the other methods for finding the KLicensee, cause I wouldn't know where to start with it.

[jester]

Originally Posted by Saimin I haven't tried any of the other methods for finding the KLicensee, cause I wouldn't know where to start with it.

Decrypt the game EBOOT.BIN than write a bruteforce routine that tries to generate the hash using every 16bytes of the EBOOT.

[Saimin]

Originally Posted by jester Decrypt the game EBOOT.BIN than write a bruteforce routine that tries to generate the hash using every 16bytes of the EBOOT.

I must not've had my head on straight this morning. Thanks! I got the KLicensee from the decrypted eboot, and I'm correctly generating the header hash on all 16 edat files.

[Octopus]

For example "Flower" weighs about 10 Mb, it means it has about 11 millions of bytes, it means we must try about 11 millions of keys. Nice)

[jester]

Originally Posted by Octopus For example "Flower" weighs about 10 Mb, it means it has about 11 millions of bytes, it means we must try about 11 millions of keys. Nice)

What's the problem? It is faster than you can imagine! about 2 minutes with a crappy laptop...

EDIT: I've tried to use the licensee extracted from the relative .rif to try to generate the third hash for a paid edat, but it doesn't seems to be the right way

EDIT2: I'm now certain that this dev_klic has nothing to do with rif key for paid content...