Planeta-Consolas.com
29Mar/100

Half Byte Loader Beta 1.0 (SVN abierto)

Hay gente gilipollas por el mundo.

Yendo al tema, los actuales desarrolladores del Half Byte Loader (un cargador de homebrew a partir de exploits de juegos para PSP) hemos decidido poner todo el proyecto en un SVN público, sin restricciones de código como pasaba en las anteriores publicaciones.

Para más información: http://advancedpsp.tk/foro_es/viewtopic.php?f=21&t=190

¡Saludos a todos!
12Mar/100

Half Byte Loader Alpha 1.1

Hace poco he publicado una mejora sustancial del eloader. La mejora más interesante en esta versión es que he relocalizado el código en el scratchpad, evitando que la carga de ELF sobreescriba el código de HBL.

Estoy trabajando con un par de desarrolladores más en un proyecto que involucra el HBL y un exploit, aunque no puedo dar más detalles. Sólo esperemos que dé los frutos que esperamos y posiblemente los usuarios de placas malditas con firmware superior a 5.03 puedan disfrutar de algún software casero ;)

Os dejo el enlace a esta nueva versión (la última publicada por ahora): http://advancedpsp.tk/foro_es/viewtopic.php?f=21&t=190

Cualquier cosa, ya sabéis que podéis comentar o bien por aquí o bien en el foro.

Hasta pronto con más interesantes noticias, espero
28Ago/09Desactivado

Eloader para PSP

Uf, cuánto tiempo sin escribir por aquí... Y es que escribir un eloader para PSP no es algo sencillo, aunque tampoco es imposible ;). ¿Qué es un eloader? Bueno, una pequeña introducción:

El sistema de seguridad de la PSP se basa en varios niveles. El nivel que nos interesa es a la hora de ejecutar programas. Sony decidió utilizar el formato ejecutable ELF, aunque los ELFs ejecutables van embebidos con otros ficheros de información en lo que se denomina EBOOT.PBP. Existen ELFs sueltos, llamados PRX (PSP Relocatable eXecutable), pero son usados generalmente como librerías. En todo caso, para cargar y arrancar un ejecutable, se debe pasar forzosamente por la función sceKernelLoadExec(), exportada por el kernel de la PSP. Y ésta función comprueba que el ejecutable en cuestión esté firmado por Sony, es decir, una marca de copyright. Dado que es ilegal firmar código sin ser Sony (aparte de extremadamente díficil de conseguir), en teoría no hay manera de cargar software no firmado por Sony, el llamado software casero en la escena.

Pero en la práctica existen varias formas de arrancar caseros en la PSP. Los dos métodos HEN (Homebrew ENabler, activador de software casero) más usados son el firmware modificado (CFW) y el eloader. Ambos se basan en exploits, que son aprovechamientos de vulnerabilidades en el software que corre en la PSP.

El primero es un hack sobre el firmware oficial de Sony que elimina la comprobación de validez de la firma y el descifrado, dejando vía libre para la ejecución de cualquier software casero. Esto requiere o bien un exploit del proceso de arranque (llamado exploit Pre-IPL, con lo que el firmware modificado arranca directamente usando un cargador (IPL) hackeado) o bien un exploit de alguna función del kernel (con lo que el firmware modificado arranca usando el exploit). En todo caso, hay que tener acceso a las direcciones de memoria donde corre el kernel (direcciones a partir de 0x80000000), algo normalmente prohibido para las aplicaciones, que corren en modo usuario (direcciones por debajo de 0x80000000).

El segundo, el eloader, es el método usado cuando no es posible hackear el proceso de arranque ni existe ningún exploit en modo kernel que permita modificar el firmware oficial. Esto generalmente se da en las llamadas placas malditas (con un arranque modificado que soluciona el antiguo exploit Pre-IPL). En éstas sólo nos quedan los exploits modo usuario. Desgracidamente, en éstos no se puede usar la llamada al sistema sceKernelLoadExec() para arrancar ejecutables, puesto que ésta llamada comprueba la firma de Sony y por tanto daría error al ser software casero lo que queremos ejecutar. Por tanto, hay que crear un programa que implemente de nuevo sceKernelLoadExec y así poder cargar los ELFs en espacio de usuario, lo que se llama eloader. Esto evidentemente deja fuera del alcance del eloader cualquier memoria del kernel, lo que viene a redundar en que no se pueden cargar módulos (ejecutable o librería) que requiera de modo kernel para trabajar, ya que el eloader no podría cargar el módulo en la zona superior de memoria que necesita el módulo para funcionar correctamente.

Habiendo aclarado el concepto de eloader, vuelvo a lo que quería comentar: actualmente estoy trabajando con n00b81 y ab5000 en un eloader para el reciente exploit del Medal of Honor Heroes descubierto por kgsws, y el proyecto va bastante avanzado. Es probable que al final de esta semana o la semana que viene ya se pueda publicar una beta.

Hasta entonces, nos vemos y que tengáis buenas vacaciones y disfrutad del verano (para el hemisferio norte, claro ;)).