La primera jailbreak de la Nintendo Switch 2 usa IA generativa como herramienta de explotación
El investigador de seguridad Sammy Hajhamid, conocido online como pepsipu, reveló el 18 de octubre de 2026 la existencia de la primera jailbreak de software para la Nintendo Switch 2. Denominada ns2jb, la exploit funciona en el firmware más reciente (23.0.1) y, a diferencia de métodos anteriores que requerían modificación física de las consolas, opera íntegramente mediante vulnerabilidades de software — con un detalle particular que ha generado debate: el proceso de descubrimiento de las falhas fue conducido por agentes de IA basados en el OpenAI Codex.
El enfoque inusual: LLMs como herramienta de vulnerability research
Hajhamid no trabajó solo. En su descripción técnica publicada en su blog personal, detalla un montaje físico complejo: dos consolas (una Switch 1 y una Switch 2), dos dispositivos JetKVM para control remoto vía HDMI y USB, y un interruptor Bluetooth de Amazon capaz de presionar físicamente el botón de encendido cuando la consola se bloqueara. Con esta infraestructura, ejecutó instancias del Codex directamente en ambas consolas, asignándoles la tarea de encontrar vulnerabilidades explotables.
El enfoque inicial — intentar explotar el navegador integrado en la Switch 2 — se topó con defensas modernas que la consola implementa: memoria ejecutable-only (XOM), PAC (Pointer Authentication Codes) y CFI (Control-flow Integrity). El navegador de la Switch 2 está protegido por WebKit con XOM, lo que significa que incluso con lectura y escritura arbitraria en la memoria, no hay forma de localizar gadgets útiles para hacer llamadas IPC arbitrarias. Además, el PAC (Pointer Authentication Codes) impide que pointers no-autorizados sean ejecutados, y el CFI (Control-flow Integrity) verifica la mayoría de los call sites. Esta combinación de defensas hizo la vía del navegador impracticable.
El cambio de ruta fue elegante: en lugar de atacar la Switch 2 directamente, Hajhamid dirigió el Codex para explotar juegos de la Switch 1 ejecutándose vía compatibilidad inversa. La lógica era sólida: los juegos de la Switch 1 no sufren de PAC (la arquitectura de la Switch 1 no lo incluye), y dado que la raíz de confianza de la Switch 1 ya era conocida, era posible desencriptar y analizar el código de forma segura. La elección recayó sobre SmileBASIC 4, un intérprete BASIC de US$ 25 en la eShop que ya había sido explotado antes en el escenario 3DS (smilehax), dando al investigador un punto de partida conocido.
La cadena de explotación
Codex encontró una falla de desborde entero de 32 bits en el intérprete BASIC del SmileBASIC 4, específicamente en el código que elimina elementos de un array. Esta falla proporcionó el primitivo básico de lectura y escritura en la memoria — un foot hold, como describe Hajhamid. Con eso, el investigador luego dirigió agentes adicionales para investigar servicios del sistema, y la falla más fructífera apareció en el módulo fs (filesystem): un buffer overflow en el manejo de ciertas rutas de archivo.
El módulo fs es particularmente interesante en la arquitectura Switch porque sirve código desencriptado y es uno de los pocos sysmodules con una superficie de ataque grande accesible vía SmileBASIC. A partir de él, Hajhamid pudo ejecutar código arbitrario como cualquier sysmodule ordinario, incluyendo el propio módulo fs — y crucialmente, como el módulo ro (run-only).
El truco final involucra al loader del sistema: cuando el loader solicita el ExeFS de un ejecutable, verifica firmas en el archivo original, pero el módulo fs es el que sirve el contenido real al loader. Dado que la exploit controla el módulo fs, puede engañar al loader para servir código modificado. Este patrón de explotación — abusar de un servicio del sistema en lugar de romper criptografía — es una técnica avanzada que demuestra madurez considerable en reverse engineering de consolas. Patrones similares fueron observados en explotaciones de la Switch original, pero la escala y la sofisticación de este enfoque son notables.
Qué permite la jailbreak (y qué no)
La ns2jb se describe como una jailbreak "tethered": requiere un ordenador con Node.js 22+ en la misma red local, y cada reinicio de la consola elimina la exploit de la memoria, exigiendo que se ejecute de nuevo. No ofrece firmware personalizado persistente ni acceso al kernel — es una jailbreak de userland.
A pesar de las limitaciones, el alcance de capacidades ya es significativo:
- Ejecución de código nativo con privilegios de sysmodule ordinario - Homebrew: ejecutar software no-oficial desarrollado por la comunidad - Modificación de juegos: demostrado con personajes personalizados en Mario Kart World (Cinnamoroll, Peter Griffin, Hatsune Miku, Angry Birds) - Backup de saves: dump de archivos guardados encriptados para análisis - Ingeniería inversa: acceso a periféricos vía MMIO (Memory-Mapped I/O) - Desencriptación de sysmodules: útil para investigadores buscando nuevas falhas
En la demostración publicada, Hajhamid y colegas modificaron el Mario Kart World — exclusivo de la Switch 2 — para incluir personajes completamente fuera del alcance original del juego. El video muestra el Peter Griffin de Family Guy, la vocaloid japonesa Hatsune Miku, Cinnamoroll (el personaje de Sanrio), y un pollito del Angry Birds compitiendo como rivales en una pista del juego. La versatilidad de la exploit va más allá de mods superficiales: dado que el código corre con privilegios de sysmodule, es posible inyectar recursos binarios directamente en el espacio de memoria del juego, abriendo puertas para modificacions mucho más profundas.
Contexto: la resistencia histórica de Nintendo
Nintendo tiene una larga y consistente historia de resistencia a la modificación de sus consolas. La Switch original recibió su primera jailbreak de software meses después de su lanzamiento en 2017, y desde entonces la escena de homebrew ha crecido significativamente — incluyendo port de Dolphin (emulador de GameCube/Wii) e incluso versiones de PC de juegos como Final Fantasy VII Remake corriendo en ella. La compañía responde agresivamente: recientemente eliminó 401 repositorios de emuladores Switch de GitHub y envió múltiples notificaciones DMCA contra proyectos de emulación.
La propia Nintendo ya había comenzado a eliminar características de código dinámico del sistema, incluyendo el módulo JIT. Hajhamid observa esta tendencia en su write-up, sugiriendo que el ecosistema de explotación necesita moverse rápido mientras funciones como el JIT aún existen. La eliminación progresiva de capacidades de código dinámico de la Switch 2 no es solo una cuestión de seguridad — es parte de una estrategia más amplia de Nintendo para controlar el ecosistema de software del console, lo que puede tener implicaciones a largo plazo para la comunidad de desarrolladores independientes.
El debate sobre IA en seguridad ofensiva
La participación del Codex en el descubrimiento de las vulnerabilidades plantea preguntas que van más allá del escenario específico de la Switch 2. Hajhamid construyó el hardware de prueba, definió los objetivos estratégicos y ejecutó el proceso durante aproximadamente dos semanas. El Codex fue la herramienta de reconocimiento y descubrimiento, no el arquitecto de la estrategia.
Sin embargo, la naturaleza automatizada y autónoma del trabajo del LLM — asignar metas como "set a goal to jailbreak the switch 2, make no mistakes" y dejar que agentes iteren sobre buffers y arrays buscando corruptions — representa un posible punto de inflexión. Si los LLMs pueden acelerar el descubrimiento de vulnerabilidades en codebases complejas como intérpretes BASIC, la misma técnica puede ser aplicada a cualquier sistema embebido con superficie de ataque accesible por software.
Esto no es especulación: Hajhamid menciona que el enfoque vía navegador en la Switch 2 falló, pero que encontró descubrimientos relacionados que aún no puede divulgar públicamente. La existencia de más vectores potenciales, incluso si aún no explotados, es en sí misma una presión sobre la seguridad de la consola. Además, el mismo enfoque basado en LLMs para vulnerability research puede ser aplicado a otras consolas, dispositivos IoT, y sistemas embebidos — qualquer coisa con código fuente accesible y una superficie de ataque grande o suficiente.
Hacia dónde va la escena a partir de aquí
La ns2jb no es el final del viaje de seguridad de la Switch 2 — es el comienzo. La jailbreak actual es un paso bajo en términos de funcionalidad, pero establece la prueba de concepto más concreta vista hasta ahora para la plataforma. El siguiente paso natural — y lo que la comunidad ya espera — es la evolución hacia un exploit de kernel que elimine la necesidad de tethering y ofrezca control total del sistema.
La respuesta de Nintendo será decisiva. El SmileBASIC 4 ya fue eliminado de la eShop británica, lo que significa que solo las copias físicas o descargas previas están disponibles. Si el parche de firmware llega antes de que la comunidad consolide el conocimiento de la ns2jb, la ventana de explotación puede ser muy corta. Pero, como muestra la historia de la Switch 1, incluso una foothold limitada es suficiente para mantener activa la comunidad de modders por años.
La pregunta no es si la Switch 2 se abrirá completamente — es cuánto tiempo puede resistir Nintendo mientras la IA se convierte en parte estándar del toolkit de investigadores de seguridad. La intersección entre IA generativa y seguridad ofensiva es un campo en expansión rápida, y la Switch 2 puede ser apenas el comienzo del que viene por delante.
Fuentes: pepsipu.com, GBAtemp, Android Authority
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
