Use 1.0 to encrypt an exploite for 1.5

zenjay · Post by **zenjay** » Fri May 13, 2005 12:07 pm

If, and this is a big IF, all save game data is encrypted. That means that the encryption function could be in the bios. Could we get the address of that on a 1.0 firmware and use it, like nems did with sceDisplaySetMode, to encrypt a saved game data with a buffer-overflow exploite of some kind. then load that file onto 1.5 and see if you can get it to work?... and share it, at least with me;-)?

possible road blocks are:

finding a game with a buffer-overflow exploite of some kind
the encryption function isn't in the bios.
the encryption function is itself encrypted.

But once we get an encrypted saved game then it should be able to run on a 1.5, right? I mean if they want save game data to be compatible with different bios versions then a saved data encrypted by a 1.0 should work on 1.5. I mean if you update your bios and then can't read game file you saved on 1.0 would be something they wouldn't want right? Maybe I'm crazy... Perhaps this will save us the problem of figuring out how to crack the encryption (which seems impossible).

Anyone with a 1.0 who tried to find out if the encryption function is in the bios yet or willing to give this idea a try?

P.S. I've been trying to keep up with this fourm.... amazing work you guys are doing i just wish i had a 1.0 PSP to try this on, so I could contribute more.

P.S.S. It seems to me more and more that we might have to reverse engineer the firmware in order for us to do homebrew dev. I hope it doesn't come to that.

Raoul · Post by **Raoul** » Fri May 13, 2005 12:17 pm

If there is a function to encrypt we can suppose that there is also one to decrypt. So it is useless to encrypt a savegame if we can decrypt the 1.5 firmware.
Just a guess.

zenjay · Post by **zenjay** » Fri May 13, 2005 12:22 pm

I was not trying to get the 1.5 firmware decrypted. I was trying to get encrypted binaries from a 1.0 PSP so that it can be run on a PSP with a 1.5 firmware. because the 1.5 firmware only executes encrypted binaries.

Krevnik · Post by **Krevnik** » Fri May 13, 2005 3:34 pm

The problem here is that people are assuming the encryption is as simple and careless as something like CSS which is not the case. With BSAFE and Verisign being used, and possibly asymmetric encryption to protect symmetric keys... it makes CSS look like a toy (which it is).

Gamesaves are the exception however, so it is a possible vector. Unfortunately, it still requires a dump from the game and some work in order to achieve this, as we have to understand what key that particular game is using for encryption (which is likely purely symmetrical, tied to the particular release of the game, as the source and destination of the data is the same object). So the best place to start is work on finding an exploit in the game you own, and then work from there. Unfortunately, this route will only work for the particular version of the game the exploit is crafted for (so crafting it with the JP Wipeout will not help the US PSP owners with the US Wipeout, for example).

zenjay · Post by **zenjay** » Fri May 13, 2005 11:52 pm

Krevnik wrote:The problem here is that people are assuming the encryption is as simple and careless as something like CSS which is not the case. With BSAFE and Verisign being used, and possibly asymmetric encryption to protect symmetric keys... it makes CSS look like a toy (which it is).

Well I'm not saying trying to break the encyption, from what i've read on this forum about the AES cipher, that seems nearly impossible. but... couldn't we use the encryption function they have in the 1.0 firmware to encrypt our own elf binary? I mean only the people with the 1.0 could encrypt but hopefully we could all run that encrypted file on a 1.5 firmware, right?

Krevnik wrote: Unfortunately, it still requires a dump from the game and some work in order to achieve this, as we have to understand what key that particular game is using for encryption

good point... humm... i'm assuming we can get a dump for a game already?... though it's encrypted. couldn't we use the decrypt function in the BIOS once we can call it? (see bellow)

Krevnik wrote: Unfortunately, this route will only work for the particular version of the game the exploit is crafted for (so crafting it with the JP Wipeout will not help the US PSP owners with the US Wipeout, for example).

