Kernel access with 2.6 (hitchhikr and Ookm codes)

[tnt]

I'm trying to understand what is currently possible in 2.6 and how.
When searching for kernel mode access in 2.6, I found mainly :

- The proof of concept 2.6 ( Exploit_2.6.zip ) written by hitchhikr / Neural.
- The code posted by Ookm ( 25_26_VSH_KA.zip ) named "Kernel access under FW2.50/2.60 VSH"
- eloader 0.99 with "partial kernel support"

My questions / interrogations are :

* I've never been able to execute successfully the hitchhikr code. Either with eloader 0.98 and 0.99 (both tiff version), it just freeze the PSP. It is said it should be run using GTA eloader but what's the difference ? What
should be done to make it compatible with the tiff exploit ?

* The Ookm code : It runs fine with eloader 0.98 but not with 0.99. I would guess the "partial kernel support" of eloader 0.99 actually use the same exploit and so both can't be used at the same time. But then why isn't eloader 0.99 providing full kernel mode ? The Ookm code seems to launch any kernel thread or am I missing something ?

Secondly about the Ookm code, the comment says :
Game mode Kernel access by hitchhikr / Neural.
VSH mode Kernel access by moonlight
I guess what he means by that is that first VSH access is obtained using the tiff exploit, then from there using the hithickr exploit, kernel mode is accessed. But then why can't I run the hithickr exploit from the tiff eloader 0.98 ?

Finally, does the Ookm code do more than the hithickr exploit ?


My hw : A recent PSP but not ta-082 with firmware 2.60. I have eloader 0.98 and 0.99 installed, both using the tiff exploit.

PS: About the tiff exploit, eloader works fine with it, but both tiffsdk example (1.0 and 1.1 tetris) just don't load, they simple freeze the psp ... any idea ?

[0okm0000]

* I've never been able to execute successfully the hitchhikr code. Either with eloader 0.98 and 0.99 (both tiff version), it just freeze the PSP. It is said it should be run using GTA eloader but what's the difference ? What
should be done to make it compatible with the tiff exploit ?

because eloader(TIFF) run in VSH mode, so can't use "sceKernelLoadExec"
in eloader(TIFF) need to use "vshKernelLoadExecVSH"

* The Ookm code : It runs fine with eloader 0.98 but not with 0.99. I would guess the "partial kernel support" of eloader 0.99 actually use the same exploit and so both can't be used at the same time. But then why isn't eloader 0.99 providing full kernel mode ? The Ookm code seems to launch any kernel thread or am I missing something ?

because eloader0.99 Unloaded "vshbridge", so can't use "vshKernelLoadExecVSH"

[tnt]

Hi 0okm0000,
thanks for the answer.

* I've never been able to execute successfully the hitchhikr code. Either with eloader 0.98 and 0.99 (both tiff version), it just freeze the PSP. It is said it should be run using GTA eloader but what's the difference ? What
should be done to make it compatible with the tiff exploit ?

because eloader(TIFF) run in VSH mode, so can't use "sceKernelLoadExec"
in eloader(TIFF) need to use "vshKernelLoadExecVSH"

yes, using vshKernelLoadExecVSHs1 works great ! Thanks.

* The Ookm code : It runs fine with eloader 0.98 but not with 0.99. I would guess the "partial kernel support" of eloader 0.99 actually use the same exploit and so both can't be used at the same time. But then why isn't eloader 0.99 providing full kernel mode ? The Ookm code seems to launch any kernel thread or am I missing something ?

because eloader0.99 Unloaded "vshbridge", so can't use "vshKernelLoadExecVSH"

Any idea why it does that ?
Since it doesn't support yet full kernel support, using the exploit inside the homebrew eboot looks like the only solution for now. (I mean to have a custom eboot doing kernel stuff)

[tnt]

Another question is about the magic addresses in those code :

* Like why 0x09f02020 is a "safe place"
* And what are the 0x880bdcc4 and 0x880be2ac functions
(or where to find this infos)

Thanks for any insight you may have ...

[hitchhikr]

The 0x09f02020 address will be part of the overflow string so each byte of that address needs not to be zero (and doesn't contain 0x3a as this char is needed to control the length of that string).

[Fanjita]

Any idea why it does that ?
Since it doesn't support yet full kernel support, using the exploit inside the homebrew eboot looks like the only solution for now. (I mean to have a custom eboot doing kernel stuff)

To use the limited kernel support in eLoader, you need to flag your module with kernel mode attributes, and make a function with the attribute '__constructor__', e.g.

Code: Select all

void __constructor__ MyKernelProc()
{
  // Here I am in kernel mode
}

Note that MyKernelProc will be called as the first thing that your program does, and that it is unable to create kernel threads (due to permissions checks in sceKernelCreateThread). However, you could do any kernel mode initialisation that you wanted, including patching of functions in kernel memory, for example to allow creation of kernel threads.

We unload VshBridge simply because it takes up a lot of user memory, and most users of eLoader are more concerned with running high-occupancy usermode games, than working with smaller kernel mode apps.

[tnt]

The 0x09f02020 address will be part of the overflow string so each byte of that address needs not to be zero (and doesn't contain 0x3a as this char is needed to control the length of that string).

Ok, thanks. Damn it was so simple ...
I thought there was just something special in memory at that location, silly me ...

Any idea why it does that ?
Since it doesn't support yet full kernel support, using the exploit inside the homebrew eboot looks like the only solution for now. (I mean to have a custom eboot doing kernel stuff)

We unload VshBridge simply because it takes up a lot of user memory, and most users of eLoader are more concerned with running high-occupancy usermode games, than working with smaller kernel mode apps.

Ok, good reason ;)


Thanks for the input to all of you.