PS3 packages and how it leads to PSP signing

[coyotebean]

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?

Making a sample decryptable prx to run is more than just able to decrypt.
I think the kernel code place many restrictions on where to run what programs.

e.g. Each type of program has a corresponding decoding routine in mesg_led.
Each type are fixed with a small set (mostly 1-2) of code (i.e. index to Kirk 7 for descrambling the prx header)
Many useful code are not included in the PS3 Kirk.

If you set 1 at byte offset 0x64 in the Kirk header, Kirk will use public key signature method instead of CMAC, I believe Sony convert everything possible in 6.30+ to requiring the public key signature. e.g 6.30 will refuse old update simply because 0x64 is not set. (But then, Sony don't know how to sign properly with public key algorithm ).

[wololo]

Real life is a bitch and I'm way behind everybody else on this thread, since I just installed psp-objdump. Strangely enough it wasn't as easy as I expected, but then again I suck big time at Linux. I couldn't find any "spu-binutils" or "binutils-spu" or "cell-sdk" package, or any clear indication on how to install such things on my system (Ubuntu 10).

Installing the ps3 toolchain by ooPo finally did the trick. https://github.com/ooPo/ps3toolchain
This installs much more than necessary (for what we are doing here, I mean), but after all, I expect to use these tools in the future

Anyways, for those like me who are trying to catch up, installing the ps3toolchain is one way to get a working spu-objdump. From there,
spu-objdump -d [your decrypted sprx file]
will output the assembly code, and the addresses of functions posted by various people in the previous pages will hopefully make sense to you (most of the time a new function starts after bi $0)

(I feel so bad for stating what's probably obvious to 90% of the participants in this thread, don't mind my post and keep digging )

[silverspring]

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.

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

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.

EDIT:
Found it:
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

EDIT2:
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.

EDIT3:
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.

[coyotebean]

Wololo, here are some good supplement information for reading the SPU assembly listings

Cell Broadband Engine Public Information & Download
http://cell.scei.co.jp/e_download.html
SPU Assembly Language Specification
SPU Application Binary Interface Specification

http://www.faqs.org/rfcs/rfc4493.html
RFC 4493 - The AES-CMAC Algorithm

Many hash & encryption algorithm has distinct constants which can be used to identify routines.

[Mathieulh]

We need to get the algorithms to generate those keys ourselves then we can generate the entire set.

Wouldn't we also need the fuses they set at factory ? Or do you have that somehow?

[coyotebean]

EDIT2:
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.

According to PS3 Kirk,
0x00-0x1F is decrypted (AES-CBC) by Kirk 1 internally to form the data & cmac key.
That's why it caused header hash check failure.

Header hash is calculated from 0x60-0x8F

Data hash is calculated from 0x60 to end of (16 byte align) data.

For ECDSA (not in PS3 Kirk), it seems only 0x00-0x0F is decrypted to get the data key (data can be decrypted with this key the same as CMAC).
0x10-0x5F is the header hash & data hash.

Sequence:
Decrypt key data from input.
Validate header hash
Validate data hash
Decrypt data

[silverspring]

Wouldn't we also need the fuses they set at factory ? Or do you have that somehow?

Yea that as well. And no, no fuses and no algo's .

Sequence:
Decrypt key data from input.
Validate header hash
Validate data hash
Decrypt data

The sequence I've tracked on the PSP itself (old IPL on older mobo's that is, not newer ECDSA ones):

- KIRK checks MIPS interface is enabled (returns error 0x01 if not)
- then checks "mode" value at 0x60 equals 1 (returns error 0x02 if not)
- then checks size value at 0x70 not equals 0 (returns error 0x10 if 0)
- then checks header hash (returns error 0x03 if failed)
- then checks data hash (returns error 0x04 if failed)

Does any of that show up on PS3 KIRK?

KIRK doesn't actually DMA the whole data from RAM in one go, which means via timing methods, you can wait until the data hash passes then change the encrypted data in RAM to be able to change the decrypted output, therefore bypassing the sig. This is the only way I know of to be able to bruteforce the encrypted data easily, otherwise you would have to re-bruteforce the hashes each time you change any of the encrypted data.

[kgsws]

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

That modified uhura.prx is very interesting, so 0xD4 contains SHA1 of "something" ... i wonder what is at 0x80 with size 0x30. I guess this will need to reverse mesg_led.prx ...

[Draan]

Well, i have actually a question.

