[Investigacion] Modificar Nand para desactivar firmas

Moogle escribió:

VDF_Demon escribió:No...

¿Entonces si que se puede modificar un kernel de MS oficial haciendo que sea compatible con el reset glich hack y con las mismas ventajas que el jtag, pero no lo hacen por que respetan la decision de gligli?

Sí.

De tomas maneras el código de los rebooters deben andar por algún lado, no se parte desde 0

La comprobacion de efuses se ejecuta antes del lv1,de echo es lo primero ke se comprueba
vdf_demon
Osea ke eso de igorarla o eliminarla esta por ver

paxama escribió:La comprobacion de efuses no se ejecuta antes del lv1?

Lvl 1 me suena a ps3...


Arranque JTag...

Consola inicia, lee efuses, se inyecta el codigo basado en 4532 o 4558 para el xploit y procede a la carga del rebooter...

funcionamiento del reboter....

El rebooter reemplaza ciertas llamadas al sistema, para que en vez de leer los efuses de la consola los lea desde la nand y el kernel a bootear crea que los efuses estan como se suponen debe estar (version del kernel) y no genere ningun tipo de error


EL GLICTH NO NECESITA DE NADA DE ESTO PARA ARRANCAR

VDF_Demon escribió:

paxama escribió:La comprobacion de efuses no se ejecuta antes del lv1?

Lvl 1 me suena a ps3...


Arranque JTag...

Consola inicia, lee efuses, se inyecta el codigo basado en 4532 o 4558 para el xploit y procede a la carga del rebooter...

funcionamiento del reboter....

El rebooter reemplaza ciertas llamadas al sistema, para que en vez de leer los efuses de la consola los lea desde la nand y el kernel a bootear crea que los efuses estan como se suponen debe estar (version del kernel) y no genere ningun tipo de error


EL GLICTH NO NECESITA DE NADA DE ESTO PARA ARRANCAR

Claro, el parche de los efuses es porque cuando actualisas al siguiente dash de 7371 quema los efuses y hace ciertas modificaciones, y el exploit queda obsoleto.
en glitch es diferente, porque no tiene que emular los efuses, porque ya estan quemados para el dashboard actual, y si sale otro dashboard, se queman los efuses real mente, para que arranque me entienden?? , no se ocupan

VDF_Demon escribió:

Moogle escribió:

VDF_Demon escribió:No...

¿Entonces si que se puede modificar un kernel de MS oficial haciendo que sea compatible con el reset glich hack y con las mismas ventajas que el jtag, pero no lo hacen por que respetan la decision de gligli?

Si, al menos de momento....

Cuando los fabricantes de Chips vean que no se venden por falta de un Loader "Free", Desembolsaran algo de dinero para crearlo...

esperemos jajajaa

VDF_Demon escribió:

paxama escribió:La comprobacion de efuses no se ejecuta antes del lv1?

Lvl 1 me suena a ps3...


Arranque JTag...

Consola inicia, lee efuses, se inyecta el codigo basado en 4532 o 4558 para el xploit y procede a la carga del rebooter...

funcionamiento del reboter....

El rebooter reemplaza ciertas llamadas al sistema, para que en vez de leer los efuses de la consola los lea desde la nand y el kernel a bootear crea que los efuses estan como se suponen debe estar (version del kernel) y no genere ningun tipo de error


EL GLICTH NO NECESITA DE NADA DE ESTO PARA ARRANCAR

El lvl 1 estaba comprometido hasta el dash 7371,la siguiente actualizacion a 7371 fue diferente a todas las vistas hasta el momento la consola hacia 2 reinicios,en el primero se parcheaba el lvl 1 y kemaba los efuses y en el segundo se ejecutaba la actualizacion
La comprovacion de efuses se hace antes de ejecutar el lvl 1 y sigue presente con el actual xploit
Os sigo diciendo ke teneis ke adaptar los efuses a la imagen ke kereis crear si no 3LR con su correspondiente error

paxama escribió:

VDF_Demon escribió:

paxama escribió:La comprobacion de efuses no se ejecuta antes del lv1?

Lvl 1 me suena a ps3...


Arranque JTag...

Consola inicia, lee efuses, se inyecta el codigo basado en 4532 o 4558 para el xploit y procede a la carga del rebooter...

