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
SAVEDATA Exploit Theory
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...
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...
I assume it would work in a similar fashon to the XBOX save game exploit. In which you load the modified save game in a specific game thus resolving the issue of encryption differing from game to game. From other posts I would probably look at RR or wipeout as both of those games aparently violate the TRCcyod wrote: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...
Except for the fact that we don't know how to encrypt for even one game, and I believe that several different game saves were analyzed on xbox before one with a exploitable bug was found.I assume it would work in a similar fashon to the XBOX save game exploit. In which you load the modified save game in a specific game thus resolving the issue of encryption differing from game to game.
Except they dont violate the TRC by making unencrypted saves so I doubt its relevant in this case......I would probably look at RR or wipeout as both of those games aparently violate the TRC
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
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
Re: SAVEDATA Exploit Theory
Done. See http://forums.ps2dev.org/viewtopic.php?p=16065steddy wrote: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