Arquitectura de la PlayStation 3

Todo lo que acabas de leer tiene que estar protegido de alguna manera contra el acceso 'no autorizado'. Si quieres saber cómo lo llevó a cabo Sony, tienes mucho que leer.

Visión general de la base de seguridad

Muchas partes de la consola ya proporcionan funciones de seguridad que no requieren ninguna implementación manual en software:

• SysCon, el chip propietario poco conocido (mencionado brevemente en el proceso de arranque), controla las líneas de alimentación de Cell, RSX y Southbridge. Su EEPROM contiene registros leídos por los módulos del sistema operativo para determinar qué funciones están habilitadas y cuáles no .
  • Aunque uso la palabra 'poco conocido', SysCon es simplemente un microcontrolador, ya sea un ARM7TDMI-S de catálogo (sí, la PS3 comparte algo de su ADN con la Game Boy Advance e incluso con las últimas revisiones del PS2) mejorado con soporte MagicGate, o una variante NEC 78K0R personalizada . Lo que más intriga es el firmware interno de SysCon.
  • SysCon y Cell se comunican mediante una interfaz serie (SPI) que se conecta al componente TEST de Cell . TEST proporciona muchas funciones de depuración en Cell, aunque SysCon solo se conecta al puerto de 'Pervasive logic', lo que le permite gestionar áreas como la alimentación o la temperatura .
• Cell alberga una ROM oculta que almacena rutinas de arranque sin cifrar sin preocuparse de miradas indiscretas.
• Los modos de privilegio de Cell y el isolated mode del SPE impiden que los programas accedan a recursos no autorizados.
• El Southbridge cifra transparentemente el contenido del disco duro mediante AES.
• El subsistema Blu-ray es otra fortaleza cerrada, y el contenido de sus discos está cifrado mediante una clave encontrada en el área 'ROM mark' del disco (inaccesible para los lectores convencionales) .

Además de esto, Sony implementó las siguientes protecciones por software:

• Una compleja cadena de confianza que comienza con la ROM de arranque sin cifrar de Cell y termina con una interfaz gráfica de usuario (XMB) que solo carga binarios cifrados (por Sony) bajo un kernel y un hipervisor.
  • La cadena de confianza implementa múltiples algoritmos de cifrado, incluyendo asimétricos como RSA y ECDSA y sistemas simétricos como AES; combinados con HMAC y SHA-1 (para confirmar la integridad de los datos).
• Algunas claves de cifrado se generan durante la fabricación, lo que significa que si los hackers las encuentran y filtran, no funcionarán en otras consolas. Aunque esto tiene el coste de que Sony no puede parchear el software cifrado con esas claves una vez que la consola sale de fábrica.
  • Estas claves especiales se usan para bootldr y metldr (las primeras etapas de arranque).
• Los juegos deben llamar al kernel para acceder al hardware, que a su vez pide permiso al Hypervisor. Esta 'cebolla de abstracción' evita que los exploits de los juegos escalen privilegios, en teoría.

La derrota

Ya has visto de lo que es capaz esta consola, ¿esperabas que los hackers se conformaran con las funciones limitadas de OtherOS? Supongo que Sony tampoco. La empresa se esforzó mucho por proteger algunas áreas, mientras dejaba otras a medio cerrar, como los hackers demostrarían más tarde.

Veamos cómo algunos de sus bastiones fueron descifrados por hackers independientes de todo el mundo; ten en cuenta que la comunidad de hacking de la PS3 era muy activa, con muchas herramientas y documentación producidas cada año. Así que me centraré en algunos hitos que allanaron el camino para una avalancha de contenido y desarrollo homebrew, pero puedes encontrar más información en PS3History .

Elusión del Hypervisor

