PS3 packages and how it leads to PSP signing

[Draan]

Advertising

Thx coyote! The output has correct size now...but the "info" block is messed up.

Current code:

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+sizeof(KIRK_CMD1_HEADER)+header->sth_size, outbuff, header->data_size, &k1, ivec, AES_DECRYPT);   
   return KIRK_OPERATION_SUCCESS;
}


And BTW. OpenSSL lib can generate CMAC hashes?

[kgsws]

Advertising

@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.

Not always. Games can't be per-console only. Also, action replay works on any PSP.
And there are 2 versions of ~PSP header, i want to know first.

OpenSSL lib can generate CMAC hashes?

I think some dev version can. Since i was not able to get it working, i use libcrypto++ to do CMAC, also you need newer version.

[sven]

CMAC is easy when you can already do aes encryption. do you want me to write some code for you?

[Draan]

@sven: Would be nice, as we don't need 18KB of other cryptos from crypto++. I've found an implementation of CMAC, but can't get it to work.
EDIT: RFC implementation works just fine.

Still don't know why 16byte "info" block from IPL is not correct...

EDIT2:
I'm quite confused...

Code: Select all

u8 cmac_header_hash[16];
AES_CMAC(keys.CMAC, inbuff+0x60, 0x30, cmac_header_hash);


That header hash is valid(i'm only CMAC'ing from 0x60-0x8F as you see) How it can also check data from 0x00-0x1F then?

And second question: how FINALLY looks the data hash calculation? ;d

I tried CMACing from 0x60 to 0x1000-0x60 = 0xFA0, but the hash is invalid. (I'm testing on IPL ofc)

[kgsws]

That header hash is valid(i'm only CMAC'ing from 0x60-0x8F as you see) How it can also check data from 0x00-0x1F?

Because 0x10 - 0x1F contains CMAC key, if you change it, hash will be different. Also 0x00 - 0x1F is AES CBC encrypted, if you change 0x00 - 0x0F, 0x10 - 0x1F will be changed too.

And second question: how FINALLY looks the data hash calculation? ;d

AES_CMAC(keys.CMAC, inbuff+0x60, 0x30 + datasize + dataoffset, cmac_header_hash);
inbuff must contain everything (entire kirk block, still encrypted ... of course keys can be decrypted already since it checks from 0x60)
datasize (kirk header at 0x70) must be aligned to 16 bytes, so if there is only 4, you must add 12 to it. C code: if(size % 16) size += 16 - (size % 16);
dataoffset is in kirk header at 0x74

[Draan]

Because 0x10 - 0x1F contains CMAC key, if you change it, hash will be different. Also 0x00 - 0x1F is AES CBC encrypted, if you change 0x00 - 0x0F, 0x10 - 0x1F will be changed too.

Thx for explaination. I've misunderstood, thought we would copy 0-1F and 60-8F to some temp buffer and calcuate hash from that

And second question: how FINALLY looks the data hash calculation? ;d

AES_CMAC(keys.CMAC, inbuff+0x60, 0x30 + datasize + dataoffset, cmac_header_hash);
inbuff must contain everything (entire kirk block, still encrypted)
datasize (kirk header at 0x70) must be aligned to 16 bytes, so if there is only 4, you must add 12 to it. C code: if(size % 16) size += 16 - (size % 16);
dataoffset is in kirk header at 0x74

That actually works! I'm going to push the code onto SVN in the moment

[kgsws]

OK, i made another PRX that can be decrypted using PRX decrypter. Now it uses new ~PSP format and encryption, and SHA1 is correct.
PSP still can't run it, but it is ecrypted as UMD program so i will test it in ISO, if i find way to make one.
Also there are still 16 bytes wich i don't understand to. PRX decrypter ignores them, but it might be part of signcheck.

EDIT: Tried in iso, not working. Well, i did not create my own ISO, i just modified existing using HEX editor so file size was bigger. I don't know if that is problem.
EDIT: OK, now it works ... inside ISO ...
Seems like i have signed module for UMD/ISO. It's hard to say since i have to test it on CFW.

[Draan]

IIRC when PRX module is not "fake" ~PSP (and not plain module, obviously) systemcontrol passes it to orginal loading code. However, the loading code could have patched some error branches, so I'm not sure if CFW matters or not.

Anyway, awesome work. Are you going to relase something? At least info about ~PSP format you've just pwned

Thanks to your tip, i was able to correctly decrypt IPL block with working "info" 16 bytes...I wanted to commit in a second, but a strange bug occured... It started to calculate hashes incorrectly for last block in 5.00 2k ipl, and in 6.20 ipl for both 1k and 2k. Dunno what happened, but even reverting the code to last commit didn't fix that....However, it decrypts just fine.
I'll probably rewrite the code :<

[coyotebean]

Thanks to your tip, i was able to correctly decrypt IPL block with working "info" 16 bytes...I wanted to commit in a second, but a strange bug occured... It started to calculate hashes incorrectly for last block in 5.00 2k ipl, and in 6.20 ipl for both 1k and 2k. Dunno what happened, but even reverting the code to last commit didn't fix that....However, it decrypts just fine.
I'll probably rewrite the code :<

The last block is not "signed" with CMAC. 0x64 is 1. It is using signed with ECDSA.

[kgsws]

Are you going to relase something? At least info about ~PSP format you've just pwned

It is simple, just reverse order seen in PRX decrypter.
Anyway, using leaked keys we can sign only UMD/ISO modules, there are no keys for demos, which can be run from card.
Actually key with index 0x60 will be enough

Or there is some trick which i don't know.

Here is version 2 ~PSP header. Seems to be correct.

Spoiler

Code: Select all

typedef struct {
   int id; // 0x5053507E
   int unk1; // run flags?
   short version;
   char name[28];
   byte unk2; // 0x01
   byte e_phnum;
   int datasize; // filesize - 0x150
   int filesize; // filesize
   int e_entry;
   int modinfo_offset;
   int bss_size;
   short p_align[4];
   int p_vaddr[4];
   int p_memsz[4];
   int unk3[6];
   int type;
   byte data3[0x30];
   byte data5[0x10]; // kirk head part, 0x70
   byte data4[0x10];
   int tag;
   byte empty[0x58];
   byte data2[0x14];
   byte data1[0x10];
} psphead_t;