Proyecto 1BL CB Patch 6750 - Dash - 7363 & 7371

Buena iniciativa, la veo dificil pero no se si imposible, subiria mi nand pero de todas las veces que la saque me daba error 250 en el bloque 372 y ya mejor ni lo intente sacar mas...

No hace falta subir ninguna nand tranquilo, ademas que seria ilegal ya que es codigo de m$, solamente se a de tener en el hd de cada uno, en principio tiene que dar igual el size, cualquiera con CB 6750 vale.

Si tu nand te da error en el offset 0x0250h no importa no te separes del hilo que podremos darte un rango inferior.

Hola,
que utilidad tendría?

Xploitear todas las placas indiferente del CB siempre y cuando tengan el kernel 7371

Interesante...
Entonces te deseo toda la suerte!!!!
Animo

yo me apunto! así puedo devolveros el favor que me haceis enseñandome cada día mas acerca de la xbox y el homebrew!

chechill escribió:Interesante...
Entonces te deseo toda la suerte!!!!
Animo

Gracias, pero la suerte la necesitamos todos por algo se esta pidiendo ayuda, si esto avanza y nos ponemos a ello toda aportacion es poca, recuerdalo

MetalxXx escribió:Xploitear todas las placas indiferente del CB siempre y cuando tengan el kernel 7371

entonces se podra con todas las consolas,xk hasta ahora se puede hacer downgrade,no?

Si me equivoco que me corrijan, pero ¿al tener el 1BL parcheado, no esta parcheado tambien el agujero de seguridad?

Si me equivoco que me corrijan, pero ¿al tener el 1BL parcheado, no esta parcheado tambien el agujero de seguridad?

El 1BL no esta parcheado simplemente es distinto con otra key, el agujero de seguridad se tapa cuando se actualiza por encima de 7371

fulfidor escribió:

MetalxXx escribió:Xploitear todas las placas indiferente del CB siempre y cuando tengan el kernel 7371

entonces se podra con todas las consolas,xk hasta ahora se puede hacer downgrade,no?

Vamos haber si se consiguiera la key se podrian hacer todas las consolas siempre y cuando su firmware no fuera superior al 7371, esta propuesta es para modificar las maquinas con CB no xploiteable dicho asi 6750 pero que no esten actualizadas.

Todo esto suena muy bonito y parece hecho el trabajo, en fin podemos soñar que es gratis, no es imposible pero no comencemos por el tejado, ir contestando los que quieran unirse al proyecto y empezaremos a repartir rangos.

Os gusta la idea? lo intentamos señores?

Si necesitais alguna ayuda podeis contar conmigo, aunque ahora ando cortisimo de tiempo, tengo un tuto por terminar xD

Gracias andresete, toda ayuda por pausada o por falta de tiempo sigue siendo valiosa.

Flash78 compañero si me lees necesito si puedes que me eches un cable, espero que no estes perdio por hay

Esto va por las consolas con el 7363 o el 7371 con fecha de fabricacion mayor al 16 de junio de 2009 ¿no?

guillermo2501 escribió:Esto va por las consolas con el 7363 o el 7371 con fecha de fabricacion mayor al 16 de junio de 2009 ¿no?

Si, para todas, despues de dicha fecha, siempre y cuando su kernel sea 7371 o inferior.

Contad comigo en lo que buenamente pueda ayudar.

Pero qué coño hay que hacer... es decir, yo tengo una jasper vulnerable, y necesitáis gente con jasper no vulnerable, o eso da igual?? Hay que saber de programación??

don pelayo escribió:Pero qué coño hay que hacer... es decir, yo tengo una jasper vulnerable, y necesitáis gente con jasper no vulnerable, o eso da igual?? Hay que saber de programación??

No, solamente necesitas tener una nand con CB 6750 en tu hd y un programa que en breve subire, despues asignaremos los rangos por usuarios y listo, poco mas

MetalxXx escribió:

