Analisar um APK online: o que há no relatório

A maioria dos serviços que permitem analisar um APK online devolve um veredito e pouco mais. O veredito afirma que um arquivo é malicioso. Não estabelece o que o aplicativo faz, qual evidência sustenta essa classificação nem o que um analista deve escalar.

Este artigo documenta a cadeia de análise do Droidwatch de ponta a ponta: os formatos aceitos, as etapas executadas no envio, cada bloco do relatório resultante e o ponto em que a análise estática deixa de produzir evidência utilizável.

O raciocínio do analista — como trabalhar uma amostra suspeita, em vez de como a plataforma a processa — é tratado separadamente em o fluxo de triagem de APK.

Formatos aceitos

São aceitos cinco formatos. Todos são de Android, exceto o último.

O tamanho máximo depende do plano: 150 MB sem conta, 200 MB no Free, 500 MB no Pro, 750 MB no Team e 1 GB no Enterprise. Os aplicativos bancários em produção ficam bem abaixo do teto do Free; pacotes acima de 500 MB costumam ser jogos.

Existem duas vias de entrada. O envio pelo navegador atende arquivos isolados. A API atende todo o resto e está documentada adiante.

A cadeia de análise

Um único envio dispara uma cadeia de 28 etapas que produz mais de 25 análises independentes. As etapas pertencem a uma mesma execução e não a produtos distintos, o que é relevante para interpretar o resultado: um achado produzido por uma etapa pode alterar como uma etapa posterior pontua a amostra.

As etapas se agrupam em seis áreas. Identificar de qual área veio um achado determina que peso ele carrega.

1. Pacote e identidade

Análise do manifesto, nome de pacote, versão e código de versão, SHA-256, min_sdk, target_sdk e a cadeia do certificado de assinatura. Esta área executa também a comparação com a Google Play: se o pacote existe na Play e, existindo, se o certificado coincide com o que a Play distribui.

Um descompasso de certificado é a saída de maior valor de toda a cadeia. Reclassifica a amostra de «aplicativo suspeito» para «reempacotamento confirmado», que é outro tipo de incidente e com outro responsável dentro da organização.

2. Bytecode

Análise profunda de DEX via androguard: classes, métodos, uso de API, reflexão, carregamento dinâmico de classes e a postura de ofuscação da build. O comportamento de dropper aflora aqui. Um APK cuja carga útil é obtida após a instalação se apresenta como irrelevante em todas as demais áreas.

3. Código nativo e empacotamento

Objetos compartilhados, assinaturas de packers, assets de alta entropia e qualquer componente presente no pacote que o manifesto não justifique.

4. Detecção de família

Regras YARA combinadas com heurísticas. A atribuição de família é o dado operacionalmente mais útil que um relatório pode conter, porque incorpora todo o conhecimento existente sobre a infraestrutura, os alvos e o comportamento dessa família.

5. Cadeia de suprimentos

Esta merece precisão, porque é onde os fornecedores costumam prometer demais. O Droidwatch identifica 87 SDK de terceiros por assinatura e consulta o OSV.dev no momento da análise em busca de vulnerabilidades conhecidas.

São duas medições distintas, e a diferença importa. O OSV cobre 12 dos 87. Os SDK de publicidade e atribuição são fechados e não estão representados nas bases públicas de vulnerabilidades. Para os 75 restantes, a plataforma estabelece o que o aplicativo contém, mas não se existe um CVE publicado. Afirmações de cobertura de CVE sobre SDK móveis proprietários devem ser avaliadas contra o conteúdo real das bases públicas. Um módulo separado acompanha aproximadamente 120 rastreadores de privacidade.

Esta área produz achados em aplicativos legítimos com mais frequência do que qualquer outra, e é a razão pela qual as equipes de segurança de aplicações rodam a plataforma sobre as próprias builds, e não apenas sobre amostras suspeitas.

6. Inteligência de infraestrutura

Extração de endpoints, identificação de C2 e extração de configuração criptografada quando a amostra permite.

Classificador de aprendizado de máquina

Um classificador roda em paralelo à cadeia. Seu desempenho medido é F1 macro 0,9873 sobre um holdout de 1.661 amostras, treinado com 6.642 amostras do CICMalDroid 2020. O tamanho do holdout é citado deliberadamente: uma cifra de acurácia sem conjunto de avaliação declarado não é uma medição.

O classificador contribui com um sinal para o veredito. Não determina o veredito, e nenhum achado de um relatório se apoia somente nele.

Duração da análise

Medições sobre relatórios de produção em 19 de setembro de 2026:

Um APK de 50 MB conclui em dois a cinco minutos. Pacotes acima de 100 MB levam em média de oito a dez minutos. Os trabalhos transitam por quatro estados: queued, running, done e failed.

A documentação anterior indicava de 30 a 90 segundos. Essa cifra era imprecisa e foi retirada.

Estrutura do relatório

metadata

run_id, app_name, package, version_name, version_code, sha256, file_size, min_sdk, target_sdk, analyzed_at.

