PS3 packages and how it leads to PSP signing

[kgsws]

Right I managed to decrypt the sprx with unself from ps3tools under linux but I cant manage to run spu-objdump. It keeps saying
spu-objdump: emulator_drm.prx: File format not recognized
Any idea what I'm doing wrong?

emulator_drm only contains isolated module, you have to extract it and use spu-objdump on it.

Also I still think there is AES CBC operation somewhere, Kirk decrypt exhibit CBC behaviour, i.e. when 1 bit is reverse, the decoding of that block is messed up and the next block has the bit reversed in the same position. AES CTR operation alone will not chain the changes to the next block.

Yes, i think same. As i know, AES CTR is inverse to itself (= no encryption/decryption operations). Kirk command 7 (used in PRX) has inverse command 4 (inverse for PRX keys is disabled). Thanks to CBC fact i was able "encrypt" any data which were correctly decrypted by kirk command 7, but first 16 bytes were always "random".

EDIT: Here is example - just use kirk command 7 on it. Note that i just use decrypting algorithm fact and i don't know keys - that's why first 16 bytes are "random".

Advertising

[ben1066]

And how would I extract it?

Advertising

[wololo]

And how would I extract it?

By reading the whole thread, you should be able to figure it out

[kgsws]

OK, got some KIRK command 7 keys, also with working algorithm
Command 7 is used in PRX header. I tested only type 0x4B, but all of them should work.
Here is example source code to encrypt data.

here is code list

Code: Select all

KIRK cmd 7 key list
type 0x03: 9802C4E6EC9E9E2FFC634CE42FBB4668
type 0x04: 99244CD258F51BCBB0619CA73830075F
type 0x05: 0225D7BA63ECB94A9D237601B3F6AC17
type 0x0C: 8485C848750843BC9B9AECA79C7F6018
type 0x0D: B5B16EDE23A97B0EA17CDBA2DCDEC46E
type 0x0E: C871FDB3BCC5D2F2E2D7729DDF826882
type 0x0F: 0ABB336C96D4CDD8CB5F4BE0BADB9E03
type 0x10: 32295BD5EAF7A34216C88E48FF50D371
type 0x11: 46F25E8E4D2AA540730BC46E47EE6F0A
type 0x12: 5DC71139D01938BC027FDDDCB0837D9D
type 0x38: 12468D7E1C42209BBA5426835EB03303
type 0x39: C43BB6D653EE67493EA95FBC0CED6F8A
type 0x3A: 2CC3CF8C2878A5A663E2AF2D715E86BA
type 0x4B: 0CFD679AF9B4724FD78DD6E99642288B
type 0x53: AFFE8EB13DD17ED80A61241C959256B6
type 0x57: 1C9BC490E3066481FA59FDB600BB2870
type 0x5D: 115A5D20D53A8DD39CC5AF410F0F186F
type 0x63: 9C9B1372F8C640CF1C62F5D592DDB582
type 0x64: 03B302E85FF381B13B8DAA2A90FF5E61

We are small step closer to signing. KIRK command 1 remaining.

[wololo]

Forgive my ignorance, but where do the names "command 7" and "command 4" come from, in the case of Kirk? Is there some kind of naming convention here? Or is it just how you decided to name them?

[Proxima]

There is a great resource http://my.malloc.us/silverspring/kirk-crypto-engine/ that maps out the KIRK functions like 1,4 ,7 etc.

From my analysis, at offset 0xbdc0 in the dumped SPU asm is the KIRK1 function. KIRK4 is at 0xa398 and KIRK7 is at 0xafe8. At least in the 3.15 and 3.41 versions.
There are 60 functions to analyze total. The easiest way to pick them out is to look for the bi $0 instructions, its kind of the SPU equivalent of return. the bsrl is like the MIPS jalr or x86 call. You can track function calls that way.

Hope that helps.

[wololo]

Thanks, this helps a lot!

[Mathieulh]

I certainly hope none of you forget who gave you those keys/told you where they are. Eh?

[shadyblue9o9]

you know i was thinking and there maybe a way for sony to block any game signed with this key from official firmware update.
all they have to do is make a database of all of the names and identification of the games they have officially created and make it where if you update it it will block these games and all other games not on the list from running, then the only way you can run the game is if you download a patch for the game that will then let you play the game.... it is alot of work on sony's behalf but it could be possible.... right? i mean it might make the next update go from like 30mb to 50mb but it will still fix the problem right?
or just call me a noob and tell my to be quite because i dont know what i am talking about

[wololo]

@ shadyblue9o9 They would need to revoke the keys with a software change in the kernel + add this "old games" compatibility list.

I think the keys are on the kirk chip. So unless they have some "spare" keys that they didn't put in the PS3, that is not doable because they can't revoke all of them.

Now, assuming they can revoke some of the keys AND they have spares ones that cannot be found on the PS3, they would additionally need some kind of "whitelist" hash for all old games. This list would lie in the Kernel, and assuming it's some 16bytes hashes/checksums (is that enough?), and that they have a list of 1500 old games (I'm counting 500 games * 3 regions), that's a few dozen kilobytes in the kernel, which doesn't sound impossible to me... But the kernel is already quite full I believe...so that would mean removing some features...or move them to the memory stick...quite a lot of work if the PSP2 is really coming soon...

Edit:

I certainly hope none of you forget who gave you those keys/told you where they are. Eh?

coyotebean?
Seriously though, your name is mentioned 4 times in the OP, and I clearly stated that you were the source (I quote: "I'm trying to understand the process with which Mathieu found the PSP master key"), not sure what else we can do to please you here