I've implemented sven's decryption in C (actually I've omited CMAC hash generation xD).

Code: Select all

int kirk_CMD1_decrypt(void* outbuff, void* inbuff, int size)
{
   KIRK_CMD1_HEADER* header = (KIRK_CMD1_HEADER*)inbuff;
   if(header->mode != KIRK_MODE_CMD1) return KIRK_INVALID_MODE;
   if(header->data_size == 0) return KIRK_DATA_SIZE_ZERO;
   
   u8 decrypted_keys[32]; //0-15 AES key, 16-31 CMAC key
   
   AES_KEY a;
   AES_set_decrypt_key(kirk1_key, 128, &a);
   
   u8 ivec[16];
   memset(ivec, 0, sizeof(ivec));
   
   AES_cbc_encrypt(inbuff, decrypted_keys, 16*2, &a, ivec, AES_DECRYPT); //decrypt AES & CMAC key to temp buffer
   memcpy(inbuff, decrypted_keys, 32); //copy back decrypted keys to header
   
   AES_KEY k1;
   AES_set_decrypt_key(header->AES_key, 128, &k1);
   
   AES_cbc_encrypt(inbuff+0xA0, outbuff, header->data_size, &k1, ivec, AES_DECRYPT);
   return KIRK_OPERATION_SUCCESS;
}


Tried on first block of 6.20 slim IPL. It works, but in the output i have 0x200 bytes of (trash?) and then correct IPL code.
From SilverSpring's ipl_decrypt_sample i saw that it should output me 16 bytes of information (loadaddr, blocksize, etc...) before the code.

What's wrong with that?

@kgsws: at 0xD4 is signcheck, the whole stuff ties a module to your console only (encrypted with kirk5, which does something with fuseID, as Silver told), so copying anything from flash0 from one to another PSP won't work.

That part actually could be done on PSP (signcheck & unsigncheck) before(updater does that before flashing), good source is in PRXDecrypter, i'll post that:

Code: Select all

// sigcheck keys
u8 check_keys0[0x10] = {
   0x71, 0xF6, 0xA8, 0x31, 0x1E, 0xE0, 0xFF, 0x1E,
   0x50, 0xBA, 0x6C, 0xD2, 0x98, 0x2D, 0xD6, 0x2D
};

u8 check_keys1[0x10] = {
   0xAA, 0x85, 0x4D, 0xB0, 0xFF, 0xCA, 0x47, 0xEB,
   0x38, 0x7F, 0xD7, 0xE4, 0x3D, 0x62, 0xB0, 0x10
};

int DecryptSC(u32 *buf, int size) {
   buf[0] = 5;
   buf[1] = buf[2] = 0;
   buf[3] = 0x100;
   buf[4] = size;

   if (sceUtilsBufferCopyWithRange_(buf, size+0x14, buf, size+0x14, 8) < 0) {
      return -1;
   }

   return 0;
}

int EncryptSC(u32 *buf, int size) {
   buf[0] = 4;
   buf[1] = buf[2] = 0;
   buf[3] = 0x100;
   buf[4] = size;

   if (sceUtilsBufferCopyWithRange_(buf, size+0x14, buf, size+0x14, 5) < 0) {
      return -1;
   }

   return 0;
}

int UnsignCheck(u8 *buf) {
   u8 enc[0xD0+0x14];
   int iXOR, res;

   memcpy(enc+0x14, buf+0x80, 0xD0);

   for (iXOR = 0; iXOR < 0xD0; iXOR++) {
      enc[iXOR+0x14] ^= check_keys1[iXOR&0xF];
   }

   if ((res = DecryptSC((u32 *)enc, 0xD0)) < 0) {
      return res;
   }

   for (iXOR = 0; iXOR < 0xD0; iXOR++) {
      enc[iXOR] ^= check_keys0[iXOR&0xF];
   }

   memcpy(buf+0x80, enc+0x40, 0x90);
   memcpy(buf+0x110, enc, 0x40);

   return 0;
}

int ResignCheck(u8 *buf) {
   u8 enc[0xD0+0x14];
   int iXOR, res;

   memcpy(enc+0x14, buf+0x110, 0x40);
   memcpy(enc+0x14+0x40, buf+0x80, 0x90);

   for (iXOR = 0; iXOR < 0xD0; iXOR++) {
      enc[0x14+iXOR] ^= check_keys0[iXOR&0xF];
   }

   if ((res = EncryptSC((u32 *)enc, 0xD0)) < 0) {
      return res;
   }

   for (iXOR = 0; iXOR < 0xD0; iXOR++) {
      enc[0x14+iXOR] ^= check_keys1[iXOR&0xF];
   }

   memcpy(buf+0x80, enc+0x14, 0xD0);

   return 0;
}

// check 0xD4 to 0x12B inclusive. if any of it is not 0x00, the file is sigchecked
int IsSignChecked(u8 *buf) {
   int i;
   for (i = 0; i < 0x58; i++) {
      if (buf[0xD4+i] != 0) return 1;
   }
   return 0;
}

//UnSignCheck, isSignChecked, ReSignCheck takes a pointer to prx with ~PSP header)


To ReSignCheck on PC we would need to figure out what stuff kirk does with that fuseID, and grab 0x100 key seed (is it in PS3 KIRK?).

[coyotebean]

Code: Select all

   AES_cbc_encrypt(inbuff+0xA0, outbuff, header->data_size, &k1, ivec, AES_DECRYPT);


+0xA0 should be 0x90+(little endian value at 0x74-0x77)
0x74-0x77 is the size of "predata" or I call it "info", between kirk header and encrypt data.