Por que APKs reassinados ainda são instalados e onde residem os riscos

Conclusões e condições de decisão

Instalação bem-sucedida, verificação de assinatura bem-sucedida e identidade do publicador oficial são três julgamentos distintos; os dois primeiros não podem substituir o terceiro.
Pacotes reassinados normalmente não conseguem sobrepor uma versão oficial instalada sob uma identidade de assinatura diferente; a cadeia de atualização é um gate crítico para identificar artefatos anômalos.
O APK final deve fixar o nome do pacote, a versão, o digest do certificado, o digest do arquivo, a origem da build e a ordem de processamento do canal.
O servidor deve manter uma allowlist de versões e identidades de aplicativo permitidas, tratando sinais de integridade da plataforma como entradas de risco em vez de confiar em dados autorrelatados pelo cliente.

Distinguir Validação de Instalação, Identidade de Assinatura e Autorização de Negócio

O Android exige que os APKs sejam assinados. O sistema verifica se a estrutura do pacote do instalador e os dados de assinatura provam que o conteúdo atual foi assinado pela chave privada correspondente. Se um atacante modificar arquivos DEX, recursos ou o Manifest e depois reassinar completamente o resultado com sua própria chave, o novo pacote pode ser criptograficamente autoconsistente e satisfazer as condições para uma nova instalação.

Esse resultado responde apenas se o pacote atual possui uma assinatura verificável; não responde se o signatário é o publicador oficial. Autorização da marca, canais legítimos, permissões de login de conta e acesso a interfaces de alto risco são preocupações de negócio que o aplicativo e o servidor devem avaliar separadamente.

Portanto, os relatórios de teste não devem equiparar 'instalável após reassinatura' a 'falha na proteção de assinatura', nem equiparar 'falha na instalação' a 'todos os riscos de repacotagem eliminados'. As perguntas corretas são: o pacote modificado consegue chegar aos dispositivos dos usuários? Ele consegue se passar pela versão oficial durante uma atualização? Consegue conectar-se a serviços reais? E como o servidor identifica e lida com esses casos?

Quatro Julgamentos Frequentemente Confundidos
Julgamento	Pergunta Respondida	Evidência Necessária	Conclusão Que Não Pode Ser Extrapola
Pacote Analisável	O instalador consegue ler a estrutura do arquivo?	Resultado do instalador, Manifest e estrutura de recursos	Não prova legitimidade da assinatura ou segurança do código
Assinatura Atual Autoconsistente	O conteúdo atual foi assinado pela chave privada correspondente ao certificado atual?	Verificação do esquema de assinatura e digest do certificado	Não prova que o certificado pertence à entidade oficial
Continuidade de Identidade na Atualização	Consegue sobrepor um aplicativo oficial já instalado?	Execução de uma atualização a partir de uma versão genuína em produção	Não prova que todas as interfaces de negócio rejeitarão clientes anômalos
Autorização de Negócio Aprovada	O servidor permite que a conta e a versão acessem os recursos?	Políticas de versão, conta, integridade e comportamento no lado do servidor	Não garante que o código do cliente esteja imune a análise ou modificação

Por que pacotes reassinados frequentemente permitem apenas instalação limpa

O Android usa a identidade de assinatura do aplicativo para manter a continuidade das atualizações. Ao aceitar uma atualização por sobreposição, a plataforma deve confirmar se a nova versão atende às regras de identidade de assinatura em relação à versão existente. Um pacote modificado assinado com um certificado não relacionado geralmente não pode substituir diretamente a versão oficial; é necessário desinstalar o app oficial primeiro, alterar o nome do pacote ou induzir o usuário a instalá-lo em um ambiente separado.

É por isso que os testes de reembalagem devem executar tanto a instalação limpa quanto as atualizações por sobreposição. Testar apenas a instalação limpa ignora as verificações de continuidade de assinatura, enquanto testar apenas atualizações por sobreposição omite caminhos onde pacotes falsificados entram no dispositivo via nomes de pacote diferentes ou ciclos de desinstalação e reinstalação. Os resultados de ambos os cenários devem ser registrados separadamente.

