A raiz de la publicacion en el dia de ayer del codigo fuente que indicaba la SYSCALL utilizada para el sistema de montajes, ya no es necesario por seguridad, mantener esta informacion de forma privada, ya que realmente la informacion si no habia sido publicada por mi, pese a que se diga lo contrario por muchos usuarios, era para evitar un mal uso y atacar la flash, de todos modos como ya comente en el post anterior teniamos en mente liberarlo cuando estuviera pulida alguna cosa nueva, todo el mundo es libre de creernos o no, pero asi es.
Para mas informacion, un post mio antiguo: http://ps3mrenigma.wordpress.com/2010/11/10/a-quick-note-a…reversing-post/
Como ya no es el caso, paso a redactar que son los montajes, como funcionan, cuales existen y como se montan y desmontan explicando a su vez las SYSCALL usadas en el proceso.
Ante todo entender que este post es un post tecnico, con lo que a muchos usuarios no os servira de nada mas que para vuestro conocimiento personal, cosa que creo que vale mucho mas que cualquier otro programa que exista o que se pueda hacer a raiz de ello.
[NOTA: Este post es inicial, se puede ir AMPLIANDO gradualmente al igual que arreglando informacion en el caso de que algo no sea del todo exacto. Es REPITO, un post inicial para explicar este tema. Por supuesto cualquiera que quiera colaborar es bienvenido a dejar sus comentarios.]
————————————————————————-
MONTAJES:
La PS3 utliza un sistema de montajes muy parecido a lo que podria ser montar una unidad en un entorno Linux.
CELL_EXTNOR_AREA: 
Lo primero que se indica es el tipo de unidad que vamos a montar, donde se especifica un string de los siguientes:
- CELL_FS_DUMMY: Este tipo de unidad es utilizado en las maquinas Retail para montar una unidad DUMMY (es decir, existe pero no hace nada) en la unidad “/app_home”. Este tipo tambien es utilizado en las maquinas Debug o RefTool en el caso de que arranquemos en el modo Release.
- CELL_FS_HOSTFS: Este tipo de unidad es usado para el montaje de la unidad “/host_root” y “/app_home”.
- CELL_FS_IOS:BDVD_DRIVE: Este tipo de unidad tal y como su nombre indica esta relacionado con la unidad “/dev_bdvd” de una forma generica.
- CELL_FS_IOS:PATA0_HDD_DRIVE: Indica el tipo de unidad para montar la unidad “/dev_hdd0″, este tipo es utilizado en los modelos por ejemplo Phat de 60 Gigas.
- CELL_FS_IOS:PATA0_BDVD_DRIVE: Tipo de unidad que ayuda a montar la unidad “/dev_bdvd”, este tipo es utilizado en los modelos por ejemplo Phat de 60 gigas.
- CELL_FS_IOS:PATA1_HDD_DRIVE: Indica el tipo de unidad para montar la unidad “/dev_hdd0″, este tipo es utilizado en los modelos por ejemplo Phat de 60 Gigas.
- CELL_FS_IOS:PATA1_BDVD_DRIVE: Tipo de unidad que ayuda a montar la unidad “/dev_bdvd”, este tipo es utilizado en los modelos por ejemplo Phat de 60 gigas.
- CELL_FS_IOS:BUILTIN_FLASH: Tipo de unidad que especifica el montado de una unidad flash generica, por ejemplo “/dev_flash”.
- CELL_FS_IOS:COMPACT_FLASH: Unidad de tipo Compact Flash para ayudar al montaje de la unidad “/dev_cf”. Logicamente solo para los modelos que lo soporten internamente.
- CELL_FS_IOS:MEMORY_STICK: Al igual que el anterior ayuda en el montaje de la unidad “/dev_ms”. Al igual que ocurre con la anterior solo si internamente se tiene soporte.
- CELL_FS_IOS:SD_CARD: Unidad de tipo SD_CARD para ayudar al montaje de la uniadd “/dev_sd”. Requiere tener soporte interno.
- CELL_FS_IOS:USB_MASS_STORAGExxx: Tipo de unidad que ayudara a montar las unidades “/dev_usbxxx”. xxx puede ser cualquier valor numerico comenzando desde el 000 para la unidad “/dev_usb000″, etc.
- CELL_FS_IOS:USB_MASS_STORAGE: Lo mismo que la anterior pero para montar una unidad generica “/dev_usb”.
- CELL_FS_IOS:BUILTIN_FLSH1: Tipo de unidad indicado para montar la unidad “/dev_flash” exclusivamente.
- CELL_FS_IOS:BUILTIN_FLSH2: Tipo de unidad indicado para montar la unidad “/dev_flash2″ exclusivamente.
- CELL_FS_IOS:BUILTIN_FLSH3: Tipo de unidad indicado para montar la unidad “/dev_flash3″ exclusivamente.
- CELL_FS_IOS:BUILTIN_FLSH4: Tipo de unidad indicado para montar la unidad “/dev_flash4″ exclusivamente.
- CELL_FS_UTILITY:HDD0: Disco duro HDD0
- CELL_FS_UTILITY:HDD1: Disco duro HDD1
- CELL_FS_UTILITY:HDD2: – Sin informacion -
- CELL_FS_UTILITY:HDD: Disco duro
- CELL_FS_PSEUDO: – Sin informacion -
- CELL_FS_ADMINFS: Para ser usado en el montaje de la unidad “/app_home”.
Lo segundo a indicar es el tipo de sistema de archivos que usaremos en esa unidad, indicado por un string de los siguientes:
- CELL_FS_DUMMYFS: Precisamente un sistema de archivos DUMMY, a ser indicado con el IOS DUMMY visto anteriormente.
- CELL_FS_ADMINFS: Para ser usado con el IOS con el mismo nombre.
- CELL_FS_FAT: Para montar una unidad con el sistema de archivos FAT32.
- CELL_FS_SIMPLEFS: Usado a veces por los discos duros y la flash2. Se utiliza principalmente para chequear si tiene formato la unidad, en este modo se permite el formateo de la unidad.
- CELL_FS_UFS: Para montar las unidades de disco duro, como veremos posteriormente.
- CELL_FS_UDF: Para montar la unidad de disco “/dev_bdvd”.
- CELL_FS_ISO9660: Sirve para montar unidad de disco.
- CELL_FS_EFAT: – Sin informacion -
- CELL_FS_PFAT: – Sin informacion -
Lo tercero a especificar es el nombre de la unidad en un string, este nombre de unidad tiene que ser un nombre de unidad reconocido por el sistema para la unidad que queremos montar.
Puede ser uno de los siguientes:
- /app_home : Unidad para tener un sistema de archivos en un equipo remoto, como un PC. Tambien sirve para entornos de depuracion.
- /host_root: En conjuncion con lo anteriormente citado.
- /dev_bdvd: La unidad de disco BDVD.
- /dev_flash: La unidad flash principal, en donde la mayor parte del firmware esta alojado.
- /dev_flash2: Unidad flash donde se almacena el registro con la configuracion del sistema, por ejemplo.
- /dev_flash3: Tercera unidad flash, con archivos de sistema. Es recomendable hacer backup de ella tambien.
- /dev_flash4: Desconocido, aparece indica en el IOS, pero todavia desconozco si su existencia es real o cual podria ser su verdadero uso o nombre.
- /dev_hdd0: La unidad principal del disco duro interno de la consola, donde por ejemplo estarian las demos, etc.
- /dev_hdd1: Segunda unidad del disco principal, usada principalmente como cache.
- /dev_usb: Unidad generica de usb.
- /dev_usb000 – 127: Unidad usb especificando el puerto a usar por el numero siendo el 0 el puerto de mas a la derecha de los que tenga la maquina. El 1 seria el adyacente hacia la izquierda, y asi danddo la vuelta por todos los numeros.
- /dev_cf: Unidad Compact Flash.
- /dev_sd: Unidad para tarjetas SD.
- /dev_ms: Unidad para las Memory Stick.
Sabiendo esto pasare a explicar los codigos de error que nos podremos encontrar en el caso de un montaje o desmontaje fallido:
- ERROR_KERNEL_ARGUMENTO_INVALIDO: 0×80010002 -> Este error surge cuando especificamos algun argumento a la llamada de la SYSCALL de forma incorrecta o inexistente, por ejemplo un puntero nulo, pero tambien pude ser reportado en el caso de que se envie una combinacion no reconocida o una mala combinacion de parametros al lv2.
- ERROR_KERNEL_DEVICE_BUSY: 0x8001000A -> Este error aparece cuando intentamos desmontar una unidad que todavia tiene algun vinculo activo, por ejemplo un file descriptor, etc.
- ERROR_KERNEL_I/O_ERROR: 0x8001002B -> Aparece cuando NO existe en ese modelo de maquina / firmware un determinado IOS , o cuando pese a ser una combinacion correcta de parametros lo que es la unidad no puede ser encontrada, por ejemplo, un usb insertado en el puerto adecuado, etc.
- ERROR_KERNEL_INVALID_MEMORY: 0x8001000D -> Cuando especificamos un puntero de forma incorrecta o en una region de memoria no permitida.
- ERROR_KERNEL_8001003B: 0x8001003B -> Aparece si se monta mal una unidad bdvd, pero desconozco su significado real.
- ERROR_KERNEL_ILLEGAL_ACTION: 0×80010009 -> Precisamente eso mismo, algun chequeo de seguridad del firmware evita que esa accion se pueda realizar.
- SUCCESS: 0 -> El valor retornado en caso de exito.
Tras estas explicaciones pasamos a ver la SYSCALL que afectan a lo que nos referimos.
DESMONTAJE:
——————————————————————-
Tal y como aparece indicado en el post
Es por ello que usaremos la SYSCALL 838 -> lv2FsUnMount de esta forma:
Por ejemplo, para desmontar la flash principal:
” int ret = lv2FsUnMount(“/dev_flash”);”
La unidad especificada tiene que existir o de lo contrario recibiremos el error de ARGUMENTO_INVALIDO, del mismo modo la unidad tiene que estar libre de estar ocupada, o de lo contrario nos encontraremos con el error DEVICE_BUSY.
Una vez realizada con EXITO esta operacion, la unidad estara desmontada y POR LO TANTO NO ACCESIBLE.
Por ejemplo, para que probeis esta SYSCALL realizar un programa que desmonte la unidad de BDVD, instalarlo en la maquina, y luego introducir en el XMB un juego de PS3, cuando el XMB lo reconozca arrancar vuestra aplicacion y que desmonte la unidad, luego salir de ella, cuando volvais al XMB la unidad de disco sigue apareciendo visible, con el nombre del juego incluso (esto es debido a que el VSH guarda informacion de que estuvo, y su param.sfo), pero si intentais acceder al disco vereis que os devuelve un error de que la unidad no esta montada,
INFORMACION ACERCA DE ‘ALEJANDRO’:
En este punto pasare a explicar como funcionaba ‘Alejandro’ para poder realizar con exito el desmontado de la flash principal.
Como podreis comprobar si realizais un programa que intente desmontar la flash desde el XMB, os encontrareis al final con el error de DEVICE_BUSY. Esto es normal.
Entonces, como desmontaba ‘Alejandro’ la unidad? Realmente ‘Alejandro’ no la desmontaba, lo que hacia era cambiar el nombre en la tabla de montajes de la “/dev_flash”, para que luego el siguiente montado pudiera realizarse.
ADVERTENCIA!: Para el sistema en el caso de que no se arreglase de nuevo el nombre de la unidad a lo que era, al salir al XMB, el sistema pensaria que no existe flash pues para el estaba desmontada. Es por ello que si ‘Alejandro’ fallaba en algun punto del proceso se expecificaba que se apagase la consola con el cable de red o con el interruptor trasero.
Es por ello que si queremos realizar alguna accion con una unidad ya existente, lo primero que tenemos que hacer es desmontarla usando la SYSCALL o sino forzando el “desmontado” en la tabla de montajes.
MONTAJE:
——————————————————————–
Tal y como pone en el post:
En efecto, la SYSCALL clave en este proceso es la SYSCALL 837 -> lv2FsMount.
Para montar la unidad flash usariamos esta sentencia, presumiento que la anterior estuviera desmontada:
“int ret = lv2FsMount(“CELL_FS_IOS:BUILTIN_FLSH1″, “CELL_FS_FAT”, “/dev_flash”, 0, MODO, 0, 0, 0);”
Donde MODO puede ser un valor entre 0 / 1.
Siendo:
- WRITE_PROTECTED: 1
- WRITE_NOT_PROTECTED: 0
Como podemos comprobar aqui NO era ningun exploit ni nada por el estilo como algun usuario se empeño en decir SIN TENER NI IDEA de como funcionaba el programa “Alejandro” y lo que es peor sin ni siquiera saber como funcionaba el sistema interno de la PS3.
Por supuesto pruebas como montar la unidad BDVD con permiso de escritura logicamente fallaran,
Espero que con este post haya quedado algo mas claro el sistema de montajes, accesos y permisos de escritura.
Ahora solo os queda probar con todos ellos, POR SUPUESTO CON EXTREMO CUIDADO, antes de hacer una estupidez pensar las consecuencias.
Las utilidades que tiene esto son infinitas, desde el ejemplo dado con ‘Alejandro’ hasta crear unidades emuladas virtualmente, por ejemplo, de disco, usb (esto lo realiza el sistema), y un largo etc.
Como siempre tanto JaiCraB como yo os indicamos que podeis dejar vuestros comentarios tanto positivos como negativos en el blog.
Un saludo
Posted: December 17, 2010 by ps3mrenigma in Playstation 3, Tools and Utils
Ante todo, pedir disculpas por poner este post casi una semana despues de la aparicion de la aplicacion, 
Lamentablemente no tengo el tiempo necesario para poder actualizar el blog como quisiera, pero pese a ello, mas vale tarde que nunca,
Quiero dar las gracias a todos aquellos que han tenido palabras de agradecimiento al programa, me complace ver que fue bien aceptado.
Si bien, no he podido evitar leer algunos comentarios que surgieron ya hace algunos dias, que me hicieron reir, por la falta de conocimiento dando afirmaciones, sin saber realmente como funciona la aplicacion.
Es por ello que paso a contestar algunas dudas que podrian existir.
A. ¿Usa ‘Alejandro’ algun exploit no conocido?
La respuesta es NO. El metodo que usa ‘Alejandro’ para realizar su funcion es muy simple, no tiene nada de magico ni es un exploit, como pude leer, sin dejar de reirme, hace un rato de algun usuario.
Si bien, conozco exploits en la PS3, ninguno de ellos es usado en ‘Alejandro’, no son necesarios en este caso.
B. Tengo una version que hace spoof a la version del firmware, ¿me impide usar ‘Alejandro’?
La respuesta es SI. ‘Alejandro’ en su primera version chequea que se este ejecutando en un firmware 3.41.
Desgraciadamente los payload que hacen spoof modifican el mismo punto que ‘Alejandro’ chequea, asi que en esos casos, logicamente impedira su uso.
En el caso de que se quiera evitar este spoof, pongo aqui un ejemplo de como hacerlo, en pocos segundos, para evitar tener que cambiar el payload, solo permanecera activo el cambio hasta que se deshaga o se reinicie la maquina:
- Con el Awesome Peek/Poke, ir a la direccion 0x2D7586 y poner el siguiente valor 0×8534. Esto solo es un ejemplo, de lo facil que es cambiar la version en la maquina,
El cambio NO se vera aplicado en el XMB, pues el VSH permanece residente y ya cogio el valor en el arranque inicial spoofeado por el payload, pero ‘Alejandro’ si leera el valor correcto y os funcionara.
C. ¿Puedo usar ‘Alejandro’ en una maquina debug / reftool?
Si bien la aplicacion PODRIA ejecutarse en dichas maquinas, no esta garantizado. Aparte de eso, ‘Alejandro’ chequea el modelo de maquina, y en el caso
de que detecte un modelo que no sea Retail, reportara que no esta soportado. ‘Alejandro’ se realizo con las maquinas Retail en mente, que son las que, logicamente, mas usuarios tienen.
D. ¿Los cambios realizados usando ‘dev_Alejandro’ son PERMANENTES en la maquina? ¿Sobreviven al reinicio?
Aunque esta respuesta logicamente ya llega tarde, , la respuesta es SI.
Fue divertido ver como se argumentaba en un principio que NO eran cambios permanentes, para luego descubrir que si, tal y como lei de algun usuario.
Como tal, logicamente, el UNICO responsable FINAL de lo que hagamos con nuestra maquina y en su flash es del propio USUARIO.
Jugar con la flash no es recomendable si no se sabe lo que se hace.
E. ¿Porque sacar la aplicacion tan pronto?
Existiendo ya un downgrader, tanto gratuito como de pago, para muchos soportes, que puede arreglar problemas producidos por una mala manipulacion de la flash (ATENCION: NO TODO SE PUEDE ARREGLAR!)
ya no tenia mucho sentido, al menos a nuestro parecer, que no se pudiera manipular libremente.
Aparte de eso, y con la posible futura liberacion de nuevos exploits por parte de importantes sceners, esto podria permitir un uso mas idoneo de la maquina para futuras ideas.
F. ¿Toca algo ‘Alejandro’ en la flash aparte de crear el mirror?
La respuesta es NO. ‘Alejandro’ no toca para nada los contenidos de la flash, solo crea el mirror.
G. ¿Liberareis el codigo fuente de la aplicacion?
Eso es algo que tanto JaiCraB como yo tenemos que pensarlo.
Si bien, el codigo es muy simple, no es ya por no querer liberarlo, sino por las consecuencias que podria tener iniciales.
Como bien sabemos siempre existe gente estupida, que se divierte perjudicando al projimo, en internet eso se potencia aun mas, es por ello
que si el codigo fuente es libre o el metodo, no me extrañaria ver al/a tipic@ estupid@ creando un bricker, tal y como paso hace poco, pero esta vez sin usar un programa oficial.
Esta es la unica razon por la que el codigo fuente no fue liberado junto con la aplicacion.
H. ¿Se podria adaptar ‘Alejandro’ para funcionar, por ejemplo, en el 3.15?
Por supuesto, si se hizo para la version 3.41 es porque esta mas difundida entre los usuarios.
Particularmente, yo prefiero la 3.15, por varios motivos, y teniendo en cuenta que yo a la PS3 no juego salvo
en contadas ocasiones, no necesito la 3.41 ni superiores.
I. ¿ Se puede crear un Custom Firmware ahora usando ‘Alejandro’?
Tal y como he podido ver, no se tardo mucho en realizar modificaciones a los XML, iconos, sonidos al entrar en el XMB,
asi que logicamente podriamos decir si.
Pero con una aclaracion en este punto, ‘Alejandro’ no permite la creacion de un Custom Firmware, permitiria instalarlo, o al menos sus archivos.
Por supuesto, y ya puedo decirlo, crear un Custom Firmware real (actualmente de forma publica usando JIG), es perfectamente posible ahora mismo,
Para finalizar el post, solo decir que como siempre podeis postear vuestras dudas y comentarios, tanto positivos como negativos acerca de la aplicacion.
Un saludo
Como indico en el titulo del post, este post es simplemente para informar de una serie de explicaciones para los futuros post que tendran como objetivo ser post de ingenieria inversa.
Tal y como saben la gente que comprende, realiza y en algunos casos se gana la vida con la ingenieria inversa, el proceso es lento, consume mucho tiempo, requiere tener experiencia y sobre todo mucha paciencia.
Como toda ciencia, no existe algo exacto, con lo que muchas veces en un inicio de ingenieria inversa, al desconocer que hace el codigo o sus variables, se tiende
a nombrar las variables, por ejemplo, de una forma generica que ayude al reversado, pero sin especificar que realiza, para luego segun se entienda mas el codigo saber su funcion y poder cambiar el nombre de la variable, pero aun asi NO esta garantizado de que todo sea correcto.
Es por ello, que en los futuros post de ingenieria inversa, pese a que hago todo el esfuerzo posible con el poco tiempo que tengo, puede haber errores lexicos, errores en los nombres de las varibles si su funcion es distinta a la pensada que es, etc; por lo que, si se descubren errores rogaria que en lugar de hacer criticas nada constructivas, como es el insulto, el ataque, y un largo etc sea omitido.
Yo ignoro dichos eventos, asi que no perdais el tiempo. Sin embargo, me encanta poder escuchar distintos puntos de vista, corregir mis errores si alguien con mas experiencia o conocimiento me indica, etc, con lo que si veis errores no dudeis en argumentar el porque, donde, etc.
Muchas gracias por vuestro entendimiento, espero que los futuros post sean de vuestro agrado, pese a que algunos puedan ser complejos.
Otra cosa que no quiero dejar fuera es indicar que, como se puede presuponer, los comentarios en el foro los tengo moderados. No tuve mas remedio que hacer eso tras, aparte del tipico spam, observar a algunos usuarios intentando atacar alguna otra pagina web usando mi blog, diciendo cosas que no aportan nada al conocimiento y aprendizaje.
El blog no es un campo de batalla entre paginas webs, no lo pienso permitir, toda la informacion que aparece en mi blog puede ser cogida y publicada en cualquier pagina web siempre que de los creditos a quien corresponda, incluyendo a los colaboradores que de forma altruista colaboran con el blog (MUCHISIMAS GRACIAS A TOD@S), al igual que tampoco es un campo de batalla para atacar a otros sceners.
Muchisimas gracias por leer este post!
Posted: October 26, 2010 by ps3mrenigma in LV-2 Kernel Reverse, Playstation 3
En este post veremos como realizar hooks (ganchos) en las SYSCALL del LV-2. Las posibilidades que nos da un gancho son infinitas, solo estando limitado a nuestra imaginacion
y a lo que queramos conseguir con el gancho.
Para este apartado tenemos que tener en cuenta que necesitamos cumplir los siguientes requisitos:
- Tener un dump del LV-2 entero, a ser posible sin estar modificado de ninguna forma por un payload.
- Conocimientos de ensamblador para entender las SYSCALL originales y poder crear nuestros ganchos.
- Comprender como funciona la/s SYSCALL que vamos a modificar.
Para este post tomare como ejemplo un LV-2 3.41 Debug (pues es con el que trabajo mayoritariamente), pero puede ser aplicado del mismo modo en un LV-2 Retail.
Lo primero que necesitamos saber es el inicio de la SYSCALL_TABLE, y el numero de la SYSCALL que queremos ponerle un gancho.
Para el ejemplo pondremos un gancho a la SYSCALL 0×363 (867) para alterar el modelo de maquina que esta nos devolvera.
La SYSCALL_TABLE se encuentra en la posicion 0×303130 (a todas las posiciones en el LV-2 suponer que se les suma la direccion base 0×8000…), sabiendo el numero de la SYSCALL (867)
y teniendo en cuenta que cada entrada de la tabla son 8 bytes en la direccion a la que apunta multiplicamos 867 * 8 = 6936, asi que le sumamos eso a la SYSCALL_TABLE, 0×303130 + 0x1B18 = 0x304C48.
En esa direccion nos encontramos otra direccion de memoria, 0x348FB0, nos vamos a esta segunda y tenemos otra direccion de memoria, 0x27A368. En esa direccion comienza el codigo de la SYSCALL.
Apuntamos la direccion en donde esta la direccion donde comenzaria la SYSCALL, en este caso, 0x348FB4.
Entramos en el codigo de la SYSCALL, sabiendo que la SYSCALL tiene 2 parametros, siendo el primero el comando de la operacion a realizar y el segundo un puntero a un buffer donde guardar el resultado
de la llamada, podemos intentar ver como funciona la SYSCALL.
La SYSCALL 867 con el comando 0×19004 devuelve en el buffer de salida en la posicion 3 (comenzando desde la 0) el byte que indica el modelo de la maquina, sabiendo esto podemos hacer que nuestro gancho
inyecte este valor en el buffer de salida.
Comenzamos a escribir nuestro gancho, para ello escribimos el preambulo de la SYSCALL basandonos en el codigo original:
stdu %sp, -0xB0(%sp)
mflr %r0
std %r30, 0xA0(%sp)
std %r31, 0xA8(%sp)
std %r29, 0×98(%sp)
std %r0, 0xC0(%sp)
Habiendo echo el preambulo, vemos que tenemos guardado en la pila los registros %r30, %r31, %r29 pudiendolos usar para lo que nosotros necesitemos en nuestro gancho, al igual que tenemos guardado
el Link Register por lo que podriamos usar subllamadas en nuestro gancho sin problemas de poder volver al codigo llamante.
Necesitamos chequear que el comando que queremos modificar sea el 0×19004, asi que procedemos a crear un chequeo:
lis %r31, 1
ori %r31, %r31, 0×9004
cmpw %r31, %r3
bne _salir_sin_nada
En este punto tenemos dos flujos posibles, el que sea nuestro comando o que directamente no lo sea. Primero realizaremos el que lo sea:
li %r30, 0×85
li %r29, 1
stb %r29, 1(%r4)
stb %r30, 3(%r4)
stb %r29, 5(%r4)
stb %r29, 7(%r4)
li %r3, 0
ld %r0, 0xC0(%sp)
ld %r29, 0×98(%sp)
ld %r31, 0xA8(%sp)
ld %r30, 0xA0(%sp)
mtlr %r0
addi %sp, %sp, 0xB0
blr
_salir_sin_nada:
Con este codigo haremos que siempre seamos una Retail Europea de los primeros submodelos.
Ahora pasamos a implementar el codigo en el caso de que no fuera el comando chequeado:
b <direccion> , aqui tenemos que calcular a direccion de memoria en la que esta este branch incondicional la distancia a la direccion de memoria objetivo donde queremos ir, en este caso 0x27A380.
Pasemos a explicar el codigo, en el caso de que el comando fuera el deseado, modificamos el buffer destino rellenandolo con un modelo forzado retail eur, de los primeros submodelos, tras lo cual arreglamos
el preambulo de la funcion y volvemos SIN PASAR POR LA SYSCALL original al codigo llamante de la SYSCALL. En el caso de que no fuera el comando, hacemos un salto incondicional a la SYSCALL original
despues de su preambulo ya realizado en nuestro codigo, de este modo y como los parametros originales estan sin tocar, cuando la SYSCALL acabe y proceda a volver a su llamante, volveria al codigo
original que la llamaba, ya que el propio codigo de la SYSCALL corregira el preambulo nuestro.
Una vez creado el gancho, solo tendremos que copiarlo a una region de memoria en el LV-2 adecuada, en el caso de la debug comenzaria en 0×54408, mientras que en retail 0x50B44.
No olvidar que el salto incondicional que realizaba al final del gancho tiene que ser recalculado en la direccion en donde este copiado.
Una vez copiado, se necesita instalar el gancho para que cuando los modulos llamen a la SYSCALL llamen a nuestro codigo, en nuestro caso como sabemos donde comienza nuestro codigo (0×54408), procedemos a escribir
esta direccion de memoria en la segunda direccion que apuntamos que nos indicaba la SYSCALL_TABLE, es decir, en 0x348FB4.
Una vez realizado esto, CUALQUIER modulo, homebrew, etc que llame a esa SYSCALL pasara por nuestro gancho, y si su comando es el 0×19004, devolveremos que somos Retail Eur de forma forzada.
En el caso este de ejemplo, en una debug produce que desde el XMB NO se puede lanzar aplicaciones sin firmar, devolviendo el error del VSH de no permitido (este problema es parcheado por el PSGROOVE, tal y como
pasaremos a explicar en otro futuro post).
Para mas informacion, leer mi otro post acerca de la SYSCALL 0×363.
Posted: October 18, 2010 by ps3mrenigma in Playstation 3, SYSCALL List and new added ones
En este post hablaremos de la SYSCALL 0×363 (o en decimal 867).
Una SYSCALL que no esta en la lista publica en la SDK, la cual nos permite realizar una operacion de lo mas interesante, leer informacion acerca de nuestra maquina.
El uso que le daremos a esta SYSCALL en este post informativo sera el de obtener el modelo de maquina, y su subsiguiente gama.
PROTOTIPO DE LA SYSCALL:
La SYSCALL requiere 2 argumentos:
- La posicion desde la que queremos obtener informacion, en este caso el valor es 0×19004, en el caso de que no se aporte correctamente la SYSCALL devolvera el error 0×80010002 (Argumento invalido)
- Un puntero a un espacio en la memoria con al menos 8 bytes en el que nos sera devuelta la informacion obtenida, en el caso de que no aportemos este parametro la SYSCALL devolvera el error 0×80010509.
La SYSCALL nos devolvera en %r3 o el codigo de error, o un 0 en caso de exito, siendo en la direccion de memoria aportada en %r4 previamente donde tendremos su informacion.
Por lo tanto, la SYSCALL puede ser utilizada de esta forma:
system_call_2(0×363, 0×19004, model_buffer); // donde model_buffer es un buffer local de 8 bytes al menos, tambien puede ser usado 0×19003, pero cambiara el orden de lo retornado.
Una vez realizada la llamada, pasaremos a comprobar el resultado.
En este caso del modelo nos interesan los bytes 4, 6 y 8.
En el byte 4, o en este caso de ejemplo model_buffer[3] , tendremos un valor de 9 posibles, al menos que yo conozca:
- 0×81 -> Reference Tool, es decir maquina de desarrollo, NO CONFUNDIR con debug.
- 0×82 -> Debug Machine, es decir la maquina de testeo y pruebas.
- 0×83 -> Retail Japonesa.
- 0×84 -> Retail USA.
- 0×85 -> Retail Europea.
- 0×87 -> Retail UK.
- 0×89 -> Kiosk Australia – Thanks to Mark_Webber
- 0x8E -> Retail Asia (Hong Kong) – Thanks to Jon Salat
- 0xA0 -> System Debugger
Simplemente con esta comprobacion ya sabemos el modelo de producto base que nuestra maquina tiene, pero no todo se acaba aqui, tambien podemos obtener el submodelo dentro de la gama.
Para esto miramos los bytes 6 y 8 , u en este ejemplo model_buffer[5] y model_buffer[7].
- En el caso de una Debug de 60 gigas ambos valores tendran un 0×1.
- Byte 6: 0×1
- Byte 8: 0×1
- En el caso de una Reference Tool el byte 6 sera 0×9.
Sin embargo lo interesante es en el caso de las Retail (los pocos modelos que he podido conseguir):
- Submodelo Phat de 60 Gb (Europeo, con retrocompatibilidad PS2 por Software):
- Byte 6: 0×3
- Byte 8: 0×4
- Submodelo Phat de 60 Gb (Asia (Hong Kong), Full BC/Memory Card Slots/WIFI):
- Byte 6: 0×1
- Byte 8: 0×4
Thanks to Jon Salat
- Submodelo Phat de 60 Gb (Kiosk Australia):
- Byte 6: 0×3
- Byte 8: 0×4
Thanks to Mark_Webber
- Submodelo Phat de 40 Gb (Europeo, sin retrocompatibilidad PS2):
- Byte 6: 0×5
- Byte 8: 0×1
- Submodelo CECHK04 80 Gb (Europeo):
- Byte 6: 0×7
- Byte 8: 0×5
Thanks to SnoopDo2G
- Submodelo CECH-2001A (USA):
- Byte 6: 0×9
- Byte 8: 0×5
Thanks to pyro2028
- Submodelo Phat de 40 Gb (Japonesa, sin retrocompatibilidad PS2):
- Byte 6: 0×6
- Byte 8: 0×4
- Submodelo Slim de 250Gb (Europea, sin retrocompatibilidad PS2 ni Linux):
- Byte 6: 0xA
- Byte 8: 0×5
- Submodelo Slim de 160 Gb (Europea – UK):
- Byte 6: 0xB
- Byte 8: 0×5
Thanks to Jon Salat and sorrowuk.
NOTA: En las maquinas Debug (desconozco si en las Ref Tool tambien) esta SYSCALL no puede ser utilizada, pues devolvera el error 0×80010003 (No implementada).
Posted: October 16, 2010 by ps3mrenigma in Playstation 3, SYSCALL List and new added ones
NOTE: Yep, this syscall can be tweaked to let you call any point in LV-1 too, if you have some exploit in it before. This way can create a LV-2 SYSCALL that call any LV-1 point, anyways in this post any LV-1 exploit is explained, it is only the SYSCALL as it. I explain it because i read this post:
http://psx-scene.com/forums/f149/asbestos-geohot-70025/#post576097
Como sabemos el metodo de comunicacion entre una aplicacion homebrew, un juego, o cualquier otro tipo de modulo de entorno usuario se realiza mediante una llamada a un procedimiento de sistema, o tambien llamado SYSCALL.
Este procedimiento permite llamar a funciones que solo son exportadas de esta forma por el kernel usuario en el LV-2.
Es por ello, que se me ocurrio la idea de implementar una nueva SYSCALL que me permitiera con una simple llamada a ella poder “saltar” (de aqui su nombre Jumper) a cualquier punto que desease del LV-2.
El unico requisito que se exige para poder usarla correctamente es saber a donde ir y los argumentos que se utilizaran en donde vayamos para un resultado positivo para nosotros.
Su utilidad es, pues, clara, desde un homebrew podemos llamar a una funcion que no este exportada como SYSCALL en el LV-2, llamar a otra SYSCALL sin tener que llamarla directamente ofuscando nuestro codigo por tanto, modificar o crear nuevo codigo usando otras SYSCALL y luego saltando a ese punto en cualquier momento, etc, la imaginacion es el limite.
Pensar de esta SYSCALL como una puerta abierta directa a cualquier punto del LV-2.
Su PROTOTIPO DE LLAMADA:
Se puede utilizar cualquier prototipo “system_call_x” de la SDK.
Los unicos requisitos son:
- Colocar en %r3 (arg1) la direccion de memoria (64bits) a la que queremos saltar en el LV-2.
- Colocar en %r4 – r10 (arg2 – arg9) los argumentos que queramos utilizar en la posicion del salto en el LV-2, es importante darse cuenta que en %r4 pondremos el argumento que en una llamada directa a esa direccion en el LV-2 seria el %r3, y asi sucesivamente, %r5 seria %r4 realmente, etc.
La SYSCALL se encargara antes de hacer el salto de recolocar los registros a las posiciones correctas.
- La SYSCALL retorna en %r3 el error 0x8001000D (Direccion invalida) si en el %r3 (arg1) pusimos un puntero nulo por error, o devolvera en %r3 – %r4…, lo que devuelva el salto realizado en el LV-2.
De esta forma podemos comprobar que se puede llamar desde:
system_call_1(9, <direccion>); // para un salto a la direccion sin argumentos
hasta:
system_call_8(9, <direccion>, <arg1>, <arg2>….); // para un salto con 7 argumentos
CODIGO:
_syscall_9:
cmpdi %r3, 0
beq _null_addr
stdu %sp, -0×10(%sp)
mflr %r0
std %r0, 8(%sp)
mtctr %r3
mr %r3, %r4
mr %r4, %r5
mr %r5, %r6
mr %r6, %r7
mr %r7, %r8
mr %r8, %r9
mr %r9, %r10
# As you can see you lost a arg here, but you can use %r12 as the last arg in your SYSCALL 9 CALL, but you will need use assembler inline to make it
# mr %r10, %r12
bctrl
ld %r0, 8(%sp)
addi %sp, %sp, 0×10
mtlr %r0
b _exit_9
_null_addr:
lis %r3, 0×8001
ori %r3, %r3, 0xD
_exit_9:
blr
Solo se necesita insertarla en el payload, y activar la SYSCALL usando los metodos habituales.
]