don pelayo escribió:Pero qué coño hay que hacer... es decir, yo tengo una jasper vulnerable, y necesitáis gente con jasper no vulnerable, o eso da igual?? Hay que saber de programación??

No, solamente necesitas tener una nand con CB 6750 en tu hd y un programa que en breve subire, despues asignaremos los rangos por usuarios y listo, poco mas

Entonces cuenta conmigo. Ojalá esto se abra para TODO EL MUNDO. Mi pregunta es ahora si esto es realmente posible y cuáles son las dificultades. Sobre todo me escama que los propios descubridores del exploit no lo hayan intentado. ¿Cuáles pueden ser las razones? ¿No será que es más bien imposible?? En fin, pesimismos, al margen, insisto en que podéis contar con parte de mi tiempo para esto.

Enhorabuena por la iniciativa.

La razon es porque es casi imposible de averiguar no nos vamos a engañar, pero haciendo un llamamiento y siendo muchos usuarios podemos tardar 100 años en conseguirlo o que caiga la breva y lo consigamos en poco tiempo, creo que si nos quedamos de brazos cruzados, seguro que conseguimos nada de nada.

Por intentarlo no perdemos nada

Yo no tengo mucha idea, pero si puedo ayudar tengo una zephyr con CB 4558.
Saludos y suerte con el proyecto.

Cuenta con mi espada!

Hola, no es por desanimarte ni nada, pero voy a describirte un poco algo que deduje leyendo los foros de xbox-hacker, no se si me equivoque, pero al menos fue lo que entendi.

Una xbox 360 tiene por defecto en kernel 7371 lo siguiente:

1BL: porcion diminuta de software que comprueba la ram y la CPU (posiblemente tambien los eFuses) y lanza el 2BL que se encarga del resto

1BL Key: DD88AD0C9ED669E7B56794FB68563EFA la cual es universal para todas la consolas.

CPU Key unica: se encuentra entre 00000000000000000000000000000000 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

EFuses: son micros que se queman (graban, modifican) en tiempo real para ajustar la consola, en este caso cuando se actualiza, en algun punto (creo que por los kernels 5xxx) pusieron en black list los kernels xploiteables 4552 y 4558, por lo que se ve en el Xell, de una u otra manera tienen grabados la CPU Key.

SMC: el cual es el responsable de permitir la ejecucion actual del xploit...

cuando actualizas basicamente lo que se hace primero es actualizar el firmware (por asi decirlo) del smc (xploit perdido), posteriormente se actualizan los archivos pertinentes de la NAND, y por ultimo se quema un eFuse que pone en Black List todos los kernels anteriores, en ningun momento se ve alterada la CPU Key, ni el 1BL ...

por lo tanto para permitir el xploit en las consolas actualizadas, lo primero deberia ser crear respaldo y downgradear el SMC (esto deberia hacerse via hardware), suponiendo que el SMC no lleve comprobacion de algun componente adicional de la consola y sea universal...

luego de eso deberiamos downgradear los eFuses, ya que al tener en black list los kernels anteriores, no nos permitiria ejecutar el xploit, pues esta basado en K/4552, para hacer esto, de ser cierta mi teoria, deberiamos tener previo conocimiento de la CPU key y alguna forma de modificar los minusculos eFuses ....

Luego de eso ya podriamos aplicar el JTag en dichas consolas

MetalxXx escribió:No, solamente necesitas tener una nand con CB 6750 en tu hd y un programa que en breve subire, despues asignaremos los rangos por usuarios y listo, poco mas

Si eso es todo lo que hace falta, tienes i falcon v3 a tu disposicion

MetalxXx escribió:No, solamente necesitas tener una nand con CB 6750 en tu hd y un programa que en breve subire, despues asignaremos los rangos por usuarios y listo, poco mas

Pero explica que es lo que hace ese programa o que, como funciona...

