Timing attack! explicacion tecnica

Archivado
Explicacion Chusquera en Español (agradezco correcciones):

Leer primero: proceso de arranque de X360 en el wiki
http://www.elotrolado.net/wiki/Proceso_Arranque_Xbox_360

La NAND desde donde se carga el kernel en la X360 contiene tanto el kernel a cargar como un 'kernel de backup'. el kernel de backup se carga si el kernel mas actualizado se encuentra defectuoso o alterado (vamos, que no pasa el chequeo de firma)
en las X360 antiguas, el kernel de backup es el 1888 (por lo menos, en la mia asi es) o alguno de los 'preburn-fuse' (kernels vulnerables con el bug del hipervisor).
puesto que cuando el kernel actual falla la comprobacion de firmado, se procede a cargar el kernel de backup, y puesto que dicho kernel de backup NO PUEDE SER CARGADO por el fuse quemado, la consola se BLOQUEA.
El timing attack se aprovecha de este proceder para, por fuerza bruta, dar con una firma VALIDA que pase el chequeo, y asi cargar, un kernel VULNERABLE aun con un fuse quemado.
- se coge un kernel con bug del hipervisor.
- se modifica para que no importe que tenga un fuse quemado
- se mete en un emulador de NANDs y se empiezan a probar con diversas firmas. (por ejemplo, firma 00 00 00 00)
- se testea EL MOMENTO en el que falla la firma (por eso lo de 'timing attack')
- segun el momento justo en que falla la firma, sabemos 'aproximadamente' en que bit ha fallado la firma, cambiamos ese bit, y reseteamos la consola.
- seguimos haciendo timing attack hasta que la consola arranque con un kernel vulnerable.
- cargamos KingKing (abreviado en casi todos sitios como KK) con linux, y sacamos la KeyVault (abreviado como KV) y la CPUKey (abreviado como CK).
a partir de aqui, la consola en nuestra. con el KV y la CK podemos cargar CUALQUIER KERNEL, con CUALQUIER CONFIGURACION DE FUSES e incluso DESBANEAR LA CONSOLA (esto aun sin confirmar).


Fuentes originales en ingles.

------------------------------

Here is the proposed sequence (correct me if I get this wrong):

1) Dump the flash from a post 4552 box
2) Modify the fuse count in the flash image to allow the original firmware to boot (1888)
3) Corrupt the 4552 update in the flash image
3) Find the hash value (16 bytes) for the modified flash
a) program the flash with 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 for the key (and correct ECC bytes)
b) boot 360 and measure time to failure code
c) program the flash with 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d) boot 360 and measure time to failure code
.
.
.
e) if time to failure is 2.2uS longer, remember the first key byte and start interating on the second key byte

--------------------------------------------

Done it! My bricked box - one blown eFuse but no CPU key and no valid flash dump that would boot (I did have a valid 2241 dump though that would no longer boot because of the eFuse) - is now alive and well and booting 2.0.1888 with a patched CB (LD count = 1) and a "guessed" hash. Even doing it "manually" only took 3 evenings ;) Now, sleep

Just to be clear, the timing attack will allow you to downgrade to 2.0.1888. You can then upgrade to 4532 & run the KK sploit and obtain your CPU keys. You should be able to replace the original CB after the upgrade (this needs to be confirmed) and then the only "clue" to what happened is that you may have 1 or 2 more burned eFuses for the HV/Kernel version you are running

-----------------------------------------

I'm using the Infectus chip (with a dll interface provided by them) to rewrite one NAND block with sequential hash guesses. The process takes approx 1 second. The Hynix data sheet quotes a 100,000 read write cycles, our worst case is 4096 or 4%. Since this is a one time operation I think 4% wear is acceptable.
Some PIC processors have CCP modules that allow an internal 16 bit counter to be sampled when a +ve or -ve edge is detected, the counter is claimed to have a 50nS resolution although I'm not convinced ;) Simple software in the PIC allows me to detect the end of CE and the POST port changing from 0x21 => 0xA4 (the end of hashing). The PIC also drives the JTAG reset line. A couple of cheap interface ICs and some passives complete the design - you will definitely be able to build your own hardware from easy to obtain parts, on stripboard, for around 20 Euros.
Controlling all this is some PC software that can generate the required CB section patch, control the infectus and the PIC. It would seem that the "cycle" time should be less than 3 seconds. To test this I am using the 360 I "bricked" at christmas, I don't know the CPU key for this box so I cant "cheat" and test each correctly "guessed" hash byte.

