Originally written by TheFlow, deleted for some reason. archive org had a copy (
https://web.archive.org/web/20180706194624/https://gist.github.com/TheOfficialFloW/81466e70d7ea57facb5897568dd28f12) and here is the text with a new link to the CrashDump Enabler for preservation purposes:
--------How to find savedata exploitsSince the release of h-encore you might be wondering how such an user entry point is even possible.
It is possible because games that were developed with an SDK around 3.00 and lower were compiled as a statically linked executable, thus its loading address is always the same and it cannot be relocated to an other region, which means that if we have an exploit in such a game, we can happily do ROP and don't need to deal with ASLR.
They also don't have stack protection enabled by default, so stack smashing is the easiest way to trigger user ROP execution.
Savedata exploits are more powerful than WebKit exploits in terms of available syscalls.
The reason for that is after firmware 3.30 or so, Sony introduced sceKernelInhibitLoadingModule in their browser, which prevented us from loading additional modules.
This limitation is crucial, since this was the only to get syscalls, as they are randomized at boot.
Note that the following guide is written for people with few knowledge about exploitation.
How do we know that a game is a statically linked executable? They have got the value 0xFE00 for the e_type field in their ELF header. This is how you can see what type the executable has:
Choose any game you want to attempt exploiting.
Open the game in VitaShell using Open decrypted.
Click on the file eboot.bin, press triangle and select Open hex editor.
See what value is at offset 0xB0:
If it is 00 FE, it is statically linked, hence it may be exploitable.
If it is 04 FE, it is dynamically linked, hence is not exploitable due to ASLR.
If it is indeed a statically linked executable, you can now begin with fuzzing the savedata:
Download any hex editor.
Download and install CrashDump Enabler. (
https://github.com/CelesteBlue-dev/CrashDumpEnabler)
Start your game and play it a little bit until you are sure that it has created a savedata.
Either use vita-savemgr or VitaShell to export the savedata. If you use VitaShell, simply navigate to ux0:user/00/savedata and use Open decrypted on your game, then copy the savedata file out of the folder.
Connect your PS Vita to your computer and begin writing crap into the savedata file using your hex editor. Simply write alot of a's at some points.
Copy the savedata back (again with Open decrypted if using VitaShell) and play the game.
Repeat this procedure until you get a crash. If the game complains that the savedata is invalid or so, then it is because there's a crc/hash check. In that case, you should give up, unless you know how to reverse engineer.
In case you get a crash, the crashdump will be written to ux0:data. You can open these dumps using VitaShell and then see whether there are any 0x61 or other repetitive values in the registers (assuming you've only written a's into your savedata):
If the register pc contains the value 0x61616161 or something similar, then congratulations, you've found a new user entry point!
If BadVaddr is 0x61616161 or something similar, then it may also be exploitable (depends on whether it was a load or a store that crashed).
If it doesn't contain anything special, then continue with fuzzing.
Be careful that in case you find something useful, you should NOT show a screenshot of the crashdump that contains any titleid/strings of the game (otherwise Sony might see and patch it).
--------EDIT: Silica says title IDs are given in order by reserve order so when going by title ID order, if executables start to be consistently dynamic (though not instantly, since SDKs may not get updated nearing completion/throughout development.), the rest should be dynamic as well unless a title had extremely long development with no SDK updates or something.
