Skip to content
KitploitKITPLOIT
FerramentasBlog
Log in
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
fusee-gelee — Uma implementação da exploração Fusee Gelee (CVE-2018-6242) para o Nintendo Switch, juntamente com um payload personalizado. | Kitploit
Ferramentas/GitHubGitHub/oliviaholly/fusee-gelee
Segurança de Sistemas EmbarcadosExploraçãoEngenharia ReversaTestes de PenetraçãoSegurança de HardwareDesenvolvimento de PayloadsAnálise de FirmwareExploração de Binários
GitHuboliviaholly/fusee-gelee

fusee-gelee

Uma implementação da exploração Fusee Gelee (CVE-2018-6242) para o Nintendo Switch, juntamente com um payload personalizado.

12há 6 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
Ver Repositório

fusee-gelee

Uma implementação do exploit Fusee Gelee (CVE-2018-6242) para o Nintendo Switch, baseada na vulnerabilidade divulgada por Kate Temkin / ReSwitched em março de 2018.

Lança uma carga arbitrária (por exemplo, hekate) em um dispositivo Tegra X1 no Modo de Recuperação USB (RCM), ignorando completamente a verificação de assinatura da ROM de inicialização.

Contexto

O que é RCM?

RCM (Modo de Recuperação) é um protocolo de recuperação baseado em USB incorporado na ROM de inicialização do Tegra X1. A NVIDIA o projetou para que possa carregar pequenos programas ("applets") em um dispositivo para diagnóstico ou reparo — por exemplo, quando um Switch não encontra um bootloader válido em seu armazenamento.

No Nintendo Switch, o RCM é acessado conectando os pinos 1 e 10 do trilho do joycon direito durante a inicialização. Em operação normal, apenas a NVIDIA pode usar o RCM — todos os comandos devem ser assinados com a chave privada RSA da NVIDIA, e a ROM de inicialização verifica as assinaturas antes de executar qualquer coisa.

Duas camadas de protocolo

O exploit opera em duas camadas de protocolo independentes que compartilham IRAM (RAM no chip):

Camada USB (padrão, EP0): Todo dispositivo USB possui um endpoint de controle (EP0) que lida com requisições padrão como GET_STATUS, GET_DESCRIPTOR, SET_ADDRESS. A ROM de inicialização implementa essas conforme exigido pela especificação USB 2.0. EP0 é implícito — ele não aparece nos descritores de endpoint do dispositivo.

Camada RCM (proprietária da NVIDIA, EP1): A NVIDIA define um endpoint bulk (EP1) para transferir comandos e cargas do RCM. EP1 aparece no descritor do dispositivo em duas direções:

  • 0x01 = OUT (host envia dados para o dispositivo)
  • 0x81 = IN (dispositivo envia dados para o host)

Os dados enviados via EP1 são estruturados como:

[680-byte RCM command header] [payload bytes]

O cabeçalho de 680 bytes é a struct rcm_msg_t — uma estrutura proprietária da NVIDIA contendo módulo/assinatura RSA, ECID, opcode e outros campos. Esse tamanho foi determinado por engenharia reversa da ROM de inicialização do Tegra X1 (veja o banco de dados IDA do q3k). O tegrarcm de código aberto da NVIDIA documenta apenas até 644 bytes (Tegra124); a variante T210 é 36 bytes maior.

A vulnerabilidade

O manipulador de requisições de controle EP0 da ROM de inicialização tem um bug na implementação do GET_STATUS para destinatários ENDPOINT. Do whitepaper de Temkin:

// BUG: should be size_to_tx = sizeof(status), i.e. 2 bytes
size_to_tx = length_read;  // attacker-controlled via wLength, up to 65535

data_to_tx = &status;      // a uint16_t on the stack

memcpy(dma_buffer, data_to_tx, size_to_tx);

O memcpy lê de &status (uma variável de pilha logo abaixo de 0x40010000) e escreve no buffer DMA (em 0x40009000). Com um comprimento superdimensionado:

  • Origem: lê além de &status, pelo restante da pilha, e para dentro da área de carga controlada pelo atacante em 0x40010000+ (colocada lá via escritas bulk EP1).
  • Destino: escreve além do buffer DMA, transbordando pela IRAM e para dentro da própria pilha, sobrescrevendo endereços de retorno.

Os dados de origem incluem um "stack spray" (0x40010000 repetido), que é escrito sobre os endereços de retorno da pilha. Quando o manipulador retorna, a execução salta para 0x40010000 — onde colocamos um pequeno stub de realocação chamado intermezzo.

Tudo isso acontece durante o loop de recebimento do RCM (dentro de handle_control_requests), antes que a ROM de inicialização valide assinaturas. O protocolo RCM é o mecanismo de entrega; o manipulador de controle USB é o gatilho.

Mapa de memória IRAM

0x40005000  +------------------+
            | DMA buffer LOW   |  USB controller writes odd packets here
0x40009000  +------------------+
            | DMA buffer HIGH  |  USB controller writes even packets here
            +------------------+
            | execution stack  |  grows downward toward DMA buffers
0x40010000  +------------------+  <-- stack ends here / payload starts here
            | intermezzo       |  small relocator stub (124 bytes)
0x40010E40  +------------------+
            | user payload pt1 |  first ~16KB of the user payload
0x40014E40  +------------------+
            | stack spray      |  0x40010000 repeated (8640 bytes)
0x40017000  +------------------+
            | user payload pt2 |  remainder of user payload
            +------------------+

A carga do usuário é dividida ao redor do stack spray porque o spray deve ser posicionado de modo que o overflow o copie sobre os endereços de retorno da pilha. O Intermezzo remonta as duas metades em um bloco contíguo em 0x40010000 e salta para ele.

Sequência do exploit

  1. Encontre o dispositivo por VID/PID (0x0955:0x7321) via enumeração USB padrão
  2. Leia o ID do dispositivo de 16 bytes via EP1 IN — o handshake RCM
  3. Envie a carga via escritas bulk EP1 OUT — a ROM de inicialização copia cada pacote dos buffers DMA para a IRAM em 0x40010000+, colocando nosso intermezzo, carga do usuário e stack spray
  4. Garanta que a última escrita tenha como alvo o buffer DMA HIGH (0x40009000)
  5. Envie uma requisição de controle GET_STATUS no EP0 com wLength=0x7000 — isso aciona o memcpy vulnerável, o stack spray sobrescreve os endereços de retorno, e o manipulador retorna para intermezzo
  6. Intermezzo remonta a carga dividida em um bloco contíguo e salta para ele
  7. Execução de código arbitrário no BPMP, antes de qualquer bloqueio de fusíveis ou reduções de privilégio

Uso

pip install pyusb
python launcher.py

Requer um Switch no modo RCM conectado via USB. No macOS, pode ser necessário brew install libusb.

Coloque seu binário de carga em binaries/payload.bin. O intermezzo.bin incluso lida com a realocação da carga e não precisa ser substituído.

Arquivos

  • launcher.py — o script do exploit
  • binaries/intermezzo.bin — stub de realocação (124 bytes), remonta a carga dividida
  • binaries/payload.bin — a carga do usuário a ser executada (ex.: hekate)

Referências

  • Whitepaper do Fusee Gelee (Kate Temkin)
  • Banco de dados IDA da ROM de inicialização do Tegra X1 (q3k / fail0verflow)
  • Cabeçalhos RCM do tegrarcm da NVIDIA
  • ShofEL2 (fail0verflow)
Baixar ferramenta