A proposito de Demonhades.... en PlayStation 3

Mathieulh 02 jul 2010 21:29

Novato

9 mensajes
desde jun 2007

Como dije antes, una consola debug tiene el mismo hardware que una retail con set_fself_control_flag(), set_debug_support_flag() puesto en la eepron del syscon (esos flags puede sobreescribirse) y el id objetivo puesto a 0082 en EID (el cual se almacena en la nand fuera del FS y encriptado con la clave propia de cada PS3). Además tienes una versión específica de lv2_kernel.self y archivos dev_flash específicos (lv0 y lv1 son las mismas que en las consolas ordinarias) se hacen verificaciones concretas para asegurar que el kernel debug no se ejecuta en las consolas normales, (el lv2 SIEMPRE revisa el flag de soporte debug, si no se encuentra en la consola, esta NO ARRANCARÁ.) Hay otras verificaciones que hacen prácticamente inutil el uso de un kernel debug en una unidad si el target id correcto, las cuales no detallaré por ahora, por ejemplo un self falso (los fself son elfs con una firma falsa tales como los que normalmente se ejecutan en las consolas debug) no funcionarían en consolas normales AUNQUE las forzaras a usar un kernel debug.

El TRM no tiene NADA que ver con esas verificaciones.

Por cierto, ¿no fue Demonhades el primero en felicitar a SKFU por su supuesto "hack" basado en temas? Eso demuestra bastante bien como este tio no tiene ni idea de la ps3 ni de como funciona. Esto no es nada nuevo, de hecho, que se podría esperar de alguien que solo se queja de que los desarrolladores/investigadores/hackers no "comparten" (lease "se les descubren") sus hallazgos. Eso tiene la misma pinta que una (no muy recomendable) página web que conozco... Pero como se suele decir, Dios los cría y ellos se juntan.

La gente debería parar de leer blogs y webs que sacan dinero de la publicidad mientras muestras los supuestos "hacks" e "investigaciones" basados en hechos y suposiciones sin base que proclaman como verdaderas, algunas de ellas suscitando el uso de esas "técnicas" para promover la piratería (seguramente para juntar a más gente y sacar más de los anuncions...)

De todas maneras ya veis mi punto de vista en todo este asunto. Gente que dice que quieren mejorar la scene deberían realmente trabajar para conseguir esa visión en vez de simplemente mendigar los binarios, trabajo, código etc. de otras personas.

Source: http://twitter.com/Mathieulh (en ingles)

Gracias a elorz007 por ese traducion.

Psmaniaco 02 jul 2010 21:40

Duelista de EOL

44.506 mensajes
desde mar 2002
en León(España)

¿Y??????

.
Un saludo.

Technoise 02 jul 2010 21:40

Adicto

244 mensajes
y 1 foto
desde mar 2007
en donde nace el olvido

La que le da en todo el morro al Demonhads,estopa buena si

. El MAth tiene todo mi respeto, vista la afinidad que teneis aqui por el Demon seguro que mas de uno la esta gozando on MAthiu tan conciso y claro exponiendo como ve al Demo como scener. Lo que me queda preguntar es que fue el detonante de dicha afirmacion y por que la misma en estos momentos. No dudo de MAth ni mucho menos,pero me gustaria saber el detonante de la misma. Alguin sabe que hizo el Demon?

Saludos [bye]

Psmaniaco 02 jul 2010 21:45

Duelista de EOL

44.506 mensajes
desde mar 2002
en León(España)

Vale¿y eso que mas da? por que no le veo sentido a esto.
Un saludo.

panajoa 02 jul 2010 21:47

Novato

15 mensajes
desde abr 2010

Demon afirmo a un muchacho q si X cosa fuese posible, el firmware debug podria ejecutarse sin problemas en las ps3 retail, incluso dijo q esta ultima tenia opciones ocultas en el XMB (conocido mejor como vshmain). Solo eso :/

borrego92 02 jul 2010 21:50

MegaAdicto!!!

624 mensajes
desde abr 2009