Once I finish testing I will post more info followed by a complete, open source package of hardware and software so you can build your own in a few hours. Now might be a good time to get that infectus chip.

One final point, a lot of the people who want to downgrade will probably have recent versions of the applications (dash, media player etc etc). Some of the latest dashes definitely completely replaced the dash.xex (and possibly others) rather than write new xexp files. These newer versions of the applications definitely require newer system libs and I doubt they will boot on a 2.0.1888 machine. We will need to obtain an image of a clean 2.0.1888 file system.

-----------------------------------------------

The timing attack does not try to "bruteforce" the cpu key itself. It tries to find/bruteforce a hash value which is a result of the usage of the cpu key (so even if you have that hash you still cannot backwards compute the cpu key). But finding this hash value (I usually refer to it as the CB-auth value) will enable the xbox to boot the original kernel (v 1888). This then allows you to upgrade to a vulnerable kernel (eg 4532) and THEN you can extract the cpu key using the kk exploit.

The real NAND flash memory contains several sections. Sections are referred to as CB, CD, CE, CF etc (also SMC and KV). The CB section contains (among many other things) the 16 bytes CB-auth value. But because we want to change the CB-auth value each time we boot we somehow have to make sure that when the CPU reads the 16 bytes in the CB section from the NAND we (sneakly) take over with a nand emulator. This is some electronics that behaves like a NAND but is not. The reason we do is because its easier/faster/better to change bytes in the nand emulator than to change bytes in the nand flash itself (which may also break if you flash it too many times).

So the nand emulator makes sure 1 byte (of the 16 bytes) changes each time the xbox boots. And since we already got the electronics/chip -to emulate the nand- we also use this (programmable) electronics/chip to automatically reset and measure time. This makes an easier design.

From a hardware perspective this means that the programmable electronics/chip has soldering connections to the real nand flash (since it has to be able to "take over"), to the reset "button" to reboot (recently found and tested) and to the connections on the cpu that signify an error or a boot state. That way it can measure between two points in the boot sequence: 1) just before the error is detected 2) just after the error is detected. This means our guessed CB-auth 16 bytes are compared byte-by-byte with the real one (only known by the cpu) and a difference is found at one of the 16 bytes. And if it takes 2,2 micro seconds longer between these points in the boot sequence we know we have found another valid CB-auth byte.

Since -on average- you will find the correct value at roughly half of the possible byte values you only need to try (approx) 128 values for each of the 16 bytes. Thats why vax is talking about 16 * 128 total number if byte changes...
There is a theoretical minimum to the reboot time of about 1 second. So in theory you could find the 16 bytes in 34 minutes. Thats probably not gonna happen. Grin And installing the hardware will probably take even more time so its not a really big issue. But this is basically where the time speculations are based on.
Lástima que esto no este al alcance de todo el mundo por su dificultad, sino me podría manos a la obra.

Salu2. Y Gracias por toda la información que estas posteando.
Alguien puede dejarlo traducido a nuestro idioma? yo es que del ingles no paso del hello y fuck X-D
Modo Paja mental - On

Con este nuevo avanze no se podria crear un chip que tuviera una copia de la flash y q se hicieran sobre esa copia los cambios. Esta claro q el chip tendria q ser el encargado de cambiar los efuses para poder arrancar con un firm antiguo (vulnerable) o uno nuevo.

Modo Paja mental - Off

Perdonar si es una parida pero es q se me acaba de ocurrir y queria comentarlo al mundo :) .
Un grandisimo avance, ahora estamos mucho mas cerca de tener scene real en nuestra xbox360, esto hara que mucha mas gente pueda tener acceso a una consola con kernel vulnerable y por tanto mucha mas gente trasteando con la consola.
Yo creo que esto es tan importante como el descubrimiento del k-xploit de la psp.
Enorme notición.

Por lo q puedo entender el proceso es bastante manual y pesado, pero no dudo q con esta puerta abierta se aligeren las cosas.

salu2 y a la espera de avances me quedo
hay algun tutorial en español a mano por algun lado?

salu2 y gracias
Ackman escribió:hay algun tutorial en español a mano por algun lado?


