
Quando li pela primeira vez o relatório técnico publicado pela High Code (a mesma equipe por trás do High Boy, sobre a qual já escrevi aqui no Ciência Embarcada), confesso que fiquei impressionado com o nível de sofisticação do ataque e ainda mais impressionado com a qualidade técnica do relatório.
Para quem me conhece, sabe que o ESP32-S3 é um microcontrolador que aparece com frequência nos meus projetos e discussões. É um chip excelente, com bastante poder de processamento para aplicações IoT. Mas neste caso, ele foi usado para substituir o Elemento Seguro certificado Common Criteria EAL5+ da Ledger Nano S Plus original — é a partir daqui que se inicia o ataque.
Neste artigo eu vou destrinchar o que foi encontrado, explicar por que isso importa do ponto de vista de hardware e segurança, e o que qualquer pessoa que compra eletrônicos de fontes não oficiais precisa saber.
O que é a Ledger Nano S Plus e por que ela importa?
Carteiras de hardware para criptomoedas como a Ledger Nano S Plus existem para resolver um problema fundamental: guardar as chaves privadas de uma forma que elas nunca precisem sair do dispositivo. O modelo de segurança inteiro depende de duas premissas:
- O material secreto nunca sai em texto claro
- O hardware que você está usando é autêntico.
A Ledger originial utiliza um Elemento Seguro ST33J2M0 (certificado EAL5+) combinado com um microcontrolador de aplicação STM32WB55. Essa arquitetura garante que mesmo que alguém obtenha acesso físico ao dispositivo, extrair as chaves seja extremamente difícil.
O ataque descrito ocorreu substituindo tudo isso por um único ESP32-S3, de uso geral, com as marcações dos chips fisicamente raspadas para dificultar a identificação.
Como a unidade falsa chegou às mãos dos pesquisadores
O dispositivo foi adquirido no JD.com, um marketplace de e-commerce da China Continental, em março de 2026. A embalagem era visualmente idêntica à original: caixa, selos, material impresso, cabo USB e até o QR code no encarte “Comece Aqui”. O preço também coincidia exatamente com o valor oficial da Ledger segundo os pesquisadores.
Mas o primeiro sinal de problema apareceu já na primeira conexão com o aplicativo oficial Ledger Wallet (antigo Ledger Live), onde o dispositivo reprovou na verificação de autenticidade (Genuine Check), que é a rotina criptográfica que confirma se o Elemento Seguro conectado possui um certificado assinado pela Ledger SAS. Uma unidade legítima passa nessa verificação sempre. A reprovação em um produto aparentemente novo e lacrado é um indicador imediato de adulteração na fabricação.
O hardware por dentro

