2.60 syscalls

[jas0nuk]

Is there a list of 2.60 syscalls available?

Thanks in advance, although I doubt that this firmware is well-documented...

[groepaz]

i dont think so...why would you want one anyway? :)

[jas0nuk]

I'm trying to add some stuff to DevHook's VSHExtender which runs in emulated 2.60 (no, not ISO-related stuff :))

Thanks anyway.

[moonlight]

The code i gave you the other day should work.
NIDS don't change between firmware revisions.

The only reasons why it shouldn't work is the function being removed, or the library containing the function being changed of module.

[jas0nuk]

That code causes a crash. It could be that scePower_service/scePower_driver no longer applies, or the function has been entirely removed, as you said.

I will try to use asm("syscall 0x2198"); instead as this is the same function.

(btw, for anyone who doesn't know what I'm on about, I'm talking about using scePower_0442D852)

[moonlight]

I have checked it. The function still exists and in the same place.

[jas0nuk]

Okay, well it's definitely crashing. I'll try some more stuff :)

[jas0nuk]

Tried the following:

static void reboot(int blah)
{
__asm__ volatile("syscall 0x2198");
}

When I called reboot(0); the PSP crashed.



static void reboot(int blah)
{
asm("syscall 0x2198");
}

When I called reboot(0); it ignored it.

[bradskins]

Could you forward the same info my way?

bradskins (underscore) 28@hotmail.....

thanks!

[Fanjita]

You can't use fixed syscall IDs on 2.5 or 2.6.

See the older thread about coding for the GTA exploit, but basically there's a random offset applied to the syscall ID (not entirely sure when it changes, probably at each reboot).

You need to find some way of calibrating the syscall IDs. The typical way is to find the link table in some preloaded module elsewhere in RAM, and to determine the ID of a known NID from there.

BTW there's a simple syscall list in that thread, with all the syscalls that are used by GTA.

[jas0nuk]

Thanks for the list. BTW, this code is to be used within a PRX which is loaded by DevHook on top of the 2.60/2.71 VSH, so we're in kernel mode and not restrained by the GTA eLoader environment :)

After looking at the list I realised that the syscall for the scePower_0442D852 function is 0x2197 and not 0x2198.. I must have been looking at the wrong row :/

Anyway, I changed my code to

Code: Select all

__asm__ volatile("syscall 0x2197");

yet it still crashes.

However, scePower_0442D852 needs to be called as "scePower_0442D852(0);" but I'm not sure how to do this using inline asm.

Hope someone can help me with this :s

[Fanjita]

If you're in kernel mode then you can use a kernel mode function (sorry, I forget the name, I've never used it personally) to retrieve the syscall ID for a given NID.

On 2.5+, the syscalls are not constant - so as I said before, you can't rely on using a fixed syscall number every time.

[PspPet]

sceKernelQuerySystemCall and related sceKernelRegisterSystemCallTable

IIRC 'sceKernelQuerySystemCall' takes a pointer to the real function in (kernel) memory
Anyway not very useful in most cases for the reasons stated.

[Fanjita]

sceKernelQuerySystemCall and related sceKernelRegisterSystemCallTable

IIRC 'sceKernelQuerySystemCall' takes a pointer to the real function in (kernel) memory
Anyway not very useful in most cases for the reasons stated.

Hmm, that's unfortunate, I was hoping to look into using that function at some point in the near future.

Still, I guess it's possible to RE the table in kmem and retrieve the syscall from there. Or perhaps to use QueryModuleInfo to look through the export info of the module concerned.