Page 2 of 3

Re: memory management: FPL...

Posted: Sat Apr 07, 2012 10:29 pm
by wololo
My problem is that syscall estimation doesn't work all the time. I could confirm that my function is now available, but i need to know its syscall accurately. This is why i want to browse the stubs. Without them, this function call works only 30% of the time.

Re: memory management: FPL...

Posted: Sun Apr 08, 2012 3:25 am
by wololo
OK, I have something that's reasonably fast.
Fast enough actually, that I think going through the current "hardocded list of stubs" is a waste of time and potentially not as precise as this. For now I'll let that as a compile time option, but I'm strongly thinking of getting rid of the list of stubs in the config file.

I am now missing sceIoMkdir (necessary for VHBL to be able to install homebrew), any idea where I could get it from? I haven't looked yet, so if you don't have an idea on top of your head don't bother, I'll dig a bit.

Re: memory management: FPL...

Posted: Sun Apr 08, 2012 5:58 am
by wololo
sceIoMkdir was available from the p5_stubs technique, I just had to get rid of the calls to sceUtilityGetSystemParamInt.
I'm getting the menu to load now in a fairly difficult environment... still getting a crash when running most of my test homebrews, I'll have a deeper look.

The whole system of hooks/ etc... now makes it flexible, but also very hard to get the things correctly from the start... I need to spend more time on gen_exploit_config to get things to work now...

Re: memory management: FPL...

Posted: Sun Apr 08, 2012 8:07 am
by wololo
I submitted my work.
I realized I still don't have access to DeleteFPL sadly, because loading PSP_MODULE_NET_SSL yields an error (I didn't note the error number, I will if I work again on this).

At the very least, this could unblock some people who have been working with games that do not import enough functions.
defining LOAD_MODULES_FOR_SYSCALLS should help increasing access to the right functions. It does require access to sceUtilityLoadModule and sceUtilityUnloadModule, however.

I realized this afternoon that the game I have been working on is not available on the JP store nor the French store, which limits its attractiveness to me. Not that I won't finish the work, but I have much less motivation knowing that I'd have to create yet-another-account just to test the exploit. I don't think it is available in the US either, but I've seen it available on some other stores.

Re: memory management: FPL...

Posted: Sun Apr 08, 2012 8:17 am
by JJS
wololo wrote:I realized I still don't have access to DeleteFPL sadly, because loading PSP_MODULE_NET_SSL yields an error (I didn't note the error number, I will if I work again on this).
Just checked and it should be available through the PSP_UTILITY_SAVEDATA_AUTOLOAD dialog: http://moonlight.lan.st/5.00/vsh/module ... logimp.xml

So it should already be usable if p5 stubs are searched :?

Re: memory management: FPL...

Posted: Sun Apr 08, 2012 4:02 pm
by m0skit0
Do the syscalls loaded from P5 stubs stay available after unloading the modules?

EDIT: now that think, it's probably yes since the game syscalls are available even if the game module was unloaded...

Re: memory management: FPL...

Posted: Sun Apr 08, 2012 10:45 pm
by wololo
The answer is yes. This is why we load the modules, fetch the stubs, then unload the modules again. I think the reason is that when the module is unloaded, the system does not know what syscalls aee needed by other loaded modules.

Re: memory management: FPL...

Posted: Mon Apr 09, 2012 10:24 am
by m0skit0
wololo wrote:I think the reason is that when the module is unloaded, the system does not know what syscalls aee needed by other loaded modules.
Poor programming... Could be fixed anyway. You just need a counter for each syscall.

Re: memory management: FPL...

Posted: Mon Apr 09, 2012 11:09 am
by wololo
Yup. Of course that's just a guess. Maybe they simply forgot, or maybe it's for performance reasons, or whatever...

Re: memory management: FPL...

Posted: Mon Apr 09, 2012 11:13 am
by m0skit0
Or maybe it was not required by Sony's suits... you know how this stuff works in software companies... you only code what's required. Anyway, doesn't matter.