› Foros › Xbox 360 › Exploits y homebrew
Sergio_Lector+Muerto escribió:Hola tengo una duda... ¿se puede quitar el chip del rgh fisico luego de instalar el xebuild? y si despues de quitarlo seguiria fucionando el rgh?
Agradeceria cualquier aporte Gracias.
Estrello escribió:es un pregunta no respondida por muchos ya que no se hace correctamente
primero que consola tienes ?
y segundo si tienes el cpukey y tu consola es una fat puedes intentar meterle el xbr (con los puentes diodos ) y checar que arranque
yo no lo e intentado pero el problema siempre fue el cpukey para poner el xbr si lo tienes no creo que tengas problema
un saludo y si me equiboco pues que comenten
setzer_x escribió:lo que entendi que intenta decir estrello es
se hace el RGH y se le pone en XeBuild un dash 7176 el cual es el perfecto del Jtag
a lo que entendi es hacerle un downgrade a esa version de modo que se ahorre uno el chip
para poner los diodos ,
entonces el proceso seria,
leer nand, crear la ecc y sacar la cpu key,
crear una imagen retail del dash 7176 ,
al ya tener la cpu key, se podria crear un ecc de jtag y una imagen ya modificada,
suena bien , pero creo que solo aplicaria en consolas phat,
ya que hasta donde se , y como casi en cualquier aparato , al hacer un downgrade de un soft
que no lo halla tenido nunca seria algo dificil,
duke5000 escribió:...el Exploit del JTAG aprovecha una vunerabilidad en el CB de la consola, en versiones mas modernas se parchean los CB y se cierra el JTAG
Estrello escribió:....si tienes el cpukey y tu consola es una fat puedes intentar meterle el xbr (con los puentes diodos ) y checar que arranque
yo no lo e intentado pero el problema siempre fue el cpukey para poner el xbr si lo tienes no creo que tengas problema
setzer_x escribió:se hace el RGH y se le pone en XeBuild un dash 7176 el cual es el perfecto del Jtag
a lo que entendi es hacerle un downgrade a esa version de modo que se ahorre uno el chip
para poner los diodos , entonces el proceso seria,
leer nand, crear la ecc y sacar la cpu key,
crear una imagen retail del dash 7176 ,
al ya tener la cpu key, se podria crear un ecc de jtag y una imagen ya modificada
Tmv_Josue escribió:duke5000 escribió:...el Exploit del JTAG aprovecha una vunerabilidad en el CB de la consola, en versiones mas modernas se parchean los CB y se cierra el JTAG
No existe alguna vulnerabilidad en el CB, y el Jtag no aprovecha nada en él... mas bien M$ tapó el exploit a través del CB.Estrello escribió:....si tienes el cpukey y tu consola es una fat puedes intentar meterle el xbr (con los puentes diodos ) y checar que arranque
yo no lo e intentado pero el problema siempre fue el cpukey para poner el xbr si lo tienes no creo que tengas problemasetzer_x escribió:se hace el RGH y se le pone en XeBuild un dash 7176 el cual es el perfecto del Jtag
a lo que entendi es hacerle un downgrade a esa version de modo que se ahorre uno el chip
para poner los diodos , entonces el proceso seria,
leer nand, crear la ecc y sacar la cpu key,
crear una imagen retail del dash 7176 ,
al ya tener la cpu key, se podria crear un ecc de jtag y una imagen ya modificada
Como les han dicho todos NO se puede.
Aquí tienen el por que con mi mala redacción, además de explicar como funciona el SMC-Jtag Hack:
Todo empezó con el exploit en el juego King Kong (KK):
A través de este juego era posible escribir código sin firmar en una parte de la memoria sin cifrar y aprovechando un bug en el Hyper Visor del Kernel 4532 o 4548 para que este lo ejecute.
Aclaraciones:
-Ningún Kernel anterior al 4532 tiene ese bug en el HV
-En la posterior actualización, en el kernel 4552 fue corregido el bug en el HV
-ÚNICAMENTE el HV del Kernel 4532 y 4548 tiene el bug
Después apareció el Exploit SMC-Jtag:
Este exploit es a base de software y hardware.
Aquí en lugar del juego KK el que se encarga de escribir el código sin firmar es el SMC mandando instrucciones a través del puerto Jtag de la GPU para escribirlo en la memoria.
¿Pero que caso tiene escribir en la memoria si el bug fue corregido desde el kernel 4552 y ya no podrá ser ejecutado?
Aquí es donde entra la versión de CB, la paridad a zero y comienza la magia.
A grandes rasgos el CB al ser emparejado a cero, hace que la consola entre al modo de Fabricación y ya no necesita el software estar cifrado con la Cpu-key de la consola, además de que el proceso entero ya no necesita estar cifrado también. Lo malo es que en este modo solo se puede ejecutar el kernel base 1888 (el primer kernel) que está guardado en la nand desde siempre y hasta ahora, por lo cual es una perdida de tiempo ya que no puede correr el dash, no se puede salir de él y no se puede aprovechar el eploit del juego KK por que no funciona en se kernel.
Esto cambió a partir de la versión del CB de las Xenon 1920 (kernel 7371) ya que su CD tuvo un cambio muy interesante, cuan el CB se empareja a cero las ranuras de actualización ya no son ignoradas y si la ranura de actualización es cero emparejada también, se ejecuta. Ese cambio permitió arrancar cualquier kernel, con lo cual se pudo construir una imagen que ejecuté el kernel 4532, independientemente de la cantidad de fusibles quemados en la línea de fusibles 07-11 (actualizaciones del Dash/Kernel).
Sin embargo, el proceso de valides del CB debe ser aprobado, por lo que depende de los fusibles de la línea 02 (actualizaciones del CB).
Al usar la paridad a cero el hash del SMC ya no importa, con lo cual puede ser libremente modificado. El problema es que al arrancar en el modo Manufacturing con la versión 4532 ahora, hace que las luces parpadeen en rojo y verde. Pero el SMC/JTAG permite implementar el payload/cargador del Exploit y hacer que la CPU lo ejecute. El SMC hack (Jtag) hace esto usando el SMC para implementar el payload/cargador en la memoria ejecutable (a través del puerto JTAG de la GPU) y luego decirle a la CPU que haga una lectura DMA en ese lugar para ejecutar el código sin firmar.
Disculpen el tocho pero era para que entiendan como funciona...
Ahora bien esta forma se retiró en la actualización del verano del 2009 (8498).
Haciendo que el Jtag quede inutilizado simplemente desactivando el puerto Jtag de la GPU al arrancar, eso lo hacen las nuevas versiones del CB desde ese entonces y hasta el día de hoy.
Así que para poder hacer funcionar el jtag de la GPU de nuevo necesitarías poder ejecutar un CB que no lo apague, es decir el CB1920 de la actualización 7371.
Pero lo que hace que no podamos volver a ejecutar ese CB son los fusibles.
Los fusibles de la línea 02 no son quemados secuencialmente, son quemados de forma que se usen como mascara de bits por el propio CB. El CB antes de ejecutase checa que coincida su Set de fusibles con los que hay en la línea 02 dentro de la CPU, si no coinciden simplemente no se ejecuta.
La comprobación de mascara de bits puede pasar la prueba si faltan fusibles por quemar en la CPU, pero no si hay mas NO, es decir, se pueden ejecutar CBs mas actuales de los que la línea está habilitada a correr pero no al contrario, o sea que no se puede ejecutar CBs anteriores.
Los fusibles NO se pueden deshacer o “desquemar”.
El JTAG de la CPU es de hecho (en parte/mayormente) desactivada por eFUSE.
El JTAG de la GPU es desactivado por software (CB), ya que la GPU no tiene efuses.