PS3 packages and how it leads to PSP signing

[coyotebean]

Advertising

@kgsws what question you have on the structure?

@Draan PSARDUMPER will not help in analyse of Kirk 1. It just throw the descrambled program to Kirk to have it decrypted (by using Kirk 1).

[kgsws]

Advertising

I know there is header hash at 0x20, calculated from values: 0x00 - 0x1F and 0x60 - 0x7F.
I know there is data hash at 0x30, calculated from values starting at 0x80. - is this hash of encrypted data or decrypted? (it seems to be compared after decryption)
At 0x00 there is encryption key. - is this key for data decryption?
What is at 0x10? Another part of key? (if it uses AES256)
At 0x70 there is data size.
At 0x74 there is some offset value (in ipl_ms.bin it is 16, in PRX it is 128, in 620ipl it is 512) - what does this exactly do?
Another question is, where encrypted data starts. It has to be at 0x80, but many SCE files contain plaintext before encrypted data - this plaintext is also part of data hash.

I was playing with kirk even before (bruteforce 4*2^32 != 2^128), but there is not too much info about kirk headers.

[coyotebean]

I know there is header hash at 0x20, calculated from values: 0x00 - 0x1F and 0x60 - 0x7F.
I know there is data hash at 0x30, calculated from values starting at 0x80. - is this hash of encrypted data or decrypted? (it seems to be compared after decryption)
At 0x00 there is encryption key. - is this key for data decryption?
What is at 0x10? Another part of key? (if it uses AES256)
At 0x70 there is data size.
At 0x74 there is some offset value (in ipl_ms.bin it is 16, in PRX it is 128, in 620ipl it is 512) - what does this exactly do?
Another question is, where encrypted data starts. It has to be at 0x80, but many SCE files contain plaintext before encrypted data - this plaintext is also part of data hash.

I was playing with kirk even before (bruteforce 4*2^32 != 2^128), but there is not too much info about kirk headers.

I am pretty much in the same boat as you are.
The Kirk header seems to end at 0x8F. Starting at 0x90 is a "buffer" of size mentioned at 0x74 which either is skipped or used to form the initial IV.

The first thing Kirk 1 does is to use the hidden key to decrypt 32 bytes (probably the 0x00-0x1F) using decrypt_cbc().

These are my notes:


a0- 49f aes_encrypt_key()
4a0- 5b7 aes_decrypt_key()
5b8- 75f aes_encrypt_cbc? arg0,arg1/block,arg2/block,arg3/flag
760-103f aes_encrypt_??
1040-122c aes_decrypt_??
1230-1ccf aes_decrypt_cbc?
1cd0-1e3f encrypt_cbc(outbuf,inbuf,insize,key,bits,iv) reference by a398(Kirk 4),bdc0(Kirk 1)
1e40-213f decrypt_cbc(outbuf,inbuf,insize,key,bits,iv) reference by afe8(Kirk 7),bdc0(Kirk 1)
2140-24cf encrypt_ctr??
24d0-26df reference by bdc0(Kirk 1) hmac? aes-mac?
26e0-3557 SHA-1 Update??
3558-35cf SHA-1 Init?
35d0-3807 HMAC-SHA1 ??
41f8-4b0f MD5 Update??
4b10-4b7f MD5 Init?
7400-7497 SHA-224 Init
9f00-9f07 return 0x100 (Kirk version?)
9f08-a394 (Kirk Interface)
a398-afe7 Kirk4()
afe8-bdbf Kirk7()
bdc0-d83f Kirk1()

Kirk 4/7 Keys:
0000E670 98 02 C4 E6 EC 9E 9E 2F FC 63 4C E4 2F BB 46 68
0000E680 99 24 4C D2 58 F5 1B CB B0 61 9C A7 38 30 07 5F
0000E690 02 25 D7 BA 63 EC B9 4A 9D 23 76 01 B3 F6 AC 17
0000E6A0 84 85 C8 48 75 08 43 BC 9B 9A EC A7 9C 7F 60 18
0000E6B0 B5 B1 6E DE 23 A9 7B 0E A1 7C DB A2 DC DE C4 6E
0000E6C0 C8 71 FD B3 BC C5 D2 F2 E2 D7 72 9D DF 82 68 82
0000E6D0 0A BB 33 6C 96 D4 CD D8 CB 5F 4B E0 BA DB 9E 03
0000E6E0 32 29 5B D5 EA F7 A3 42 16 C8 8E 48 FF 50 D3 71
0000E6F0 46 F2 5E 8E 4D 2A A5 40 73 0B C4 6E 47 EE 6F 0A
0000E700 5D C7 11 39 D0 19 38 BC 02 7F DD DC B0 83 7D 9D
0000E710 0C FD 67 9A F9 B4 72 4F D7 8D D6 E9 96 42 28 8B
0000E720 AF FE 8E B1 3D D1 7E D8 0A 61 24 1C 95 92 56 B6
0000E730 1C 9B C4 90 E3 06 64 81 FA 59 FD B6 00 BB 28 70
0000E740 03 B3 02 E8 5F F3 81 B1 3B 8D AA 2A 90 FF 5E 61
0000E750 12 46 8D 7E 1C 42 20 9B BA 54 26 83 5E B0 33 03
0000E760 C4 3B B6 D6 53 EE 67 49 3E A9 5F BC 0C ED 6F 8A
0000E770 2C C3 CF 8C 28 78 A5 A6 63 E2 AF 2D 71 5E 86 BA
0000E780 11 5A 5D 20 D5 3A 8D D3 9C C5 AF 41 0F 0F 18 6F
0000E790 9C 9B 13 72 F8 C6 40 CF 1C 62 F5 D5 92 DD B5 82
0000E7A0 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