Por lo que he leido en su blog, tal personaje trabaja en sony, y por su culpa al estar en todos los proyectos se han ido a la mierda

Rapture 02 jul 2010 21:56

Adicto

376 mensajes
desde sep 2008
en Andorra

Página web de Rapture

La credibilidad de Demon es nula si analizamos todo lo que ha aportado a la scene. Solamente tiene un falso reconocimiento y una web que se nutre de lo que hacen los demás. Pero mejor no hacer ni caso. Hace mil que no visito su web

Technoise 02 jul 2010 22:03

Adicto

244 mensajes
y 1 foto
desde mar 2007
en donde nace el olvido

Me puse a investigar un poco a raiz de este comentario y lo que me contesto panajoa(gracias),por si alguno le interesa cito el tema que ademas son pregutas del compa Keihanzo.
#
12 Mayo 2010 00:10
posted by Keihanzo

Que pasa Demon,

Vamos por partes, antes de nada dejar claro que me parece fantástico que os tomeis con interés este tema y que mis “apuntes” pretenden ser constructivos.

En primer lugar me gustaría ver como conseguís que la consola se trague un vshmain debug, ya que necesitaríamos firmarlo antes como bien sabes… a no ser que me haya perdido algo.

Por otra parte, el tema de los shaders de la gráfica… si bien es cierto que el exploit del KK en 360 se basaba en modificar unos shaders de un juego (para ello ya necesitaríamos estar cargando copias), tenemos que tener en cuenta que el hecho de que esos shaders fueran vulnerables se debía a una anomalía que se subsanó en siguientes reediciones del juego (no hablamos de que todos los shaders lo permitan, ni muchísimo menos)… me parecería mucha coincidencia encontrar una vulnerabilidad en los shaders del mismísimo GameOS.

Y referido al lector, evidentemente no sé como van avanzando vuestras investigaciones, pero hasta la fecha lo que se sabe ( y no precisamente gracias a EoL) es que tenemos en él un puerto Jtag, probablemente desactivado, el cual no tenemos ni repajolera idea de como aprovechar… en el supuesto de que se pudiera.

¿Habeis pensado en hablar con Xorloser?, el modificó los shaders del KK y también ha contribuído en cierta forma al hack de Geo.

Para acabar diría que nuestra mejor opción para hacking está en el famoso pulso de Geo.
Hacer ingeniería inversa a Game OS, parchearlo para modificar su hipervisor a nuestro antojo y lanzarlo desde Linux. Que se dice pronto… y seguiré manteniendolo hasta que mostreis un plan más concreto que la nebulosa de “buenas ideas” que habeis plasmado aquí. O mejor, algún avance.

Por último decir que ni trato de iluminar nada y mucho menos fardar de algo. Yo me siento aquí y veo como os divertís con vuestros cacharritos. A ver lo que sois capaces de hacer

.
Inicia sesión para responder

1.
12 Mayo 2010 01:38
posted by DemonHades

keihanzo aqui jugamos con varios marcos de trabajo,entre ellos los parches de redireccion de los juegos instalados en el hdd.

por lo que tenemos varios sitios:

lector
hdd
dev_flash
linux
betas pkg

Cuando decimos de manipular el vshmain de una retail a debug es porque se tiene constancia de que se puede manipular la dev_flash,y en su defecto meter el tan citado vshmain debug.

el lector el tema jtag es otra historia,la unica seguridad que contempla el sistema hacia el lector son 2:

1)cuando se procede a hacer un update que hace checkeos al lector,si estos no son validados para el update..osease brick

2)lo que tu y yo conocemos como id de emparejamiento,ya sabes lector y motherboard de la consola.

el resto el lector es autonomo y no necesita del sistema,piensa que el propio lector tiene embedida su vm java,y que los ejecutables tienen su protocolo de cripto engine al spu,mientras tu cumplas eso no hay problema.

tambien tenemos la mascara o el layer de cifrado que esta aplicado a los juegos y el sector 0 donde se guarda la key que quita el layer.

el resto seria como 360 redireccion de los ss a otra ubicacion.

