Firmware personalizado

Debido a que se utiliza habitualmente para eludir la gestión de derechos digitales , el firmware personalizado se considera una herramienta para facilitar la piratería , aunque el acto de instalar firmware personalizado en sí mismo puede no ser ilegal.

En Japón, los firmwares personalizados fueron prohibidos como parte de una legislación más amplia en 2018 que ilegalizó la modificación de consolas. ^{[ 1 ]}

El firmware personalizado es común en las consolas portátiles PlayStation Portable lanzadas por Sony. Entre los firmwares personalizados más destacados se encuentran M33 de Dark_AleX, así como otros creados por terceros, como la serie 5.50GEN, Minimum Edition (ME/LME) y PRO. El firmware personalizado en la PlayStation Portable permitía extensiones no oficiales de las capacidades del hardware. Complementos como RemoteJoyLite ^{[ 2 ]} permitían transmitir la salida de vídeo de la consola en tiempo real a través de USB a un monitor de ordenador conectado. Además, aplicaciones caseras como iR Shell ^{[ 3 ]} aprovechaban el puerto infrarrojo integrado de la PSP-1000 original para implementar la funcionalidad de control remoto universal para dispositivos electrónicos de consumo mediante el envío de códigos remotos a través de la interfaz IR.

También se puede usar firmware personalizado en la consola PlayStation 3. Solo los primeros modelos "Fat" y Slim (CECH-20xx hasta los primeros CECH-25xx) pueden ejecutar firmware personalizado. Los modelos Slim (finales CECH-25xx y CECH-30xx) y Super Slim solo pueden ejecutar HEN (Homebrew Enabler), que tiene una funcionalidad similar a la de un firmware personalizado. También existen ODE (Optical Drive Emulator), HAN (etHANol) y HFW (Hybrid Firmware) para PS3.

La PlayStation Vita / PlayStation TV cuenta con eCFW, es decir, firmware personalizado para PSP que se ejecuta en el emulador de PSP de la PS Vita/PS TV. Estos eCFW incluyen ARK, TN-V y, más recientemente, Adrenaline, que incorpora más funciones al haber sido modificado desde el lado nativo. En 2016, un equipo llamado Molecule lanzó HENkaku (un Homebrew Enabler, con una funcionalidad similar a la de un firmware personalizado) para PlayStation Vita/PlayStation TV, que modifica el firmware de la PS Vita/PS TV a la versión 3.60, permitiendo crear un firmware personalizado en la consola. El equipo detrás del HENkaku original también lanzó taiHEN. taiHEN es un framework sobre el que se ejecuta la versión más reciente de HENkaku. Es una forma de cargar plugins a nivel de sistema, como se hacía en la PSP, permitiendo modificar o añadir funciones a la consola. Enso es una vulnerabilidad del gestor de arranque de la PS Vita/PS TV que hace que HENkaku sea permanente y permite ejecutarlo al inicio, de modo que la PS Vita/PS TV tenga un CFW completo con HENkaku Enso. Los usuarios de la versión 3.60 también pueden actualizar a la 3.65 sin perder HENkaku Enso.

La comunidad de modding de Nintendo 3DS se centra principalmente en firmware personalizado (software que modifica el firmware oficial sobre la marcha), lo que requiere una vulnerabilidad para obtener el control del ARM9, el coprocesador de seguridad de la 3DS, y, secundariamente, en cartuchos flash , que emulan un cartucho de juego original (que se puede usar exclusivamente para jugar copias de seguridad de ROM de cartuchos de juego sin modificar). El CFW más utilizado actualmente es Luma3DS , desarrollado por Aurora Wright y TuxSH, que permite la instalación de archivos CIA (CTR Importable Archives) sin firmar, incluye módulos de firmware del sistema reescritos de código abierto y manejo de excepciones para desarrolladores de software casero.

Otros CFW pasados ​​y abandonados incluían Gateway (un CFW propietario bloqueado a un cartucho flash mediante DRM y el primero disponible públicamente), Pasta, RxTools (el primero gratuito y ampliamente utilizado), Cakes CFW ^{[ 4 ]} (el primer CFW de código abierto, que utilizaba un enfoque modular para parches y fue la inspiración para los siguientes), ReiNAND, en el que se basó originalmente Luma3DS, y Corbenik; ^{[ 5 ]} hasta ahora el único firmware personalizado que todavía se está desarrollando es Luma3DS (anteriormente conocido como AuReiNAND). Los CFW de 3DS solían depender de "EmuNAND"/"RedNAND", una característica que arranca el sistema desde un espacio no particionado de la tarjeta SD que contiene una copia de la memoria NAND de la 3DS. Estos EmuNAND podían proteger el sistema 3DS de un brickeo, ya que la NAND del sistema habitual no se veía afectada si el emuNAND dejaba de funcionar correctamente o era inutilizable por alguna otra razón. Las EmuNAND también podrían actualizarse por separado de la NAND del sistema habitual, lo que permitiría a los usuarios tener la última versión del sistema en la EmuNAND mientras conservan la versión vulnerable en la NAND del sistema; de este modo, sería posible jugar en línea y acceder a la Nintendo eShop en versiones obsoletas del sistema 3DS.