interesting... we only need one game for the JP and another for the US exploited to make this work? if a person with a JP 1.0 firmware can get a JP wipeout and a US wipeout... find an exploite for both... compile and encrypt two different game save with the exploite on his 1.0 system. we could then test the load on a non-1.0 version of the firmware with either the JP or the US version of the game and the correct version of the exploite.

I know this sounds a lot like the step two in the underwear noms(sp?) episode from South Park... I mean first you need to find an expolite in 1.0 for JP AND US games... This is only a theory... I can't test it cause i don't own a 1.0 so i lack the hardware not to mention the the hardware knowlege to dump my own dump of the 1.0 firmware to look at. I've looked through nems "Hellow World" code and tried to figure out how his MIPS assm code (startup.s) does the loading of the sceDisplay functions. Couldn't we us a similar method (assuming we knew where this function's address is on the firmware) to call the encryption functions?

so

Step 1: get 1.0 firmware dump.
Step 2: find where encryption/decryption function is in the 1.0 firmware BIOS
Step 2.1: test using nems startup.s to load and call encryption/decryption functions. (obviously on a 1.0 PSP)
Step 2.2: decrypt a UMD game (either JP or US) and find an exploite to use (hahahaha this should be a topic of its own if we can even get this far)
Step 2.3: us the 1.0 PSP to encrypt the exploite.
Step 3: Load it onto a PSP 1.5+ to exploit game!!!!!

There's many ways this could not work so i'm just wondering if someone could give it a try. and IF sony built the ecryption process into the bus lines between memory and the registery then we're all screwed.

th0mas · Post by **th0mas** » Fri May 13, 2005 11:55 pm

Krevnik wrote:we have to understand what key that particular game is using for encryption (which is likely purely symmetrical, tied to the particular release of the game, as the source and destination of the data is the same object).

I believe it's already a fact that encrypted gamesaves are signed against the PSP, not just the game (that is, gamesaves are non-transferrable between PSPs). I believe this was found when people were attempting to distribute a savegame they believed had a buffer overflow (i think it was a wipeout gamesave).

zenjay · Post by **zenjay** » Sat May 14, 2005 12:07 am

th0mas wrote: I believe it's already a fact that encrypted gamesaves are signed against the PSP, not just the game (that is, gamesaves are non-transferrable between PSPs).

serious? that sucks... wait that means you can't swap your memory cards like you can on the PS2? that doesn't sound right.

oh well i guess its time to write my own firmware. j/k ;-)

yackom · Post by **yackom** » Sat May 14, 2005 12:10 am

save games non transferable? then whats the point of having them so easly removed on memory sticks and stuff. that doesnt seem likely, why would sony prevent people from emailing friends savegames or whatever? is this actually confermed or are you just saying?

MDave · Post by **MDave** » Sat May 14, 2005 12:16 am

People need to start looking at the gameshare function more, like I said in off-topic chat (in snes emu thread). If someone can find out how to make their homebrew code go into "send game to other psp's through gameshare" mode then we could have homebrew on 1.5 psp's. Anyone looked into that? I think we'd get better results with that then figuring out how to encrypt/decrypt gamesaves.

zenjay · Post by **zenjay** » Sat May 14, 2005 12:22 am

I'm going to test this as soon as I find someone with another PSP. in the meantime if anyone else can confirm this save game transfer issue it would be great.

I was also looking at the firmware directory dump in the other treads and i believe the best place to start would be:

flash0:\vsh\module\
60224 savedata_auto_dialog.prx [PSP] sceVshSDAuto_Module
61344 savedata_plugin.prx [PSP] sceVshSDPlugin_Module
59344 savedata_utility.prx [PSP] sceVshSDUtility_Module
and
flash0:\vsh\resource\
68328 savedata_plugin.rco
64428 savedata_utility.rco

I know the .prx files are something like .dll files and unfortunately encrypted but what are the .rco files? and how are they used? cause they seem to be unencrypted.

spiral · Post by **spiral** » Sat May 14, 2005 1:36 am

