Como identificar um pacote Android desconhecido

Aparece um nome de pacote em um chamado de suporte. Um inventário de MDM sinaliza algo que ninguém reconhece. Um cliente dita uma cadeia que leu nas Configurações depois de uma ligação da qual agora desconfia. Nos três casos a evidência inicial é a mesma: uma cadeia em DNS invertido como com.system.service, e nada mais.

A cadeia é escolhida por quem construiu o aplicativo, então sozinha não prova nada. Ainda assim basta para começar, e cinco verificações costumam resolver a questão sem acesso ao dispositivo.

O que é um nome de pacote

O Android identifica cada aplicativo instalado por um nome de pacote escrito em DNS invertido: com.exemplo.meuapp. Ele precisa ser único no dispositivo e, para o que é distribuído pela Google Play, único em toda a Play.

Três propriedades importam para identificar:

• É escolhido por quem construiu o aplicativo. Não há autoridade de registro nem verificação de que o domínio do nome pertença ao desenvolvedor. com.banco.seguro pode ser publicado por quem chegar primeiro à Play ou a um canal de instalação lateral.
• É estável após a instalação. Diferente do rótulo e do ícone — que um aplicativo pode alterar em tempo de execução —, o nome de pacote é fixo na cópia instalada. Isso o torna um identificador utilizável mesmo quando o nome exibido engana de propósito.
• Não é uma identidade. Dois aplicativos com o mesmo nome de pacote não são necessariamente o mesmo aplicativo. Demonstrar que são é justamente o objeto da terceira verificação.

Verificação 1 — É mesmo um pacote do sistema?

É aqui que a maior parte das identificações erra, e é aqui que o padrão comum de nomenclatura de spyware funciona.

Os componentes do próprio Android ficam sob dois prefixos:

• com.android.* — os componentes do Android Open Source Project
• com.google.android.* — os aplicativos e serviços do Google

Qualquer outra coisa não faz parte do Android, soe como soar. Um pacote chamado com.system.service, com.android.system.core ou com.systemui.service não é um pacote do sistema Android. O nome é construído para sobreviver exatamente à olhada que quase todo mundo dá: o usuário percorre a lista de aplicativos, lê a palavra «system» e segue adiante.

Pacotes de sistema genuínos que as pessoas confundem com suspeitos: com.android.vending (a loja da Play), com.google.android.gms (Serviços do Google Play) e com.android.providers.media (o repositório de mídia). São esperados em qualquer dispositivo com serviços do Google.

Um nome que imita um componente do sistema e não aparece na Play é motivo para seguir, não para concluir.

Verificação 2 — Existe na Google Play?

A Play expõe um pacote diretamente pelo identificador:

https://play.google.com/store/apps/details?id=<nome-do-pacote>

Três resultados possíveis:

A página carrega e corresponde ao que o usuário descreveu. Siga para a terceira verificação, que é a que decide.

A página retorna não encontrado. O pacote não é distribuído pela Play, ao menos não na região consultada. Isso é normal em aplicativos corporativos, distribuição regional e builds de desenvolvimento. Também é normal em malware. A ausência é uma pergunta, não uma resposta.

A página carrega mas descreve algo completamente diferente. Ou o nome foi reutilizado, ou o usuário leu errado. Confirme a cadeia caractere a caractere antes de prosseguir: rn e m são indistinguíveis em muitas interfaces, e essa substituição é usada de propósito.

Verificação 3 — A cópia instalada coincide com a da Play?

Esta é a verificação que resolve o caso, e é a que normalmente se pula.

Um nome de pacote na Play e o mesmo nome em um dispositivo só são o mesmo aplicativo se carregarem o mesmo certificado de assinatura. O certificado é emitido pelo desenvolvedor, não pelo Google, e um reempacotador não consegue forjá-lo: uma build modificada carrega necessariamente outra assinatura.

Portanto a pergunta decisiva não é «este pacote existe na Play?» e sim «a cópia deste dispositivo tem o certificado que a Play distribui para ele?».

Um descompasso significa que o aplicativo instalado é uma build reempacotada carregando o nome de um aplicativo legítimo. Em um aplicativo bancário isso é um incidente de fraude e não uma curiosidade de malware, e cabe no mesmo dia à proteção de marca, porque o canal de distribuição costuma continuar ativo.

O Droidwatch faz essa comparação automaticamente em toda análise Android: identidade do pacote contra a Play, mais a cadeia completa do certificado de assinatura — sujeito, emissor, janela de validade, esquema de assinatura e impressões digitais.

Verificação 4 — Quais permissões ele pede?

O manifesto declara o que o aplicativo é capaz de fazer. Para fins de identificação, o conjunto de permissões costuma ser conclusivo por si só, porque certas combinações não têm nenhuma categoria de aplicativo legítima.

