Analisador de APK

Largue um pacote Android — um ficheiro .apk — e leia o que ele declara sobre si mesmo antes de se aproximar de qualquer telemóvel: o nome e a versão do pacote, os níveis de SDK que visa, cada permissão que pede, se permite depuração e cópias de segurança, quais dos seus componentes outras apps conseguem alcançar e com que certificados está assinado. O ficheiro nunca sai do seu dispositivo: é aberto e analisado nesta página, não enviado, porque um APK de que desconfia é exatamente o ficheiro que não deve entregar ao servidor de um estranho.

Ou largue o ficheiro em qualquer ponto desta caixa. Tudo o que se segue é lido do próprio pacote, neste dispositivo — o manifesto, os recursos compilados e os blocos de assinatura.

O que um APK declara antes de executar uma linha de código

Um APK é um arquivo ZIP com opiniões. Antes de o Android executar qualquer código dele, o sistema lê o AndroidManifest.xml binário que traz dentro, e esse único ficheiro é uma declaração de intenções surpreendentemente completa. Nomeia o pacote — a identidade contra a qual as atualizações são comparadas — e a sua versão. Declara a versão do Android mais antiga que a app diz suportar e aquela cujas regras de comportamento segue, e é por isso que o SDK de destino importa: um destino baixo mantém vivo, em silêncio, o comportamento de permissões antigo e mais permissivo. Lista cada permissão que a app poderá alguma vez usar, porque uma permissão não declarada não pode ser concedida mais tarde. Diz se a compilação é depurável — um indicador que nunca deveria sobreviver a uma versão de produção — e se os seus dados podem ir parar às cópias de segurança do dispositivo. E inventaria os componentes da app: atividades, serviços, recetores e fornecedores, cada um com um estado de exportação que decide se outras apps do dispositivo o podem chamar. Um componente exportado sem verificação de permissão é a superfície de ataque clássica do Android, e pode vê-la aqui, no manifesto, sem instalar nada.

A outra metade da história é a assinatura. O Android só instala uma atualização sobre uma app existente quando ambas estão assinadas com a mesma chave, por isso a impressão digital do certificado do signatário é a continuidade de identidade da app: o mesmo nome de pacote assinado com outra chave é outra app com um rótulo familiar. Esta página lê as duas gerações de assinatura — os certificados de estilo Jar em META-INF e o bloco APK Signature Scheme v2/v3 — e mostra o sujeito, o emissor, a janela de validade e a impressão digital SHA-256 de cada signatário, que o comparador de certificados e chaves pode confrontar com uma chave ou um CSR que tenha. O guia complementar, o que há dentro de um APK antes de o instalar, percorre toda a inspeção como uma lista de verificação. Dois limites honestos: esta página lê declarações, não comportamento — não descompila código, não executa a app nem julga se é malware — e onde o próprio manifesto é ambíguo (um indicador exported omitido num componente com intent-filter, um rótulo que os recursos compilados não resolvem), diz isso em vez de preencher a lacuna com um palpite. Para o que a app faz na rede depois de estar a correr, o analisador PCAP lê a captura.

Perguntas frequentes

Para onde vai o meu ficheiro APK?

Para lado nenhum. O ficheiro é aberto e analisado nesta página, no seu dispositivo, e nada é enviado, transmitido ou guardado — analisar um ficheiro não faz qualquer pedido de rede. Aqui isso importa mais do que na maioria das ferramentas: os APK que mais se querem inspecionar são os que já geram desconfiança — um ficheiro de um fórum, um descarregamento direto, uma ficha de loja que parece errada — e enviar um binário suspeito para um serviço de análise remoto é, em si, uma exposição. Também funciona offline depois de a página carregar.

O que devo verificar antes de instalar um APK?

Quatro coisas, todas visíveis acima. O nome do pacote: é o espaço de nomes real do editor, ou um imitador com um carácter trocado? As permissões: uma app de lanterna precisa mesmo dos seus contactos, do registo de chamadas e da localização precisa — e há algum pedido de nível de assinatura ou especial disfarçado de rotina? Os componentes exportados: cada atividade, serviço, recetor ou fornecedor que outras apps conseguem alcançar é superfície que está a aceitar. E o signatário: uma atualização tem de trazer o mesmo certificado de assinatura que a app instalada, por isso compare a impressão digital SHA-256 com a cópia em que confia antes de instalar por fora uma «versão mais nova» vinda de qualquer lado.

Isto pode dizer-me se uma app é malware?

Não, e qualquer ferramenta que o prometa a partir de um manifesto está a vender demais. Esta página lê o que o pacote declara — identidade, permissões, componentes, indicadores e assinaturas —, o que chega para apanhar os descuidados e os impostores: um clone com o signatário errado, uma lanterna a exigir acesso a SMS, uma compilação de produção que ficou depurável. Julgar o que o código faz realmente exige descompilação, análise dinâmica ou o veredicto de um analisador reputado sobre o próprio binário. Trate um resultado limpo aqui como «nada do que foi declarado parece errado», nunca como um certificado de segurança.

Porque é que algumas permissões dizem «não está na tabela de referência»?

Porque a honestidade vence um palpite plausível. Os níveis de proteção mostrados — normal, perigosa, assinatura, especial — vêm de uma tabela cuidada das permissões android.* mais conhecidas e do nível que a framework atribui a cada uma. Os fornecedores acrescentam as suas próprias permissões, os fabricantes acrescentam mais, e as novas versões do Android introduzem nomes novos; nenhum deles está na tabela, por isso a página diz isso explicitamente. Um nível desconhecido não significa que a permissão seja inofensiva ou perigosa — significa que esta referência não a cobre, e o nome e o espaço de nomes da própria permissão são o sítio por onde começar a verificar.

O que significa «exportado: não especificado»?

Significa que o manifesto realmente não o diz. Quando um componente declara um intent-filter mas omite android:exported, a resposta efetiva dependeu historicamente do SDK de destino da app e da versão do Android — as regras antigas exportavam esses componentes por omissão, as novas recusam-se a instalar a app até o programador decidir. Um leitor que imprimisse um sim ou um não com toda a confiança estaria a inventar um facto que o ficheiro não contém, por isso esta página reporta a omissão em si. Nas suas próprias compilações, é a linha que merece ser corrigida explicitamente.