Kirk 1 Key:
0000E7B0 98 C9 40 97 5C 1D 10 E8 7F E6 0E A3 FD 03 A8 BA

0000E800 00 00 1C D0 1cd0: reference by a398:(Kirk 4),bdc0:(Kirk 1) aes_encrypt_cbc ?
0000E810 00 00 1E 40 1e40: reference by afe8:(Kirk 7),bdc0:(Kirk 1) aes_decrypt_cbc ?
0000E820 00 00 24 D0 24d0: reference by bdc0:(Kirk 1) hmac? aes-mac?

[Draan]

I've created a small SVN repository with the KIRK crypto functions.

https://code.google.com/p/kirk-engine/

Working CMDs: 4,5,6,7,8,9. (I'm not sure about 6,9. Others are tested).

[kgsws]

These are my notes

You have much more notes than i do, but yes, some of them are same as mine.
I was playing with kirk header area 0x00 - 0x1F and secret kirk key, but separately.
I am more testing "how can it work" than reversing ... it succeeded with kirk cmd 7/4, but that was really obvious even in SPU assembly.

Anyway, i am still confused with kirk header offset 0x74. It seems to be offset to real encrypted data (to skip plaintext), but this offset is 0x200 in 6.20 ipl, so it points behind plaintext and some "random" bytes.

Here is my experimental block signed by bure force. I did it long time ago and it seems to work. Offset value is 0x80 here, same used for PRX modules. Also plaintext header is here and one value found in pandora IPL.

[coyotebean]

Kirk 1 data decryption discovered (by trial and error XDDD)

decrypt_cbc 0x00 to 0x1F using Kirk 1 key
decrypt_cbc 0x90+value at 0x74 to end of file using decrypted 0x00-0x0F as key

[Proxima]

Here's my findings for the various Hash Functions. I think these are complete.


Hash Functions:

26e0: SHA1_Block
3558: SHA1_Init
35d0: SHA1_Update
3808: SHA1_Final
3b90: SHA1
3c20: HMAC_SHA1_Init
3d20: HMAC_SHA1_Update
3d40: HMAC_SHA1_Final
3dd8: HMAC_SHA1
41f8: MD5Transform
4b10: MD5Init
4b80: MD5Update
4db8: MD5Final
50e8: MD5
5178: HMAC_MD5_Init
5278: HMAC_MD5_Update
5298: HMAC_MD5_Final
5330: HMAC_MD5
53d0: SHA256_block
6fa0: SHA256_Final_inner
7400: SHA224_Init
7498: SHA224_Update
74b8: SHA224_Final
74d8: SHA224
7568: HMAC_SHA224_Init
7668: HMAC_SHA224_Update
7688: HMAC_SHA224_Final
7720: HMAC_SHA224
77c0: SHA256_Init
7858: SHA256_Update
7a90: SHA256_Final
7b48: SHA256
7bd8: HMAC_SHA256_Init
7cd8: HMAC_SHA256_Update
7cf8: HMAC_SHA256_Final
7d90: HMAC_SHA256


Data Section
d8e0: AES SBOX (ENCRYPTION) 0x100 bytes
da90: AES SBOX INVERSION (DECRYPTION) 0x100 bytes
dcd0: MD5 Round 1 Constants 0x40 bytes
dd20: SHA256 K256 Constants 0x100 bytes

Hope this helps.

[coyotebean]

Header hash done. It is calculated with AES-CMAC.

[silverspring]

Ok, this enticed me to start working on PSP again.

I'll publish all my KIRK notes I have including cmd1 format (or what was known about cmd1 before this revelation).

Offtopic: Been working full-time so haven't had free time lately.

EDIT: @coyotebean both header hash and data hash is CMAC-AES

EDIT2:
0x00-0x0F is decryption key (but stored encrypted with AES128, is not PLAINTEXT key)
0x10-0x1F is CMAC key (but again, derived ver not plain)
0x20-0x2F is header hash (CMAC)
0x30-0x3F is data hash (CMAC)

That "predata" at offset 0x90 includes a few bits, used as a salt, SHA1, etc.

Will edit post with more info when I have time (these are all info I gathered before this PS3 stuff so there may be some inaccuracies, but at least the info can be double checked now to confirm).

EDIT3:
Btw, KIRK is a 32-bit Sony-propriety CPU. AES ops are hardware accelerated, other things like ECDSA (cmd0x11) is done purely in software.

[coyotebean]

EDIT: @coyotebean both header hash and data hash is CMAC-AES

Posting at the same time I found the calculation of the header hash.
Yes I can see/guess the data hash is AES-CMAC from the Kirk emulator. But haven't figure out the exact formula yet.
You said you knew that before it is exposed in the PS3, you found that out from analyzing the CPU chip?

EDIT: Get the data hash now.\