por el momento creo q donde hay mas información técnica sobre este down en español es en este mismo hilo...xD, habrá q esperar
Xc@t escribió:

por el momento creo q donde hay mas información técnica sobre este down en español es en este mismo hilo...xD, habrá q esperar


ya me lo imaginaba... pero solo queda esperar XD

entre el reparador de bricks de PSP y este downgrade de 360 toi mas contento que unas castañuelas XD

salu2
Ackman escribió:
ya me lo imaginaba... pero solo queda esperar XD

entre el reparador de bricks de PSP y este downgrade de 360 toi mas contento que unas castañuelas XD

salu2


Jajajajaja, así estamos todos, yo más que nada con el tema de la PSP que a más de un amigo le voy a dar una alegría pero esto de la 360 también viene de perlas ya que si es cierto el desbaneo... va a dar mucho que hablar este Timing Attack!.

Salu2.
Una pregunta, con la tarjeta xd se puede poner cualquier versión del dashboard y volver a la vulnerable?
Si es así es un chollo [angelito]
Pues yo si alguien encuentra algo en español k este decentillo lo pruebo en mi consolo y os cuento lo del desbaneo. Pork esk mi ingles es de pena.... [chiu]
Dejo una traducción del árticulo de Xbox-Scene. También dejo el original en inglés porque puede haber partes que la traducción no sea muy buena (principalmente las partes más técnicas).

"Xbox Scene" escribió:>> Robinsod managed to successfully boot his Xbox360 with one flashed eFuse with kernel 1888 using the timing attack we talked about some weeks ago. It's not something everyone out there can do yet, but as more information gets released (it's an open source project :)) and things get optimized and developed further it might open homebrew and linux for the Xbox360 on a much larger scale soon. Of course once your 360 is back to an (older) vulnerable kernel (4532,4548), you won't be able to go on LIVE anymore (it only accepts the latest kernel (5766 atm)) ... but a dual kernel system is a possibility (using a xD memory card even).

From Robinsod on XBH:
Done it! My bricked box - one blown eFuse but no CPU key and no valid flash dump that would boot (I did have a valid 2241 dump though that would no longer boot because of the eFuse) - is now alive and well and booting 2.0.1888 with a patched CB (LD count = 1) and a "guessed" hash. Even doing it "manually" only took 3 evenings ;) Now, sleep

Just to be clear, the timing attack will allow you to downgrade to 2.0.1888. You can then upgrade to 4532 & run the KK sploit and obtain your CPU keys. You should be able to replace the original CB after the upgrade (this needs to be confirmed) and then the only "clue" to what happened is that you may have 1 or 2 more burned eFuses for the HV/Kernel version you are running


Here's a bit more info about his "proof of concept" downgrader hardware:
I'm using the Infectus chip (with a dll interface provided by them) to rewrite one NAND block with sequential hash guesses. The process takes approx 1 second. The Hynix data sheet quotes a 100,000 read write cycles, our worst case is 4096 or 4%. Since this is a one time operation I think 4% wear is acceptable.
Some PIC processors have CCP modules that allow an internal 16 bit counter to be sampled when a +ve or -ve edge is detected, the counter is claimed to have a 50nS resolution although I'm not convinced ;) Simple software in the PIC allows me to detect the end of CE and the POST port changing from 0x21 => 0xA4 (the end of hashing). The PIC also drives the JTAG reset line. A couple of cheap interface ICs and some passives complete the design - you will definitely be able to build your own hardware from easy to obtain parts, on stripboard, for around 20 Euros.
Controlling all this is some PC software that can generate the required CB section patch, control the infectus and the PIC. It would seem that the "cycle" time should be less than 3 seconds. To test this I am using the 360 I "bricked" at christmas, I don't know the CPU key for this box so I cant "cheat" and test each correctly "guessed" hash byte.

Once I finish testing I will post more info followed by a complete, open source package of hardware and software so you can build your own in a few hours. Now might be a good time to get that infectus chip.

One final point, a lot of the people who want to downgrade will probably have recent versions of the applications (dash, media player etc etc). Some of the latest dashes definitely completely replaced the dash.xex (and possibly others) rather than write new xexp files. These newer versions of the applications definitely require newer system libs and I doubt they will boot on a 2.0.1888 machine. We will need to obtain an image of a clean 2.0.1888 file system.