É o bloco mais citado adiante. A combinação de sha256 e analyzed_at estabelece a reprodutibilidade: identifica qual build foi examinada e quando, que é o que uma auditoria ou uma divergência seis meses depois exige.

min_sdk merece atenção. Um aplicativo que aponta para um nível de API obsoleto costuma fazê-lo para ficar fora de um modelo de permissões que as versões atuais do Android impõem.

overview

score, verdict e uma distribuição de severities entre info, low, medium, high e critical.

O Droidwatch pontua o risco de 0 a 100, onde a pontuação mais alta indica risco maior. As faixas de veredito são fixas:

Usa-se uma única escala. A coluna Score do threat feed público contém o mesmo valor, de modo que um 63 no feed corresponde a um 63 em um relatório privado.

Para triagem, a distribuição de severities costuma ser mais informativa do que a pontuação composta, porque descreve a forma do problema. Dois achados críticos e nada mais indicam um aplicativo concreto e explicável. Quarenta achados médios e nenhum crítico indicam normalmente um aplicativo legítimo com dívida técnica. Os dois relatórios vão para equipes diferentes.

sections

Um array de { id, title, findings } que contém o corpo da análise: permissões, componentes, detalhes do certificado, configuração de rede, indicadores extraídos, análise de código e cadeia de suprimentos. A cadeia do certificado, os indicadores de rede e as correspondências YARA ficam aqui dentro, em suas respectivas seções, e não soltos na raiz do documento.

Cada achado carrega o próprio raciocínio de apoio. É a diferença substantiva entre um relatório e um veredito de scanner: o relatório identifica qual componente solicita determinada permissão e o que ela habilita, em vez de afirmar que a permissão é perigosa. Quando uma equipe de desenvolvimento contesta um achado, o raciocínio é o que resolve a divergência em um sentido ou no outro.

Três elementos dentro de sections merecem atenção específica:

• Detalhes do certificado. A reutilização de certificados entre aplicativos aparentemente sem relação é o sinal de vínculo de campanha de menor custo disponível na inteligência de ameaças móvel, e é sistematicamente ignorado. Um certificado de depuração em um aplicativo que se apresenta como produto bancário resolve a investigação de imediato.
• Indicadores de rede. Domínios, endereços IP, URLs e configuração descriptografada quando a extração teve êxito. São a saída com maior vida operacional: um veredito protege um único cliente, enquanto um domínio C2 incluído em uma blocklist de DNS protege todos os usuários por trás dela.
• Correspondências YARA. Atribuição de família. Um resultado vazio é um resultado válido. A maioria das amostras não pertence a uma família conhecida, e uma ferramenta que devolve atribuição sistematicamente está inferindo, não correlacionando.

ttp_mapping

Achados mapeados para técnicas do MITRE ATT&CK Mobile.

O mapeamento torna um achado móvel legível para responsáveis que não trabalham com segurança móvel. Os identificadores de técnica podem ser incorporados a um modelo de cobertura de detecção, o que elimina o parque móvel como lacuna nos relatórios de cobertura ATT&CK.

Os achados também são mapeados para as oito categorias de controle do OWASP MASVS: MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE e MASVS-PRIVACY. O MASTG fornece o procedimento de teste correspondente a cada controle quando um resultado precisa ser demonstrado de forma independente.

Uma advertência quando ambas as cifras aparecem no mesmo relatório: elas correm em sentidos opostos. O risco é pontuado de 0 a 100 onde mais alto é pior. A cobertura MASVS é pontuada de 0 a 100 onde mais alto é melhor.

narrative e behavior_summary

Descrições em prosa da amostra e do seu comportamento, compostas a partir dos achados.

O método de geração é declarado explicitamente porque a suposição predominante diante de qualquer prosa em um relatório de segurança é que um modelo de linguagem a produziu. Esses campos são produzidos por um motor de regras. Uma fase da cadeia de ataque aparece na saída somente quando há achados que a sustentam, o que significa que o resumo não pode afirmar uma etapa que a evidência não carrega — o modo de falha característico de texto gerado, e a razão pela qual texto gerado não pode ser citado como evidência.

Ambos os campos continuam sendo resumos, não evidência. A evidência é sections, e é sections que entra em um registro de incidente.

coverage, analyzer_version e toolchain

Estes três blocos determinam se um relatório é defensável.

coverage registra o que a análise conseguiu examinar. Uma amostra cujo manifesto não pôde ser lido não é uma amostra limpa, e um relatório que não distingue «examinado, nada encontrado» de «não foi possível examinar» não sustenta uma conclusão assinada.

analyzer_version e toolchain registram o que produziu o resultado. Isso é operacionalmente significativo porque o motor de análise é versionado e muda com o tempo. Em 19 de setembro de 2026 o conjunto de assinaturas de SDK passou de 35 para 87 e a detecção de Log4j entrou em operação. Um relatório gerado depois dessa data pode conter legitimamente achados ausentes em uma execução anterior sobre o mesmo arquivo. Quando duas análises de um mesmo aplicativo são comparadas entre datas, analyzer_version estabelece que a diferença é uma mudança no motor e não uma inconsistência dele.