funcionamiento del reboter....

El rebooter reemplaza ciertas llamadas al sistema, para que en vez de leer los efuses de la consola los lea desde la nand y el kernel a bootear crea que los efuses estan como se suponen debe estar (version del kernel) y no genere ningun tipo de error


EL GLICTH NO NECESITA DE NADA DE ESTO PARA ARRANCAR

El lvl 1 estaba comprometido hasta el dash 7371,la siguiente actualizacion a 7371 fue diferente a todas las vistas hasta el momento la consola hacia 2 reinicios,en el primero se parcheaba el lvl 1 y kemaba los efuses y en el segundo se ejecutaba la actualizacion
La comprovacion de efuses se hace antes de ejecutar el lvl 1 y sigue presente con el actual xploit
Os sigo diciendo ke teneis ke adaptar los efuses a la imagen ke kereis crear si no 3LR con su correspondiente error

Y dicha actualizacion/quema de FUSES se realizo para que no se pudiesen cargar los kernels 4532 y 4558, que son en los que se basa la ejecucion de codigo no firmado en el JTAG y por eso no se puede realizar el JTAG en consolas atualizadas


PERO EL RESET GLITCH NO USA, NINGUNO DE LOS ELEMENTOS DEL JTAG, Y POR ESO ES INDEPENDIENTE DE KERNEL, INDEPENDIENTE DE LOS FUSES,

Lvl 1 me suena a ps3...


Arranque JTag...

Consola inicia, lee efuses, se inyecta el codigo basado en 4532 o 4558 para el xploit y procede a la carga del rebooter...

funcionamiento del reboter....

El rebooter reemplaza ciertas llamadas al sistema, para que en vez de leer los efuses de la consola los lea desde la nand y el kernel a bootear crea que los efuses estan como se suponen debe estar (version del kernel) y no genere ningun tipo de error


EL GLICTH NO NECESITA DE NADA DE ESTO PARA ARRANCAR[/quote]
El lvl 1 estaba comprometido hasta el dash 7371,la siguiente actualizacion a 7371 fue diferente a todas las vistas hasta el momento la consola hacia 2 reinicios,en el primero se parcheaba el lvl 1 y kemaba los efuses y en el segundo se ejecutaba la actualizacion
La comprovacion de efuses se hace antes de ejecutar el lvl 1 y sigue presente con el actual xploit
Os sigo diciendo ke teneis ke adaptar los efuses a la imagen ke kereis crear si no 3LR con su correspondiente error[/quote]

Y dicha actualizacion/quema de FUSES se realizo para que no se pudiesen cargar los kernels 4532 y 4558, que son en los que se basa la ejecucion de codigo no firmado en el JTAG y por eso no se puede realizar el JTAG en consolas atualizadas


PERO EL RESET GLITCH NO USA, NINGUNO DE LOS ELEMENTOS DEL JTAG, Y POR ESO ES INDEPENDIENTE DE KERNEL, INDEPENDIENTE DE LOS FUSES,[/quote]
Ya se ke el reset glitch no usa ninguno de los elemtos del jtag,pero la consola si comprueba los efuses y como te he dicho es lo primero ke hace(lo hace antes de arrancar el kernel) no me kieres entender?
La imagen ke se va escribir tiene ke tener los efuses correctos y en su sitio,si no 3LR
y no hace falta ke escribas en mayusculas,entiendo igual

paxama escribió:Ya se ke el reset glitch no usa ninguno de los elemtos del jtag[/color],pero la consola si comprueba los efuses,no me kieres entender?
La imagen ke se va escribir tiene ke tener los efuses correctos y en su sitio,si no 3LR
y no hace falta ke escribas en mayusculas,entiendo igual

y los fuses van el la nand con propositos del rebooter... cosa que aca no usamos y los fuses se leen de la consola, como lo hace una retail

VDF_Demon escribió:

paxama escribió:Ya se ke el reset glitch no usa ninguno de los elemtos del jtag[/color],pero la consola si comprueba los efuses,no me kieres entender?
La imagen ke se va escribir tiene ke tener los efuses correctos y en su sitio,si no 3LR
y no hace falta ke escribas en mayusculas,entiendo igual

