Quitar chip rgh luego de instalar Xebuild

Hola tengo una duda... [comor?] ¿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.
No, el chip sirve para cargar codigo sin firmar exploiteando la boot de la consola

Si no exploiteas la boot no cargara ningun dash modificado
El RGH es un exploit que se tiene que hacer cada ves que quieras cargar código sin firmar.
Digamos que el chip "es" el exploit y que si lo quitas ya no cargará código sin firmar.

Es decir, siempre tienes que tenerlo instalado.
Sergio_Lector+Muerto escribió:Hola tengo una duda... [comor?] ¿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.

amigo solo con tu firma, te digo que estoy :-|

presionando liteon erase no te da resultado un lector muerto, si no un lector en vendor mode, listo para que le escribas en la memoria.

en cuanto a tu pregunta, el chip es necesario para enviar los pulsos al cpu y asi este se desestabilice para correr codigos sin firmar, en otras palabras no retires el chip por nada del mundo si tienes RHG.
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
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


amigo, lee bien antes de decir lo que dices, el amigo pregunto si se puede quitar el chip luego de hacer RGH, lo que tu comentas se podria hacer si la consola fuera jtag, pero no lo es, en serio hay que leer bien antes de responder :D saludos.
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,
Ni de coña, los requerimientos del jtag son del dash oficial, por mucho que pongas el xbr no sirve de nada, al ser un dash modificado xDDD

No se puede bajar de versión con el dash oficial, además el exploit ya estaría tapado.
Ya este hilo podria estar perfectamente cerrado, esta clarisimo que si vas hacer RGH tienes que tener el chip instalado, es el quien hace el RGH XDD, y no podemos downgradear la maquina a un dash de los antiguos para hacer Jtag si se pudiera seguro que todos lo estariamos haciendo en vez de poner chips. Un saludo.
como lo comento no lo e tratado de hacer pero tengo una consola falcon y mañana me llegan unos coolruner y lo intento
saco la cpukey instalando el cool runer
pongo los puentes y diodos
y creo la nand con el marranito para jtag
y la escribo
si arranca les comento
un saludo
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,


si eso se pudiera hacer tu crees que pasariamos comprando matrix glitcher a cada rato jajaja, no mi amigo el problema es que al subir el dash oficial arriba de 7176, se queman unos efuses del procesador que permitian el exploit, o sea hubo un cambio fisico en la consola, la cual no podra volver a funcionar haciendo downgrade, ya que esos efuses ya no existen.
Hermano no puedes hacer lo que comentas ya que la consola quema efuses y no puedes volver a ese dash por favor no confundan a la gente antes de ponerse a inventar y especular informece bien saludos
No se puede hacer, ya que 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

Cuando la consola actualiza el CB "QUE NO EL DASHBOARD" quema una linea de eFuses dedicados al bootloader, una vez quemados NO HAY VUELTA ATRAS.

El XBR corre por encima del CB, si no tiene un CB expecifico no funcionara nunca, porque necesita el exploit del JTAG el cual esta cerrado en CB's modernos

Aun que tuvieras la CPU KEY para modificar la NAND y parchear con el exploit del JTAG, en el momento de hacer las verificaciones al no existir el exploit via software el JTAG quedaria anulado bloqueandose la consola y dando un bonito arbol de navidad por modificacion del HASH de la NAND

Saludos!
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 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

Como todos les han dicho NO se puede.
Aquí explico por que no se puede y como funciona el 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, cuando 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 quería explicar 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, 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 eFuses.
El JTAG de la GPU es desactivado por software (CB), ya que la GPU no tiene eFuses.
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 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

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.


me recordaste de aquellos tiempos a finales del 2006 y principios del 2007 XD a bendito kk con eso empezo todo.
14 respuestas