En 2010, tras tres años tranquilos en la escena del hacking, la comunidad dio un giro positivo. George Hotz, un hacker conocido por haber desbloqueado previamente el primer modelo de iPhone (alias '2G') para que pudiera funcionar con cualquier operadora (originalmente solo en Cingular/AT&T), logró leer y escribir en áreas protegidas de la memoria sin ser detenido por el Hypervisor. Luego publicó su exploit junto con un breve resumen en su blog .

El exploit requiere dos materiales: una instalación de Linux corriendo bajo OtherOS (para ejecución de código arbitraria, aunque limitada) y un glitcher externo conectado al bus XDR (que interfiere con la RAM principal). En pocas palabras, el hipervisor utiliza una tabla hash almacenada en la RAM principal para catalogar las direcciones de memoria junto con sus niveles de privilegio, de modo que los programas de usuario no puedan acceder a espacios de memoria protegidos. El ataque funciona rompiendo la integridad de esa tabla para poder escribir sobre ella y, a continuación, usar ese privilegio para modificar las entradas y otorgar al programa actual acceso a todos los rincones de la memoria.

En resumen, Hotz descubrió que bajo Linux/OtherOS, los programas pueden solicitar al Hypervisor múltiples bloques de memoria que apuntan a la misma dirección física, pero si el programa los libera mientras hay una interferencia externa en el bus XDR (debida a un glitcher que envía pulsos eléctricos), el proceso de liberación queda incompleto . Como consecuencia, la tabla hash del hipervisor (que reside en la RAM) sigue conteniendo una entrada de las direcciones asignadas, pero al mismo tiempo cree que ese espacio ha sido liberado. El exploit de Hotz procede entonces a solicitar más bloques para que el Hypervisor amplíe su tabla con más entradas, y el proceso continúa hasta que una entrada de la tabla hash se superpone a la ubicación de memoria del bloque que debía liberarse. Como la tabla hash mantenía la entrada antigua que otorgaba al usuario acceso a esa dirección, el hipervisor acaba dando al usuario acceso para modificar esa entrada de la tabla hash. ¡Así, el exploit modifica la entrada para extender el acceso a todo el espacio de memoria!

Aunque este exploit requería un entorno de Linux corriendo bajo OtherOS, fue un enorme paso adelante para posteriores proyectos de ingeniería inversa e investigación, ya que los hackers podían ahora investigar áreas críticas del sistema que antes eran inaccesibles. Cabe mencionar que, al mismo tiempo, Sony lanzó la actualización de software 3.21 que eliminaba OtherOS. Podría pensarse que esto disuadiría a los hackers de continuar su trabajo, pero simplemente les dio más razones para acelerarlo.

PSJailbreak

A finales de 2010, un grupo identificado como 'PS Jailbreak' anunció (y luego publicó) una solución única para ejecutar Homebrew directamente desde el shell nativo de la consola (XMB, bajo GameOS) sin necesidad de manipular el hardware de la consola. Todo ello para disgusto de Sony, que pronto tomaría la vía legal para bloquear las ventas de ese producto.

'PS Jailbreak' consistía en un dongle USB que se conectaba al puerto USB frontal antes de encender la consola. El usuario tenía que pulsar el botón de encendido y, poco después, el de expulsión. Si las instrucciones se seguían correctamente, el usuario veía la interfaz XMB normal pero con la incorporación de una opción 'Install PKG' y un par de aplicaciones homebrew diseñadas para volcar los juegos Blu-ray al disco duro y luego cargarlos.

Entre bastidores, este dongle realizaba una enorme cantidad de trabajo, que puede dividirse en dos grupos :

