Malware & Ameaças
TV box no Brasil: BADBOX, Vo1d e o risco no firmware
TV boxes sob análise: T95, X96, MXQ, chipsets, variantes, BADBOX e Vo1d. Como investigar firmware e inventário sem confundir indícios com infecção.
Uma TV box pode reproduzir vídeo normalmente enquanto participa de uma infraestrutura controlada por terceiros. O risco mais interessante para a análise técnica está abaixo do aplicativo visível: firmware, bibliotecas do sistema, permissões privilegiadas e componentes capazes de receber novas instruções.
No Brasil, a Anatel documentou em 2025 riscos de BADBOX 2.0 em aparelhos não homologados. Seu informe técnico contextualiza a distribuição desses equipamentos no país. Esta matéria explica os mecanismos conhecidos e propõe uma triagem reproduzível, sem executar malware ou consultar seus servidores.
Representações editoriais, não fotografias de amostras infectadas. A placa ilustrada não identifica o SoC de nenhum aparelho real.
Quais modelos observar: nome comercial não é diagnóstico
T95, X96 Mini, X96Q, X88 e variantes MXQ são nomes que ajudam a reconhecer esse ecossistema. Não há, nas referências consultadas, um ranking auditado que permita chamá-los de “os mais vendidos no Brasil”. Além disso, nomes semelhantes podem circular com placas, memórias, módulos de rádio e imagens de sistema diferentes.
A investigação original da HUMAN sobre BADBOX examinou um T95 comprometido desde a primeira inicialização. O relatório BADBOX 2.0 inclui identificadores como X96mini, X96Q, X88 e MXQ9PRO entre amostras relacionadas ao código de backdoor. Isso não comprova que todo produto que ostenta esses nomes esteja infectado.
| Nome ou família | Hardware que pode ser documentado | Como interpretar a relação com segurança |
|---|---|---|
| InXPlus / TouroBox, unidades do estudo Anatel | O informe não identifica SoC, RAM e revisão das placas. | Malware persistente e uso como proxy foram confirmados nas unidades examinadas; não atribuir automaticamente a toda unidade comercializada. |
| T95, amostra H616 | Allwinner H616 no caso de pesquisa identificado como T95-H616 | Há investigação de uma amostra; não generalizar para todas as revisões T95 |
| X96 Mini, variante S905W | Amlogic S905W, Cortex-A53; opções de DDR3 e eMMC | O nome X96mini aparece no relatório de 2025; identificar a variante concreta antes de relacionar os casos |
| X96Q / X88 / MXQ9PRO | SoC não determinável apenas pelo identificador de modelo da lista de malware | O relatório associa identificadores a amostras/APKs, não oferece uma ficha única de todas as placas vendidas |
| MXQ / MXQ Pro genéricos | Identificação física e de firmware necessária; não pressupor um chipset | Nome de anúncio e aparência não confirmam nem descartam backdoor |
| Tanix TX6, placa descrita no Linux | Allwinner H6 | Exemplo de hardware identificável; a referência citada não demonstra infecção dessa placa |
O registro de pesquisa T95-H616 ajuda a delimitar a amostra. A ficha da variante X96 Mini S905W informa processador, DDR3 de 1/2 GB, eMMC de 8/16 GB, Wi-Fi b/g/n e interfaces. Esses são dados declarados daquela oferta, não medições de toda caixa com a mesma etiqueta. O device tree Tanix TX6 no Linux vincula a placa descrita ao H6.
O estudo brasileiro oferece uma evidência mais direta: a Anatel identificou malware ativo e persistente nas amostras InXPlus e TouroBox, com processos, conexões externas e uso não autorizado como proxy residencial. Os exames combinaram observação em standby, engenharia reversa e comparação de indicadores. O informe não publica uma ficha de chipsets dessas unidades; preencher essa lacuna por aparência inventaria precisão.
Por dentro: o SoC não explica sozinho a infecção
O SoC integra CPU e outros controladores; a placa acrescenta RAM, armazenamento, alimentação, rádio e conectores. Uma box costuma manter bootloader, kernel, componentes do fabricante e aplicativos em áreas distintas. A aparência externa não revela quais partições são verificadas nem quem controla a chave de atualização.
RAM determina o espaço de trabalho. eMMC ou outro armazenamento conserva o sistema e dados. O módulo Wi-Fi pode ter driver e firmware próprios. Portas USB e Ethernet ampliam as formas de interação. Esses componentes ajudam a planejar aquisição e instrumentação, mas o simples uso de Allwinner, Amlogic ou qualquer outro fornecedor não constitui uma vulnerabilidade.
Uma falha pode estar no software instalado por um integrador, numa atualização, num aplicativo com privilégios ou na ausência de controle de integridade. Distinguir esses caminhos evita acusar um fabricante de chip por um problema introduzido na imagem de sistema. O objeto do exame deve ser a combinação de placa, build e cadeia de distribuição.
BADBOX: quando a persistência começa antes do aplicativo
Na análise de 2023, a HUMAN descreveu uma modificação de libandroid_runtime.so, carregamento de componentes adicionais e atividade ligada ao diretório Corejava. A alteração de uma biblioteca de sistema amplia o alcance para além de um APK isolado. Esse é o comportamento das amostras examinadas, não uma descrição universal de AOSP.
No BADBOX 2.0, a pesquisa identifica a backdoor BB2DOOR e caminhos envolvendo biblioteca modificada e aplicativos infectados. Os resultados incluem abuso como proxy residencial e fraude publicitária. A orientação do FBI de junho de 2025 também descreve infecção anterior à compra ou durante a instalação de aplicativos. Os mecanismos podem variar entre campanhas e amostras.
Firmware ou componente introduzido na distribuição
↓
Execução privilegiada na inicialização ou em aplicativo
↓
Comunicação de controle
↓
Carregamento de módulos adicionais
↓
Atividade de rede sem correspondência clara na interfaceO fluxo é uma síntese didática de classes de comportamento. Não reproduz um protocolo operacional nem oferece implementação da backdoor. Seu valor é mostrar os pontos nos quais um examinador pode buscar evidência: origem da execução, persistência, contexto de privilégio e atividade de rede.
Vo1d: nomes parecidos e alterações na área do sistema
A Doctor Web publicou em setembro de 2024 a análise de Android.Vo1d, com casos em R4, TV BOX e KJ-SMART4KVIP. O relatório descreve mudanças em install-recovery.sh e daemonsu, além de componentes como /system/xbin/vo1d e /system/xbin/wd. A grafia “vo1d” usa o número um, lembrando o nome legítimo “vold”.
A mesma pesquisa registra versões declaradas de Android incompatíveis com outros indícios do build e não determina uma única origem de infecção para todos os casos. Preserve essa incerteza. Vo1d e BADBOX são análises distintas; compartilhar uma classe de equipamento não permite juntar todos os indicadores numa campanha única.
Para a triagem, compare caminho, hash, origem e modo de inicialização. Um nome suspeito é uma pista. Um arquivo legítimo pode compartilhar parte do nome; um invasor pode mudar a grafia. A conclusão precisa ligar o objeto à atividade observada ou a uma análise verificável da amostra.
Android anunciado, certificação e homologação são verificações separadas
O número de Android exibido pode ser um texto de propriedades. Registre release, SDK, build fingerprint e nível de patch, observando inconsistências. A documentação Android sobre postura de segurança distingue níveis de atualização de componentes. Uma string recente não comprova que todos os patches foram aplicados.
A certificação Play Protect é diferente do recurso de verificação de aplicativos. Desativar o verificador não certifica um aparelho. Ausência de certificação é um sinal para avaliar suporte e procedência, não uma prova automática de malware. Também existem ecossistemas legítimos que não dependem dos serviços Google.
No Brasil, consulte a página de TV boxes homologadas da Anatel e confira o certificado correspondente ao modelo. A própria página aponta para a base de consulta atualizada, além da listagem. Homologação, compatibilidade Android e análise do firmware respondem a perguntas diferentes; nenhum selo deve virar promessa de invulnerabilidade.
Verified Boot: integridade exige uma raiz de confiança útil
O Verified Boot do Android encadeia verificações desde uma raiz protegida até partições do sistema, com mecanismos de proteção contra rollback. A existência da tecnologia na plataforma não garante sua ativação correta em cada box.
Há também uma questão de origem: uma imagem maliciosa assinada pela chave confiada ao equipamento pode passar na validação criptográfica. O mecanismo responde se aquela versão foi aceita pela cadeia configurada. Avaliar quem controla a chave e o que foi autorizado a entrar na imagem continua necessário.
Um estado desbloqueado, root disponível ou patch antigo aumenta a necessidade de revisão, mas não identifica a família de malware. Do mesmo modo, um estado declarado “green” em um sistema potencialmente comprometido deve ser confrontado com evidências independentes. A fonte do dado participa da confiança no resultado.
Triagem sem transformar o exame numa alteração do aparelho
Comece registrando etiqueta, alimentação, portas, fornecedor, build e comportamento em uma rede isolada. Não faça login com conta pessoal. Se ADB já estiver disponível em uma interface autorizada, comandos de leitura podem ajudar. Não habilite ADB pela rede apenas para imitar um roteiro, e não conecte equipamentos de terceiros.
adb devices
adb shell getprop ro.product.model
adb shell getprop ro.board.platform
adb shell getprop ro.build.fingerprint
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.security_patch
adb shell getprop ro.boot.verifiedbootstate
adb shell id
adb shell pm list packages -fO ADB do Android SDK fornece a interface de shell utilizada neste roteiro de leitura. Os comandos não foram executados contra uma box física neste trabalho. A ausência de um campo pode significar que o fabricante não o expôs. Guarde o texto original, o horário e a versão da ferramenta. Não use uma propriedade vazia como prova de que uma proteção está ativa.
Abrir a caixa pode ajudar a identificar o SoC e a revisão, mas exige cuidados próprios de eletrônica. Conectores não documentados não devem receber tensões por tentativa. Não grave firmware de outro modelo porque o gabinete parece igual: memória, bootloader e periféricos podem divergir.
Um classificador de pendências, não um detector de malware
O exemplo original usa uma fixture de inventário para orientar revisão. Ele não lê o aparelho nem decide que há infecção. Valores desconhecidos permanecem como lacunas, e um estado favorável não produz um certificado de segurança.
from datetime import date
def revisar_inventario(item, hoje):
pendencias = []
if not item.get('origem_firmware'):
pendencias.append('origem do firmware não documentada')
estado = item.get('boot', 'desconhecido')
if estado != 'green':
pendencias.append('integridade de boot exige revisão')
patch = item.get('patch')
try:
instante = date.fromisoformat(patch)
except (TypeError, ValueError):
pendencias.append('patch ausente ou inválido')
else:
idade = (hoje - instante).days
if idade < 0 or idade > 180:
pendencias.append('data de patch exige verificação')
return {'pendencias': pendencias, 'malware': 'não determinado'}
fixture = {'boot': 'orange', 'patch': '2020-01-01'}
resultado = revisar_inventario(fixture, date(2026, 10, 15))
assert len(resultado['pendencias']) == 3
assert resultado['malware'] == 'não determinado'
print('pendências registradas sem inventar diagnóstico')O prazo de 180 dias é uma política ilustrativa desta fixture, não um requisito universal ou regra da Anatel. A revisão real precisa considerar suporte do fabricante, boletins pertinentes e risco do uso. Uma data futura é tratada como anomalia de registro e não como evidência de atualização antecipada.
Rede: o que observar e o que o tráfego não prova
Em segmento próprio, registre DNS, destinos, duração, volume e relação com as ações na tela. Uma box que permanece ativa durante ociosidade merece comparação com uma linha de base. Atualizações e serviços legítimos também geram tráfego; atividade de fundo não é sinônimo de proxy criminoso.
Uma cadeia convincente liga processo ou módulo, persistência, conexão e finalidade demonstrada. Indicadores históricos ajudam a pesquisa, mas endereços podem mudar de dono. Não copie uma lista antiga para afirmar infecção em 2026. Evite consultar C2 real: o artigo usa nomes e objetos de laboratório.
| Observação | Conclusão admissível | O que falta |
|---|---|---|
| Patch antigo ou release inconsistente | Atualização e identidade do build precisam de revisão | Não identifica malware |
| Arquivo alterado frente a uma referência confiável | Os bytes divergem daquela referência | Origem, finalidade e cobertura da comparação |
| Conexões em ociosidade | Existe atividade sem ação visível naquele período | Processo, módulo e natureza do serviço |
| Componente analisado e execução correlacionada | Comportamento delimitado sustentado por evidência | Alcance temporal e diferenças entre variantes |
Por que reset e troca de aplicativo podem ser insuficientes
Um reset que apaga dados de usuário não necessariamente regrava uma partição modificada do sistema. Se a persistência estiver nessa camada, o componente pode voltar. Não prometa que um antivírus ou restauração elimina qualquer backdoor: cobertura e privilégios de acesso variam.
Havendo indício consistente, isole o equipamento e preserve a evidência antes de alterações. Uma recuperação depende de imagem confiável para a placa exata e de um procedimento verificável. Quando não é possível estabelecer origem e integridade, substituir o aparelho pode ser a decisão mais prática.
Para aprofundar o método de evidência, leia IPED e proveniência. Para escolher sensores, consulte o guia de hardware Wi-Fi. O diferencial de uma análise profissional é conseguir explicar a cadeia entre firmware, execução e rede, mantendo claras as lacunas que ainda precisam ser testadas.