VDF_Demon escribió:Hola, no es por desanimarte ni nada, pero voy a describirte un poco algo que deduje leyendo los foros de xbox-hacker, no se si me equivoque, pero al menos fue lo que entendi.

Una xbox 360 tiene por defecto en kernel 7371 lo siguiente:

1BL: porcion diminuta de software que comprueba la ram y la CPU (posiblemente tambien los eFuses) y lanza el 2BL que se encarga del resto

1BL Key: DD88AD0C9ED669E7B56794FB68563EFA la cual es universal para todas la consolas.

CPU Key unica: se encuentra entre 00000000000000000000000000000000 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

EFuses: son micros que se queman (graban, modifican) en tiempo real para ajustar la consola, en este caso cuando se actualiza, en algun punto (creo que por los kernels 5xxx) pusieron en black list los kernels xploiteables 4552 y 4558, por lo que se ve en el Xell, de una u otra manera tienen grabados la CPU Key.

SMC: el cual es el responsable de permitir la ejecucion actual del xploit...

cuando actualizas basicamente lo que se hace primero es actualizar el firmware (por asi decirlo) del smc (xploit perdido), posteriormente se actualizan los archivos pertinentes de la NAND, y por ultimo se quema un eFuse que pone en Black List todos los kernels anteriores, en ningun momento se ve alterada la CPU Key, ni el 1BL ...

por lo tanto para permitir el xploit en las consolas actualizadas, lo primero deberia ser crear respaldo y downgradear el SMC (esto deberia hacerse via hardware), suponiendo que el SMC no lleve comprobacion de algun componente adicional de la consola y sea universal...

luego de eso deberiamos downgradear los eFuses, ya que al tener en black list los kernels anteriores, no nos permitiria ejecutar el xploit, pues esta basado en K/4552, para hacer esto, de ser cierta mi teoria, deberiamos tener previo conocimiento de la CPU key y alguna forma de modificar los minusculos eFuses ....

Luego de eso ya podriamos aplicar el JTag en dichas consolas

me cito a mi misma ... y la verdad si el 1bl cambiara, no c de k te serviria

El problema es que los eFuses son OTP, una vez quemados no se pueden reponer.

Pero vamos a ver. Es que se está diciendo que una cosa es que el bootloader venga capado/sea distinto, y otra cosa son los efuses que se queman al actualizar. Él lo que pretende es averiguar la key del nuevo bootloader para máquinas sin actualizar posteriores al 16 de junio, en las que se supone que no ha habido quema de efuses. Es evidente que con los fuses quemados poco o nada se puede hacer, pero lo que hay que refutar es la cuestión de si conociendo la key del nuevo bootloader se puede hackear una consola posterior al 16 de junio no actualizada.

Y fijaos que a lo mejor ya lo habéis explicado, pero a mí, que soy muy ignorante del tema, me queda la impresión de que habláis de cosas distintas.

don pelayo escribió:Pero vamos a ver. Es que se está diciendo que una cosa es que el bootloader venga capado/sea distinto, y otra cosa son los efuses que se queman al actualizar. Él lo que pretende es averiguar la key del nuevo bootloader para máquinas sin actualizar posteriores al 16 de junio, en las que se supone que no ha habido quema de efuses. Es evidente que con los fuses quemados poco o nada se puede hacer, pero lo que hay que refutar es la cuestión de si conociendo la key del nuevo bootloader se puede hackear una consola posterior al 16 de junio no actualizada.

Y fijaos que a lo mejor ya lo habéis explicado, pero a mí, que soy muy ignorante del tema, me queda la impresión de que habláis de cosas distintas.

hola =)

el 1bl es universal en las consolas, el exploit nunca residio, reside, residira alli.

El exploit se encuentra en el SMC de la consola, en las actualizadas, viene en blacklist los kernels anteriores a NXE que segun entiendo es el k viene de fabrica en las mismas

VDF_Demon escribió:

