Advertising (This ad goes away for registered users. You can Login or Register)

PS3 packages and how it leads to PSP signing

Forum rules
Forum rule Nº 15 is strictly enforced in this subforum.
Locked
Zecoxao
Posts: 280
Joined: Mon Sep 27, 2010 7:27 pm

Re: PS3 packages and how it leads to PSP signing

Post by Zecoxao »

No it isn't because it's allocated on RAM, so everytime you do a "hard boot" (which is when you hold the switch more than 3 seconds to power off the psp), or when you're messing with crashes or when you remove your battery, you need to restart the whole process (of triggering the exploit).
But yeah it would help ;)
Advertising
My sig is original :D
Cloudy
Posts: 4
Joined: Sat Jan 15, 2011 12:21 am

Re: PS3 packages and how it leads to PSP signing

Post by Cloudy »

If you could throw a signed prx in the boot chain then you could do patches to make it a perma cfw. Wouldn't necessarily have to be a vshmain, but you would be better talking to the cfw developers.
Advertising
chapix
Posts: 6
Joined: Sat Jan 15, 2011 7:26 pm

Re: PS3 packages and how it leads to PSP signing

Post by chapix »

kgsws wrote:It is properly signed, but it uses precalculated header from existing demo game(s) :)
i am a little bit skeptical.
First we don't have any keys for demos.And in my investigation, in order to encrypt and sign code we need to :

1)Encrypt aes_game key and cmac key with kirk key ->ok
2)Xor aes_game_enckey, cmac_enckey, cmac_header_hash and cmac_header_data ->ok
3)Encrypt these datas with kirk7_keydemo -> fail we don't have kirk7_keydemo
...

So i do some test with eboot.bin 2.xx . I can decrypt eboot.bin and encrypt my own code with these keys but sign failed.
Hykem
Guru
Posts: 75
Joined: Sat Jan 15, 2011 8:11 pm

Re: PS3 packages and how it leads to PSP signing

Post by Hykem »

Hi. :)
Long time lurker, first time poster.

After seeing coyotebean's references to Kirk4, Kirk7 and Kirk1 functions calling 0x1e40, 0x1cd0 and 0x24d0 in the SPU disasm, I've been looking for other similar functions that could be calling these handlers. Here're my findings so far:

Code: Select all

// Encrypt
ENCRYPT_CBC(0x0003F000, 0x0003E000, 4096, unkkey, 128, stack + 784 + 32);
ENCRYPT_CBC(0x0003F000, 0x0003E000, calcsize, stack + 768, 128, stack + 784 + 32);
ENCRYPT_CBC(stack + 1792 + 32, stack + 1648 + 32, 32, 59312, 128, stack + 1616 + 32);
HMAC(stack + 1824 + 32, stack + 1648 + 96, 48, stack + 1792 + 16, 128);

// Decrypt
DECRYPT_CBC(0x0003F000, 0x0003E000, 4096, stack + 1792 + 32 + 16, 128, stack + 1616 + 32);
DECRYPT_CBC(0x0003F000, 0x0003E000, calcsize, stack + 1792 + 32 + 16, 128, stack + 1616 + 32);
DECRYPT_CBC(0x0003F000, 0x0003E000, 4096, stack + 1792 + 32, 128, stack + 1616 + 32);
DECRYPT_CBC(0x0003F000, 0x0003E000, calcsize, stack + 1792 + 32, 128, stack + 1616 + 32);
HMAC(stack + 1824 + 32, 0x0003E000, 16, stack + 1792 + 32 + 16, 128);
I'm assuming DECRYPT/ENCRYPT_CBC(outbuf, inbuf, insize, key, bits, iv) and HMAC(outbuf, inbuf, insize, key, bits) just for conveniece, as these can mean something completely different.
Most of the params are obtained from the stack and some of them, like unkkey and calcsize, result from several rot and xor operations.

EDIT: By the way, in the posted PSPHEADER struct, is the decryptMode supposed to match the last param passed to sceUtilsBufferCopyWithRange, or is it something else? I've noticed this parameter is mostly 09 in post 2.00 FW, UMD signed EBOOT's, but I've also came across another PSPHEADER struct (with less params), prior to 2.00 FW, that, as decryptMode, can also accept encrypt modes (4 and 6, so far).
hitchhikr
Posts: 8
Joined: Tue Jan 11, 2011 10:46 pm