1. El exploit USB: una vez encendida la consola, el dongle engaña al sistema haciéndole creer que está conectado a un hub USB de seis puertos, y luego realiza una compleja secuencia de comandos USB hasta provocar un heap overflow y escalar el acceso al Kernel de la PS3 (nivel 2), procediendo a continuación a ejecutar un payload.
2. El Payload: otro paquete complejo que parchea el shell original para habilitar funciones ocultas solo disponibles en unidades de depuración (como la entrada 'Install PKG'), deshabilitar la verificación de firmas (para cargar cualquier módulo/paquete arbitrario) y redirigir los comandos Blu-ray al disco duro (para cargar juegos desde el disco duro). El hecho de que este programa pueda alterar tanto desde el nivel del kernel te hace preguntarte para qué sirve el hipervisor.
   • Como complemento, M4j0r me comentó posteriormente: «Curiosamente, ni siquiera explota el código de Sony; esta parte de lv2 fue escrita por Logitech y los desarrolladores de ese exploit pudieron tener acceso al código fuente (debido al hackeo de 2008).» .

Este producto fue posteriormente sometido a ingeniería inversa por otras comunidades y, poco después, aparecieron clones de código abierto (como PS Groove) que eliminaron muchas restricciones (por ejemplo, los usuarios ya podían desconectar el dispositivo tras terminar el exploit). Algunos forks incluso se desplegaron en una calculadora Texas Instruments . En cualquier caso, Sony actuó rápidamente con la actualización de software 3.42 para eliminar esta mina de oro , aunque la puerta al Homebrew ya estaba abierta.

Menciones honoríficas

Antes de hablar del gran premio de la escena homebrew de la PS3, permíteme describir un par de métodos que se desarrollaron por aquella misma época:

• El USB Jig: otro pendrive USB, esta vez programado para hacer que la consola entrara en el Factory Service Mode, destinado únicamente al mantenimiento de la consola por personal autorizado. El programa incluido en el Jig replica lo que Sony proporciona a sus técnicos. La principal ventaja del modo de servicio es poder hacer downgrade de la consola a una versión compatible con PSJailbreak. El payload también estaba disponible como aplicación Homebrew para PSP . Sony respondió parcheando el modo de servicio para dificultar su restauración al modo 'normal' o la modificación del firmware desde él, desanimando a los usuarios a recurrir al modo de servicio.
• El emulador de disco óptico (ODE): una serie de productos de hardware distribuidos por distintas empresas (Cobra, E3, etc.). En lugar de manipular el firmware de la consola, estos manipulaban la interfaz SATA/PATA del Blu-ray. Los ODE son placas que se sitúan entre la placa base y la unidad Blu-ray, actuando como intermediarios que engañan a la consola haciéndole creer que contiene un disco de juego válido, pero en realidad cargando una imagen de disco desde una unidad USB externa. La historia del hacking de la PS3 contiene largos períodos 'unhackables' en los que no había ningún exploit de software disponible para las nuevas consolas. Así que, a un precio considerable, los ODE vinieron a llenar ese vacío.
• El Downgrader: a medida que Sony seguía mitigando los exploits con más actualizaciones de software, los usuarios se quedaban sin opciones viables salvo hacer downgrade a un firmware vulnerable. Así, hubo empresas como E3 que distribuyeron equipos especializados que podían sobrescribir el sistema de la consola 'a la fuerza', es decir, flasheando directamente los chips NAND o NOR. Por razones obvias, este método requería más habilidad y paciencia comparado con los basados en USB.
• Fugas del modo aislado: se trata de algo para fines de investigación, a diferencia de una 'función' que verá el usuario (aunque igualmente imprescindible para desarrollos posteriores). El caso es que los datos de revocación (utilizados para incluir certificados comprometidos en listas negras) son analizados por lv2ldr, ¿bien hasta aquí? Pues se descubrió que este proceso contenía muchas vulnerabilidades. En primer lugar y por alguna razón inexplicable, los datos de revocación son escribibles en el espacio de usuario. En segundo lugar, el analizador no realiza comprobaciones de límites sobre los datos leídos (aquí vamos de nuevo). Por ello, los hackers consiguieron elaborar datos de revocación personalizados que podían producir un buffer overflow y, en última instancia, permitirles ejecutar código arbitrario dentro del isolated mode del SPU. Esto les dio acceso a datos confidenciales (como claves) que supuestamente estaban protegidos del resto del sistema .