A rotação de assinaturas e o Play App Signing adicionam complexidade à cadeia de lançamento. As equipes devem preservar as identidades de certificados atuais e historicamente permitidas, as regras de rotação e as responsabilidades distintas entre chaves de upload e chaves de assinatura do app. As políticas no lado do servidor devem usar dados compatíveis com o método de distribuição. Certificados de desenvolvimento, de upload e de distribuição final nunca devem ser confundidos em um único campo.

Executar atualização por sobreposição a partir da versão atual em produção
Realizar instalação limpa após desinstalação
Verificar alterações no nome do pacote e impactos no diretório de dados
Validar a rotação de certificados contra as regras da plataforma de distribuição

A Governança de Reembalagem Deve Começar pela Identidade do Artefato Final

As equipes frequentemente salvam apenas o número da build, negligenciando o registro do digest do arquivo APK final e do digest do certificado de assinatura. Injeção de recursos por canal, realinhamento, reassinatura ou otimização de pacote podem alterar o arquivo final. Se a varredura de segurança analisar artefatos pré-canais, os arquivos recebidos pelos usuários em produção não estarão cobertos pelas mesmas evidências.

Recomendamos gerar registros de artefatos inequívocos para cada release candidate: nome do pacote, versionCode, versionName, SHA-256 do arquivo, SHA-256 do certificado, resultado da verificação do esquema de assinatura, origem da build, canal, ordem de processamento e timestamp de geração. Verificações estáticas, atualizações de instalação, testes de regressão funcional e regras de permissão no servidor devem referenciar este registro.

Digests de arquivo não são medidas de proteção por si só; seu valor reside em impedir que o objeto de teste mude silenciosamente durante o fluxo de trabalho. Qualquer alteração no digest, na assinatura ou na sequência do canal indica um novo release candidate, exigindo a reexecução dos gates afetados.

Exemplo Público de Registro de Identidade de APK Release Candidate

artifact:
  package: com.example.redacted
  version_code: 240
  version_name: 2.4.0
  sha256: REDACTED
signing:
  certificate_sha256: REDACTED
  schemes: [v2, v3]
  distribution: managed-channel
pipeline:
  - build-release
  - harden-candidate
  - channel-resources
  - final-sign
acceptance:
  install_fresh: required
  upgrade_from_production: required
  server_policy_check: required

Servidores Devem Tratar Clientes Anômalos como um Problema de Política

Clientes podem reportar nomes de pacote, versões, certificados ou materiais de integridade, mas clientes modificados também podem adulterar esses campos padrão de relatório. Servidores devem priorizar sinais verificáveis, combinando status da conta, versão, comportamento da requisição, risco do dispositivo e ambiente de distribuição em uma política, em vez de confiar em um único booleano reportado pelo cliente.

O Play Integrity pode retornar veredictos sobre reconhecimento do aplicativo, integridade do dispositivo, licenciamento da conta e risco ambiental. A documentação oficial observa que certos sinais podem estar indisponíveis devido à versão do SO, fator de forma do dispositivo, fonte de distribuição, status do Play Services ou configuração. A abordagem correta é modelar separadamente os estados 'indisponível', 'falha' e 'alto risco', preparando estratégias para degradação, verificação secundária, restrição de privilégios ou negação.

Cenários de distribuição fora da Google Play não podem simplesmente copiar sinais exclusivos do Play. Distribuição corporativa, canais domésticos e entrega privada exigem o estabelecimento de suas próprias allowlists de versões, mapeamentos de certificados, mecanismos de atualização e procedimentos de tratamento de anomalias. Sinais da plataforma são parte da evidência, não uma resposta universal para todos os canais.

Tratamento em Camadas no Servidor para Identidade do Cliente
Entrada	Método de Verificação	Estados Possíveis	Ação Recomendada
Versão e Nome do Pacote	Comparar com o registro de lançamentos e regras de canal	Permitido, Expirado, Desconhecido	Permitir, solicitar atualização ou restringir capacidades de alto risco
Sinal de Reconhecimento da Aplicação	Validar a assinatura retornada pela plataforma e os resultados de identidade da aplicação	Identificado, Não Identificado, Indisponível	Normal, desafiar ou restringir, degradar conforme o canal
Conta e Licenciamento	Permissões de conta no servidor e licenças de distribuição	Válido, Expirado, Anômalo	Autorizar ou negar com base no escopo do recurso
Comportamento da Requisição	Taxa, replay, alterações no dispositivo e contexto de negócios	Normal, Suspeito, Alto Risco	Registrar em log, verificação secundária, limite de taxa ou bloqueio
Dispositivo e Ambiente	Vereditos da plataforma e regras proprietárias de risco	Satisfeito, Sinal Fraco, Desconhecido	Classificação de risco em vez de julgamento absoluto pontual