Las emuNAND quedaron obsoletas con el lanzamiento de arm9loaderhax, una vulnerabilidad de ARM9 que se activaba al arrancar el sistema y permitía usar SysNAND de forma segura y actualizarla. Los CFW comenzaron a parchear el código de actualización del sistema operativo para que las actualizaciones oficiales no eliminaran la vulnerabilidad. Sin embargo, esta vulnerabilidad requería una degradación a una versión muy antigua del sistema para obtener la contraseña de un solo uso (OTP) única de la consola, necesaria para la instalación.

El 19 de mayo de 2017 se publicó una nueva base de exploit llamada sighax, que reemplazó a arm9loaderhax y permitió a los usuarios obtener un control aún más temprano del sistema, otorgando ejecución de código en el contexto de la bootROM y, por lo tanto, un entorno más limpio, sin necesidad de downgrades ni OTP. Se publicó Boot9Strap, una versión de sighax fácil de usar. Sighax funciona desbordando el puntero del analizador de firmas en la pila, de modo que el hash de la imagen del firmware se compara consigo mismo, ya que el analizador no valida ciertos campos. ^{[ 6 ] [ 7 ]}

Al mismo tiempo, se anunció otro exploit de bootROM llamado ntrboot, que permite usar una puerta trasera presente en el bootROM para obtener el control total del sistema en cualquier consola 3DS, independientemente de la versión del firmware (ya que el bootROM no se puede actualizar), requiriendo únicamente un cartucho flash DS modificado y un imán. El lanzamiento inicial fue el 12 de agosto, compatible con los cartuchos AceKard 2i y R4i Gold 3DS RTS.

Páginas 11 y 12 de la acusación contra los desarrolladores de SX OS (Team Xecuter), en relación con su software utilizado en Nintendo Switch ^{[ 8 ].}

Actualmente, existen varios firmwares personalizados para la consola Nintendo Switch : Atmosphère, ReiNX y SX OS. Las diferencias entre ellos son prácticamente insignificantes; Atmosphère sigue en desarrollo activo y es software libre y de código abierto . ReiNX basa gran parte de su código en Atmosphère ^{[ 9 ]} , pero con algunas modificaciones en los componentes de tiempo de ejecución y un gestor de arranque diferente, mientras que SX OS es de código cerrado y de pago, pero se basa en gran medida en el código de Atmosphère a pesar de las afirmaciones en contrario. ^{[ 10 ]}

Nintendo ha hecho que el entorno de Switch sea mucho más seguro que las consolas anteriores. A pesar de esto, existen errores notables que permiten a los usuarios explotarlos. De estos, el error de la pila Nvidia Tegra ( CVE - 2018-6242 ) ^{[ 11 ]} es el más explotado. Aprovecha el Modo de Recuperación (RCM) de la unidad Switch para insertar payloads sin firmar/sin verificar, ^{[ 12 ]} lo que a su vez otorga al usuario acceso a la ejecución de código arbitrario . Esta vulnerabilidad ha sido aprovechada por usuarios dentro de la escena de hacking de Switch para realizar ingeniería inversa del firmware, lo que ha dado lugar a otros dos exploits notables: Nereba y Caffeine. Mientras que RCM es un exploit de hardware, Nereba y Caffeine son exploits de software y dependen de que la consola tenga versiones de firmware iguales o inferiores a ciertas para poder utilizarlos. RCM, al estar relacionado con el hardware, simplemente depende de que la consola sea vulnerable a ese exploit en particular y no tiene un requisito o rango de firmware.

Debido a la divulgación por parte de Nvidia de CVE-2018-6242, Nintendo se vio obligada a abordar la vulnerabilidad, ^{[ 13 ]} y a finales de 2018 comenzó a fabricar y distribuir unidades que habían sido parcheadas por hardware y que no pueden acceder a la vulnerabilidad RCM. Cualquier unidad fabricada durante o después de este período probablemente tenga parches por hardware, incluyendo la Switch Lite y las nuevas Switch de "caja roja", y cualquier unidad que tenga parches por hardware y ejecute un firmware relativamente reciente es improbable que pueda acceder a firmware personalizado en este momento o en el futuro debido al entorno de software inusualmente seguro de la Switch. Estas Switch se conocen comúnmente como Switch "parcheadas" dentro de la comunidad de modificación de Switch. Si bien no se pueden modificar por medios normales ("softmodding"), se puede soldar un chip de modificación donde estaría el puerto USB-C de la Switch después de que se retire ("hardmodding"), evitando así la necesidad de entrar en el modo RCM.