con esto te quiero decir que no siempre se publica toda la informacion..o llega distorsionada.

lo que tu dices es hacer un reboot limitandote a tener que pasar por la lpar_linux…un poco engorroso..pero lo mas plausible para quien no se quiera pringar.

tambien decirte que nosotros mismos hace unos años cargamos un debug en retail,obviamente no se instalo el core_os,ya que el syscon(bios) guarda un flag del modelo de consola que luego el pup lee para usarlo e instalar solo lo que hace referencia a ese flag.Pero te aseguro que se instalo el vshmain debug en una retail..por lo tanto los modulos o ejecutables que se le instala al sistema son independientes del kernel.

xorloser fue quien manipulo los shaders???creia que habia sido tmbinc cuando se hizo la famosa conferencia de hackers en alemania jajaj

elorz007 02 jul 2010 22:03

Habitual

92 mensajes
desde mar 2010
en En este lado...

Este es uno de los tweets que ha hecho mathieul, había pedido una traducción y se la he hecho, por eso igual no tiene mucho sentido sacado de contexto.

Los tweets son:
http://www.twitlonger.com/show/291bgb
Traducción:

Solo saben quejarse en vez de trabajar en serio. Lo peor es su blog que está lleno de hechos falsos como, por ejemplo, cómo se utilizan los denominados "efuses" o que el TRM tiene algo que ver con las debug vs retail y que cambiándolo mágicamente conviertes tu consola.... Bien, cuando veais quién está asociado con ellos no quedarán dudas de como han llegado a este nivel (de mierda)... Debería dejarse de pretensiones infundadas y empezar con el trabajo de verdad. Si hasta hubo alguna vez en la que no dependía del trabajo de otros, no?

y
http://www.twitlonger.com/show/291hsg
La traducción, lo que pone en el primer post de este hilo:

Como dije antes, una consola debug tiene el mismo hardware que una retail con set_fself_control_flag(), set_debug_support_flag() puesto en la eepron del syscon (esos flags puede sobreescribirse) y el id objetivo puesto a 0082 en EID (el cual se almacena en la nand fuera del FS y encriptado con la clave propia de cada PS3). Además tienes una versión específica de lv2_kernel.self y archivos dev_flash específicos (lv0 y lv1 son las mismas que en las consolas ordinarias) se hacen verificaciones concretas para asegurar que el kernel debug no se ejecuta en las consolas normales, (el lv2 SIEMPRE revisa el flag de soporte debug, si no se encuentra en la consola, esta NO ARRANCARÁ.) Hay otras verificaciones que hacen prácticamente inutil el uso de un kernel debug en una unidad si el target id correcto, las cuales no detallaré por ahora, por ejemplo un self falso (los fself son elfs con una firma falsa tales como los que normalmente se ejecutan en las consolas debug) no funcionarían en consolas normales AUNQUE las forzaras a usar un kernel debug.

El TRM no tiene NADA que ver con esas verificaciones.

Por cierto, ¿no fue Demonhades el primero en felicitar a SKFU por su supuesto "hack" basado en temas? Eso demuestra bastante bien como este tio no tiene ni idea de la ps3 ni de como funciona. Esto no es nada nuevo, de hecho, que se podría esperar de alguien que solo se queja de que los desarrolladores/investigadores/hackers no "comparten" (lease "se les descubren") sus hallazgos. Eso tiene la misma pinta que una (no muy recomendable) página web que conozco... Pero como se suele decir, Dios los cría y ellos se juntan.

La gente debería parar de leer blogs y webs que sacan dinero de la publicidad mientras muestras los supuestos "hacks" e "investigaciones" basados en hechos y suposiciones sin base que proclaman como verdaderas, algunas de ellas suscitando el uso de esas "técnicas" para promover la piratería (seguramente para juntar a más gente y sacar más de los anuncions...)

De todas maneras ya veis mi punto de vista en todo este asunto. Gente que dice que quieren mejorar la scene deberían realmente trabajar para conseguir esa visión en vez de simplemente mendigar los binarios, trabajo, código etc. de otras personas.