Sequenciamento Incorreto de Lançamento Invalida Verificações Anteriores

Modificar DEX, recursos ou o Manifest após a assinatura final quebra o conteúdo coberto pela assinatura; reconstruir ou reassinar após a varredura desvincula as conclusões da varredura do arquivo final. Se ferramentas de processamento de canal precisarem modificar o corpo do pacote, isso deve ser concluído antes da assinatura final, e a sequência deve ser fixada no registro de artefatos.

A distribuição AAB distingue ainda mais entre artefatos enviados e APKs divididos recebidos pelos dispositivos dos usuários. As equipes devem baixar ou obter os artefatos realmente entregues pela plataforma de distribuição para verificações pontuais, confirmando que nomes de pacotes, versões, identidades de assinatura e recursos-chave correspondem aos registros de lançamento. APKs genéricos gerados localmente não podem representar automaticamente todas as configurações de dispositivo.

Pacotes de rollback também devem passar pela mesma validação de assinatura e atualização. Em um incidente, reassinar temporariamente um arquivo antigo pode falhar na instalação por sobreposição devido a incompatibilidades nos números de versão, assinaturas ou requisitos de migração de dados.

Sequência Recomendada do Pipeline de Lançamento
Etapa	Entrada	Evidência de Saída	Condições Primárias de Falha
Build de Lançamento	Código-fonte e dependências congelados	Registro de build e artefatos base	Dependências ou configuração não reproduzíveis
Processamento de Hardening da Aplicação	Configuração explícita de proteção	Versão da configuração e artefatos candidatos	Objeto de processamento incompatível com a versão alvo
Processamento de Canal	Recursos de canal e informações de conformidade	Artefatos candidatos de canal	Conteúdo modificado após a assinatura
Assinatura Final	Chaves controladas e corpo final do pacote	Resumo do certificado e resultado da verificação de assinatura	Uso de chave ou ambiente incorreto
Lançamento de Aceitação	Arquivo final único	Instalação, atualização, negócios e gates no lado do servidor	Substituição de objetos aceitos por outros arquivos

Como Determinar se o Risco de Repackaging Está Sob Controle Publicável

Uma conclusão publicável não significa que pacotes modificados nunca possam ser instalados. Significa que a identidade do artefato oficial é rastreável, artefatos anômalos não podem sobrepor silenciosamente versões oficiais, o servidor pode identificar ou restringir clientes não confiáveis, os usuários têm caminhos para obter versões genuínas e se recuperar, e as equipes podem auditar os arquivos de entrega final.

Os testes devem reter evidências tanto para caminhos de sucesso quanto de falha. Caminhos de sucesso incluem instalação/atualização normal de versões oficiais, logins e fluxos de negócios-chave. Caminhos de anomalia incluem atualizações por sobreposição com certificados não relacionados, versões desconhecidas acessando interfaces de alto risco, versões expiradas, sinais de integridade indisponíveis e recuperação de falsos positivos. Verificar apenas a rejeição sem um processo de recuperação prende usuários reais em estados irresolúveis.

Este artigo não afirma que nenhuma tecnologia de hardening sozinha possa prevenir todas as instalações reassinadas. A governança de repackaging é um esforço de engenharia de sistemas completado conjuntamente pelo gerenciamento de assinaturas, controles de atualização, gerenciamento de artefatos, resiliência do cliente, sinais da plataforma e políticas no lado do servidor.

A identidade do artefato oficial pode ser auditada independentemente
Certificados anômalos não podem sobrepor silenciosamente instalações oficiais
O servidor possui políticas graduadas para clientes desconhecidos
Os usuários podem recuperar para canais de lançamento confiáveis
Os pacotes de rollback concluíram antecipadamente a validação de atualização.