La caída del cifrado

Al igual que la saga del PSP, los exploits iniciales requerían mucho esfuerzo y Sony podía parchearlos fácilmente, lo que resultaba en un desventajoso juego del gato y el ratón. Sin embargo, como ocurrió con el PSP, era cuestión de tiempo que un descubrimiento rompiera la seguridad fundamental de este sistema: su cadena de confianza.

En 2011, George Hotz (junto con el equipo fail0verflow) publicó otro descubrimiento revolucionario: las claves de cifrado privadas que Sony usa para firmar los binarios ejecutados por metldr. Los binarios cargados durante esa etapa de arranque están firmados con una clave ECDSA. Al ser un sistema de cifrado asimétrico, esto significa que cualquiera que posea la clave privada (Sony, y ahora otros) puede cifrar y firmar binarios; por tanto, parecerán 'auténticos' a ojos de metldr. Como metldr es la tercera etapa de arranque antes de cargar lv1 (el hipervisor), esto significa que los hackers podrán personalizar o desarrollar su propio hipervisor, kernel y todo lo que haya por debajo. Y para más inri, todos los PlayStation 3 del mercado también considerarán auténticos los binarios personalizados. En definitiva, un exploit al estilo Pandora realizado completamente con software.

El descubrimiento de esta clave, que debería haber sido computacionalmente inviable, es posible gracias a lo que se considera un 'error garrafal' en la implementación de Sony del algoritmo ECDSA. En pocas palabras, la fórmula matemática usada para ECDSA utiliza un valor aleatorio que Sony nunca modificó en todos los archivos de actualización que distribuyó , convirtiendo ese número en una constante y facilitando así la resolución de las demás variables, que es exactamente lo que ocurrió.

Los efectos de este descubrimiento se describen en los siguientes párrafos.

La era del Custom Firmware (CFW)

Descifrar metldr significó que todo el mundo podía crear ya sistemas 'oficiales' para la PS3, lo que dio lugar a una avalancha de 'sabores' del GameOS producidos por distintas comunidades con diversas personalizaciones. Estos sistemas eran modificaciones de los archivos oficiales del firmware de Sony (que Sony distribuía como actualizaciones) y reempaquetados usando las claves filtradas de Sony, por lo que podían instalarse en cualquier consola. El resultado se llamó Custom Firmware (CFW) y se convirtió en el método de facto para hackear esta consola, al menos hasta que Sony respondió con medidas contundentes.

Mi instalación de CFW con el 'VSH menu' abierto. Esta variante (llamada 'Rebug') también me permitió convertir mi consola en una estación de depuración (fíjate en la dirección IP en la esquina inferior derecha; conviene introducirla en el depurador para conectarse a un proceso en ejecución) y experimentar con mi propio homebrew.

Mientras tanto, muchos CFW aparecieron en la red con distintos nombres ('Rebug', 'Ferrox', etc.) y contenían personalizaciones como :

• Deshabilitar las verificaciones de firma en cualquier módulo instalado o por instalar.
• Habilitar la lectura y escritura (el clásico peek and poke) sobre cualquier dirección de memoria, ya sea usando el Hypervisor (nivel 1) o el Kernel (nivel 2).
• Activar funciones de depuración ocultas para instalar módulos empaquetados como archivos 'pkg'. Estos no necesitaban estar firmados con las claves de Sony para funcionar en un entorno CFW.
• Permitir montar imágenes de disco como un disco Blu-ray virtual.
• Restaurar OtherOS e incluso mejorarlo eliminando las restricciones impuestas por el Hypervisor. El resultado se llamó OtherOS++.
• Sobrescribir la base de datos de la EEPROM de Syscon para poder instalar cualquier versión del sistema. Esto también se conoce como QA Toggling.
• Alterar el estilo del XMB (eliminar la advertencia de epilepsia, permitir capturas de pantalla en el juego, etc.).