i've downloaded a save game with completed progress on a game I borrowed and it worked fine on my psp. I assume the other save game must have been played on another psp, so save games aren't locked to one psp.

yackom · Post by **yackom** » Sat May 14, 2005 1:49 am

i didnt think they would be, thanks for the check spiral.

sq377 · Post by **sq377** » Sat May 14, 2005 1:59 am

Game saves are not locked per psp. Ghost saves are for wipeout however.

Someone was considering an exploit in the ghost saves, but when i gave him one to look at, he could not run it on his psp, but i could run it on mine.

zenjay · Post by **zenjay** » Sat May 14, 2005 2:02 am

is there a difference between a game save and a ghost save? and what is it? whatever ghost saves are I'd still try to focus on game saves.

steddy · Post by **steddy** » Sat May 14, 2005 3:58 am

Already discussed... duplicate thread.

See my previous post from a few days ago:-

http://forums.ps2dev.org/viewtopic.php?t=1638

Steddyman

zenjay · Post by **zenjay** » Sat May 14, 2005 4:43 am

well i guess it was brought up. but has anyone have any luck trying to find this encryption function in the BIOS? this work depends on finding and being able to run the encryption function on a 1.0 PSP. If we can't do this then this thread and the one mention just now are both useless.. except for pure info sake (aka... so we don't repeat it;-)

and if the encryption for the saved games are the same as the executable program then we can just forget about having to exploite a game... we could just compile and encrypt binaries to run... though my guess is that saved games and exec are encrypted differently.

Perhaps this could be a dead end but i don't see another way. We must figure out how to encrypt our binaries or they won't execute. other then sodering wires to the registery and dumping the instruction sets directly into the CPU's registers that way or reprogramming the BIOS.

Krevnik · Post by **Krevnik** » Sat May 14, 2005 5:03 am

zenjay wrote: Well I'm not saying trying to break the encyption, from what i've read on this forum about the AES cipher, that seems nearly impossible. but... couldn't we use the encryption function they have in the 1.0 firmware to encrypt our own elf binary? I mean only the people with the 1.0 could encrypt but hopefully we could all run that encrypted file on a 1.5 firmware, right?

But in a way, you have to in order to encrypt something yourself. It isn't like the key is out in the open, or static. RSA is used to hide the key from prying eyes like us, or used so that different AES keys can be used on different game saves (generated randomly), making analysis difficult.

good point... humm... i'm assuming we can get a dump for a game already?... though it's encrypted. couldn't we use the decrypt function in the BIOS once we can call it? (see bellow)

Somewhat, but we already have raw dumps (BOOT.BIN), the issue is that games aren't just encrypted through a single function. Most of it is signed too, making it difficult as to sign something ourselves, we have to have the key. And the AES key is not static for everything, it changes (thanks to the ability of signing and asymmetric encryption... read up on how PGP encrypts things).

zenjay · Post by **zenjay** » Sat May 14, 2005 7:56 am

I looked up some info on PGP ecryption. and from a website I got this quick case.

Lets say youw want to send Allice an encrypted message

1. You say to PGP that it has to encrypt a message with the Alice's public key 'APK'
2. PGP creates a new temporary secret key 'TSK' randomly
3. PGP encrypts the message by means of the temporary key 'TSK' (it uses IDEA, CAST or Triple-DES algorithms, which are symmetric systems)
4. PGP encrypts the temporary key 'TSK' by means of the Alice's public key 'APK' (it uses RSA or DSS/Diffie-Hellman algorithms, which are asymmetric systems). So this key become an encrypted key 'EK'
5. PGP sends both of them (the encrypted message and the key used to encrypt it) to the recipient
6. Alice receives your message
7. She decrypts the encrypted key 'EK' by means of her private key 'APRIVK' (here PGP uses RSA or DSS/Diffie-Hellman algorithm). So the key become 'TSK' again
8. Now her copy of PGP 'knows' the temporary secret key 'TSK', so it can use it to decrypt the message...

Now... apply this to the PSP...