don pelayo escribió:Pero vamos a ver. Es que se está diciendo que una cosa es que el bootloader venga capado/sea distinto, y otra cosa son los efuses que se queman al actualizar. Él lo que pretende es averiguar la key del nuevo bootloader para máquinas sin actualizar posteriores al 16 de junio, en las que se supone que no ha habido quema de efuses. Es evidente que con los fuses quemados poco o nada se puede hacer, pero lo que hay que refutar es la cuestión de si conociendo la key del nuevo bootloader se puede hackear una consola posterior al 16 de junio no actualizada.

Y fijaos que a lo mejor ya lo habéis explicado, pero a mí, que soy muy ignorante del tema, me queda la impresión de que habláis de cosas distintas.

hola =)

el 1bl es universal en las consolas, el exploit nunca residio, reside, residira alli.

El exploit se encuentra en el SMC de la consola, en las actualizadas, viene en blacklist los kernels anteriores a NXE que segun entiendo es el k viene de fabrica en las mismas

Entonces que se parchea en el boot loader exactamente... Bueno, en cualquier caso prefiero que no te esfuerces conmigo. Si supiera algo más allá de darle a aceptar o cancelar cuando se me pregunta "¿desea ejecutar este software?" pase, pero teniendo la idea que tengo lo más que podemos lograr es que pierdas tu tiempo, que creeme, considero bastante valioso

Veo que la cosa es más difícil que lo de los 100 años de pruebas. Y eso ya era difícil.

en el 1bl no se parchea nada .... se actualiza el codigo en el SMC y se funde un eFuse de bloqueo de CB que es muy distinto de los eFuses "normales". este eFuse se funde cuando se actualiza y viene fundido en el caso de las nuevas ...

si el valor del eFuse no corresponde, simplemente no arranca

VDF_Demon escribió:en el 1bl no se parchea nada .... se actualiza el codigo en el SMC y se funde un eFuse de bloqueo de CB que es muy distinto de los eFuses "normales". este eFuse se funde cuando se actualiza y viene fundido en el caso de las nuevas ...

si el valor del eFuse no corresponde, simplemente no arranca

Vale, esto si lo entiendo. SÍ hay quema de efuses. Nada más que añadir.

MetalxXx si he entendido bien.. la idea es conseguir meter un CB inferior y que se lo trague la consola, no ?
Es decir... que lo estarias "firmando"
Si se pudiera hacer eso... se podria firmar cualquier otra version mas antigua del CB (y podria ser un CB modificado)
Es decir... que controlarias completamente el arranque de la consola... lo que significaria que todos los modelos de 360 podrian exploitearse
Suena muy bonito, pero me temo que es casi imposible de hacer


*El SMC es el "system management controller"
Es un mini-procesador metido dentro del southbridge y controla toda la consola
Cuando tu conectas el cable de alimentacion por detras a la consola (aunque no la enciendas)... el SMC se pone a funcionar y carga un bloque de configuracion de la nand (no recuerdo si 1 bloque o 2)
En ese bloque de configuracion es donde se mete el exploit del JTAG
El SMC es el que "lanza" el ataque mediante JTAG a una posicion de la ram donde esta cargado el exploit (el exploit es el del king kong modificado)

VDF_Demon escribió:Hola, no es por desanimarte ni nada, pero voy a describirte un poco algo que deduje leyendo los foros de xbox-hacker, no se si me equivoque, pero al menos fue lo que entendi.

Una xbox 360 tiene por defecto en kernel 7371 lo siguiente:

1BL: porcion diminuta de software que comprueba la ram y la CPU (posiblemente tambien los eFuses) y lanza el 2BL que se encarga del resto

1BL Key: DD88AD0C9ED669E7B56794FB68563EFA la cual es universal para todas la consolas.

CPU Key unica: se encuentra entre 00000000000000000000000000000000 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

EFuses: son micros que se queman (graban, modifican) en tiempo real para ajustar la consola, en este caso cuando se actualiza, en algun punto (creo que por los kernels 5xxx) pusieron en black list los kernels xploiteables 4552 y 4558, por lo que se ve en el Xell, de una u otra manera tienen grabados la CPU Key.

