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.
carlosgs
Posts: 17
Joined: Mon Jan 17, 2011 11:57 am

Re: PS3 packages and how it leads to PSP signing

Post by carlosgs »

m0skit0 wrote:
carlosgs wrote:I would like to know if someone is going to make this program for linux also.
You can do it yourself, you have all you need.
Sorry I posted that too soon! Though I haven't seen the source code, it works with "Wine" without problems.
I have been able to compile a simple particle simulator without problems.
Thanks again.
Advertising
carlosgs
Posts: 17
Joined: Mon Jan 17, 2011 11:57 am

Re: PS3 packages and how it leads to PSP signing

Post by carlosgs »

OSlib actually works, but the screen doesn't clear between frames (thats easy to solve).
Maybe it happens just to me.
Intrafont GU demo works without problems, the "graphics.h + intrafont" demo doesnt work.

If an eboot returns an error try to insert an UMD since i've seen the PSP responds diferently with the UMD.
Advertising
hitchhikr
Posts: 8
Joined: Tue Jan 11, 2011 10:46 pm

Re: PS3 packages and how it leads to PSP signing

Post by hitchhikr »

Draan: the SHA1 implementation you're using seems to be bogus (doesn't give the same result as openssl's which is correct) also the insize is used not the outsize value (which makes sense since the output is always 20 bytes).

