wololo.net/talk

It seems HBL Freezes on my PSP 1000 with 6.60, at the "freeing memory" step.
It's late and I haven't taken the time to investigate but I am assuming some of the nids changed (or some nids were added).

My memory on the subject is very fuzzy... I'll try to run a debug version later this week, but maybe it's time for us to give grandpa an update?

I tried with rev 113, which, as far as I know, was running fine on 6.39

Edit: renaming libs_63x into libs_66x to override libs_6xx didn't help, different type of crash at the same step...
more when I run a debug version.

Yup! It should freeze! I think sony has patched all the bugs and expoilts. Hopefully some1 will find an expoilt. Neur0n already told that he will port me to 6.60

Please dont post when you have no clue what you are talking about

I will also take a look at it once my PSP has finished loading the battery . If there are new NIDs we have to wait for a new Psardumper release that supports 6.60 I guess. The one for 6.39 cannot decrypt the modules from the update.

Edit: Looks like the procfw guys already got the key. Man, those are coding machines.
Edit2: Maybe not, at least it doesn't decrypt anything for me.
Edit3: Nevermind. I fail at mercurial.

Could somebody tell me why we need HBL on 6.60?

It hasn't patched signing.

I tried HBL out last night, here's my dbglog from r115 debug if it helps

ASKidwai wrote:Could somebody tell me why we need HBL on 6.60?

It hasn't patched signing.

Remember not all homebrew can be signed. A lot of those that are unsignable, such as snes9xtyl, and PSP Filer can still be launched through hbl.

What I can say up to now is that HBL crashes the PSP on calling sceKernelGetModuleIdByAddress(). Not sure why because that function works fine in a signed homebrew. If all fails we might just call sceKernelGetModuleId() in the launcher to get its id, store it somewhere in memory and then just unload that single module instead of searching through the whole user memory. It is not necessary anyway because the only module loaded is the launcher and we have full control over that.

There is also one new NID in SysmemUserForUser, see the attachment.


Edit: Ok, if sceKernelGetModuleIdByAddress() is added to the launcher imports all works fine. So this is some kind of syscall estimation problem. Very puzzling. If you guys want I can check in a version that starts on 6.60. Cannot really be bothered to test it all that much, but it seems to run Snes9xTYL and Basilisk just fine.

JJS wrote:So this is some kind of syscall estimation problem. Very puzzling.

Well, syscall estimation will obviously fail if there are new NIDs on the library. We would need to add those on the corresponding library .nids file to estimate the syscalls correctly.

I guess this should be moved to HBL Development forum to avoid useless comments.

EDIT: ok I see your attachment now JJS So even with that NID added syscall estimation still fails? Did you add it in order? Sorry I can't check this because I'm on my father's computer this days.

Of course I added the NID at the right place Doesn't matter though because sceKernelGetModuleIdByAddress() is from modmanforuser, which has not changed. The estimation worked perfectly on 6.39. I have a suspicion that there is a change in the syscall code so that only actually imported syscalls can be used. But I have to verify that with more tests before being certain.

Edit: I tried running PSPdisp now, for which the sceAudioSRC* functions have to be estimated. Guess what? It crashes on initializing the audio. The debug logs of both tries are attached, each time the NID was correctly estimated (you can calculate it by hand and compare). Still the PSP freezes on calling that function. If you recall, before a wrongly estimated NID would most of the time only lead to some malfunction and not an immediate crash. I bet this "crash" is a deliberate breakpoint.

Edit again: Here, have the modified version of R116 that starts on 6.60. Includes a patch and a debug build.