More useful information by Arnezami explaining the attack:
The timing attack does not try to "bruteforce" the cpu key itself. It tries to find/bruteforce a hash value which is a result of the usage of the cpu key (so even if you have that hash you still cannot backwards compute the cpu key). But finding this hash value (I usually refer to it as the CB-auth value) will enable the xbox to boot the original kernel (v 1888). This then allows you to upgrade to a vulnerable kernel (eg 4532) and THEN you can extract the cpu key using the kk exploit.

Since -on average- you will find the correct value at roughly half of the possible byte values you only need to try (approx) 128 values for each of the 16 bytes. Thats why vax is talking about 16 * 128 total number if byte changes...
There is a theoretical minimum to the reboot time of about 1 second. So in theory you could find the 16 bytes in 34 minutes. Thats probably not gonna happen. Grin And installing the hardware will probably take even more time so its not a really big issue. But this is basically where the time speculations are based on.



Robinson consiguió arrancar su Xbox360 con un eFuse fundido y con kernel 1888 usando el timing attack del que hablamos hace unas semanas. No es algo que cualquiera pueda hacer aun, pero una vez que se obtenga más información (esto es un proyecto de código abierto :) ) y todo se optimice más, podría abrir las puertas del homebrew y linux a gran escala muy pronto. Por supuesto, una vez que tu 360 tiene un kernel vulnerable (más antiguo) no podrás seguir conectándote al Live (ya que sólo se puede con el último kernel, 5766 en este momento)... pero un sistema de kernel dual es una posibilidad (usando incluso una tarjeta de memoria xD).


De Robinson en XboxHacker:

Conseguido. Mi consola brickeada -un eFuse fundido y sin la CPU key ni un dump válido de la flash con la que arrancarla (tenía un dump de la versión 2241 pero no funcionaría por culpa del eFuse)- está ahora sana y salva arrancando con una versión 2.0.1888 con un CB parcheado (la cuenta LD a 1) y un hash inventado. Incluso haciéndolo "manualmente" sólo me llevó 3 tardes ;). Ahora a descansar.

Para dejarlo claro, el timing attack permitirá el downgrade a la versión 2.0.1888. Entonces puedes actualizar a la versión 4532 y ejecutar el exploit KK y obtener las CPU keys. Una vez hecho esto ya se podría reemplazar el CB original después de actualizar (esto está todavía por confirmar) y el único rastro de lo que habría pasado serían 1 o 2 eFuses quemados para la versión de Kernel que estás ejecutando.



Aquí hay un poco más de información sobre esta prueba de concepto del downgrader:

Estoy utilizando el chip Infectus (con una interfaz dll obtenida de ellos) para reescribir un bloque de la NAND con hashes secuenciales inventados. El proceso dura aproximadamente 1 segundo. Según las especificaciones de Hynix soporta hasta 100.000 ciclos de lectura - escritura. En nuestro peor caso necesitariamos 4096, lo que es el 4%. Teniendo en cuenta que solo hay que hacer esta operación una vez creo que un 4% es bastante aceptable.

Algunos PIC tienen modulos CCP con un contador interno de 16 bits que cambia cuando detecta un pico de tensión positiva o negativa. El contador se supone que tiene una precisión de 50ns aunque no estoy yo muy seguro ;). Con un sencillo programa en el PIC me permite detectar el final del CE y el puerto POST cambiando de 0x21 a 0xA4 (fin del hashing). El PIC tambien controla la línea de reset del JTAG. Con un par de interfaces ICs y algunas resistencias tenemos hecho nuestro diseño -podrás construir tu propio hardware con componentes fáciles de conseguir, y que te costarán unos 20 Euros-.

Se puede controlar todo esto con un programa de ordenador que pueda generar la sección CB necesaria, controlar el infectus y el PIC. Cada "ciclo" debería de durar algo menos de 3 segundos. Para probarlo yo estoy usando la 360 que brickeé en navidades. No sé la CPU key de esta consola así que no puedo probar con los bytes correctos del hash.

Una vez que acabe las pruebas postearé más información además de un paquete open source del hardware y el software para que podáis construirlo vosotros en unas pocas horas. Ahora podría ser un buen momento para conseguir ese chip Infectus.