SONY is trying to send encrypted code onto the PSP. so...
SONY is YOU (the sender) and the PSP is Alice (the reciever).
In this case the PSP is the reciever. AND that means that SONY is using a temp key ('TSK') that they encrypted with the the PSP's public key ('APK') to get 'EK'.
The code has already been coded with 'TSK' and is sent to the PSP along with an 'EK'
The 'APRIVK' should be somewhere in the BIOS and if we can get that and use that to decode 'EK' to get 'TSK' then we can use the 'TSK' and the 'APK' to encode our own code, if we could find the right encryption/decryption functions.

I feel that PGP encryption is secure enough for the purpose of encrypting a message that can not be read by someone without the 'APRIVK' (private key). But the private key for the PSP SHOULD be in the PSP BIOS! or else it won't be able to decrypt anything. Which leaves a small door open for us to get in if we could find the 'APRIVK' (private key) and the locations of the encryption/decryption functions in the BIOS.

Now as far as signing stuff goes... they would have to built a signing verification function into the BIOS. and if they did I'm not sure if we can fake the signature.

Sculay · Post by **Sculay** » Sat May 14, 2005 8:00 am

Have u tried this out if it works

EDITED

zenjay · Post by **zenjay** » Sat May 14, 2005 8:03 am

If I had a 1.0 firmware I would definately dump out a BIOS be going down this route. Alas I don't and can't :-(

Sculay · Post by **Sculay** » Sat May 14, 2005 8:10 am

same here someone told me to update the psp beccause loads of nice cool features will be included dat dumbass was my bloody brain:@ grrrrrrr

i might buy the MB for the psp and try helpin

Famicom DS · Post by **Famicom DS** » Sat May 14, 2005 3:02 pm

I tried updating my japanese psp to version 1.51 (not that I would continue with the instalation) I was just curious wether or not my psp would show that I need to update my firmware and I got an error

Connection to the server failed.
A DNS error has occurred.
(80410410)

PSP_killer · Post by **PSP_killer** » Sat May 14, 2005 3:07 pm

I think the reason for that is you still have ur internet setting set up for the wipout pure browser "hack"

Famicom DS · Post by **Famicom DS** » Sat May 14, 2005 3:10 pm

PSP_killer wrote:I think the reason for that is you still have ur internet setting set up for the wipout pure browser "hack"

I don't think thats it because i've never tried the wipeout pure browser "hack" could it be that im not standing close enough to my wireless connection? Has anyone tried to update from 1.50 to 1.51 jap psp?

Krevnik · Post by **Krevnik** » Sat May 14, 2005 3:31 pm

zenjay wrote:I looked up some info on PGP ecryption. and from a website I got this quick case. <snip>

Good example. :)

Now... apply this to the PSP...

SONY is trying to send encrypted code onto the PSP. so...
SONY is YOU (the sender) and the PSP is Alice (the reciever).
In this case the PSP is the reciever. AND that means that SONY is using a temp key ('TSK') that they encrypted with the the PSP's public key ('APK') to get 'EK'.
The code has already been coded with 'TSK' and is sent to the PSP along with an 'EK'
The 'APRIVK' should be somewhere in the BIOS and if we can get that and use that to decode 'EK' to get 'TSK' then we can use the 'TSK' and the 'APK' to encode our own code, if we could find the right encryption/decryption functions.

Here is where things change. Instead of encrypting this way, we 'sign'. Signing is the REVERSE process... encrypting with the private key so that only the public key can decrypt it. The secret is still kept secret, but you can verify where the data signed came from. You know that EK came from the APRIVK, and can thus trust it if you trust that the owner of APRIVK is still the owner.

I feel that PGP encryption is secure enough for the purpose of encrypting a message that can not be read by someone without the 'APRIVK' (private key). But the private key for the PSP SHOULD be in the PSP BIOS! or else it won't be able to decrypt anything. Which leaves a small door open for us to get in if we could find the 'APRIVK' (private key) and the locations of the encryption/decryption functions in the BIOS.