Also KIRK_CMD_ENCRYPT_IV_0 expects 4 as first value (something like: #define KIRK_MODE_ENCRYPT_CBC 4) instead of 5 and the output is a valid KIRK_CMD_DECRYPT_IV_0 packet (so it reconstruct the same header with 5 instead of 4 and encrypted data are written at outbuf + sizeof(KIRK_AES128CBC_HEADER)).

Notice that the KIRK can decrypt keys up to 0x7f but can only encrypt up to 0x3f.

Forging data to match the CMAC is a good idea (i don't think we can modify the header because of the 332 bytes SHA1 check run over it), i had a similar idea but i quickly dismissed it as i didn't think it would possible :D

One possible issue is that Sony might create a white list with SHA1 of all official demos (there aren't that many) and forbid anything not matching and then use a stronger PRX scheme for the next demos to be released (i think they sign the demos themselves not the developers otherwise signing tool would be in the wild already) this, together with a new firmware, would render any signed homebrews quickly obsolete (or they can also just use UMD ISO images from now on and drop those kind of PRX in the future).
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 »

hitchhikr wrote:Draan: the SHA1 implementation you're using seems to be bogus (doesn't give the same result as openssl's which is correct) also the insize is used not the outsize value (which makes sense since the output is always 20 bytes).

Also KIRK_CMD_ENCRYPT_IV_0 expects 4 as first value (something like: #define KIRK_MODE_ENCRYPT_CBC 4) instead of 5 and the output is a valid KIRK_CMD_DECRYPT_IV_0 packet (so it reconstruct the same header with 5 instead of 4 and encrypted data are written at outbuf + sizeof(KIRK_AES128CBC_HEADER)).

Notice that the KIRK can decrypt keys up to 0x7f but can only encrypt up to 0x3f.

Forging data to match the CMAC is a good idea (i don't think we can modify the header because of the 332 bytes SHA1 check run over it), i had a similar idea but i quickly dismissed it as i didn't think it would possible :D

One possible issue is that Sony might create a white list with SHA1 of all official demos (there aren't that many) and forbid anything not matching and then use a stronger PRX scheme for the next demos to be released (i think they sign the demos themselves not the developers otherwise signing tool would be in the wild already) this, together with a new firmware, would render any signed homebrews quickly obsolete (or they can also just use UMD ISO images from now on and drop those kind of PRX in the future).
We conveniently happen to have the keys for both npdrm isos and UMD prxs
---
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 »

hitchhikr wrote:Draan: the SHA1 implementation you're using seems to be bogus (doesn't give the same result as openssl's which is correct) also the insize is used not the outsize value (which makes sense since the output is always 20 bytes).
IIRC i tried that SHA1 calculation and it worked. I'll fix that if not. Actually it takes insize, so what's the problem? ;)
hitchhikr wrote: Also KIRK_CMD_ENCRYPT_IV_0 expects 4 as first value (something like: #define KIRK_MODE_ENCRYPT_CBC 4) instead of 5 and the output is a valid KIRK_CMD_DECRYPT_IV_0 packet (so it reconstruct the same header with 5 instead of 4 and encrypted data are written at outbuf + sizeof(KIRK_AES128CBC_HEADER)).

Notice that the KIRK can decrypt keys up to 0x7f but can only encrypt up to 0x3f.
Didn't I do it exacly that way? I've done rewert of the code twice, maybe i forgot to add it back.

I know that KIRK is restricted, but my code was meant to not be :)
flofrucht
Posts: 587
Joined: Wed Sep 29, 2010 5:46 pm
Location: /root
Contact:

Re: PS3 packages and how it leads to PSP signing

Post by flofrucht »

bbtgp wrote:It may not work with more complex eboots, that particular program may also be importing functions that dont exist if your on ofw such as SystemControl.

http://bbtgp.net/downloads/prxencrypter_sdk.7z correctly named it, modded build.mak and included sample. Set ENCRYPT=1 in the makefile for other programs to encrypt them.

EDIT: also that emulator appears to to be compiled statically. Probably why it failed to load.
Awesome :) ,thanks dude ;)
twitter.com/flofrucht
PSPDev and scener
hitchhikr
Posts: 8
Joined: Tue Jan 11, 2011 10:46 pm

Re: PS3 packages and how it leads to PSP signing

Post by hitchhikr »

Draan: sorry my bad i must have been using an older version but you implemented it meanwhile.

Still, i tested the SHA1 again and the result is different from Openssl implementation, also you only copy 16 bytes to the output buffer but SHA1 digests are 20 bytes.

Btw, I was wondering if all the KIRK keys could have been generated with simple srand()/rand() back 2003/2004 ?
Last edited by hitchhikr on Mon Jan 17, 2011 4:08 pm, edited 1 time in total.
hitchhikr
Posts: 8
Joined: Tue Jan 11, 2011 10:46 pm

Re: PS3 packages and how it leads to PSP signing

Post by hitchhikr »

We conveniently happen to have the keys for both npdrm isos and UMD prxs
Now what is the format of these files ? (beside the usual PBP data segments which apparently can't even be moved).
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 »

bbtgp wrote:It may not work with more complex eboots, that particular program may also be importing functions that dont exist if your on ofw such as SystemControl.
kgsws wrote:There must be something wrong with PSP SDK prxes, OFW always refuses more complicated ones, with error 0x80020148, that means it refused it even before imports checking. (i know it because i made smaller homebrew with invalid import and it returned different error - library not found)

Why in PSP SDK? Well, OFW accepts re-signed original demos, unchanged, and no matter if ~PSP header is incorrect.
Also, CFW accepts all "signed" homebrews. So CFW seem to have patch that allows all homebrews to run.
So, someone else working on it? I was not able to find what is wrong in SDK PRXes. I know for sure it is not about invalid imports sice that returns different error number.
Demo games seems to have little different values in ELF(section/program) headers, but not much.
Libre
Posts: 47
Joined: Sat Jan 01, 2011 4:51 pm

Re: PS3 packages and how it leads to PSP signing

Post by Libre »

kgsws wrote:So, someone else working on it? I was not able to find what is wrong in SDK PRXes. I know for sure it is not about invalid imports sice that returns different error number.
Demo games seems to have little different values in ELF(section/program) headers, but not much.
I though it was relevant to say that it did only work for me with EBOOTs whose DATA.PSP were build with "BUILD_PRX = 1" (most are not). I know the source provided is for PRXs but I think it might be related to the issue, or at least give some way to look at. The same code build without that option ends up on a 0x80020148 error, but works fine with it. It may also rely on some flags used in the optimization process or some kind of tiny differences in the structure inside the PRXs. I tried out several flags with no success.

Feel free to delete this post if it's not relevant.
Post Reply

Return to “Programming and Security”