El desarrollador kmx360 ha publicado una actualización para el exploit Xbox360BadUpdate, propuesto originalmente por grimdoomer. El desarrollador kmx360 está bifurcando la solución original, lo que mejora significativamente la velocidad y la tasa de éxito de la fase 3.
Como saben, Bad Update es un exploit no persistente para el hipervisor de Xbox 360 que se ejecuta en la última versión del software (17559). Puede usarse para ejecutar código sin firmar en Xbox 360 , aprovechando una vulnerabilidad del hipervisor, con el juego Tony Hawk’s American Wasteland (NTSC).
Las mejoras de kmx360 se explican en una publicación específica :
Esta es una evolución diseñada para mejorar la velocidad y la tasa de éxito de la etapa 3 .
En lugar de guardar el texto cifrado del oráculo + el reemplazo para un único valor de blanqueamiento, calculo previamente esto para esencialmente todos (o casi todos) los valores de blanqueamiento posibles.
Luego, en el hilo de sobrescritura, en lugar de realizar la sobrescritura si coincide un texto cifrado específico, puedo hacer una búsqueda y si encuentro _un_ texto cifrado coincidente, puedo realizar el ataque.
Sin embargo, logré superar la condición de carrera con el bucle de sobrescritura más lento creando una tabla de búsqueda indexada por ciertos bits del texto cifrado (en el código, la llamo “tabla pseudohash”). Con este esquema, una coincidencia se reduce a una sola carga que siempre debería alcanzar la caché L2. Con un número cuidadosamente seleccionado de bits del texto cifrado, puedo integrar esta tabla en la caché de la CPU y mantener allí casi todos los pares de texto cifrado + sobrescritura.
Aún no he podido eliminar los fallos, pero incluso sin ellos, la tasa de éxito ronda el 80% , y cada partida desde la fase 3 dura unos 15 segundos. Estos resultados se basan en mis propias pruebas y en una prueba de concepto preliminar compartida con usuarios del servidor de Discord de Xbox 360 Hub, quienes han obtenido resultados similares.
Mi teoría sobre los fallos actuales es que los dos hilos se están desincronizando (pero esto aún no se ha verificado exhaustivamente):
– el sobrescritor detecta una coincidencia canaria y escribe el reemplazo correspondiente, y realiza la sobrescritura del texto cifrado
– pero en ese punto el otro hilo ve ese valor, está en una iteración diferente de la carga útil XKE y ese texto cifrado ya no es válido.
– escribir texto cifrado no válido hace que el HV lea un puntero no deseado y escriba allí los datos LZX descomprimidos, lo que genera un error.
Publico esto para iniciar un debate sobre si actualizarlo o continuar el desarrollo mediante una bifurcación. También he realizado algunos cambios en el código a mi gusto durante el desarrollo, por lo que, lamentablemente, no tengo una delta mínima que simplemente contenga la nueva estrategia de búsqueda de texto cifrado. Además, estoy desarrollando este código únicamente con un compilador de C y un enlazador personalizado que escribí en Go, por lo que no tengo un archivo ASM intermedio que proporcionar.
Tenga en cuenta que
Add Comment