Now as far as signing stuff goes... they would have to built a signing verification function into the BIOS. and if they did I'm not sure if we can fake the signature.

Here is the thing, I don't think Sony would be suicidal enough to put private keys into the PSP. I could be wrong, but I do believe Sony and their track record on encryption is pretty strong (considering), and that they would stick to signing. The signature can be faked, but it involves cracking the public key to get the private key from it (read up on RSA in particular to know why really fast factoring of numbers is a threat to asymmetric systems).

Signing in this case makes more sense. The AES encryption is mostly for the wireless (prevent sniffing, spoofing and general cheater mayhem), but it is a great tool for ensuring that a signed binary remains trustable. As I have stated before, Sony's goal is to ensure that devs go through them (and pay their license fees), not to prevent us from understanding the system... but the fact that it slows homebrew down from even /knowing/ exactly how tough it is going to be is icing on the cake.

zMastaa · Post by **zMastaa** » Sat May 14, 2005 5:29 pm

hum.....

maybe u wud like this save file or maybe not

lol

i got my hands on wipeout a few months before it released obviously a W-I-P version but it did save an Online system info file and it shows in the "Save Data Utility" but now in the complete wipeout its unreadable!?!?

well.....

do u guys want it? it seems useless with me having it

zenjay · Post by **zenjay** » Sun May 15, 2005 12:38 am

Krevnik wrote: Signing in this case makes more sense. The AES encryption is mostly for the wireless (prevent sniffing, spoofing and general cheater mayhem), but it is a great tool for ensuring that a signed binary remains trustable. As I have stated before, Sony's goal is to ensure that devs go through them (and pay their license fees), not to prevent us from understanding the system... but the fact that it slows homebrew down from even /knowing/ exactly how tough it is going to be is icing on the cake.

OK make sense that signing is what they use... i'll have to read up on signing a bit and i'll see what i can glean from that stuff...

now... I agree that Sony wants to make it so they have to sign everything that runs on the PSP... one thing though, I think a UMD would have to go through them (at Sony) but a saved game file is another story. the saved game file HAS to be signed when you save the file on your PSP. right? i would think the saved file is originally unencrypted/signed then encrypted/signed when it saves it to the MemoryStick, that means that everything needed to SIGN a saved game file is on the PSP at the time you save the file, right?

i know it'll be hard to find all the pieces, not to mention you need a 1.0 firmware, but i believe (by the looks of the firmware directory) that the cert files and the "modules" I mentioned in a few posts above are good places to start. I only wish I could myself.. DAMN the 1.5 I gonna eat that damn cake AND it's icing!

;-)

zMastaa wrote:hum.....

maybe u wud like this save file or maybe not

lol

i got my hands on wipeout a few months before it released obviously a W-I-P version but it did save an Online system info file and it shows in the "Save Data Utility" but now in the complete wipeout its unreadable!?!?

well.....

no that file wouldn't really do us any good. unless you've compiled and encoded your own save game file on a 1.0. other saved game files are pretty useless at this stage. down the line IF we ever find these encrypt/decrypt functions we may need save files to analyse, but for now I could really use a BIOS dump from a 1.0 to ponder over ;-)

Fluff · Post by **Fluff** » Sun May 15, 2005 1:14 am

zenjay wrote:OK make sense that signing is what they use... i'll have to read up on signing a bit and i'll see what i can glean from that stuff...

Dont waste your time, i seriously doubt the "signing" used for savegames is anything like the signing done for executable formats, its more likely signed using a generic public key created from the game's ID, allowing it to be loaded by any psp running the same region game.
I do not for a second beleive sony would include the ability to sign executable code using the psp itself, not do i beleive it will be possible.

havocxrush · Post by **havocxrush** » Sun May 15, 2005 2:36 am

(URL DELETED)

The official dump of the 1.0 firmware is here grab it quick and get hackin

Post by **ooPo** » Sun May 15, 2005 2:43 am

You're allowed to discuss things like firmware dumps, but pointing to where you can download it... that's a no no.