forums.ps2dev.org

steddy · Joined: 04 Apr 2005 Posts: 139

I have four games for my PSP and multiple save games files present on my memory stick.

An obvious exploit used in both XBOX and GC hacks is to modify save game files so as to cause a buffer overflow exploit. Looking at the contents of the save files in WinHex, I would guess they are encrypted since they seem uniformly junk and contain no text in any of them.

Now, heres the theory part:-
1. Unlike EBOOT.BIN, save game files must be encrypted on the device.
2. From one leads the fact the key and therefor the function to encrypt save files is present on the device.
3. This will be the same no matter what BIOS version you have, otherwise you would no longer be able to load your save files after an upgrade.
4. A 1.0 firmware PSP can run unsigned code
5. The ISO images of existing Apps must call a function to encrypt the Save files
6. Comments have been made on the forums that Wipeout contains the symbolic link information
7. The function used to encrypt save files could be compiled into a simple App and executed on a 1.0 PSP to create the encrypted file
8. The encrypted file would decode correctly on a 1.5 firmware PSP
9. This would provide a exploit entry point on 1.5 firmware PSP by encrypting on 1.0 PSP

Does this all sound feasible?

Steddy

zigzag · Joined: 26 Jan 2005 Posts: 129

Sounds good but, what if the encryption used for game saves is not the same used for executables...?

steddy · Joined: 04 Apr 2005 Posts: 139

That doesn't matter at all. The idea is to create a corrupt save game file which creates a buffer overflow exploit, then encrypt it so a 1.5 PSP will load it anyway and overflow.

Steddy

CMoZ · Joined: 10 May 2005 Posts: 3

cyod · Joined: 29 Apr 2005 Posts: 36

This would be more effective if you could decrypt existing save files using the api, otherwise you will have to create a save file from scratch which would be harder to create a buffer overflow for assuming there is any checks for valid data...

This is all assuming that the encryption is not different from game to game, IE each game having a key in software that it uses when calling an API read/write function. If this is the case this plan wouldnt work too well as you would need to find the key for a specific game somehow, and find an exploit in that game...

CMoZ · Joined: 10 May 2005 Posts: 3

cyod · Joined: 29 Apr 2005 Posts: 36

lantus · Joined: 10 May 2005 Posts: 10

10. what if the key/encryption is on a per game level?
11. goto 1
_________________
xSnes9x - Snes9x Emulation for Xbox Consoles

steddy · Joined: 04 Apr 2005 Posts: 139

It doesn't matter if the encryption of the savegame file is on a per game basis. It would still allow us to run an exploit on one game to run our own code.

Its very likely that the encryption is provided by a library function. If this is found we can determine if a key is passed into it. If it does, then perhaps this is what the UMD_DATA.BIN file is for in the root.

Even though it would be handy, knowing the unencrypted form of the file is not required. We know the size of the file, just extending it with a bunch of NOPs then a jump to see if it executes may be enough. You would be surprised how little a hacker needs to know about a system to create this sort of exploit.

Besides, if there is an API to encrypt the file there will also be one to decrypt it. The BSAFE API provides encrypted Save and Load functions. I don't have the API here but I will look it up tonight and post the names.

Steddy

Shine · Joined: 03 Dec 2004 Posts: 728 Location: Germany

steddy · Joined: 04 Apr 2005 Posts: 139

Nice

I never thought I would see this one re-animated :)

Steddy