Kenel mode / User Mode switch
Kenel mode / User Mode switch
Is there a way if I start my thread in user mode that I can change to kernel mode and vice versa? On the ps2 it was quite easy: DI(); ee_kmode_enter(); EI(); etc..
Thx!
Thx!
So what you _actually_ want to do is get something in user mode to call a kernel function and not the other way around? That is what syscalls are for ;) In all serious you could export a function from your kernel module, find the syscall (that is up to you to work out :P) and replace the call to a syscall.
No I want to hook a pure user function call from my kernel module, without having to put the new function in user space. Or can I do something like replacing the user ordinary function call with a MAKE_SYSCALL ?? Will that work? I assume I will have to tamper with the surrounding code, set up registers etc, but I don't know MIPS.TyRaNiD wrote:So what you _actually_ want to do is get something in user mode to call a kernel function and not the other way around? That is what syscalls are for ;) In all serious you could export a function from your kernel module, find the syscall (that is up to you to work out :P) and replace the call to a syscall.
Regarding my original question, is it possible?TyRaNiD wrote:Stuff like sceDisplayWaitBlankStart are syscalls from what I recall, nothing more nothing less.
I need to hook a user mode function, from my kernel module (an ordinary function, not a syscall). Can I replace the function call with a syscall?? How would I need to change any surrounding code if necessary?
I read something about the setddrmemoryprotection function that allows you to jump into a kernel function from a user thread, but I don't think any one got it to work. So I assume turning it into a syscall will work.
Well you could unlock kernel memory and jump into it, the issue comes if your code (or any kernel functions you call) uses absolute addresses for any variables etc. as while you will have unlocked the lower 4 megs of ram you still won't be able to access it through Kseg0 (i.e. addresses at 0x8xxxxxxx). If you are just patching the jal instruction then if you went the syscall route all you would need to do would be swap the jal and its delay branch around and then set the syscall as the second instruction.
e.g. if you have:
You convert to:
e.g. if you have:
Code: Select all
jal someuserfunction
move $a0, $s0
Code: Select all
move $a0, $s0
syscall #num
I'll try converting it to a syscall. So I just have to make my module export a kernel-user function and when my module starts it will automatically make a syscall table entry for the function right.
How do I get the #num for my function? I understand that its not simply the address value in the syscall table....
How do I get the #num for my function? I understand that its not simply the address value in the syscall table....
?? But thats to find the NID. We want to find the syscall number for the function in the syscall table so that we can write a MIPS instruction "syscall num".J.F. wrote:The way some are found is to look at the old code when the NIDs were all computed from the name, then look for similar code in the new libs and see which random NID uses that code.
We already know the NID because we want to make a syscall to OUR OWN coded function in our kernel PRX. Apparently we need to find the syscall number that gets entered in the table when the PRX is loaded.
I'm a bit hazy on how the prx loader/syscall table and stuff works.
Even if we didn't know our own NIDs... we could just compute them via SHA-1 from the functionnames... (which is what I do... I beg you - don't ask... xD)
Any idea where this numtable is located in memory? If we can just dump it it shouldn't be difficult to interpret it...
We would just have to disable interrupts for a few secs, dump it and reenable interrupts then.
Any idea where this numtable is located in memory? If we can just dump it it shouldn't be difficult to interpret it...
We would just have to disable interrupts for a few secs, dump it and reenable interrupts then.
Been gone for some time. Now I'm back. Someone mind getting me up-2-date?
The apihook functions from psplink already clearly show how to iterate through the syscall table and find function addresses.
That is what is used for patching one syscall to another for syscall hooks. The thing is you just give the addresses of the function you want to hook and the apihook functions replace it with the address of your hook function. The syscall number of the original function remains the same, only the address it jumps to is changed.
You'll have to figure out yourself and how to find the syscall number for your hook function address. (Because when you load your kernel PRX, its syscall exports will be entered in the table with their own syscall numbers.)
That is what is used for patching one syscall to another for syscall hooks. The thing is you just give the addresses of the function you want to hook and the apihook functions replace it with the address of your hook function. The syscall number of the original function remains the same, only the address it jumps to is changed.
You'll have to figure out yourself and how to find the syscall number for your hook function address. (Because when you load your kernel PRX, its syscall exports will be entered in the table with their own syscall numbers.)