Y mi favorita: replicar las funciones de depuración de un testkit, permitiendo que cualquier consola de consumo se convirtiera en una estación de depuración. Esto podía hacerse bien instalando un CFW con capacidades de depuración, bien un CFW que pudiera convertir la consola de consumo (llamada 'CEX') en un modelo de depuración (llamado 'DEX') alterando datos específicos de la consola en la memoria Flash.

La contundente respuesta de Sony

De manera similar a lo ocurrido tras la aparición de los CFW para el PSP, Sony respondió con dos actualizaciones de seguridad:

Desde el lado del software, Sony distribuyó dos actualizaciones del sistema que mejoraron el sistema de seguridad:

• Con 3.56, los binarios se firman con nuevas claves de cifrado resistentes al descubrimiento previo de ECDSA ; por tanto, los creadores de CFW no pueden personalizar los nuevos binarios (al no tener las claves privadas para volver a cifrarlos). Además, se distribuye una nueva revisión de la aplicación 'actualizador del sistema', que aplica los nuevos certificados en los archivos de actualización del sistema (PS3UPDAT.PUP), lo que significa que incluso si los hackers consiguen empaquetar un nuevo CFW, solo las consolas con la versión 3.55 o inferior podrán instalarlo .
• Más adelante, la actualización del sistema 3.60 renovó el proceso de arranque, anuló metldr y promovió a lv0 para tomar el control en el arranque de los loaders (lv1ldr, lv2ldr, appldr e isoldr). En definitiva, esto significaba que los hackers no podían modificar los nuevos archivos del sistema sin descifrar primero lv0 (encontrar su clave privada).
  • Esto ocurrió finalmente a finales de 2012, cuando un equipo llamado "The Three Musketeers" publicó las claves de lv0 , lo que allanó el camino para nuevos CFW hechos a partir de versiones del sistema más nuevas que 3.55. Aunque, debido a los cambios mencionados en el actualizador, solo los usuarios con la versión 3.55 o inferior (incluido cualquier CFW con las comprobaciones de firma desactivadas) pueden instalarlo.

Desde el lado del hardware, no solo los modelos posteriores de la PS3 (CECH-25xxx tardíos, CECH-3xxx y CECH-4xxx) venían preinstalados con una versión del sistema superior a 3.55, sino que también contienen una variante diferente de bootldr/lv0ldr (llamada lv0ldr.1) que no solo descifra y carga lv0, sino que también lee un nuevo archivo del sistema llamado lv0.2. Este último contiene metadatos sobre lv0 para garantizar que lv0 no ha sido manipulado. lv0.2 está firmado con una nueva clave (también invulnerable al descubrimiento previo de ECDSA), impidiendo así que los hackers tomen el control de la cadena de arranque.

Hasta el día de hoy, estos modelos no son capaces de ejecutar un CFW, por lo que reciben el apodo de unhackables. Aunque sí pueden ejecutar un 'Hybrid Firmware' (HFW), del que hablaremos más adelante.

Con el tiempo, el número de consolas compatibles con CFW solo disminuyó. Por ello, los PS3 que no se habían actualizado más allá de la versión 3.55 se convirtieron en una especie de reliquias. Mientras tanto, creció la demanda de alternativas, como los downgraders (para revertir a la versión 3.55 del sistema en los modelos antiguos) y los ODE (para reproducir juegos pirata en los modelos nuevos).

El renacimiento del homebrew

Tras un largo período de espera para los usuarios que habían perdido la ventana para instalar un CFW, a finales de 2017 un equipo de hackers publicó PS3Xploit, una colección de exploits y utilidades que devolvió la posibilidad de instalar un CFW en los modelos antiguos sin necesidad de un costoso downgrader (y de las habilidades para operarlo).