SMC: el cual es el responsable de permitir la ejecucion actual del xploit...

cuando actualizas basicamente lo que se hace primero es actualizar el firmware (por asi decirlo) del smc (xploit perdido), posteriormente se actualizan los archivos pertinentes de la NAND, y por ultimo se quema un eFuse que pone en Black List todos los kernels anteriores, en ningun momento se ve alterada la CPU Key, ni el 1BL ...

por lo tanto para permitir el xploit en las consolas actualizadas, lo primero deberia ser crear respaldo y downgradear el SMC (esto deberia hacerse via hardware), suponiendo que el SMC no lleve comprobacion de algun componente adicional de la consola y sea universal...

luego de eso deberiamos downgradear los eFuses, ya que al tener en black list los kernels anteriores, no nos permitiria ejecutar el xploit, pues esta basado en K/4552, para hacer esto, de ser cierta mi teoria, deberiamos tener previo conocimiento de la CPU key y alguna forma de modificar los minusculos eFuses ....

Luego de eso ya podriamos aplicar el JTag en dichas consolas

Si me permites te completo la explicación con un gráfico, que creo que aclarará algunas dudas al respecto de la "Cadena de confianza" en la seguridad de la xbox 360.



Saludos

y que es lo que comprueba la versión de CB? los Efuses?

edito. He releido por lo que veo si són los efuses , la cosa estaria en generar una versión de cb 6750 partiendo de un cb6723 con un hash correcto a tu cpu-key entonces bootearia , una especie de timming atack lo unico malo es que ese bug ya está tapado , y generar ese hash a fuerza bruta consola por consola seria casi impracticable o no?

EDITO2 sospecho con el pecho que los efuses que vienen fundidos de fabrica con las consolas con CB6750 son los que bloquean el dash 45XX justamente el dash en el que está basado el xbrebooter siendo cierta mi sospecha no bastaria con mi anterior teoria si no que una consola de las que vienen con cb6750 equivaldria a una actualizada a 8955 sin exploit.

El anterior mensaje lo puse porque no acabo de entender la idea que propone MetalxXx, no pretendia cargarme el hilo
La explicacion del SMC fue porque vi que VDF_Demon tenia alguna duda en algunos detalles, pero lo que ha dicho esta bien en general (que lista eres jodia)
Aunque hay muchos detalles dificiles de entender y de explicar (yo al menos tengo unas cuantas dudas), asi que es posible que haya algun error en lo que esta escrito aqui (me incluyo yo el primero)

Mas explicaciones ayudandome de el grafico que ha puesto bpSz
El 1BL ejecuta una serie de operaciones sobre un area del CB (a ese area vamos a llamarlo... la firma del CB)
En el caso de que el CB pase correctamente esa comprobacion... se devuelve la orden a la CPU "este CB es valido, y es la version 1234"
En ese momento, se verifica la linea 2 de los efuses, para saber si esa version del CB devuelta (1234) es una de la "lista negra"
Si todo esto da resultados positivos... se ejecuta CB, que a su vez hace una comprobacion sobre CD, y se continua con el arranque (CD--->CE)

Se puede decir que el 1BL comprueba la firma del CB.... y la linea 2 de los efuses es la "lista negra" de los CB bloqueados por microsoft
Al igual que las lineas de efuses 7, 8, 9, 10, y 11 son la "lista negra" de los CF y CG (Supongo que esta "lista negra" de los CF y CG se comprueba en el momento de cargar CF o CG)

