PS3 packages and how it leads to PSP signing

[Mathieulh]

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

That's actually a nice trick, I never thought about that, I just had the idea of running a homebrew inside a "signed" npdrm iso, but if we can get passed it, it's just as fine

Advertising

[Proxima]

Here's an overall process that worked for me:

1. Use PRXDecrypter or other like app to decrypt a demo game DATA.PSP. Just before it calls KIRK1, add a step to dump the KIRK1 message with header.
2. Zero out the data section of the KIRK1 message. Copy your homebrew ELF into it.
3. Look at the original PSP header and get the entry point and mod info offset it expects
4. Put a couple of lines of code at the expected entry point to jump to the real entrypoint of your own ELF
5. copy the modinfo section from your ELF to the address indicated by the original header.
6. Re-encrypt the new KIRK1 data section with the KIRK key (AES Key from Header)
7. Do a few xor of the last 16 bytes to make it result in the correct CMAC value (decode the CMAC data hash to see what the correct value needs to be)
8. Copy the data back to the original data.psp (at 0x150). pack-pbp the new data.psp along with your favorite param.sfo and icon files.

If the original game was compressed, you need to add step 5b. gzip the entire data section (0x110-EOF) and re-paste it into the file.

Enjoy!

PS. One bit of difficulty still that remains is how to deal with the KL4E compression that the kernel modules us. Since their headers indicate compression, and KL4E is the only algorithm the rebooter or ipl supports (I think...) we will have to find a way to create something that decompresses properly with KL4E.

Advertising

[coyotebean]

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.

Since 6.30, I believe the only files left with CMAC "signature" are games, for compatibility reason. All firmware files are signed with ECDSA and CMAC files will not load. And the irony about kernel modules is: you need kernel access to replace a kernel module

[zero4894]

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

I don't know if this helps you and I'm really sorry if it doesn't but i noticed you said it was tested on a fat PSP with OFW 6.35 and I wanted to let you know that i can confirm it also working on PSP Brite OFW 6.20.

[VllnHalf]

I was going to PM him my confirmation but being the guy above posted, and it is likely that our posts will get erased anyway, I can confirm that it works on 6.20 N1000.

[kgsws]

Here's an overall process that worked for me:

1. Use PRXDecrypter or other like app to decrypt a demo game DATA.PSP. Just before it calls KIRK1, add a step to dump the KIRK1 message with header.
2. Zero out the data section of the KIRK1 message. Copy your homebrew ELF into it.
3. Look at the original PSP header and get the entry point and mod info offset it expects
4. Put a couple of lines of code at the expected entry point to jump to the real entrypoint of your own ELF
5. copy the modinfo section from your ELF to the address indicated by the original header.
6. Re-encrypt the new KIRK1 data section with the KIRK key (AES Key from Header)
7. Do a few xor of the last 16 bytes to make it result in the correct CMAC value (decode the CMAC data hash to see what the correct value needs to be)
8. Copy the data back to the original data.psp (at 0x150). pack-pbp the new data.psp along with your favorite param.sfo and icon files.

Hmm seems to be complicated. I was not modifying original ELF at all, and it worked ... with executable block size limit.

And is there some mark that it contain compressed data? If not, why compression?

Since 6.30, I believe the only files left with CMAC "signature" are games, for compatibility reason. All firmware files are signed with ECDSA and CMAC files will not load. And the irony about kernel modules is: you need kernel access to replace a kernel module

Yes, but 6.20 can be used as base. I think there is downgrader for 6.35, ins't it?

If it works on 6.20, it will bring back old times where custom firmware used 1.50 kernel as base to load newer one

[Disturbed0ne]

Like a few posters above I'd like to confirm that this works on a 3001 with 6.35OFW.

I can't wait to see what comes out of this.

[haslomaslo2]

Confirmed working on OFW 6.20 Brite 3001 4g.

[beavisdave]

Confirmed working on OFW 6.35 PSP GO

[VllnHalf]

Okay, I think we've confirmed it probably works on all PSPs; So let's let the developers get back to work.

m0skit0; being people like to talk about this. Do you think it would be cool if I made a decision topic about it in the homebrew, general, or offtopic section? That would probably keep the spam down.