Advertising (This ad goes away for registered users. You can Login or Register)

[Eloader] 1. Introduction

Forum rules
Forum rule Nº 15 is strictly enforced in this subforum.
Post Reply
User avatar
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

[Eloader] 1. Introduction

Post by m0skit0 » Mon Sep 27, 2010 2:30 pm

Originally posted by m0skit0 on
Retrieved by Ultimakillz,,80.0.html

Well, as I wished to do something with the recent MoHH exploit, a friend came with a nice suggestion: making an eloader. And I said myself "why not, let's give it a try". After a couple of weeks of research and coding, I can tell I'm able to load some non-signed ELFs on OFW using this exploit. How is this acheived? Well, you have to get some basic knowledge about how the whole thing works. Let's start with it.

First of all, we have to keep in mind that the exploit allows us to run our code, but we're still limited to user mode. This is not a kernel exploit, so we're stuck in user mode. This means we cannot access kernel memory whatsoever, so patching syscalls/functions is out of the order of the day.

Second, we're still under OFW. This means we cannot load unsigned code using sceKernelLoadExec() or sceKernelLoadModule(), unless we replace them with our own module/executable loading function. Any attempt to use such functions on homebrew modules will just crash the console.

Third, the exploit SDK only allows us to use a little subset of the whole PSP functions. Basically, you can use any function imported by the game, in this case MoHH, but only those. But not all of them are linked by the exploit SDK linker. You have to patch the SDK if you want to use those imported but not included.

Well, quite a few restrictions, right? We'll have to make workarounds for this. Let's see how.

We cannot access kernel mode, no way to workaround this except finding a kernel exploit. That said, any homebrew that require kernel mode priviliges to run would not run on our eloader.

We cannot load unsigned code using OFW kernel functions. Then we'll have to code the module loader function manually. That is, basically rewriting sceKernelLoadExec()/sceKernelLoadModule() without sign check. We'll talk about this in more detail later.

We're limited to the functions subset the exploit SDK allows us to use. We can find more MoHH imports and patch the SDK linker to be able to use more. We can also call some functions directly if we know their address or syscall (well, syscalls are not that easy as we will see), just like the TIFF and ChickHEN exploits did.

Well, basically we have to write a replacement for sceKernelLoadExec()/sceKernelLoadModule() functions taking into account those restrictions. I'll go into it in next.

Any comments appreciated, as always.
I wanna lots of mov al,0xb
"just not into this RA stuffz"

Posts: 111
Joined: Mon Sep 27, 2010 4:35 pm

1. Introducción

Post by tbg » Mon Sep 27, 2010 4:42 pm

Texto extraído de m0skit0 en
Obtenido por Ultimakillz,,80.0.html

Como deseaba hacer algo con el reciente exploit del MoHH, un amigo vino con una propuesta interesante: hacer un eloader. Y yo me dije "Por qué no, vamos a intentarlo". Después de algunas semanas de investigación y programación conseguí cargar algunos ELFs sin firmar en OFW usando este exploit. ¿Cómo se consigue? Se necesitan unos conceptos básicos sobre como funciona todo el tema. Vamos a empezar.

Lo primero, tenemos que tener en mente que el exploit nos permite ejecutar nuestro código, pero estamos limitados al modo usuario. Este no es un exploit del kernel, por lo que estamos encerrados en el modo usuario. Esto quiere decir que no podemos acceder a la memoria del kernel con lo que parchear syscalls/funciones esta fuera de la orden del día.

Lo segundo, seguimos estando en un OFW. Esto significa que no podemos cargar codigo sin firmar usando sceKernelLoadExec() o sceKernelLoadModule(), a menos que reemplacemos estas funciones con nuestras propias funciones de carga de módulos/ejecutables. Cualquier intento de usar estas funciones en módulos homebrew probocará un "crasheo" de la consola.

Lo tercero, el SDK del exploit solo nos permite usar una pequeña parte de todas las funciones de la PSP. Basicamente, podemos usar cualquier función importada por el juego, en este caso MoHH, pero solo esas. Pero no todas ellas estan enlazadas por el linker del SDK del exploit. Tienes que parchear el SDK si quieres usar las funciones importadas por el juego que no están incluidas.

¿Muchas restricciones verdad? Vamos a tener que solucionarlo. Veamos cómo.

No podemos acceder al modo kernel, la única solución a esto es buscando un exploit de kernel. Dicho esto, cualquier hombrew que necesite los privilegios del modo kernel para ejecutarse no funcionaría en nuestro eloader.

No podemos cargar código sin firmar usando funciones del kernel del OFW. Entonces tendremos que programar la función para cargar módulos manualmente. Esto significa básicamente reescribir sceKernelLoadExec()/sceKernelLoadModule() sin la verificación de firma. Hablaremos sobre esto en más detalle posteriormente.

Estamos limitados al conjunto de funciones que el SDK del exploit nos permite usar. Podemos buscar mas importaciones en MoHH y parchear el linker del SDK para poder usar más. También podemos llamar algunas funciones directamente si conocemos su dirección o syscall (las syscalls no son tan sencillas, ya lo veremos), como hacian los exploit TIFF y ChickHEN.

Básicamente tenemos que escribir un reemplazo para las funcions sceKernelLoadExec()/sceKernelLoadModule() teniendo en cuenta las restricciones. Lo veremos después.

Los comentarios son apreciados, como siempre.
Last edited by tbg on Wed Sep 29, 2010 11:35 pm, edited 2 times in total.
TBG : Team Extraction member

Posts: 1
Joined: Tue Oct 19, 2010 3:15 am

Re: [Eloader] 1. Introduction

Post by Flood » Tue Oct 19, 2010 3:31 am

I read the post in english with some troubles and I didn't pay attention to the translation ¬¬

Post Reply

Return to “Programming and Security”