CD es el "cargador" del kernel base, efectua una serie de operaciones para que la consola este preparada para cargar el CE
CE es el kernel base (1888) y el hypervisor, los 2 "incrustados" en un solo archivo (e inseparables, lo que significa que es imposible eliminar el hypervisor)
CF y CG son 2 "slots" disponibles para almacenar las versiones del kernel nuevas que vayas instalando (en realidad son parches como explico mas adelante)
Los updates del kernel se almacenan en CF y CG alternativamente, es decir.... si la primera vez que actualizaste el update se metio en CF.... la siguiente vez que actualizaste el nuevo se metio en CF
En este ejemplo, cuando enciendes la consola acabas en CG (pero tienes un kernel antiguo en CF que podria ser cargado en el caso de que hubiera algun error al intentar cargar CG)
Es una especie de "backup" para evitar que la consola quede estropeada por un fallo grave (principalmente cuando haces un update donde se reemplazan archivos inportantes)

El kernel base siempre es cargado y esta en todas las consolas (es el primero que salio con la primera version de la consola)
Los parches CF y CG se aplican sobre el kernel base (por ejemplo... 7371 seria un parche que se aplica sobre 1888 siempre que enciendes la consola)



Un ejemplo de los efuses (inventados, basandome en los mios)

CPU Fuses
fuseset 00: c0ffffffffffffff <---- ?¿?¿
fuseset 01: 0f0f0f0f0f0f0ff0 <---- modelo de la consola (fija, valor binario) modelo devkit, retail, etc... ?¿?¿
fuseset 02: 0f00000000000000 <---- CB LDV (variable, acumulativa, 1 efuse quemado por cada CB nuevo, valor binario)
fuseset 03: b3c4954c399342b8 <---- cpu key (fija, valor hexadecimal)
fuseset 04: b3c4954c399342b8 <---- cpu key (duplicada por seguridad y fija, valor hexadecimal)
fuseset 05: 23d45df31b7603e7 <---- cpu key (fija, valor hexadecimal)
fuseset 06: 23d45df31b7603e7 <---- cpu key (duplicada por seguridad y fija, valor hexadecimal)
fuseset 07: ffff000000000000 <---- CF LDV (variable, acumulativa, 1 efuse quemado por cada CF o CG nuevo, valor binario)
fuseset 08: 0000000000000000 <---- CF LDV (reservados para futuros CF, valor binario)
fuseset 09: 0000000000000000 <---- CF LDV (reservados para futuros CF, valor binario)
fuseset 10: 0000000000000000 <---- CF LDV (reservados para futuros CF, valor binario)
fuseset 11: 0000000000000000 <---- CF LDV (reservados para futuros CF, valor binario)

*LDV = lockdown value = bloqueo de las versiones anteriores

Edit:
Creo que hay un error en las lineas 0 y 1 de efuses en el ejemplo que he puesto (no estoy seguro)
La linea 0 seria el modelo de consola, y la linea 1 seria otro CB LDV

ahhhmmm nu suy lista ..... yo tube la misma idea de downgrade pero en este caso de SMC e indage sobre ello, en mi opinion, el proceso de carga que mencionas es realizado por el 2BL, ya que el 1BL al estar embedido en el CPU, debe ser un archivo lo mas diminuto posible, dado los costes que implica poner un archivo en el cpu

Heeheh, es que es raro ver a una chica que se interese en estos detalles pero se te da bien
Es dificil encontrar toda esta informacion, porque suele estar por ahi esparcida

El 1BL solo son 32KB, y como esta metido en la CPU no se puede cambiar (ni engañar hasta que alguien demuestre lo contrario)
Y el 1BL carga el 2BL (CB) que esta en la nand... asi que el CB es lo maximo que podemos aspirar a modificar, si controlas el CB controlas todo lo demas en cualquier placa base (a estas alturas estoy seguro que no les costaria mucho hacer un CB completamente modificado)

Y el bloque de configuracion del SMC... parece ser que se lo traga el SMC sin ejecutar ninguna comprobacion de seguridad sobre el
No hace falta downgradearle, la info de configuracion de ese bloque ya la tienen controlada (no se si completamente)
Es informacion sobre los sensores de temperatura, ventiladores y cosas asi de partes del hardware
No tiene mucha importancia, por eso no tiene mucha seguridad (aunque los hackers lo han sabido aprovechar para meter su codigo)
Lo mas gracioso del exploit es que el SMC es el que hackea la consola (se hackea a si misma)

