[EXE.trim.ALL]

Originally Posted by Luzifer42 I have a NPD with uncompressed 0x20 bytes metadata section. It is trunkcated (9MB total), but it should be enough to understand. I dont really known how to calculate the hash over this metadata, if it is present at all. The total length of the metadata seems rather short (0x00 to 0x20 bytes for 578 blocks), because the decryption works already at the offset 0x120.

For 0x3c type the metadata sections are placed before each data block.
For example in your file metadata for first block is at 0x100-0x120, then 0x120-0x4120 is first block of data, then again metadata for second block (0x4120-0x4140), then second block of data (0x4140-0x8140)...
But the problem of 0x3c is in obfuscation of data hash in metadata section.
In debug files in first 16 bytes is hash and then 16 nulled bytes.

[EXE.trim.ALL]

@JuanNadie
So can you say something about metadata of 0x3c type?

[JuanNadie]

First new version for 0x3C:

http://pastebin.com/TtuNF5J5

@EXE.trim.ALL You are calculating properly the hash. However you probably are not considering FLAG0x10. This flags indicates that the algorithm for hash is HMAC instead of CMAC. If FLAG0x20 is set the hash len is 0x14, otherwise the hash is truncated to 0x10 bytes.

Also another effect of FLAG0x10 is that the hashkey != encryptionKey. When this byte is set the hashKey has to be reencrypted again to calculate the proper value. Check the code above

BTW I confirm that for files with flag0x20 the structure changes from all metadatasection + all data to metadatasection and data interleaved. That means that the metadatasectionhash is ignored. I also confirm your isEncrypted. (credits to @EXE.trim.ALL )

[EXE.trim.ALL]

@JuanNadie Thanks a lot, now my prog works with all edats I have. But it's still need to be refactored to properly use flags)

[Luzifer42]

Originally Posted by JuanNadie ... 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 have seen free retail pkg files with EDAT files but without SELF files (Here).
So there must be an other way for the PS3 to obtain the devklic key. As you said, it is used to create a pkg. The algorithm for debug pkg files has already been reverse engineered, and the devklic is stored in obfuscated form at offset 0x70. For retail files, this might be similar. The algorithm for debug files does not work on retail ones. The algorithm might be a more serious cipher with a "secret" key.

[EXE.trim.ALL]

Originally Posted by Luzifer42 I have seen free retail pkg files with EDAT files but without SELF files (Here). So there must be an other way for the PS3 to obtain the devklic key. As you said, it is used to create a pkg. The algorithm for debug pkg files has already been reverse engineered, and the devklic is stored in obfuscated form at offset 0x70. For retail files, this might be similar. The algorithm for debug files does not work on retail ones. The algorithm might be a more serious cipher with a "secret" key.

Try to search for keys in unselfed vsh.

[Octopus]

@JuanNadie What about SPRX?

[Octopus]

Yeah I remembered

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)

[Octopus]

Problem solved, just use devklic.

[Luzifer42]

I dont know if it is useful, but for the sake of completeness, I have reversed the hash algorithms for debug NPD headers. Interestingly, the devklic can be retreived from debug files which are not type=1 (most EDATs are not type=1, only USRDIR/EBOOT.BIN are type=1).

Pseudocode:

function byte[] nameHash(byte[] digest) {
	byte[] nameHash=new byte[16];
	for (int i = 0; i < 16; i++)
		nameHash[i] = digest[i] ^ 0xFF;
	return nameHash;
}

function byte[] headerHash(byte[] digest, int type, byte[] devklic){
	byte[] headerHash;
	if (type == 1){
		headerHash={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1};
	}else{
		headerHash=devklic;
	}
	for (int i = 0; i < 16; i++)
		headerHash[i] = headerHash[i] ^ digest[i] ^ 0x55;
	return headerHash;	
}