Hola
La CPU_KEY son una linea de eFuses que se queman dentro de la CPU durante el proceso de ensamblado en fabrica, cada CPU lleva una llave aleatoria y unica por consola que no se puede modificar.
Para obtenerla usamos el XELL, el cual no va encriptado en la NAND pero si va inyectado justo detras del CB_B, la consola durante el arranque del CB_B se le manda el Glitch y permite ejecutar codigo sin firmar, en este caso el XELL, es una aplicacion como otra, solo que se lanza directamente despues del CB_B sin pasar por lo demas pasos de boot.
En ese punto la consola esta a medio bootear no tiene el DASH ni nada mas cargado, solo lo basico el xell es un loader de aplicaciones creadas con su propio SDK y no compatible con las demas aplicaciones de XBOX, este loader tiene la particularidad de leer el estado de la consola y como la tenemos arrancada te da el FUSESET, entre los que se encuentra el LVD de DASHBOARD el LVD del CB y la CPU_KEY
Una vez obtenida la CPU_KEY podemos desencriptar nuestra NAND, inyectar un dashboard parcheado "XEBUILD" y volver a cifrarla para que arranque normalmente, al estar modificado el DASHBOARD es necesario el chip para mandar el glitch y que la consola arranque codigo sin firmar.
El porque no podemos obtener la CPU_KEY en los nuevos DASH.
A partir del 147xx microsoft modifico el CB_A i el CB_B de manera que justo al arrancar el CB_A desactivaba el puerto POST_OUT el cual usan los CHIPS de RGH para saber en que estado se encuentra el arranque para mandar el pulso, al no tener referencia el GLITCH se hace imposible, como lo solucionaron...
Como el CB_B usa la misma encriptacion que antes y sabemos como empieza, se inyecta un CB_A antiguo el cual esta firmado por microsoft y es "VALIDO" este CB_A no desactiva el POST_OUT y podemos realizar el GLITCH en las versiones 147xx es un poco mas complejo el proceso pero a grandes rasgos funciona asi.
Como hizo microsoft para cerrar "definitivamente" el problema de seguridad.
Volvio a modificar el CB_A i el CB_B esta vez, en el CB_A ademas de desactivar el POST_OUT añade un algoritmo nuevo a la encriptacion del CB_B.
De esta manera si usamos un CB_A antiguo al estar el CB_B con otra encriptacion no sera imposible descifrarlo, si editamos el CB_A antiguo para que se trague la nueva encriptacion, perdera la firma de microsoft y dejara de ser valido asi que la consola no arrancara al encontrar un CB_A sospechoso y como no tenemos el POST_OUT el chip no sabe cuando debe mandar el GLITCH para arrancar la consola, no tenemos XELL ni tenemos NADA.
Las soluciones para el nuevo sistema de encriptacion de microsoft pasan por hacer que el chip vuelva a glichear, ya sea atacando el CB_A en vez del CB_B antes de que desactive el POST_OUT "creo que Team Xecuter va por esta linea"
O buscar un punto alternativo al POST_OUT para que el chip sepa exactamente cuando mandar el pulso
Saludos!
![[plas]](/images/smilies/aplauso.gif "Aplausos")