Una cosa más, mucha de la gente que quiera hacer el downgrade probablemente tendrán versiones actuales de las aplicaciones (el dash, media player, etc, etc). Algunos de los últimos dash reemplazaron completamente el dash.xex en lugar de escribir nuevos ficheros xexp. Estas nuevas versiones seguramente necesitarán nuevas versiones de las librerías del sistema y dudo que puedan arrancar en una consola con el 2.0.1888. Necesitaremos obtener una imagen limpia de los ficheros del sistema de un 2.0.1888.



Más información útil de Arnezami explicando el ataque:

El timing attack no intenta encontrar la CPU key por fuerza bruta exactamente. Intenta encontrar un hash que es el resultado de usar la CPU key (así que incluso si tienes ese hash no puedes calcular la CPU key). Pero encontrar este hash (normalmente me refiero a él como CB-auth) te permitirá arrancar tu Xbox con un kernel 1888. Esto entonces te permitirá actualizar a un kernel vulnerable (por ejemplo el 4532) y luego extraer la CPU key usando el exploit KK.

Entonces teniendo en cuenta que de media para encontrar el valor correcto de cada byte necesitarás probar 128 valores (la mitad de los posibles valores) y que son en total 16 bytes, es por eso que vax hable de 16 * 128 intentos para encontrar el hash correcto.

Considerando un mínimo teórico de 1 segundo para cada reboot, se podrían encontrar los 16 bytes en unos 34 minutos. Como montar e instalar el hardware llevará incluso más tiempo, ese tiempo no es muy significativo. Pero esto es básicamente en lo que están basadas las especulaciones sobre el tiempo.
.
Una pregunta:

¿Por que pensais que esto nos quitara el baneo?

o no recordais que la secene de la XBOX era mas grande, y la gente baneada, baneada se quedo...

Tios olvidaros del desbaneo, y os digo que yo lo estoy, esto es un noticion por que el homebrew se ve ya muy cerca, y eso es una puerta muy grande...

Emuladores, Linux, Divx, Musica...

Para jugar online, a pillar otra nueva.
erpuche escribió:Una pregunta:

¿Por que pensais que esto nos quitara el baneo?

o no recordais que la secene de la XBOX era mas grande, y la gente baneada, baneada se quedo...

Tios olvidaros del desbaneo, y os digo que yo lo estoy, esto es un noticion por que el homebrew se ve ya muy cerca, y eso es una puerta muy grande...

Emuladores, Linux, Divx, Musica...

Para jugar online, a pillar otra nueva.


En la anterior Xbox si te podias desbanear, solo habia que rescribir la eprom o al menos la parte del munero de serie con una que no estuviera baneada (de consolas rotas o algo asi), yo incluso tengo 2 xbox con la misma eprom, de manera que las partidas guardadas/contenido-descargable de una siempre me valen en la otra aunque vinieran firmadas. Eso si, no se pueden conectar las 2 al live simultaneamente porque te banean ese numero de serie y vuelta a empezar.
Si depuran este metodo tendremos scene en toda regla para nuesta blanquita.

No olvidemos que por ahora sólo existe linux (que ya es bastante) pero ya se estaba trabajando en un port del mame si no recuerdo mal y muchas cosas más.

A mi modo de ver en un futuro cercano sacaran un chip con dual flash al igual que en psp ahora que ya se ha roto la protección de la flash, el unico problema que le veo es que es algo complicado para un usuario medio obtener la que pero ya depuraran el sistema.

El mundillo de la scene en las consolas lleva una semana frenetica con la Ps3, Psp y Xbox360 tres fallos de seguridad bien gordos que daran de que hablar en los proximos meses.
El proceso es tedioso, solo queda depurarlo. Teniendo el agujero se da paso a los maestros y en pocas semanas empezaran a aflorar grandes nombres en la scene de xbox360.