Formatos de exportação

Há seis formatos disponíveis:

Acesso programático

Fluxos automatizados usam a API, não o envio pelo navegador. A API espelha a sequência do navegador:

POST /api/upload                              → devolve upload_id
POST /api/analyze  {"upload_id": "..."}       → devolve job_id e run_id
GET  /api/jobs/{job_id}                       → consultar até done ou failed
GET  /api/runs/{run_id}/artifact/report.json  → obter o relatório

job_id e run_id são UUID distintos e não são intercambiáveis: o job representa o trabalho, o run representa o resultado. Quando um arquivo já foi analisado antes, /api/analyze devolve cached: true com o job_id nulo; não há o que consultar, porque o relatório já existe.

A autenticação aceita X-API-Key: dw_… ou Authorization: Bearer dw_…. Quando ambos são enviados, prevalece o cabeçalho de chave de API.

O processamento em massa usa os endpoints em lote — POST /api/batch/upload, POST /api/batch/analyze, GET /api/batch/{batch_id} —, que processam a colheita de um dia em uma única passagem. As exportações em PDF e STIX são obtidas em seus próprios endpoints de artefato.

A varredura em tempo de compilação é tratada por CI/CD e não pela API. A GitHub Action analisa os artefatos de build e quebra a compilação segundo limiares de veredito configuráveis. Há cinco integrações adicionais: GitLab, Bitrise, Jenkins, CircleCI e Azure Pipelines. O guia rápido documenta a sequência mínima funcional; a referência de API, os esquemas.

Escopo e limitações

Tudo o que foi descrito é análise estática. A análise estática estabelece capacidade e não comportamento: o que um aplicativo é capaz de fazer, não o que fez durante a execução. Isso basta para a maioria das decisões de triagem e está disponível em minutos.

Quando uma decisão depende do comportamento em execução, aplicam-se três restrições:

• A análise dinâmica está disponível somente para Android. Não existe instrumentação em execução para iOS.
• A análise dinâmica executa contra o dispositivo ou emulador do próprio cliente, conectado pelo agente do Droidwatch. Nenhuma amostra executa na infraestrutura do Droidwatch. Para organizações que processam amostras de seus clientes sob obrigações de residência de dados este é o desenho pretendido, embora exija configuração do lado do cliente. A análise dinâmica está disponível a partir do plano Pro; os planos superiores ampliam a janela de execução de 300 para 450 segundos e aumentam a alocação mensal de emulador.
• O sandbox hospedado na nuvem não está em produção. Descrições da análise dinâmica do Droidwatch como sandbox hospedado são imprecisas.

A análise de .ipa no iOS executa sete módulos estáticos: análise do binário Mach-O, Info.plist, entitlements, configuração de App Transport Security, class-dump, frameworks vinculados e manifestos de privacidade declarada. Não existe componente em execução para iOS em nenhum plano.

Planos e limites

Todos os planos executam a mesma cadeia de análise. Os níveis de plano regem a vazão, o tamanho de arquivo e a retenção, não a profundidade da análise. A análise dinâmica e o acesso à API começam no Pro, com 30 minutos de emulador por mês; o Team dispõe de 90 e o Enterprise de 150.

Perguntas frequentes

A análise de APK está disponível sem custo? Sim. Uma conta gratuita oferece cinco análises por dia com a cadeia estática completa, mapeamento MITRE ATT&CK Mobile, cobertura MASVS e os seis formatos de exportação, incluindo STIX 2.1. Sem conta há três análises por dia.

As amostras enviadas são compartilhadas com terceiros? Os envios são privados por padrão. Os indicadores são publicados no threat feed público somente nas execuções cujo proprietário optou por isso. Isso difere dos serviços multi-scanner gratuitos, onde os envios do plano gratuito costumam ficar disponíveis para outros clientes — restrição que impede usá-los com amostras de clientes que contenham dados pessoais. As práticas de manuseio e divulgação estão documentadas na página de confiança.

Qual a diferença em relação ao VirusTotal? O VirusTotal responde se um hash já foi observado e como os motores participantes o classificaram. É a primeira consulta adequada. Não fornece raciocínio por achado, análise do certificado, mapeamento ATT&CK nem um relatório apto a ser apresentado a um comitê de revisão. Há uma comparação detalhada disponível.

Qual a diferença em relação a uma instância própria do MobSF? No plano da análise a diferença é limitada; o MobSF é um motor sólido e boa parte da disciplina de segurança móvel foi construída sobre ele. A diferença é operacional: sem orquestração de contêineres, sem escalonamento de workers, sem manutenção de dependências, e com multi-tenant, controle de acesso por papéis, trilha de auditoria, faturamento e inteligência de ameaças. A comparação completa documenta o trade-off.

Qual o tempo de análise previsto? De dois a cinco minutos para um APK de 50 MB; de oito a dez minutos em média para pacotes acima de 100 MB.

Pronto para testar? Envie um APK. Não é necessário meio de pagamento.