blaKCat escribió:Aclaracion nuevo Dash segun entiendo yo:
Voy a tratar de explicar lo mas claro posible la nueva situacion en que queda el RGH tras la nueva actualizacion de Microsoft.
- En el proceso de booteo primero se carga el 1Bl (que esta en la cpu y no cambia).
- Este desencrypta y carga el 2bl (CB_A) comprobando antes que es original (hash) . No podemos por tanto modificarlo (parchearlo) aunque si usar otro anterior mientras sea original (como hacemos en las slim 9230 usando el 9188) ya que pasan la comprobacion Hash.
- El Cb_A ahora desencripta y carga el CB_B comprobando el hash para ver si es original. Cuando parcheamos el cb_B el hash no coincide y no lo acepta pero aqui es donde entra el chip para desestabilizar la comprobacion y admitir nuestro cb_b. El cb_b esta encriptado con una combinacion de datos del cb y la cpukey. Como en una consola sin exploit no la sabes se usa el llamado metodo Keystream que mas o menos es:
cb_b desencriptado & Keystream = cb_b encriptado.
si conocemos cb_b desencriptado y cb_b encriptado tenemos la Keystream. Si queremos inyectar un cb_b parcheado y encriptarlo:
cb_b parcheado desencriptado &Keystream (conocido) = cb_b parcheado encriptado
Hasta aqui para recordar el proceso. Pues bien.
Ahora ha cambiado el modo en que el cb_a desencripta al cb_b usando nuevos datos para el calculo de la Key R4. De modo que por ejemplo en slim:
cb_a 9188 y 9230 = R4 antigua
cb_a 9131 = R4 nueva
Como ya sabemos el nuevo cb_B 9131 desencriptado (obtenido actualizando una xbox previamente exploiteada , usando la cpukey y la nueva encriptacion R4) no hay ningun problema para obtener nuestro keystream y por tanto podemos inyectarle cualquier cb_b como haciamos en las 9230 usando el cb_B 9188.
Pero al inyectarlo tendriamos nuestro cb_b 9188 encriptado en nuestra consola dash 15x pero al usar el keystream estara encriptado con la nueva R4.
Por lo tanto solo podemos inyectarle a esa nand un cb_a que use esa misma encriptacion nueva , o sea el cb_a 9231 que entre otras cosas anula el postout con lo que imposibilita el actual Glitch. Si hacemos como en las 9230 que inyectabamos cb_a 9188 y cb_b 9188 el cb_a no desencriptaria correctamente nuestro cb_b keystreamed. Para poder usar un cb_a 9188 nuestro cb_b inyectado debe estar encriptado con el antigua R4. Y sin la cpukey no podemos hacerlo.
En resumen han casado el cb_a con el cb_b, deben usar la mism funcion r4.
En que situacion queda el RGH:
-Si esta previamente exploiteada y tenemos la cpukey no hay problema. Simplemente se usa el cb_a anterior y el cb_b anterior (9188) encriptandolo con la cpu_key. Hay que esperar las nuevas versiones de xebuild y Autogg. Incluso sin la cpukey si tenemos un dump de nuestra consola con dual cb anterior al 15x podemos usar la keystream para generar un ECC y cargar xell para ver la cpukey y seguir el proceso. Podeis actualizar sin problemas .Dual nands inlcuidas.
-Si no tenemos ni cpukey ni dump anterior al 15x de momento no podria exploitearse .
Esta vez me temos que la jugada del granhermano es un puntazo para ellos. A mi de momento al menos no se me ocurre como contrarestarla.
La unica opcion y definitiva seria atacar al 1BL en su comprobacion de Hash del cb_A. (glitch) Ya estamos en ello.Update:
Se me ocurren otras 2 posibles medidas:
- Usar el nuevo cb_a y tratar de seguir el proceso de booteo de una forma alternativa al postout.
- Usar una key en el cb_a que produzca un cb_b keystreamed correcto. Es cuestion de buscar la formula