Evidências e limites de aplicabilidade

Esta seção separa fatos documentados da plataforma, julgamento de engenharia e limites que não podem ser generalizados em declarações de produtos não verificadas.

Julgamento do artigo	Fato ou base de engenharia	Limite de aplicabilidade
A instalabilidade de um pacote reassinado não equivale à identidade do editor oficial.	O Android exige que os APKs tenham assinaturas verificáveis; atacantes podem gerar assinaturas autoconsistentes usando suas próprias chaves em conteúdo modificado.	A instalabilidade também é afetada pelo nome do pacote, políticas do dispositivo, versão do SO e fonte de instalação; resultados específicos de amostras não podem ser inferidos apenas com base em princípios de design.
Atualizações por sobreposição devem verificar a continuidade da identidade da assinatura.	A documentação oficial do Android afirma que a plataforma usa a chave de assinatura do aplicativo para confirmar se as atualizações provêm do mesmo detentor da chave.	A rotação de certificados e as regras de assinatura da plataforma de distribuição devem ser verificadas conforme a configuração do projeto.
Os sinais de integridade da plataforma devem ser validados e tratados no backend.	Os veredictos do Play Integrity incluem reconhecimento do aplicativo, dispositivo, conta e informações ambientais; os oficiais recomendam respostas do backend baseadas no risco.	Os sinais do Play não cobrem todos os países, canais, dispositivos ou cenários offline.
Os arquivos de entrega final devem corresponder um a um às evidências de teste.	Recompilar, modificar recursos ou reassinar altera a identidade do artefato e o comportamento potencial em tempo de execução.	Os digestos de arquivo estabelecem associação de identidade, mas não fornecem por si só capacidades antiadulteração.
A falha na instalação, por si só, não prova que os riscos de reembalagem foram eliminados.	Pacotes anômalos ainda podem representar riscos ao alterar nomes de pacote, realizar ciclos de desinstalação-reinstalação, usar outros canais ou explorar a falta de políticas de versão no lado do servidor.	Caminhos de ataque específicos devem ser verificados dentro de escopos de teste autorizados contra arquiteturas reais de distribuição e de negócios.

Perguntas de engenharia

Por que o sistema não rejeita diretamente todos os APKs assinados com certificados não oficiais?

O instalador do Android pode verificar se a assinatura de um pacote atual é autoconsistente, mas o sistema não sabe qual certificado cada marca reconhece. A identidade oficial deve ser determinada conjuntamente pela cadeia de atualização, pela plataforma de distribuição e pelos serviços de negócios.

Se um pacote reassinado não puder realizar atualização por sobreposição, não há risco?

Não. Atacantes ainda podem induzir ciclos de desinstalação-reinstalação, modificar nomes de pacote ou explorar a ausência de políticas de versão no lado do servidor para acessar a lógica de negócios. A prevenção de atualização por sobreposição é apenas um item na matriz de governança.

É suficiente que o cliente leia seu próprio digesto de certificado?

Não. Um cliente modificado pode alterar simultaneamente verificações locais ou lógica de relatório. Informações de certificado podem participar da defesa em profundidade, mas decisões de autorização de alto risco devem ser tomadas pelo servidor, combinando sinais verificáveis.

Após o lançamento do AAB, qual digesto de arquivo deve ser salvo?

Salve a identidade do AAB enviado e também obtenha e audite por amostragem os artefatos realmente entregues pela plataforma de distribuição. Diferentes dispositivos podem receber APKs divididos; salvar apenas um APK genérico gerado localmente é insuficiente.

Quando uma conclusão de lançamento pode ser formada?

Uma conclusão só pode ser formada para o escopo coberto após a fixação da identidade do artefato assinado final e a conclusão de instalação, atualização a partir de versões em produção, fluxos principais de negócios, políticas do lado do servidor, faixas de SO alvo e validação de rollback.

Quer testar isso em seu próprio aplicativo?

Envie o release candidate, os sistemas de destino e os caminhos críticos de negócios para um Yudun PoC e avaliação de compatibilidade.

Continuar com: Como aceitar APK, DEX e integridade de assinatura juntos

Solicite um teste de proteção de aplicativo Envie detalhes do projeto