El exploit 'Bad Update', dirigido al hypervisor de Xbox 360, experimentó refinamientos técnicos significativos para pasar de una prueba de concepto lenta y poco fiable a un ataque altamente eficiente. Inicialmente, el exploit requería un disco de juego físico como punto de entrada y sufría de una baja tasa de éxito. Esto cambió tras dos importantes contribuciones de la comunidad: el descubrimiento de un nuevo punto de entrada de guardado de juegos en la versión de demostración de Rock Band Blitz (RBB) y la optimización de la condición de carrera del hypervisor. Al explotar la corrupción de memoria en el código de análisis de DLC de RBB, los atacantes ahora pueden iniciar la cadena de exploits a través de una unidad USB, eliminando la necesidad de un disco físico.
Un obstáculo técnico principal en la prueba de concepto original fue el fallo de una simple tabla de búsqueda de texto cifrado. El Xbox 360 utiliza un esquema de cifrado de memoria con un valor de blanqueo de 12 bits, creando 1024 combinaciones de texto cifrado posibles para cualquier texto plano dado. El intento inicial del autor de usar una tabla de búsqueda falló porque las versiones más recientes del hypervisor eliminaron un vaciado específico del Translation Lookaside Buffer (TLB) en la función del hypervisor. Debido a que el autor llamó a la llamada al sistema del hypervisor directamente, omitiendo el envoltorio del kernel que realiza el vaciado, los bits de blanqueo quedaron obsoletos, lo que resultó en lecturas de texto cifrado inválidas. Esta distinción entre los comportamientos del hypervisor antiguo y el nuevo fue un factor crítico en la inestabilidad inicial del exploit.
Esta imagen ilustra el comportamiento específico del hypervisor con respecto a los vaciados del TLB que causaron la inestabilidad del exploit original.
Esta figura demuestra el estado de fallo del exploit original antes de que se implementara la tabla de hash de texto cifrado.
Para resolver esto, el exploit ahora utiliza una tabla de hash para precalcular y almacenar valores de texto cifrado maliciosos. El sistema itera 1024 veces para agotar todos los bits de blanqueo posibles, vaciando manualmente la entrada del TLB para cada asignación cifrada para asegurar que se capture el valor de blanqueo correcto. Los primeros N bits del texto cifrado esperado sirven como índice para la tabla. Si bien una tabla de hash más grande utiliza más memoria, el tamaño de la clave se eligió para minimizar las colisiones evitando al mismo tiempo un exceso de desorden en la caché de la CPU. Combinado con una programación de hilos mejorada entre la carga útil XKE y los hilos de sobreescritura de texto cifrado, estas optimizaciones redujeron el tiempo de ejecución a unos pocos segundos con una tasa de éxito cercana al 100%. Sin embargo, la eficacia de estas optimizaciones sigue dependiendo del comportamiento de la caché del hardware específico, ya que el exploit depende de un delicado equilibrio entre la sobrecarga de memoria y la presión de la caché de la CPU.