Aqui hay un tocho de texto enorme (muy tecnico) pero con mucho detalle sobre como funciona el exploit... y tambien explican partes del arranque, es lo mas detallado que hay (es el texto de la explicacion "oficial" del exploit)
http://free60.git.sourceforge.net/git/g ... cc;hb=HEAD


Y para seguir con el hilo...
El ultimo intento que he visto de un ataque al CB... es este hilo http://www.xboxhacker.org/index.php?topic=8478.0
*Sobre todo los ultimos mensajes de cjack... donde explica su intento de "glitch attack"
Resumen:
El 1BL ejecuta una comprobacion de seguridad sobre el CB... luego el CB "devuelve" a la CPU la orden "comprobacion correcta" (o incorrecta)
En ese momento es cuando se hace el glitch attack, interceptando la orden de vuelta mediante diferentes formas
Lo que esta intentando cjack es cambiar la frecuencia de la CPU exactamente en ese momento (relentizandola o acelerandola, o apagandola, etc...)
La idea es que la respuesta de vuelta nunca llegue a la CPU... eso lo interpretaria la CPU como que la comprobacion fue correcta

que acaso ya murio el proyecto o que??

Si necesitais tengo extraida la Nand de una Jasper v.4 16MB con CB 6750 y Patch 1 a Kernel 7371.

un Saludo,

yo tengo una jasper de octubre 2009 con kernel 7371 ( vino con 7363 creo que era ).
No controlo mucho del tema pero si al final puedo ser util, decid algo.

Yo no tengo ninguna nand de una jasper, pero si tengo la nand de un Zephyr que vino del sat con CB 4578 y CD 8453. Pero de todas maneras aqui me teneis para lo que haga falta.

Siento haber estado ausente unos dias

VDF_Demon escribió:ahhhmmm nu suy lista ..... yo tube la misma idea de downgrade pero en este caso de SMC e indage sobre ello, en mi opinion, el proceso de carga que mencionas es realizado por el 2BL, ya que el 1BL al estar embedido en el CPU, debe ser un archivo lo mas diminuto posible, dado los costes que implica poner un archivo en el cpu

Cierto que ella es realista y penso y como bien dice indago el tema, la carga esta claro que pasa primero por el 1BL supuestamente intocable, los fuses marcados que os quede claro que el XBR engaña dandole los valores correctos a la CPU supuestamente quemados,
cuando nuestro dash si es vulnerable no lo estan, con el 1BL pasa exactamente lo mismo, los efuses continuan ojo siempre y cuando nuestro dash siga siendo vulnerable, pero el 1BL los enmascara, yo en su dia ya comente que esto era solamente para maquinas con dash vulnerables pero con CB no exploitables.

Hola, tengo un par de dias, siguiendo el hilo de este tema, y si les sirve de algo, tengo una jasper, con dash 7363 y cb 6750, a la cual por descuido le queme la placa del lector, y me he quedado sin equipo, pues no habia extraido la key, saque la nand, y para mi sorpresa tenia el cb 6750, asi que no tengo equipo, hasta que se encuentre una solucion a poder ver la dvd key por xploit, si les sirve de algo, solo diganme en que puedo serles util

A sus ordenes.

Avillaman

Avillaman escribió:Hola, tengo un par de dias, siguiendo el hilo de este tema, y si les sirve de algo, tengo una jasper, con dash 7363 y cb 6750, a la cual por descuido le queme la placa del lector, y me he quedado sin equipo, pues no habia extraido la key, saque la nand, y para mi sorpresa tenia el cb 6750, asi que no tengo equipo, hasta que se encuentre una solucion a poder ver la dvd key por xploit, si les sirve de algo, solo diganme en que puedo serles util