As declarações que se leem primeiro:

Qualquer uma delas tem usuários legítimos. As três primeiras juntas, em um pacote que não está na Play e imita um nome do sistema, descrevem o conjunto de capacidades de um ataque por sobreposição. A cadeia completa de capacidades explica como se combinam e o que cada uma contribui.

Verificação 5 — De onde ele veio?

O Android registra qual aplicativo realizou cada instalação, e esse registro responde a uma pergunta que o usuário frequentemente não consegue.

Com a depuração USB ativada e o dispositivo conectado:

adb shell pm list packages -3        # somente pacotes de terceiros
adb shell pm list packages -i        # cada pacote com seu instalador
adb shell pm path <nome-do-pacote>   # caminho do APK no dispositivo
adb shell dumpsys package <nome-do-pacote>

dumpsys package informa installerPackageName. Os valores a reconhecer:

• com.android.vending — instalado pela Google Play
• com.android.packageinstaller ou com.google.android.packageinstaller — instalação lateral: um arquivo aberto diretamente, não uma instalação pela loja
• null — pré-instalado, ou instalado por um método que não registrou instalador
• Qualquer outro pacote — instalado por outro aplicativo, que é o caso do dropper

Um pacote instalado lateralmente, que imita um nome do sistema e pede acessibilidade, não é um achado ambíguo.

adb shell pm path devolve a localização do APK, de modo que o arquivo pode ser extraído com adb pull e analisado diretamente, que é a única forma de responder à pergunta de maneira definitiva.

O que nada disso estabelece

As cinco verificações estabelecem identidade e capacidade. Não estabelecem comportamento.

Um aplicativo capaz de ler SMS pode nunca fazê-lo, ou fazê-lo apenas mediante instrução do seu servidor de comando e controle. A análise estática do pacote mostra o que ele pode fazer; determinar o que fez exige instrumentação em execução ou perícia no dispositivo.

Para a maioria das perguntas de identificação essa distância não bloqueia a decisão. Um pacote instalado lateralmente, que imita um nome do sistema, ausente da Play e que pede acessibilidade e sobreposição, é acionável sem confirmação em execução.

Resolvendo por completo

As verificações acima podem ser feitas à mão e vale entendê-las, porque são o que qualquer ferramenta está fazendo por baixo. Executá-las como uma única análise é mais rápido e produz algo que pode ser anexado a um chamado.

Enviar o APK devolve a identidade do pacote e a comparação com a Play, a cadeia completa do certificado, a análise de permissões e componentes, o mapeamento MITRE ATT&CK Mobile, os indicadores de rede extraídos e uma pontuação de risco de 0 a 100 onde mais alto é pior, com faixas fixas: 65 ou mais Malicious, de 40 a 64 High Risk, de 20 a 39 Suspicious, abaixo de 20 Benign. Um pacote de 50 MB conclui em dois a cinco minutos.

São três análises por dia sem conta e cinco com conta gratuita.

Se o APK não estiver disponível — comum quando o aviso vem de um cliente e não de um dispositivo em mãos —, o threat feed público pode ser consultado por hash sem conta, e é publicado sob licença CC BY 4.0. Isso só ajuda quando a amostra já foi vista antes, e por isso as cinco verificações continuam sendo o recurso de partida.

O raciocínio posterior a uma identificação positiva está em o fluxo de triagem, e o percurso do relatório explica onde cada peça de evidência aparece.

Perguntas frequentes

Um nome de pacote é único? Único no dispositivo e único dentro da Google Play. Não único no mundo: nada impede que um aplicativo distribuído fora da Play use um nome de pacote que pertence a um publicado. É nisso que consiste o reempacotamento.

Um aplicativo pode mudar seu nome de pacote? Não depois de instalado. O rótulo e o ícone mudam em tempo de execução; o nome de pacote não. Por isso ele é o identificador confiável quando o nome exibido engana.

Um pacote ausente da Google Play é necessariamente malicioso? Não. Distribuição corporativa, disponibilidade regional, canais beta e ferramentas internas produzem pacotes que não estão na Play. A ausência levanta a pergunta que as verificações três, quatro e cinco respondem.

O que significa com.system.service? Em si, nada — mas não é um pacote do sistema Android. Os componentes do Android usam com.android.* e com.google.android.*. Um nome sob com.system.* foi escolhido por um desenvolvedor, e escolher um nome que se lê como componente do sistema é uma decisão que merece exame.

O que se faz com o APK depois de recuperado? Tratá-lo como malware vivo: analisá-lo em ambiente isolado, registrar o SHA-256 antes de tudo e não redistribuir o binário. Compartilham-se hashes e indicadores; amostras não.

Para identificar um pacote a partir do seu APK, envie-o para análise. Não é necessário meio de pagamento.