Fonte: High Boy Blog
Ao abrir o dispositivo, os pesquisadores encontraram uma PCB verde de dupla camada, com qualidade de fabricação consistente com uma produção em escala comercial, ou seja, não era um protótipo. Os componentes incluem:
- MCU principal: ESP32-S3 com marcações fisicamente raspadas (acabamento fosco inconsistente com o original de fábrica)
- Cristal oscilador: YXC 40 MHz (Yangxing Tech, Shenzhen) que serve de frequência de referência padrão para ESP32-S3
- Flash: 4 MB (partições NVS, app0, app1 e SPIFFS)
- USB: Interface HID via TinyUSB, que imita o descritor USB legítimo da Ledger
- Antena: Traço serpentino para Wi-Fi/BLE no próprio PCB
Esse último item é um sinal de alerta imediato para qualquer pessoa com experiência em hardware, pois a Ledger Nano S Plus original não tem rádio algum. É um dispositivo propositalmente air-gapped (isolado fisicamente) do ponto de vista de conectividade sem fio. Ver uma antena Wi-Fi/BLE integrada ao PCB de um dispositivo que deveria ser air-gapped é, por si só, uma bandeira vermelha.
❓
O detalhe curioso é que, embora o hardware esteja fisicamente presente, o firmware nunca ativa o Wi-Fi. Não há nenhuma chamada a WiFi.begin(), nenhum SSID, nenhuma API de socket no código. A antena existe mas é ignorada pelo software, pois vetor de exfiltração é outro, bem mais discreto, como veremos.
O dump da flash e descobertas graves
Com o dispositivo em mãos, a equipe extraiu o conteúdo da flash usando o esptool.py via UART, colocando o MCU em modo de download pela ponte entre os pads de teste EN e GPIO0, procedimento padrão para qualquer ESP32-S3, mas o que encontraram na partição NVS foi o pior cenário possível:
| Chave NVS | Valor Recuperado |
|---|---|
| pin_code | 348962 (PIN em texto claro) |
| mnemonic_words | Duas frases de 24 palavras BIP39 (texto claro) |
| fw_version | 1.0.0 |
| hw_version | Ledger Nano s+ V2.1 |
| serial_num | 72654036432549 |
Nenhuma criptografia, nenhuma derivação, nenhum wrapping. O PIN e as frases mnemônicas ficam gravados como texto ASCII na flash, acessíveis a qualquer pessoa com um cabo e o esptool.
Para quem trabalha com ESP32, isso é tecnicamente revoltante: o próprio chip possui primitivas de segurança de hardware, como flash encryption, secure boot v2, HMAC, assinatura digital, armazenamento em eFuse. O firmware falso simplesmente não usa nenhuma delas.
🔎
Mesmo que alguém conseguisse extrair a flash de uma Ledger legítima, encontraria apenas slots criptografados cuja descriptografia depende de uma chave no Elemento Seguro, que por sua vez exige a interação física com o dispositivo. No clone, a chave simplesmente não existe porque não há criptografia.
O vetor real
Aqui está o truque mais elegante do ataque. O encarte “Comece Aqui” dentro da embalagem falsa possui um QR code que não aponta para o site oficial da Ledger. Ele direciona para um site clonado hospedado no Tencent CloudBase, que serve instaladores falsos do Ledger Wallet para Android (APK), Windows, macOS e iOS (via TestFlight).
O hardware falso é essencialmente um prop (uma isca) para convencer o usuário a instalar o aplicativo malicioso. Todo o roubo acontece via software, com a exfiltração dos dados pelo canal USB/BLE que o próprio usuário já usa para parear o dispositivo com o aplicativo, sem nenhum tráfego de rede anômalo originado pelo hardware.
A cadeia de ataque em seis fases
O APK falso (com.ledger.live, versão 3.99.1) foi assinado com um certificado de debug do Android (android@android.com) e não com o certificado de produção da Ledger SAS. Esse detalhe, por si só, já descarta a legitimidade do aplicativo.
Internamente, ele é um app React Native com bytecode Hermes (v96), totalizando 82 MB com 194.647 funções de bytecode e mais de 685 MB de saída de desmontagem. Os pesquisadores identificaram mais de 35 componentes maliciosos.
Os pesquisadores identificaram que o ataque segue seis as seguintes seis fases:
Fase 1 — Injeção via APDU: O firmware falso estende a resposta do comando GET_VERSION padrão do protocolo Ledger com oito campos TLV adicionais, incluindo a frase mnemônica, a URL do C2 (servidor de comando e controle malicioso) e uma chave pública RSA-2048. Esses campos são sintaticamente indistinguíveis dos campos legítimos para um parser sequencial.
Fase 2 — Parsing dos campos maliciosos: A função parseGetVersionResponse() no módulo Metro 2109 extrai os oito campos extras do buffer APDU e os armazena em slots de closure JavaScript.
Fase 3 — Propagação de estado: A função getDeviceInfo() registra todos os campos — incluindo o mnemônico — via mmdLog e dispara a função verifyDeviceMnemonic().
Fase 4 — Validação e normalização: O código verifica se a frase tem 12 ou 24 palavras (válido para BIP39), normaliza espaços e sanitiza strings. O nome da variável interna é verifyMnemonicCiyuType, onde ciyu (词语) significa “palavra” em mandarim — um artefato linguístico de atribuição.
Fase 5 — Criptografia RSA e exfiltração: A seed é criptografada com a chave RSA-2048 recebida do firmware (ou uma chave hardcoded como fallback) e enviada por HTTP POST para kkkhhhnnn.com. Também existe um mecanismo de retry automático: se a chave do firmware falhar ao parsear, o app usa a chave embutida, garantindo que a exfiltração nunca falhe completamente.
Fase 6 — Persistência local: O mnemônico é salvo no AsyncStorage e localStorage sob a chave ll_mnemonic_verifications, escolhida para parecer um recurso legítimo de verificação do Ledger Live. Isso evita re-exfiltração em conexões futuras.
Existe ainda um canal secundário disfarçado de consulta de atualização de firmware, que exfiltra metadados do dispositivo (código de campanha, nome do dispositivo) para s6s7smdxyzbsd7d7nsrx.icu — hospedado na Alibaba Cloud em Hong Kong.
Infraestrutura de Comando e Controle (C2)
| Servidor | Papel | Hospedagem |
|---|---|---|
| kkkhhhnnn.com | C2 principal (hardware + APK) | Cloudflare (domain fronting) |
| s6s7smdxyzbsd7d7nsrx.icu | APK C2 #1 (metadados) | Alibaba Cloud Hong Kong |
| www.ysknfr.cn | APK C2 #2 | Co-hospedado com rede de jogos ilegais chineses |
O servidor principal retornava respostas de erro em três idiomas: chinês, inglês e indonésio, informação que é um artefato de infraestrutura que contribui para a atribuição da operação.
Evidências de origem chinesa
Os pesquisadores identificaram quinze indicadores independentes apontando para origem chinesa:
- Comentários em chinês simplificado no bytecode compilado (Metro bundle)
- Empresa shell registrada em Xangai atuando como intermediária de distribuição
- Infraestrutura hospedada em Alibaba Cloud Hong Kong com provedores DNS e identificadores Baidu Analytics associados
- Co-hospedagem no mesmo /24 (mesmo intervalo de endereços IPv4) de operações de jogos ilegais chineses
- O próprio nome da variável
verifyMnemonicCiyuType, já que ciyu é mandarim para “palavra” - Artefatos de caminho de build: /Users/mac/.platformio/ no ELF compilado, toolchain PlatformIO + Arduino-ESP32
O impacto: US$ 9,5 milhões em criptomoedas roubadas
A pesquisa confirmou perdas acima de US$ 9,5 milhões em criptomoedas distribuídas por 20 ecossistemas de blockchain, com mais de 50 vítimas confirmadas alcançadas por cinco vetores de distribuição: hardware físico, APK Android, instalador Windows, instalador macOS e iOS via TestFlight.
O nível de sofisticação indica uma operação ativa e mantida: infraestrutura atualizada onze dias antes da análise, suporte a 20 blockchains e 8 idiomas de interface no firmware, e um sistema de rastreamento de campanhas via código de agente.
Importância para a comunidade de sistemas embarcados
Do ponto de vista técnico, o que mais me chama atenção nesse caso é como o ESP32-S3 foi usado. O chip tem recursos de segurança reais, como flash encryption, secure boot, e eFuse que, se habilitados, tornariam a extração da flash via esptool trivialmente inútil. Os atacantes simplesmente não os ativaram, provavelmente para facilitar o desenvolvimento e a manutenção do firmware malicioso.
Isso levanta uma questão importante para quem desenvolve produtos com ESP32: habilitar os mecanismos de segurança de hardware não é opcional em produtos que armazenam material sensível. É um requisito básico de design.
O caso também ilustra algo que já discuti em outros contextos: a cadeia de suprimentos de hardware é um vetor de ataque real e subestimado. Não se trata de um risco teórico ou de uma ameaça avançada, mas sim de uma operação comercial em escala, distribuída por marketplaces mainstream, com UI polida e infraestrutura ativa.
Como se proteger
Para usuários de hardware wallets:
- Compre exclusivamente pelos canais oficiais do fabricante. A Ledger não vende no JD.com, AliExpress ou Taobao. Qualquer unidade nesses canais está, por definição, fora da cadeia de suprimentos homologada.
- Sempre execute o Genuine Check na primeira conexão com o Ledger Wallet oficial (baixado direto de ledger.com).
- Desconfie de encartes com QR codes que não apontem para o domínio oficial do fabricante. Antes de escanear, verifique o destino manualmente.
- Instale o aplicativo companion apenas das lojas oficiais (Google Play, App Store).
Para desenvolvedores e fabricantes de hardware:
- Habilite flash encryption e secure boot em todo produto que armazene material criptográfico ou segredos de usuário.
- Implemente verificação de integridade criptográfica no firmware, com raiz de confiança ancorada em hardware.
- Considere que a presença de antenas de rádio em um produto que não deveria tê-las é um sinal de alerta para o usuário final, então se precisar, documente e justifique claramente.
Indicadores de Comprometimento (IoCs)
Para equipes de segurança que desejam ingerir esses dados em pipelines defensivos:
| Tipo | Valor |
|---|---|
| Domínio C2 | kkkhhhnnn.com |
| Domínio C2 | s6s7smdxyzbsd7d7nsrx.icu |
| Domínio C2 | www.ysknfr.cn |
| SHA-256 APK | 62723c30f17be2e0e59a529b7adc1a7d602a78973b9acc68a5a076eadcbc54f3 |
| SHA-256 Firmware | 93d2d28f2d46e626172fa592acee84aa5ec7c1076d59e69608ba03abfab4812a |
| SHA-256 Flash dump | 8fdddbaefbc014b4377725290c2e3c69c3ff211d71cfa1d7b8d1c41b764539ba |
| Package APK | com.ledger.live (versão 3.99.1, build 36176158) |
| Certificado APK | android@android.com (serial 93:6e:ac:be:07:f2:01:df) |
Conclusão
Este caso é, segundo os próprios pesquisadores, a contrapartida de hardware wallet mais tecnicamente completa já documentada publicamente, e eu concordo com eles. Não é uma PCB improvisada nem um firmware simplório, é uma operação com PCB de fabricação comercial, firmware suportando 20 blockchains e 8 idiomas, aplicativo trojanizado distribuído em cinco plataformas e infraestrutura C2 ativa e mantida.
O fato de o ESP32-S3 estar no centro disso tudo é uma lembrança útil para nossa comunidade: chips que usamos para fazer projetos legítimos são os mesmos chips que atacantes usam para construir hardware malicioso. A diferença está inteiramente no firmware.
Se você usa ou planeja usar hardware wallets para proteger ativos digitais significativos, este artigo deveria ser uma leitura obrigatória. E se você desenvolve hardware com ESP32, é um bom momento para revisar se sua cadeia de suprimentos e processo de fabricação incluem as proteções que o chip já oferece nativamente.
Deixo aqui também meus parabéns a equipe da High Code, que tem feito trabalhos incríveis de pesquisa, conscientização sobre cibersegurança e desenvolvimento com o High Boy. São graças a pessoas como vocês que eu sou muito grato ter nascido brasileiro! E se você ainda não conhece eles, dá uma olhada nesse post aqui.


Deixe um comentário