Este día debería pasar a la historia.
Me parece que el proceso es tedioso...pero no tanto como cabria esperar. No hace falta desoldar la nand ni nada por el estilo y la busqueda del hash me parece q se puede llegar a automatizar bastante (el habla de un pic para detectar cuando falla la firma y q resetee automaticamente). Por lo que dice el chip podria consistir en una especie de Infectus con un pic para detectar cuando falla la firma y calcular el bit q fallo y algun modo de conexcion a un ordenador (usb por ejemplo) para controlar el proceso (realmente creo q solo haria falta para meter el firm modificado para q no afecten los efuses). Por lo tanto no creo q tarden mucho en sacar algo. A los que dicen q esta scene no sera como la de la anterior xbox por no tener el SDK...puede que no sea tan prolifica como aquella pero recordar que tenemos linux y aunque no es q ese S.O. sea santo de mi devocion (me harte de el en mi trabajo jejejeje) gracias a el tenemos un monton de herramientas de programacion que ayudaran bastante. Lo ideal seria poder hacer un arranque dual. Algo parecido a lo que hay del lector de tarjetas para poder arrancar con un firm u otro.
no creas...al final se basa en soldar un infectus con un emulador de NAND y una epprom y dejar encendida la consola media horita. media hora- 2 horas mas tarde (sucede de forma aleatoria, fuerza bruta) tienes un kernel que pasa la firma y tras el cual puedes sacar la CPUKey y la KeyVault.
Sauron-Jin escribió:
En la anterior Xbox si te podias desbanear, solo habia que rescribir la eprom o al menos la parte del munero de serie con una que no estuviera baneada (de consolas rotas o algo asi), yo incluso tengo 2 xbox con la misma eprom, de manera que las partidas guardadas/contenido-descargable de una siempre me valen en la otra aunque vinieran firmadas. Eso si, no se pueden conectar las 2 al live simultaneamente porque te banean ese numero de serie y vuelta a empezar.


Hacer esto, y pillar una nueva es lo mismo, porque en la Xbox 1 ... si, podias pegarte la matada de hacer ese procedimiento, pero y? para eso intercambiabas la maquina y tan contentos, justo lo mismo que ahora.

Y por cierto, os recuerdo ... que curiosamente cuando llamais y dais vuestro numero de serie, saben si tienes o no garantia (osease, si estas o no baneado ...), por lo tanto, ya podeis hacer milagros que ESE numero de serie ya no entra en el Live.

Y sinceramente, dejar sin Live OTRA consola para conseguir entrar con una ya baneada, es banear una por otra, por lo tanto? comprar otra y todos mas contentos.

Por otro lado, es necesario el Infectus para todo este movidon? porque de ser asi, ya tardo en pillar unos cuantos.
edy, el tema esta en que con el keyvault, puedes cambiar el numero de serie por uno que te salga del mandril y ESE no estara baneado por MS.

y no, aun no te pilles los infectus. pillate dos o tres, por si hay que hacer pruebas, pero teoricamente sacaran un modchip especial que hara todo el proceso de forma automatica, te permitira cargar el kernel vulnerable, sacara el keyvault el solito y te permitira meter cualquier kernel a traves de USB o similar...

la veda se ha abierto. ahora espero que team-executer, si aun siguen activos, cree un kernel especifico que no compruebe firmas de ejecutables. aunque le diga adios al live!, por homebrew, lo acepto.
Pues entonces uno mas que se pone contentisimo.

Perdona pero no tenia ni idea de que en la anterior XBOX se consiguio desbanear...

Pero una pregunta, para escribir en la EPROM no hace falta un willem?

Vamos desoldar la EPROM, escribirla con el Willem, y volverla a soldar??

Y el nuevo numero de serie como lo obtenemos¿?

Habra que ver como microsoft se las ingenea para anular esta puerta abierta...
Esta puerta es dificil de quitar por q es, por asi decirlo, un problema hardware. Quiza en versiones mas nuevas de la consola cambien algo para q no se pueda saber en q momento exacto falla la firma y asi impedir calcular el bit q fallo. Pero en las de ahora es dificil q puedan hacer algo. De todos modos son todo expeculaciones asi q mejor esperar.
erpuche escribió:Pues entonces uno mas que se pone contentisimo.

Perdona pero no tenia ni idea de que en la anterior XBOX se consiguio desbanear...

Pero una pregunta, para escribir en la EPROM no hace falta un willem?

Vamos desoldar la EPROM, escribirla con el Willem, y volverla a soldar??

Y el nuevo numero de serie como lo obtenemos¿?

Habra que ver como microsoft se las ingenea para anular esta puerta abierta...


si, para escribir en la eprom hace falta un willem...

pero con este metodo NO ESCRIBES en la eprom, sino que DESACTIVAS CIERTAS PARTES y las REMAPEAS en el emulador de NAND que pones al lado del infectus. (o sea, que cuando la consola va a leer/escribir en esas partes de la eprom, realmente lee/escribe en el emulador de NAND del infectus.)
esto es una pasada. estoy esperando ese ansiado tuto para hacerlo con mi consola 5766 recien enviada al sat .

