Mathieulh wrote:we miss the key seed 0x43 from kirk cmd 4/7, it's not in the spu_handler (the ps3 version of kirk) so we can't do the mangling on kernel prxs (kinda sucks because we can't pwn the bootchain with prx encryption so far), we can however encrypt and hash user prx with all the provided keys as well as IPL blocks for psp-1000/2000 (We'd need the new pre-ipl hash stuff for the psp-3000 and newer), it's also believe that the new pre-ipl on the go or newer use kirk cmd 11/12 with an ECDSA check on the IPL block
Does anyone happen (Silverspring ? ) to know what's kirk cpu architecture ?
That's to be expected since the PSP emu on the PS3 doesn't need to decrypt any kmode stuff, just games. The KIRK cpu is a completely custom-made 32bit arch, not any standard one. Also, all those keys for cmd4/7 on the PSP are not stored at all in the KIRK ROM, they get dynamically generated based on the fuses that are set at factory (along with the fuses set for the serial number ie. the fuseid). The devkit seems to have some extra fuses set since there are some keys that exist to decrypt a few things on the devkit that cannot be decrypted on a retail machine. We need to get the algorithms to generate those keys ourselves then we can generate the entire set.
Proxima wrote:It's not the most elegant path, but couldn't we just use KIRK cmd 4 to encrypt the 0x43 ones for the kernel on the PSP itself? Looks like the final signer app may have to be a native PSP app.
Cmd4 can only use seed from 0x00-0x3F so won't be able to encrypt those from 0x40-0x7F, and all prxs use seed's 0x40+.
More info (try verify with disasm of PS3 KIRK emu):
Cmd4 works in 16Byte blocks, can be any size but needs to be 16Byte-aligned, valid seeds 0x00-0x3F.
Cmd7 works in 16Byte blocks, can be any size but needs to be 16Byte-aligned, valid seeds 0x00-0x7F.
Cmd5 works in 16Byte blocks, can be any size but needs to be 8Byte-aligned, valid seeds 0x100-0x1FF (doesn't change anything).
Cmd8 works in 16Byte blocks, can be any size but needs to be 8Byte-aligned, valid seeds 0x100-0x1FF (doesn't change anything).
Cmd6 works in 16Byte blocks, can be any size but needs to be 8Byte-aligned, valid seeds 0x200-0x2FF (doesn't change anything). Header is 36byte not 20 because off added option 16Byte key
Cmd9 works in 16Byte blocks, can be any size but needs to be 8Byte-aligned, valid seeds 0x200-0x2FF (doesn't change anything). Header is 36byte not 20 because off added option 16Byte key
kgsws wrote:I made PRX that is correctly decrypted with PRX decrypter, but PSP can't run it - error 0x80020148.
So next question, is there another check, for ~PSP header?
Prxdecrypter (which is based on psardumper code) does the absolute bare minimum to decrypt, it doesn't check some SHA1's for example. So you make prxs that can decrypt on prxdecrypter but will fail on the PSP. I'll post some samples if I can find them. When I was researching the AR release, I made my own AR prxs with replaced ASCII string messages.
This is a modified uhura.prx from AR with my own strings, this decrypts on both prxdecrypter and PSP and works perfectly:http://www.sendspace.com/file/609c9g
This will decrypt on prxdecrypter but NOT on PSP (I was testing to see how much of it I could modify, so I just zero'd out a lot of bits):http://www.sendspace.com/file/4kitkg
And just to compare, this is the original untouched uhura.prx from AR:http://www.sendspace.com/file/llcflr
For cmd1, header hash checks data at 0x00-0x1F, and 0x60-0x8F. Data hash checks data at 0x60-0x8F, 0x90-0x9F, and rest of data.
Data at 0x40-0x5F is not used AT ALL. Can be modified to whatever you want.
The 4Bytes at 0x60 is a type of "mode" value, has to be:
1 for cmd1
2 for cmd2
3 for cmd3
4 for cmd4,5,6
5 for cmd7,8,9
Cmd10 is just the hash check, so it does the same as cmd1 but without the decryption phase. So it's sort of like a signature check. SCE never used it on anything but I assume it's so you can sign things without having to encrypt them as well. For example, signing a JPEG or something or some other plaintext file. It can check hash for cmd1 as well as cmd2 and 3.
There's also an error in my docs on my blog about cmd4,5,6 where I wrote the IV=0, IV=fuseid, IV=user-generated. All the IV's for all three are 0. The fuseid for cmd5 and user-provided key for cmd6 are set for somewhere else, not sure where but it changes the output somewhere along the line. Maybe an xor of the cipher key or something, need to check in the PS3 KIRK emu.