y los fuses van el la nand con propositos del rebooter... cosa que aca no usamos y los fuses se leen de la consola, como lo hace una retail

pues segun decis crear un rebooter con las herramientas actuales ke no modifike los efuses y haber si arranca
sabeis donde estan ubicados?
Si seria tan facil como solo modificar los cb,smc.......... (ke hay herramientas)ya estaria echo xd

paxama escribió:

VDF_Demon escribió:

paxama escribió:Ya se ke el reset glitch no usa ninguno de los elemtos del jtag[/color],pero la consola si comprueba los efuses,no me kieres entender?
La imagen ke se va escribir tiene ke tener los efuses correctos y en su sitio,si no 3LR
y no hace falta ke escribas en mayusculas,entiendo igual

y los fuses van el la nand con propositos del rebooter... cosa que aca no usamos y los fuses se leen de la consola, como lo hace una retail

pues segun decis crear un rebooter con las herramientas actuales ke no modifike los efuses y haber si arranca
sabeis donde estan ubicados?
Si seria tan facil como solo modificar los cb,smc..........ya estaria echo xd

Dicho por gligli...

On va etre clair : c'est un fake complet, c'est pour cette raison que nous n'avons pas diffuser l'information. Pour lancer un kernel hacké sur les console glitchée il n'y a pas besoin d'un rebooter. Sur les JTag, au démarrage la console utilise le Kernel Hacké 4532 (King Kong exploit) pour lancer XeLL, à partir de là pour booter sur un Kernel plus récent comme 13599 par exemple, il faut rebooter ... d'où le nom de rebooter. Avec le Reset Glitch Hack c'est complétement différent, XeLL, le hack intervient tellement tot que peut importe le kernel de la console, le hack marchera (le CB_A ne peut pas être revoqué) ... il n'y a pas besoin de rebooter mais simplement de booter. Pour lancer un Kernel MS Hacké avec le Reset Glitch Hack, il faut uniquement patcher le HV et les bootloaders au boot de la console. Pour les personnes souhaitant avoir d'avantages d'informations voici les explications Fallen93 posté sur XBH :

Ok so you use the glitch hack to bypass CB_A check, patch CB_B (if present), CD, CF and your good, I don't see what your missing here? No ms keys are required if you patch the RSA/SHA1 checks out. The checks are extreamly trivial to patch out too. CD is not the kernel CE is, CD is just what unpacks the kernel, checks for any patch slots and if they are present loads their corresponding CF slot. Also the kernel never touches any of the bootloaders during the boot process, so no patches are required to get it to boot. Once CD makes the jump to the hv reset vector, your bootloaders are never touched again. Keep in mind we are not rebooting we are just booting!

paxama escribió:La comprobacion de efuses se ejecuta antes del lv1,de echo es lo primero ke se comprueba
vdf_demon
Osea ke eso de igorarla o eliminarla esta por ver

Creo que primero deberías pasarte por aquí...
hilo_xbox-360-reset-glitch-hack-unsigned-code-on-current-kernels-incl-x360-slim_1664512

Super interesante este hilo filosofante.
Pido disculpas si salgo del tema.

Tratando de comprender los conceptos me parece plausible lo que comentan. La teoria parece indicar que la cosa es simple.

Yo hice JTAG a 2 xenon, y recuerdo que para actualizar al dash compatible con kinect el procedimiento fue sencillo, recuerdo que basto con crear imagenes con el puerquito grabarlas en una memoria USB y listo.

Claramente el metodo por los que se llega a ejecutar el xell son diferentes pero, el punto es que esta el xell con Gligli ejecutado, esto ya supone solo un pequeño salto al rebooter. Digamos.... algo asi.... Creamos imagen con puerquito, grabamos en USB, apagamos consola y desconectamos energia, conectamos USB, arrancamos consola, xell toma la imagen y la vuelca en la nand.

Easy asi lo veo yo.

vdf_demon parece ke yo estaba ekivocado pero ya veremos jejejejejeje
Estare atento
saludos

paxama escribió:vdf_demon parece ke yo estaba ekivocado pero ya veremos jejejejejeje
Estare atento
saludos

asi sera,
yo estare atenta igualmente

