[EXE.trim.ALL]

@JuanNadie Thanks again, it's works. Bu can you help us with CMAC key for sdata's headerHash and titlefilenameHash (0x50-0x6f)?

[Octopus]

Originally Posted by gjis9cuy So I'm going to restudy the VSH looking for the missing part. We don't know the meaning of byte 0x810 to 0x1010 of act.dat. Previously I discarded that the act.dat contained an entry for each content as it has a fixed size but it is the only place to store keys. It is a slow process so please be patient.

How I know:
[0x10] - Something (forever yet 00 00 00 01), Version, User number
[0x800] - Keys Table
[0x64] - Per Console
[0x4] - Something (4 bytes)
[0x659] - Per Console
[0x138] - Something (Hash(s)?)
[0x8] - Per Console
[0x28] - Signature

@JuanNadie
Do you have algo for digest? How I know make_package_npdrm write it.

[JuanNadie]

First of all a new revision of the algorithm:

http://pastebin.com/E9ghYKj0

CHANGELOG:
-Added partial support for debug files
-Added NPD version check (between 0 and3)
-Added per version flags check
-Added support for FLAG_0x20. (Untested)
-Added support for versions 0 and 1 (ISO.BIN.EDAT). See below

When version is 0 or 1 instead of using the digest and the hash of the NPD for calculating the block key and the apploader's IV a zeroed byte array is used as base

I hope this helps your project Snowy.

@dsadsadsa I don't think I could help Kakaroto cause most of the checks are not on current code (They probably added further checking on later firmware version) and my expertise is reading assembly which I don't have. However if I can help then in any form they only need to contact me. In fact the only think that I know that is not already public is that 0x20 bytes are copied from the appldr to main memory just before setting mailbox to 7. Those bytes are at 0x890 and probably is the hash for the whitelist.

@EXE.trim.ALL There is no hash for SDAT. Those values are unknow and not checked(not confirmed). The only function as you have seen is to be xored to generate the key. To get the exacts values I'll need to check the SDK as those are generated there.

@Octopus I haven't look for the second part of the act.dat. My hyphotesis is that the second part of the file is used when debug is enabled and is common for all the consoles (will explain the COD trick). About the digest as I said there is no checked (is a hash of the original data which is unknown until the whole file is read so it can not be used as check). Geohot zeroed it on his code, An analysis of make package will obtain then (or wait until Kakaroto has the SELF fix and hope that it included the algorithm)

[snowydew]

Awake now, starting to pick it apart. it doesn't save my sent messages (so unsure if you got them). I'll let you know if i run into any errors or such with this . again thank you for your hard work <3

edit: Can't get it to run with any of the dev enviroments i've setup :/, is there anything specific / what are you using to test it with? (Curious)

[V6ser]

Thx brah!!

People did you get the difference from the previous and the new: http://pastebin.com/E9ghYKj0

EDIT: I saw just the new.

[Octopus]

Originally Posted by hyztname People did you get the difference from the previous and the new: http://pastebin.com/E9ghYKj0

You don't?

[V6ser]

Originally Posted by Octopus You don't?

I edited my post,

I saw just the new version two times.

[EXE.trim.ALL]

@JuanNadie Thanks again for your explanation.
Can you tell more about keys in edat of version 0 and 1? It's seems we can't decrypt it's content and headerHash and/or metadata hashes using other keys.
About decompression: http://pastebin.com/63WGgyDg

[JuanNadie]

@EXE.trim.ALL Thanks for the decompression algorithm. I'll check it later.

About the keys:
-For the header hashes there is no change you still use rifkey to get them.

To obtain that key (get the keys from wiki.i'm using the names used there):
-Decrypt rif 0x40-0x4F with the RIF's act.dat index decryption key. Get act.dat index (last four decrypted bytes)
-Encrypt klicensee constant with your IDPS-> I'll call the result actdatkey
-Using actdatkey decrypt act.dat values from 0x10 + index*0x10 to 0x1F + index*0x10
-Using that value as key decrypt rif 0x50-0x5F

If the file is free then use the devklic directly.

There are no changes for checking the headerhashes. However for the data there are two variations.

-The input keys:
Previously the npd.digest was used as IV. Now it is a 0x16 bytes array of zeroes.
For blockbase use 0xC zeros instead of the first 0sxc bytes of npd hash. Then append the block number. Remember to encrypt this with the rifkey.

-The apploader mode: For types 0 and 1 the keys provided to appldr are not encrypted (only compression and debug flags are allowed). They are used directly on the data

[EXE.trim.ALL]

@JuanNadie Thanks. I'll check it later but it seems I using right algo. May be there is some mistake in code...
And one more question. In your sources for 0x20 bytes metadata with no compression last 16 bytes are xoring with first ones to get data hash. I'm using this algo but (un)xored hash and real data hash are different. Can you help with it?

UPD:
Yep, I found error in my code.

And about flags in compressed edat metadata. isEndOfCompression flag actually is isCompressed. If this flag 0 then block is not compressed and if it's 1 then block is compressed.

UPD2:
One more question. I tried to calculate headerHash for version 0&1 with old algo (using all time devklic) but it doen't match. Does rifkey or devklic must be used? And can we get devklic for version 0&1 same way as for older versions? Because I can't bruteforce it in eboot.