wololo.net/talk

SMOKE wrote:

PspJunkie wrote:

The Z wrote:PSP + PS1 savegames are in /PSP/SAVEDATA/, no where else.

So if /psp gets corrupted we cannot launch a recovery.pbp via launching the exploit with r trigger held?

If the files are corrupt, how is the Vita supposed to read them?

"Corrupted" means in this case, that /PSP/ got renamed into something else, which renders the Vita useless, if it wants to boot any bought PSN games from /PSP/GAME/.../EBOOT.PBP

Same applies to savegames, since they are stored in /PSP/SAVEDATA/, which is now not accessable, cause /PSP/ got renamed.

TL;DR:

If /PSP/ gets renamed, and you exit the exploit (or it crashes), you are kinda f#cked, cause you wont be able to remove said "useless" files, cause you can't delete EBOOT.PBP files from within the PSPemulator.

How to solve this?

Re-download (or restore from a backup) JUST the necessary exploit game and add its necessary exploit savedata files.

Boot into the exploit and start PSPFiler (via recovery menu as recovery.pbp). Then rename the current /PSP/ folder (which should JUST contain your exploit game + exploit savedata files) to /PSP2/ and rename the faulty renamed folder (i guess it was QSP?) back to /PSP/.

This will give you the ability to "restore" 'access' to said games/savedatas, without formating the memory card and without having to redownload them all.

It will still leave you will one undeleteable EBOOT.PBP inside of the /PSP2/ folder (the savedata files can be removed).

The Z wrote:It will still leave you will one undeleteable EBOOT.PBP inside of the /PSP2/ folder

I actually recommend to rename the folder to "temp", that one is sometimes deleted by Vita itself (not sure when, maybe at restart?)

tinostar91 wrote:2nd game which I have left at temp folder got deleted so now I have only 1 exploit game in my PSV

tinostar91 wrote:

The Z wrote:It will still leave you will one undeleteable EBOOT.PBP inside of the /PSP2/ folder

I actually recommend to rename the folder to "temp", that one is sometimes deleted by Vita itself (not sure when, maybe at restart?)

tinostar91 wrote:2nd game which I have left at temp folder got deleted so now I have only 1 exploit game in my PSV

I would like to confirm this. I will put some random junk into "temp" and will leave it there for a few days.
Let's see if it disappears.

the worst thing that could happen is having to buy the ninja release and updating to 3.01 to have an exploit compatible with tn-v

so there's still hope for those who got their data messed up

The Z wrote:

tinostar91 wrote:

The Z wrote:It will still leave you will one undeleteable EBOOT.PBP inside of the /PSP2/ folder

I actually recommend to rename the folder to "temp", that one is sometimes deleted by Vita itself (not sure when, maybe at restart?)

tinostar91 wrote:2nd game which I have left at temp folder got deleted so now I have only 1 exploit game in my PSV

I would like to confirm this. I will put some random junk into "temp" and will leave it there for a few days.
Let's see if it disappears.

Here's what I did (few minutes ago):
Corrupted PSP folder, restored the game and savedata so the new PSP folder will be created, fixed it again and placed 2nd game into the temp folder.
Restored the game 2nd time -> temp folder got cleaned up
So yes, it works. At least for me it worked twice.

grief3r wrote:the worst thing that could happen is having to buy the ninja release and updating to 3.01 to have an exploit compatible with tn-v

so there's still hope for those who got their data messed up

i take that back
- worst case scenario is now getting vhbl with 3.02+

tinostar91 wrote:So yes, it works. At least for me it worked twice.

Yep, i can confirm this. I used King of Pool to get to the Recovery Menu, then in the PSPFiler I renamed the QSP folder with the Megamix Eboot to temp. After that I deleted King of Pool, copied the game again to my Vita and the temp folder was empty.

grief3r wrote:

grief3r wrote:the worst thing that could happen is having to buy the ninja release and updating to 3.01 to have an exploit compatible with tn-v

so there's still hope for those who got their data messed up

i take that back
- worst case scenario is now getting vhbl with 3.02+

Actually it can be possible that some games are not "strong" enough for VHBL, but useable for kernel exploits.

In this case you would end up with a FW 3.02+ and a game that cant be used, except for future eCFWs or a simple hello world.

The Z wrote:

grief3r wrote:

grief3r wrote:the worst thing that could happen is having to buy the ninja release and updating to 3.01 to have an exploit compatible with tn-v

so there's still hope for those who got their data messed up

i take that back
- worst case scenario is now getting vhbl with 3.02+

Actually it can be possible that some games are not "strong" enough for VHBL, but useable for kernel exploits.

In this case you would end up with a FW 3.02+ and a game that cant be used, except for future eCFWs or a simple hello world.

I'd be interested to know what determines if a game would be viable for a kxploit but not VHBL. Is it simply based on the amount of memory that can be freed without crashing being less for a kxploit? Obviously this doesn't help me, since I'm not going to be finding a kxploit anytime soon (haha) and I don't know if the one exploit I looked at has been stealth patched in the past year, but I'd surely care if it would be useful to the dev of some far off future kxploit.

I'd be interested to know what determines if a game would be viable for a kxploit but not VHBL. Is it simply based on the amount of memory that can be freed without crashing being less for a kxploit? Obviously this doesn't help me, since I'm not going to be finding a kxploit anytime soon (haha) and I don't know if the one exploit I looked at has been stealth patched in the past year, but I'd surely care if it would be useful to the dev of some far off future kxploit.

You're asking the wrong person

It is not the game itself which determines whether there's a kernel exploit. My kernel exploit for example requires some modules. So a game, we release for TN-V, MUST import the function which can load other modules, i.e modules for net - my kernel exploit is somewhere in these net modules. The function that we need is in almost all games available, as the function to load mp3 in example, is the same function to load these net modules. However, in FW 3.00 Sony made a whitelist of games which CAN load net modules. If you try to load them in a game which is not in the whitelist, you'll end up returning to the livearea. And of course, if you want to load modules you must have enough RAM, that's why there's an algorithm in TN-V loader which clears the RAM, but this is not an important step for the kernel exploit.

TN