Um estudante de Caltech, uma IA da OpenAI e um joguinho de programação de $25 na eShop. Essa foi a receita que quebrou a segurança do Nintendo Switch 2 em apenas duas semanas. E o mais absurdo? O exploit funciona no firmware mais recente do console, o 23.0.1.
Sammy Hajhamid, conhecido na internet como pepsipu, publicou na última semana o ns2jb: o primeiro jailbreak puramente por software do Switch 2. Nada de modchip, nada de solda, nada de hardware modificado. Só código, criatividade e uma IA que fez boa parte do trabalho pesado.
Um Jogo de Programação Virou a Porta de Entrada
A história começa com o SmileBASIC 4, um app de criação de jogos que custa $25 na Nintendo eShop. Ele roda no Switch 2 através da camada de retrocompatibilidade com jogos do Switch original, e foi exatamente essa combinação que abriu a brecha.
O Codex, agente de IA da OpenAI, encontrou um integer overflow no interpretador BASIC do SmileBASIC 4. O bug é quase poético na sua simplicidade: quando você remove itens de um array, o interpretador verifica se position + count <= array.length. O problema? Essa soma pode estourar o limite de um inteiro de 32 bits, virar um número negativo e passar pela verificação como se nada tivesse acontecido.
Com isso, o atacante ganha acesso de leitura e escrita fora dos limites da memória alocada. É o tipo de vulnerabilidade clássica que existe desde os anos 90, mas que continua aparecendo em software moderno porque ninguém audita um joguinho de BASIC com o mesmo rigor que audita o kernel.
// Pseudocódigo da vulnerabilidade
// position e count são int32
if (position + count <= array.length) { // overflow aqui!
remove_items(array, position, count);
}
// Se position=2147483640 e count=100, a soma estoura
// e vira um número negativo, passando pelo check
A Cadeia de Exploits: Do BASIC ao Kernel
Encontrar o bug foi só o começo. Transformar um overflow num joguinho de BASIC em execução de código arbitrário no sistema operacional do Switch 2 exigiu uma cadeia de exploits com quatro estágios.
Estágio 1: ROP no SmileBASIC
O integer overflow permite corromper memória de forma controlada. A partir disso, pepsipu montou uma cadeia de Return-Oriented Programming (ROP), reutilizando fragmentos de código que já existiam no executável do SmileBASIC. Como o app roda pela camada de retrocompatibilidade do Switch 1, o ROP chain funciona sem problemas.
Para quem não conhece ROP: imagine que você não pode escrever código novo na memória (porque ela tem proteção de execução), mas pode “pular” para pedaços de código que já existem no programa. Encadeando esses pedaços na ordem certa, você monta um programa inteiro só com trechos que já estavam ali. É como escrever uma carta de resgate usando recortes de jornal.
Estágio 2: Escapando da Sandbox
O ROP chain executa uma chamada IPC (Inter-Process Communication) ao módulo de sistema do filesystem. Aqui entra a segunda vulnerabilidade: um buffer overflow na função Path::Normalize.
Quando o módulo recebe um caminho contendo componentes como /..\, ele aloca um buffer temporário de 0x301 bytes no heap. Mas se o caminho de entrada for maior que isso, o buffer estoura. Esse overflow no stack do módulo de filesystem dá ao atacante execução de código dentro de um processo de sistema, fora da sandbox do aplicativo.
// Caminho malicioso que causa o overflow
/..\.......[ dados que excedem 0x301 bytes ]......
// O módulo fs aloca 0x301 bytes mas aceita input maior
// → stack buffer overflow → controle do fluxo de execução
Estágio 3: Escalando Privilégios
Com execução de código no módulo do filesystem, o exploit modifica o PID (Process ID) salvo para 1, o que concede permissão “FullPermission” no sistema operacional do Switch. Isso permite acesso irrestrito ao filesystem, incluindo a leitura de código criptografado de outros módulos do sistema.
Estágio 4: Código Arbitrário no Nível do Sistema
O passo final é o mais engenhoso. O atacante usa o acesso ao módulo ro (responsible for loading executables) para substituir objetos ExeFS por filesystems customizados contendo código modificado. Como o loader confia nas assinaturas criptográficas dos módulos já carregados, o código injetado roda com as permissões do módulo ro, que incluem acesso a SVCs (Supervisor Calls) do kernel.
| Estágio | Alvo | Técnica | Resultado |
|---|---|---|---|
| 1 | SmileBASIC 4 | Integer overflow + ROP | Execução de código no app |
| 2 | Módulo fs | Buffer overflow em Path::Normalize | Escape da sandbox |
| 3 | Sistema | Manipulação de PID | FullPermission |
| 4 | Módulo ro | Substituição de ExeFS | Código arbitrário com acesso ao kernel |
O Papel da IA: Codex Como Co-Hacker
Aqui é onde a história fica realmente interessante pra quem acompanha o mundo de IA e segurança.
Pepsipu não usou o Codex só pra escrever código. Ele montou um harness completo ao redor do Switch, com um JetKVM que permitia ao Codex enviar inputs de controle via USB e receber a saída de vídeo por HDMI. Ele até conectou um interruptor Bluetooth para que a IA pudesse ligar e desligar o console fisicamente.
A ideia original era ambiciosa: “A primeira coisa que eu fiz foi montar um harness ao redor do Switch 1 e 2 para que o Codex pudesse, idealmente, hackear o Switch 2 sem mim.” Não rolou exatamente assim (o humano ainda precisou direcionar bastante), mas o Codex foi responsável por identificar a vulnerabilidade no SmileBASIC, analisar componentes do sistema e desenvolver partes distintas do exploit.
O mais impressionante é o timeline: duas semanas. Jailbreaks anteriores de consoles costumavam levar meses ou anos de engenharia reversa manual. Ter uma IA que consegue analisar binários, sugerir vetores de ataque e gerar código de exploit em tempo real muda completamente a dinâmica.
E depois de quebrar o console, pepsipu “vibe-coded” mods para o Mario Kart World em um dia, incluindo o infame Peter Griffin como personagem jogável. Porque, claro, se você vai demonstrar um jailbreak histórico, tem que ser com estilo.
O Que Dá Pra Fazer (e o Que Não Dá)
Antes de sair correndo pra comprar um SmileBASIC 4, vale entender as limitações.
O que funciona:
- Rodar aplicativos homebrew
- Modificar jogos (mods, skins customizadas)
- Backup de saves
- Acesso a periféricos de hardware via MMIO
- Dump de código criptografado dos módulos do sistema
- Engenharia reversa do sistema operacional
O que não funciona (ainda):
- Pirataria de jogos: o jailbreak não compromete a cadeia de secure boot
- Custom firmware persistente: é um jailbreak tethered, precisa de um computador conectado e reaplicação a cada reboot
- Acesso total ao kernel: o exploit chega ao nível de sistema, mas não é um kernel exploit completo
O fato de ser tethered é uma limitação significativa. Desligou o console? Precisa rodar o exploit de novo com um PC conectado. Isso torna o uso casual bem menos prático, mas pra pesquisadores de segurança e desenvolvedores homebrew, é mais que suficiente.
Nintendo e Sua Eterna Guerra Contra Hackers
A Nintendo tem um histórico longo e agressivo de combate a jailbreaks. O Switch 1 foi famosamente comprometido pelo exploit Fusée Gelée em 2018, uma falha de hardware no chip Tegra X1 que a Nintendo nunca conseguiu corrigir por software (apenas revisões de hardware resolveram).
Com o Switch 2, a Nintendo claramente investiu pesado em segurança. O console usa um chip customizado mais moderno, com múltiplas camadas de proteção. Que o primeiro jailbreak tenha vindo de um app de terceiros rodando em retrocompatibilidade, e não de uma falha no sistema operacional em si, mostra que a segurança core do Switch 2 é significativamente melhor que a do antecessor.
A resposta esperada da Nintendo é previsível:
- Remover o SmileBASIC 4 da eShop (ou pelo menos da lista de títulos compatíveis com Switch 2)
- Lançar um patch de firmware corrigindo o buffer overflow no módulo fs
- Processar qualquer pessoa ou grupo que distribua ferramentas baseadas no exploit
O ponto 3 não é brincadeira. Em 2020, a Nintendo processou e conseguiu a prisão de membros do Team Xecuter, grupo que vendia modchips para o Switch original. Gary Bowser (sim, esse é o nome real dele) foi condenado a 40 meses de prisão e multa de $10 milhões.
A Nova Era: IA na Pesquisa de Segurança
O ns2jb é um marco não só pelo jailbreak em si, mas pelo que representa para o futuro da pesquisa de vulnerabilidades.
Até pouco tempo, encontrar exploits em consoles de videogame era um trabalho artesanal. Pesquisadores passavam meses fazendo engenharia reversa de firmware, analisando binários byte a byte, e testando hipóteses manualmente. O processo exigia conhecimento profundo de arquitetura de processadores, sistemas operacionais e criptografia.
Com ferramentas como o Codex, esse processo está sendo acelerado de forma dramática. A IA não substitui o pesquisador (pepsipu ainda precisou de muito conhecimento técnico para direcionar o trabalho), mas funciona como um multiplicador de produtividade absurdo. Duas semanas para um jailbreak completo de um console moderno é um timeline que teria sido impensável há cinco anos.
Isso tem implicações sérias para a indústria. Se pesquisadores independentes conseguem quebrar consoles em semanas com ajuda de IA, o que atores maliciosos bem financiados conseguem fazer? A corrida entre atacantes e defensores já era desigual, e a IA está inclinando a balança ainda mais para o lado ofensivo.
Por outro lado, a mesma tecnologia pode ser usada na defesa. Empresas como a Nintendo poderiam (e provavelmente vão) usar IA para auditar seus próprios sistemas, encontrar vulnerabilidades antes que pesquisadores externos as descubram, e gerar patches automaticamente. A questão é: quem vai adotar a IA mais rápido, os atacantes ou os defensores?
O Contexto Mais Amplo
O jailbreak do Switch 2 não aconteceu no vácuo. Pouco antes, o PlayStation 5 também recebeu um jailbreak permitindo emulação de PS2 com discos originais. Parece que 2026 está sendo o ano em que a segurança dos consoles modernos está sendo colocada à prova.
Para desenvolvedores, a lição é clara: retrocompatibilidade é uma superfície de ataque. O SmileBASIC 4 é um app do Switch 1 rodando em uma camada de compatibilidade. A vulnerabilidade existia no código do app, não no sistema operacional do Switch 2, mas a combinação dos dois criou a cadeia de exploits.
Isso vale pra qualquer sistema que mantém compatibilidade com software legado. Docker containers rodando binários antigos, browsers executando JavaScript de versões anteriores, sistemas operacionais mantendo APIs deprecated: cada camada de compatibilidade é uma camada a mais para auditar e proteger.
E Agora?
O código do ns2jb está público no GitLab. Qualquer pessoa com um Switch 2, um PC, e $25 para o SmileBASIC 4 pode testar, enquanto a Nintendo não corrigir. O clock está rodando.
Para a comunidade homebrew, é uma vitória significativa. Para a Nintendo, é mais uma rodada na guerra infinita contra a modificação de seus consoles. E para o resto de nós, é mais uma prova de que a IA está mudando fundamentalmente a velocidade com que vulnerabilidades são descobertas.
Se eu fosse a Nintendo, estaria menos preocupado com esse jailbreak específico (que será corrigido) e mais preocupado com o precedente: um estudante universitário, uma IA, e duas semanas. Quanto tempo até o próximo?
Fonte de inspiração: Jailbreaking the Switch 2 (pepsipu.com)













