O que há dentro de um APK antes de o instalar
Um APK é um ficheiro zip com uma declaração anexada. Antes de o Android executar uma única linha do seu código, o pacote já afirma quem diz ser, que versões do Android suporta, o que quer permissão para fazer, que partes suas podem ser invocadas por outras aplicações e quem o assinou. Nada disso exige instalar nada. Lê-lo primeiro transforma um ato de fé numa inspeção de dez minutos — e essa inspeção costuma bastar para decidir.
Porque um APK instalado manualmente merece uma olhadela prévia
As aplicações de uma loja oficial chegam com uma página, um histórico de avaliações e uma página do editor. Um APK descarregado por fora — de um site de um fornecedor, um espelho, um fórum, uma mensagem de chat ou uma cópia antiga — não traz nada desse contexto, e o aviso de instalação não o substitui. O instalador do Android mostra o nome e o ícone, e as permissões aparecem tarde, agrupadas e simplificadas, exatamente no momento em que é menos provável que pare para pensar. Quando uma aplicação já está instalada e foi aberta uma vez, pode já ter as permissões concedidas e ter usado a rede. O momento barato para fazer perguntas é antes, enquanto o ficheiro ainda é só um ficheiro.
Isto não é um argumento contra a instalação manual em si. Os fornecedores distribuem aplicações legítimas diretamente, as empresas implementam assim ferramentas internas e as versões antigas por vezes resolvem problemas reais. É um argumento a favor de ler o que lhe entregaram. O analisador de APK deste site analisa o pacote no seu navegador — o ficheiro nunca é enviado nem executado — e apresenta o manifesto, as permissões, os componentes e o certificado de assinatura numa única vista. Use a ferramenta que usar, mantenha essa ordem: primeiro inspecionar, depois instalar, e trate qualquer aplicação que não passe na inspeção como uma resposta em si mesma.
O manifesto é a própria declaração da aplicação
Cada APK traz um AndroidManifest.xml, armazenado em XML binário, e é a declaração da aplicação sobre si mesma. Nomeia o pacote — a identidade única que o Android usa, como com.example.app — juntamente com um versionCode numérico e um versionName legível. Declara os componentes que a aplicação contém, as permissões que solicita e as funcionalidades de hardware e software que espera. Como o Android faz cumprir grande parte deste ficheiro, é mais difícil de falsificar levianamente do que uma página de loja ou de descarga: uma aplicação não pode usar silenciosamente uma permissão que nunca declarou, nem fingir ser a atualização de um pacote cujo nome não partilha.
Dois números do manifesto dizem muito sobre a manutenção. O minSdkVersion é o Android mais antigo em que a aplicação funcionará; um piso muito baixo implica compatibilidade com dispositivos e modelos de segurança de há muitos anos, por vezes necessária e por vezes simplesmente herdada e esquecida. O targetSdkVersion é o nível de comportamento do Android que a aplicação afirma seguir. A Google eleva todos os anos o alvo exigido para atualizações na loja, porque um alvo mais alto submete a aplicação a regras de privacidade e segurança mais recentes. Um APK com um alvo de há vários anos não é automaticamente malicioso, mas está a dizer-lhe que evitou, ou nunca cumpriu, essas regras novas, e deve perguntar porquê.
Permissões, lidas como deve ser
O Android classifica as permissões, e a classe importa mais do que o nome. As permissões normais são concedidas automaticamente na instalação — o acesso à rede é o exemplo familiar — porque o sistema as julga de baixo risco. As permissões perigosas cobrem dados e ações sensíveis como contactos, mensagens, localização precisa, microfone e câmara; precisam de um aviso em tempo de execução que o utilizador pode recusar. As permissões de assinatura só são concedidas a aplicações assinadas com o mesmo certificado, ou ao próprio sistema, pelo que uma aplicação de terceiros que declare uma não ganha nada com isso. Ao ler uma lista de permissões, ordene-a mentalmente nesses grupos antes de julgar qualquer linha.
O contexto é o veredicto, não a contagem. Uma lanterna que pede para ler SMS não tem nenhuma razão honesta para isso; uma aplicação de mensagens que pede a mesma permissão pelo menos pode explicar-se: ler um código de verificação ou oferecer-se como aplicação de mensagens predefinida. Uma aplicação bancária pode solicitar legitimamente muitas permissões, enquanto um jogo simples que pede apenas algumas poderia incluir justamente a que não encaixa. Por isso, não pontue as aplicações só pelo número de permissões. Pergunte, para cada permissão perigosa, que funcionalidade desta aplicação deixaria de funcionar sem ela. Os pedidos que não consegue relacionar com uma funcionalidade são a descoberta, e são exatamente o que o resumo de instalação esconde.
Componentes exportados e a superfície de ataque que criam
Uma aplicação é composta por componentes — atividades (ecrãs), serviços, recetores de difusão e fornecedores de conteúdo — e o manifesto indica quais estão exportados, ou seja, acessíveis por outras aplicações no dispositivo. Os componentes exportados não são um erro por defeito: um destino de partilha, um abridor de ficheiros e uma ligação profunda funcionam porque um componente é exportado de propósito, protegido e, no Android moderno, declarado de forma explícita. O risco está nos componentes exportados que nunca deveriam ter sido uma porta pública: um serviço que qualquer aplicação pode iniciar, um recetor que qualquer uma pode acionar, ou um fornecedor que entrega os dados da aplicação a quem os pedir, sem nenhuma verificação de permissões à frente.
Dois indicadores do manifesto merecem uma olhadela direta em qualquer aplicação de produção. Uma aplicação marcada como depurável pode ser inspecionada por ferramentas numa máquina ligada; isso é uma definição de desenvolvimento, e distribuí-la ativada é um sinal de alarme sobre como a versão foi construída. Permitir cópias de segurança significa que os dados privados da aplicação podem ser incluídos nas cópias do dispositivo, o que pode ser conveniente e também pode mover dados que julgava dentro da aplicação para um local muito menos controlado. Nenhum indicador prova que uma aplicação seja prejudicial. Ambos são baratos de verificar, difíceis de justificar num produto acabado e exatamente o tipo de detalhe que nunca aparece numa página de descarga.
Certificados de assinatura: o sistema de identidade do Android
Cada APK está assinado, e o certificado de assinatura é o mais parecido com um documento de identidade que o Android tem. O Android só instalará uma atualização sobre uma aplicação existente quando ambas as cópias partilharem o mesmo nome de pacote e o mesmo signatário. Essa única regra faz muito trabalho silencioso: significa que um estranho não pode enviar uma atualização trojanizada de uma aplicação em que já confia, porque não possui a chave original, e significa que a impressão digital do certificado — mostrada normalmente como um resumo SHA-256 — é a forma prática de verificar a continuidade. Se um fornecedor publicar uma impressão digital esperada, compare-a. O comparador de certificados e chaves deste site cobre a mesma lógica de impressões digitais para certificados e chaves em geral.
Tenha claro o que uma impressão digital prova e o que não prova. Prova que este ficheiro foi assinado por quem possui uma determinada chave privada, e que coincide — ou não — com outro ficheiro assinado com a mesma chave. Não prova que o titular da chave seja honesto, competente ou sequer a empresa nomeada nos campos de assunto do certificado, que o próprio signatário preenche. Uma aplicação reembalada costuma estar assinada com um certificado diferente do original, pelo que uma impressão digital que não coincide é um forte sinal de paragem; uma impressão coincidente é apenas um sinal de continuidade. A identidade no Android é continuidade da chave, nada mais: trate-a como tal.
Uma lista de verificação antes de instalar
Junte as peças numa ordem fixa e a inspeção demora minutos. Primeiro, identidade: o nome do pacote corresponde à aplicação que esperava, e o código e o nome da versão são plausíveis para a edição que queria descarregar? Segundo, manutenção: que idade têm os níveis mínimo e alvo do SDK, e isso encaixa numa aplicação ainda cuidada? Terceiro, permissões: enumere as perigosas e relacione cada uma com uma funcionalidade, parando em qualquer uma que não consiga explicar. Quarto, superfície: que componentes estão exportados, e a depuração e as cópias estão ativadas? Quinto, assinatura: a impressão digital do certificado corresponde ao valor declarado pelo editor, ou pelo menos à cópia em que já confia? Passe o ficheiro pelo analisador de APK e percorra essa lista num único ecrã.
Depois decida em três grupos, não em dois. Instale, quando tudo se relaciona com uma funcionalidade e a impressão digital bate certo. Instale com cautela — num dispositivo de teste, num perfil de trabalho ou sem conceder as permissões duvidosas — quando quase tudo encaixa mas um ponto precisa de vigilância. Ou afaste-se, quando o nome do pacote está errado, a impressão digital não coincide ou uma permissão perigosa não tem nenhuma funcionalidade imaginável por trás. Afastar-se custa uma descarga; a outra direção pode custar uma conta. E mantenha o hábito em proporção: isto é triagem, como os primeiros dez minutos com o analisador de capturas de pacotes: uma leitura rápida e honesta do que um ficheiro declara sobre si mesmo, feita antes de lhe dar um lugar no dispositivo que leva para todo o lado.
Perguntas frequentes
Um manifesto limpo significa que um APK é seguro?
Não. O manifesto é uma declaração, não um relatório de comportamento. Uma aplicação pode declarar um conjunto modesto e totalmente plausível de permissões e componentes e mesmo assim comportar-se mal no código: ligando-se a servidores, abusando das permissões que lhe foram concedidas legitimamente ou descarregando um comportamento novo após a instalação. Ler o manifesto é triagem: deteta identidades que não coincidem, permissões inexplicáveis, componentes expostos e certificados de assinatura errados de forma rápida e barata. Não é um veredicto de malware, e qualquer ferramenta que transforme a leitura de um manifesto num selo verde de «seguro» está a afirmar mais do que a evidência sustenta.
Porque é que a mesma aplicação mostra permissões diferentes em ferramentas diferentes?
Normalmente por três razões legítimas. Primeiro, a limitação por versão: uma permissão pode ter um maxSdkVersion, de modo que só se aplica até certo nível do Android, e as ferramentas diferem quanto a mostrar essas entradas. Segundo, o agrupamento: o Android apresenta as permissões por grupos ao perguntar, enquanto o manifesto enumera permissões individuais, pelo que a vista agrupada parece mais curta do que a lista completa. Terceiro, a fusão: as bibliotecas incluídas na aplicação trazem as suas próprias entradas de manifesto, que a compilação funde no ficheiro final, pelo que o manifesto instalado pode conter permissões que nenhuma parte do código próprio da aplicação declarou. As diferenças são um motivo para ver que razão se aplica, não uma prova automática de adulteração.
Posso verificar um APK sem instalar nada?
Sim — esse é o sentido de um analisador local no navegador. O APK é analisado como ficheiro: o seu manifesto binário é descodificado, os seus recursos são lidos em busca de etiquetas e textos, e os seus certificados de assinatura são extraídos e é-lhes calculada a impressão digital. O código da aplicação nunca é executado, nada é instalado em nenhum dispositivo e, com o analisador deste site, o ficheiro também nunca é enviado: a análise acontece no separador do seu navegador. Se um serviço de verificação lhe pedir para enviar um APK para um servidor, pergunte-se se esse ficheiro — que pode ser uma compilação interna — pertence sequer à máquina de outra pessoa.