El payload principal de PS3Xploit replica el trabajo de un downgrader de hardware (parcheando archivos de CoreOS) íntegramente mediante software, y funciona así:

1. El punto de partida es el navegador de internet del XMB, construido sobre WebKit. PS3Xploit usa JavaScript para obtener ejecución de código arbitrario dentro del userspace del sistema (y fuera del entorno de JavaScript). Para iniciarlo, los usuarios solo tienen que abrir el navegador web nativo del XMB, introducir una URL que apunte al host de PS3Xploit y dejar que haga su trabajo.
2. Resulta que el kernel proporciona llamadas al sistema que pueden usarse para sobrescribir los archivos del sistema operativo en la memoria Flash. Además, el Visual Shell (XMB) y sus plugins almacenan en memoria rutinas que hacen uso de esas llamadas.
3. PS3Xploit no puede activar directamente esas llamadas al sistema debido a la protección 'no-execute' del Hypervisor, que impide que el exploit cargue nuevo código en el userland. Sin embargo, puede encontrar la manera de sobrescribir la memoria Flash 'tomando prestadas' las rutinas del Visual Shell.
4. En consecuencia, PS3Xploit procede a modificar la pila de ejecución de WebKit para redirigir la ejecución a las rutinas del Visual Shell. Este tipo de técnica (corromper la pila para desviar la ejecución hacia otro código residente en memoria) se llama Return Oriented Programming (ROP) y es muy popular en el ámbito de la seguridad informática. Una forma de mitigarlo es implementar Address Space Layout Randomisation (ASLR), que dificulta adivinar la ubicación de las rutinas (llamadas gadgets) pero, como puedes imaginar, el hipervisor de Sony carece de ASLR.
5. Por último, esas llamadas al sistema se activan con los parámetros de PS3Xploit y así reemplazan los archivos de CoreOS (la primera parte del sistema operativo, almacenada en la memoria Flash) por versiones parcheadas .
6. La consola ya puede instalar actualizaciones de software no oficiales, una oportunidad que el usuario puede aprovechar para instalar un custom firmware. Sin embargo, aún no puede hacer downgrade de la versión del sistema, pero una vez instalado un CFW actualizado, el usuario puede instalar más utilidades para hacer downgrade y, si lo desea, instalar un CFW mejor equipado.

Como puedes ver, este regalo caído del cielo devolvió los custom firmwares al primer plano y dejó obsoletos los downgraders de hardware y los ODE. Por otro lado, para aquellas unidades que de ninguna manera podían instalar un CFW (los unhackables), el equipo ofreció posteriormente PS3Hen, un paquete de exploits diferente centrado en habilitar un subconjunto de funciones del CFW (incluyendo la capacidad de ejecutar homebrew). Este se instala como una entrada en el XMB y el usuario debe ejecutarlo cada vez que enciende la consola para volver a habilitar la ejecución de aplicaciones homebrew.

La respuesta parcial de Sony

La suerte quiso que Sony solo tomara pequeños pasos para bloquear PS3Xploit (quizás porque todo ello ocurrió años después de que la PlayStation 4, sucesora de la PS3, llegara a las tiendas). Publicaron algunas actualizaciones del sistema que no corregían esta cadena de exploits, pero sí eliminaban la rutina de WebKit usada para arrancar la cadena. En respuesta, los hackers publicaron actualizaciones de software ligeramente modificadas que restauraban esa entrada (y de algún modo, no necesitaban ser refirmadas) . Estas actualizaciones personalizadas se llamaron Hybrid firmware (HFW) y, en el momento de escribir estas líneas, son la opción de facto para habilitar el homebrew en los sistemas unhackables.

Y aquí concluye la saga de antipiratería y homebrew. En mi humilde opinión, no creo que Sony esté interesada en invertir más esfuerzo en esta consola. Así que no esperaría más juegos del gato y el ratón en este ámbito.