los dumps se tienen ke hacer obligatoriamente cn el infectus no...

porke ya he mandao 2 consolas al sat por culpa del infectus :@


enga salu2
no, a ver... os estais liando:

los 'dumps' (que no es un dump) se realizan CON AYUDA del infectus, pero NO LOS REALIZA el infectus.

el infectus se usa para 'esnifar' el trafico de datos en el bus y los accesos a la NAND.

por ahora, el procedimiento es MUY ARTESANAL y no es recomendado para gente normal. una vez que se ha conseguido por metodos 'artesanales', lo normal es que una empresa fabricante de chip, saque un chip (de tropocientos hilos, porque entre snifado del bus, emulacion de NAND y soporte USB para conexion con PC...) que AUTOMATICE todo el proceso, que haga el timing attack y que te arranque la consola con un kernel vulnerable. a partir de ahi: KingKong, Linux y volcado de la keyvault/cpukey.

el timing attack, 'per se', solo te ayuda a arrancar un kernel vulnerable. para volcar la keyvault/cpukey, necesitas linux.

eso si, os recomiendo bajar el ultimo kernel vulnerable (celebre actualizacion de HD-DVD de oct.06, +o-) y comprar alguna que otra tarjeta X D
Estado desconectado de los temas de xbox360 durante un tiempo... pero si tengo un kernel vulnerable, es muy complicado obterner la KeyVault y la CPUKey?
Oboka escribió:Estado desconectado de los temas de xbox360 durante un tiempo... pero si tengo un kernel vulnerable, es muy complicado obterner la KeyVault y la CPUKey?

nop, es relativamente sencillo:
Backup de KingKing con cargador de linux, y ejecutar un par de comandos con un teclado USB.
suena dificil, pero no sera tan dificil....solo es arriesgarse y probar, ademas seguro ke en breve saldran tutos...aunke imagino ke se rekerira conocimientos de informatika, yo en kuanto me salga un tuto y me llegue mi X360 probare, jejeje
f5inet escribió:la veda se ha abierto. ahora espero que team-executer, si aun siguen activos, cree un kernel especifico que no compruebe firmas de ejecutables. aunque le diga adios al live!, por homebrew, lo acepto.


No, ojo, de momento no se puede crear un kernel propio porque para eso necesitariamos firmarlo y de momento no se puede, lo que se puede hacer ahora es poner cualquier kernel de microsoft que está firmado por ellos, pero la CPU key no sirve para firmar un kernel. En realidad el avance para la scene es nulo, se sigue pudiendo hacer lo mismo que hasta ahora, solo que ahora quien tenga un kernel nuevo puede hacer un downgrade para poner uno de los vulnerables. Lo realmente importante sería encontrar un exploit más sencillo que el del King Kong porque ese método es un coñazo.
Haber si sale algo pa quitar los baneos xD
f5inet escribió:edy, el tema esta en que con el keyvault, puedes cambiar el numero de serie por uno que te salga del mandril y ESE no estara baneado por MS.

y no, aun no te pilles los infectus. pillate dos o tres, por si hay que hacer pruebas, pero teoricamente sacaran un modchip especial que hara todo el proceso de forma automatica, te permitira cargar el kernel vulnerable, sacara el keyvault el solito y te permitira meter cualquier kernel a traves de USB o similar...

la veda se ha abierto. ahora espero que team-executer, si aun siguen activos, cree un kernel especifico que no compruebe firmas de ejecutables. aunque le diga adios al live!, por homebrew, lo acepto.


Efectivamente, metiendo otros serial, puedes conectarte al Live, pero que serial? de otra consola sera ... no creo que puedas inventarte el serial, no? XD

Ok, de momento no me pillare el infectus, lo que de verdad tengo ganas de saber, es cuando llegaran los Pass Key 79 de maximus a españa ... porque tela, y el Globe V2 360 ... tela lo que cuesta.

Por otro lado, lo dicho, teoricamente seria obligatorio tener (hasta nueva orden ...) un King Kong para ejecutar software no firmado?

Saludotes.
31 respuestas
Archivado
Volver a Exploits y homebrew