Re: PS3 packages and how it leads to PSP signing

Post by hitchhikr »

is the decryptMode supposed to match the last param passed to sceUtilsBufferCopyWithRange, or is it something else?
That's something else entirely, it's used to determine which file type and where if it can be run depending on where it's located (it's also linked to the mod_attribute field).
chapix wrote: kgsws wrote:It is properly signed, but it uses precalculated header from existing demo game(s) :)


i am a little bit skeptical.
First we don't have any keys for demos.And in my investigation, in order to encrypt and sign code we need to :

1)Encrypt aes_game key and cmac key with kirk key ->ok
2)Xor aes_game_enckey, cmac_enckey, cmac_header_hash and cmac_header_data ->ok
3)Encrypt these datas with kirk7_keydemo -> fail we don't have kirk7_keydemo
...

So i do some test with eboot.bin 2.xx . I can decrypt eboot.bin and encrypt my own code with these keys but sign failed.
I don't understand either yet but congratulations if you succeeded, i can see how the rest of the header can be re-used but bypassing the data hash doesn't seem to be possible to me as we can't encrypt it so we can't modify it to match our own made data (it's double-checked with a SHA1 but the CMAC hash can be encrypted so is the SHA1's), unless they forgot to check something and there's a hole in the firmware that can be exploited ? But in that case it'll be closed very soon after the exploit is made public. (I didn't check the "locoroco" 2.7 like demos files yet (just noticed they're less tricky to decode), only the newer ones. Did you use one of those ?)
Mathieulh
Guru
Posts: 49
Joined: Thu Jan 06, 2011 6:17 am
Contact:

Re: PS3 packages and how it leads to PSP signing

Post by Mathieulh »

You "just" need to encrypt a "store"/npdrm iso with your homebrew in it as EBOOT.BIN and it'll work.
Last edited by Mathieulh on Sun Jan 16, 2011 12:23 am, edited 1 time in total.
---
PGP Fingerprint: DF46 8C79 5D1A 76FF 75B2 C345 4679 EDEF 1B5B B192
Public Key: https://pgp.mit.edu/pks/lookup?op=get&search=0x1B5BB192

Proof: https://keybase.io/mathieulh
Draan
Posts: 72
Joined: Tue Dec 21, 2010 9:49 pm

Re: PS3 packages and how it leads to PSP signing

Post by Draan »

And because PS3 must decrypt miniS...the npdrm stuff should be in PS3 too...
coyotebean
Guru
Posts: 96
Joined: Mon Sep 27, 2010 3:22 pm

Re: PS3 packages and how it leads to PSP signing

Post by coyotebean »

kgsws wrote:Right now it might not be good idea to release it. I guess sony will do something against it as soon as possible.
Mathieulh wrote:You "just" need to encrypt a "store"/npdrm iso with your homebrew in it as EBOOT.BIN and it'll work.
I don't know how Sony can protect itself from these two issues, they have to maintain compatibility with existing releases. The algorithm & keys cannot be changed.
GBASP x1, GBM x2, NDSL x2, PSP 100X x3, PSP 200X x6, PSP 300X x5, PSP Go x4, Wii x1
dauphin327
Posts: 101
Joined: Sat Jan 15, 2011 5:58 pm
Location: 127.0.0.1,Localhost

Re: PS3 packages and how it leads to PSP signing

Post by dauphin327 »

just Asking But What's About: http://kirk-engine.googlecode.com/svn/trunk/ is that updated?
:lol:
kgsws
Guru
Posts: 77
Joined: Wed Jan 05, 2011 9:51 am

Re: PS3 packages and how it leads to PSP signing

Post by kgsws »

Well ok, here it comes. Try this one.
tested on fat PSP with OFW 6.35

How?
Simple, notice it contains ~PSP header from demo game (UCES00206), it is exactly same header.
It is easy to craft last 16 bytes of encrypted data block to match header CMAC - yes, that's the trick :)

There are some strange thigs, it can't run homebrews with bigger executable block (data block does not matter), and because of ~PSP header, it has to match exact size of original game.

This trick might be possible on firmware kernel modules to get permanent HEN on non-pandrorable PSPs, i was not able to do it but i was not trying that much.

PS: i am not only one who found this trick :)
Locked

Return to “Programming and Security”