A sus ordenes.

Avillaman

No es por desilusionarte, pero intenta a todas reparar la placa del lector o llevalo a un sitio especializado y que logren extraerle el firm del lector aunque sea desoldando la flash y luego con la key intenta comprar cualquier otro lector y spofealo e injecta tambien tu key.

Lo que se habla en este hilo son suposiciones y teorias, que a corto plazo no daran su fruto, de todas formas si quieres colaborar podras hacerlo independientemente de haber reparado tu consola.

MetalxXx si he entendido bien.. la idea es conseguir meter un CB inferior y que se lo trague la consola, no ?
Es decir... que lo estarias "firmando"
Si se pudiera hacer eso... se podria firmar cualquier otra version mas antigua del CB (y podria ser un CB modificado)
Es decir... que controlarias completamente el arranque de la consola... lo que significaria que todos los modelos de 360 podrian exploitearse
Suena muy bonito, pero me temo que es casi imposible de hacer

Por hay van los tiros, claro esta sin firma sobre el LB1 ya que es imposible al dia de hoy, ademas ya os digo de antemano que placas con kernel superior al 7371 podeis iros olvidando, por lo menos con este metodo.

El CB de una Xenon con la nand orig, lo encontramos en hexadecimal abriendo el archivo con winhex, ej nos vamos al offset 8402 y lo convertimos a Dec, nos da el valor exacto del CB, y con esta formula cualquier placa al dia de hoy, fijaros si abrimos cualquier XBR o cualquier Xell, en fin

Gracias y un saludo

Puedes explicarlo con mas detalle? la verdad es que no acabo de entender como quieres hacerlo funcionar
Si tu cambias un solo byte en el editor hexadecimal.... ya queda todo invalidado
Y como quieres hacer las pruebas? escribiendo en la nand cada CB modificado hasta que funcione?

Si no quieres explicarlo me parece bien... pero creo que esto es mas que imposible... apoteosico

Sandungas escribió:Puedes explicarlo con mas detalle? la verdad es que no acabo de entender como quieres hacerlo funcionar
Si tu cambias un solo byte en el editor hexadecimal.... ya queda todo invalidado
Y como quieres hacer las pruebas? escribiendo en la nand cada CB modificado hasta que funcione?

Si no quieres explicarlo me parece bien... pero creo que esto es mas que imposible... apoteosico

No pretendo cambiar un solo byte, era tema ironico, solamente mencionaba el offset donde se encuentra el CB y su numeracion para convertirla a dec y saber si es exploiteable, de todas formas comento que aqui hay gato encerrado y si es posible poder cambiar una cadena de instrucciones, pero vamos por partes.

MetalxXx escribió:...y un programa que en breve subire...

He vuelto a leer el hilo y sigo sin pillarlo, tendre que esperar a ver lo que hace el programa

Sandungas, desgraciadamente me temo que nuestro compadre no ha caído en que las consolas con el CB actualizado ya tienen los fuses quemados en consecuencia... Desgraciadamente me temo que su idea es inviable .


...Si fuera tan fácil

Keihanzo escribió:Sandungas, desgraciadamente me temo que nuestro compadre no ha caído en que las consolas con el CB actualizado ya tienen los fuses quemados en consecuencia... Desgraciadamente me temo que su idea es inviable .


...Si fuera tan fácil

EDITO: Miento ya que si vienen quemados todos los fuses menos al parecer x03x04x05x06 que contiene la CPU Key - fuses 0x0-0x1-0x2 los proximos no los altera el cambio.El CB solamente enmascara y la actualizacion tapa el Xploit, segun mis fuentes y datos extraidos de xbox-scene, vuelvo a recordar que esto es solamente viable a dicha actualizacion maximo 7371.

Por cierto nadie dijo que fuera facil, es mas lo vuelvo a comunicar, si hacemos esto es por hobby y por apredender pero que nadie se crea que vamos a besar el santo a la primera de cambio.