Bueno creo que la impaciente que estaba ya se me paso, xD, flashee mi xbox 360 con chip winbond, y ala primera salio OMG, sin errores en la lectora, lo ise con un cautin ultra finito y con las cordenadas >D, PERO SIEMPRE estoy tratando de que llevemos a cabo el kernel modificado

kvnkain escribió:Bueno creo que la impaciente que estaba ya se me paso, xD, flashee mi xbox 360 con chip winbond, y ala primera salio OMG, sin errores en la lectora, lo ise con un cautin ultra finito y con las cordenadas >D, PERO SIEMPRE estoy tratando de que llevemos a cabo el kernel modificado

Entonces se puede crear un rebooter o no . por favor contesta mi pregunta

supermasa escribió:

kvnkain escribió:Bueno creo que la impaciente que estaba ya se me paso, xD, flashee mi xbox 360 con chip winbond, y ala primera salio OMG, sin errores en la lectora, lo ise con un cautin ultra finito y con las cordenadas >D, PERO SIEMPRE estoy tratando de que llevemos a cabo el kernel modificado

Entonces se puede crear un rebooter o no . por favor contesta mi pregunta

se va poder arrancar el kernel, estoy 100% seguro que se va lograr, claro estan esperando que se le pase lo antipirateria a GliGli, o que le paguen ala gente que ya tiene experiencia en eso, solo tienen que lograr descomprimir el kernel y el HV, y arrancar el dashboard modificado ._.

supermasa escribió:

kvnkain escribió:Bueno creo que la impaciente que estaba ya se me paso, xD, flashee mi xbox 360 con chip winbond, y ala primera salio OMG, sin errores en la lectora, lo ise con un cautin ultra finito y con las cordenadas >D, PERO SIEMPRE estoy tratando de que llevemos a cabo el kernel modificado

Entonces se puede crear un rebooter o no . por favor contesta mi pregunta

No, por que no necesitamos de uno...

VDF_Demon escribió:

supermasa escribió:

kvnkain escribió:Bueno creo que la impaciente que estaba ya se me paso, xD, flashee mi xbox 360 con chip winbond, y ala primera salio OMG, sin errores en la lectora, lo ise con un cautin ultra finito y con las cordenadas >D, PERO SIEMPRE estoy tratando de que llevemos a cabo el kernel modificado

Entonces se puede crear un rebooter o no . por favor contesta mi pregunta

No, por que no necesitamos de uno...

como que no necesitamos de uno no entiendo

que aca no necesitamos rebootear nada, solo botear....

aca se llama loader

kvnkain escribió:

supermasa escribió:

kvnkain escribió:Bueno creo que la impaciente que estaba ya se me paso, xD, flashee mi xbox 360 con chip winbond, y ala primera salio OMG, sin errores en la lectora, lo ise con un cautin ultra finito y con las cordenadas >D, PERO SIEMPRE estoy tratando de que llevemos a cabo el kernel modificado

Entonces se puede crear un rebooter o no . por favor contesta mi pregunta

se va poder arrancar el kernel, estoy 100% seguro que se va lograr, claro estan esperando que se le pase lo antipirateria a GliGli, o que le paguen ala gente que ya tiene experiencia en eso, solo tienen que lograr descomprimir el kernel y el HV, y arrancar el dashboard modificado ._.

Y vos vas a segir con tu investigacion .

si claro, voy a seguir investigando, solo que ahorita me sali un poco por el hackeo que le hice a mi slim, pero siempre seguire

kvnkain escribió:si claro, voy a seguir investigando, solo que ahorita me sali un poco por el hackeo que le hice a mi slim, pero siempre seguire

entonces no te llega el chip el fin de semana

kvnkain escribió:Bueno creo que la impaciente que estaba ya se me paso, xD, flashee mi xbox 360 con chip winbond, y ala primera salio OMG, sin errores en la lectora, lo ise con un cautin ultra finito y con las cordenadas >D, PERO SIEMPRE estoy tratando de que llevemos a cabo el kernel modificado

Ya nos podemos tranquilizar, ya no corre tanta prisa parchear la Nand para cargar "Homebrew" creo que podemos desterrar este hilo al averno.

Bueno como no nos lleva a ninguna parte procedo a cerrar el hilo.

Si hay alguna novedad que aportar al respecto me avisáis y reabro el hilo.