HBL On 6.60?

[m0skit0]

I was 99% sure you did Then the only possible answer is that syscall number generation has been modified (hence the big version jump). Can anyone import some functions into the launcher and compare the syscalls with the estimations made by HBL?

[JJS]

My first thought was that they finally made the syscall numbers random, but they are still generated the same way.

Consider this example from sceAudio of the second debug log I posted. The entries with [xx] are imports from the launcher. Obviously all syscall estimations done by HBL are still fitting right in.

Code: Select all

[59] 0xA708C6A6 0x0000238E 19
[60] 0xB7E1D8E7 0x00002390 21
[61] 0xCB2E439E 0x00002391 22
> estimated 0xE0727056 at index 23 to 0x00002392 = correct
[62] 0xE2D56B2D 0x00002393 24
[63] 0xE9D97901 0x00002395 26   < last entry in the library
--- Gap of 4 syscall numbers + not imported index 0
[48] 0x086E5895 0x0000239B 1
[49] 0x136CAF51 0x0000239C 2
[50] 0x13F592BC 0x0000239D 3
> estimated 0x38553111 at index 5 to 0x0000239F = correct (sceAudioSRCChReserve, freeze when calling this)
[51] 0x41EFADE7 0x000023A0 6
> estimated 0x5C37C0AE at index 8 to 0x000023A2 = correct
[52] 0x5EC81C55 0x000023A3 9
> estimated 0x647CEF33 at index 11 to 0x000023A5 = correct
[53] 0x6D4BEC68 0x000023A6 12
[54] 0x6FC46853 0x000023A7 13
[55] 0x7DE61688 0x000023A8 14
[56] 0x87B2E651 0x000023A9 15
[57] 0x8C1009B2 0x000023AA 16
[58] 0x95FD0C2D 0x000023AB 17


[varun]

i think sony changed somethings in their cfw so that hbl wont run.this must be because they must have feared that if we get hbl to run , we may get signed isos running

[m0skit0]

@varun: Sony has no CFW, and ISOs are always signed. Please abstain of discussing stuff you have no idea about and keep thread clean, thanks.

@JJS: so it only freezes when calling sceAudioSRCChReserve? Other estimated calls do not freeze? What about when sceAudioSRCChReserve is actually imported? We should modify HBL code so it estimates some of the imports that already exist, just to make sure.

[bingo88380]

I will try this hbl on my friends phat when i will reach home

[JJS]

so it only freezes when calling sceAudioSRCChReserve? Other estimated calls do not freeze?

SceAudioSRCChReserve is the first call to an estimated function. My guess is that it is the same for the other estimations. At least for sceAudioSRCChRelease it is because as a test I moved the call to that function early into the main() of PSPdisp and it freezes at that point.

What about when sceAudioSRCChReserve is actually imported?

I think it would work fine then like with sceKernelGetModuleIdByAddress. Once I added that to the launcher imports and it didn't have to be estimated by HBL it was possible to call that function without freezing. I am not keen on changing the launcher again to add more imports because doing that is a real bitch (you have to update the HBL SDK each time).

I will reiterate what I stated before: In my opinion the change in FW 6.60 is that only imported functions can be called with a syscall. All non-imported functions have a syscall assigned but calling it will cause a freeze. I don't think syscall estimation will be possible anymore.

But really that is no problem because we could just import every export of a library and then have HBL determine the lowest syscall and the gap from these information. FROM_LOWEST syscall estimation can then be used so that the NID array doesn't get too large. Not a big deal, it just has to be implemented. Getting all library exports is easy too because you only have to use prxtool to generate stubs for a decrypted firmware module and then build that into the launcher (same way I did the current imports but I deleted all that were not known by name).

[varun]

to keep thread clean-

@varun: Sony has no CFW, and ISOs are always signed. Please abstain of discussing stuff you have no idea about and keep thread clean, thanks.

- ''signed isos'' i meant fake np trick

[m0skit0]

In my opinion the change in FW 6.60 is that only imported functions can be called with a syscall. All non-imported functions have a syscall assigned but calling it will cause a freeze.

Maybe you're right, but that would mean quite a few re-design work and a bigger kernel so far. Also it's nonsense to assign non-imported function a syscall without being able to be called...

[wololo]

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.

Please feel free to submit it in the SVN.
I seem to recall building the latest versions requires a specific version of the MinPSPSDK?

[JJS]

Yes, the launcher has to be built with the same version of MinPSPW as I use. I got the latest one now.

I will submit something later after I have implemented the workaround I mentioned above.

Also it's nonsense to assign non-imported function a syscall without being able to be called...

I didn't design it . Also it was surely never intentional that functions could be called that were not imported by the game.