# Scanners automáticos: o que eles pegam e o que passa batido > APKiD, apkleaks, gitleaks, trufflehog e MobSF: para que serve cada um, onde geram ruído e por que nenhum substitui a leitura manual do código. - Autor: Marcelo Silva - Publicado em: 2026-10-13 - Tema: Segurança - Série: Segurança Mobile, parte 8 de 11 (https://marcelxsilva.dev/series/seguranca-mobile/) - URL: https://marcelxsilva.dev/artigos/scanners-automaticos/ Depois de ler manualmente o manifesto, o bundle JavaScript e o código nativo, chega a hora de rodar os scanners automáticos. A ordem importa: eles geram volume, muito falso positivo e algumas descobertas genuinamente úteis, mas só fazem sentido depois da análise manual, como uma rede de segurança para o que passou despercebido, não como atalho para pular a leitura do código. ## APKiD: identificando o que protege o app O [APKiD](https://github.com/rednaga/APKiD) é uma ferramenta de impressão digital: ele examina o APK e identifica qual compilador, ofuscador, empacotador ("packer") e técnicas anti-análise (anti-depuração, anti-root, anti-VM) foram usados na build. ```bash apkid example.apk ``` Para um app que lida com dado sensível, o esperado costuma ser justamente a presença dessas proteções: ofuscação de código e algum nível de detecção de ambiente root ou emulado. A ausência delas num app desse tipo não é uma vulnerabilidade por si só, mas indica uma oportunidade de hardening (reforço de segurança) que faltou. ## apkleaks: pistas, não resultados O [apkleaks](https://github.com/dwisiswant0/apkleaks) varre o pacote em busca de padrões conhecidos de segredo e URL, usando expressões regulares genéricas. ```bash apkleaks -f example.apk -o apkleaks.txt grep -E '^\[' apkleaks.txt ``` A limitação principal é que ele não entende contexto: reconhece um padrão de texto, mas não sabe se aquele valor é, de fato, uma chave secreta, um identificador aleatório qualquer, ou um número de versão que por acaso bate com o formato de um token. Isso produz tanto ruído (um IP que na verdade é um OID de certificado, uma string que "parece" um JWT mas não é) quanto lacunas: um segredo guardado numa variável chamada `CLIENT_SECRET` no `BuildConfig`, por exemplo, não costuma ser reconhecido por uma regex genérica, porque o valor em si pode não ter nenhum formato especial. É por isso que a varredura específica de variáveis de ambiente, feita manualmente no [artigo sobre segredos no binário](https://marcelxsilva.dev/artigos/segredos-no-binario/), continua necessária mesmo depois de rodar esse tipo de scanner. ## gitleaks e trufflehog Ferramentas como o [gitleaks](https://github.com/gitleaks/gitleaks) e o [trufflehog](https://github.com/trufflesecurity/trufflehog) foram criadas originalmente para buscar segredos em repositórios Git, mas funcionam igualmente bem apontadas para as saídas descompiladas de um APK, combinando regras por padrão (como o apkleaks) com análise de entropia: uma string com alta aleatoriedade de caracteres tem mais chance de ser uma chave ou token do que texto comum. ```bash gitleaks dir . -v --no-banner trufflehog filesystem . --no-verification ``` Um detalhe importante do trufflehog: por padrão, ele tenta **verificar** cada credencial encontrada, fazendo uma chamada real ao provedor correspondente (API da AWS, do GitHub, e assim por diante) para confirmar se ela ainda está ativa. Isso significa enviar o possível segredo para um serviço externo, o que pode não ser aceitável dependendo do escopo do teste. A flag `--no-verification`, usada acima, desliga essa checagem; a [documentação da ferramenta](https://github.com/trufflesecurity/trufflehog#verification) detalha o comportamento padrão. ## MobSF: o raio-x automatizado O [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF) é o scanner mais abrangente da lista: ele recebe um APK ou IPA, roda uma bateria de checagens estáticas (e, com configuração adicional, dinâmicas) e devolve um relatório organizado por categoria de risco, com boa cobertura dos mesmos temas do [OWASP MASVS](https://mas.owasp.org/MASVS/). ```bash docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest ``` Com o container no ar, basta abrir `http://localhost:8000`, enviar o APK ou o IPA pela interface e ler as seções Manifest, Code, Secrets e URLs. Ele cobre, numa única passada, boa parte do que os artigos anteriores desta série descreveram manualmente: permissões, componentes exportados, uso de criptografia fraca, segredos aparentes e configuração de rede. Isso o torna um bom ponto de partida para um primeiro raio-x do app, mas não substitui a leitura dirigida: o MobSF sinaliza padrões genéricos, sem o contexto de negócio que diz se um determinado achado é, de fato, explorável naquele app específico. ## Chaves de serviços de nuvem expostas Uma categoria de achado que vale a pena testar à parte: chaves de API do Google e do Firebase encontradas no app às vezes correspondem a projetos configurados sem restrição adequada. ```bash grep -oE 'name="(google_api_key|google_storage_bucket|firebase_database_url|project_id)">[^<]+' apktool-out/res/values/strings.xml ``` Ferramentas como o [GMapsAPIScanner](https://github.com/ozguralp/gmapsapiscanner) testam se uma chave do Google Maps está habilitada para APIs que ela não deveria acessar (geocoding, gerenciamento de faturamento), e uma chamada direta a um banco do [Firebase Realtime Database](https://firebase.google.com/docs/database/security) sem autenticação revela, em segundos, se as regras de segurança do projeto estão abertas para qualquer leitor: ```bash curl https://.firebaseio.com/.json ``` Esse tipo de teste é importante: faz uma requisição real contra a infraestrutura de produção do dono do app, e deve ser feito só com autorização explícita de quem administra aquele projeto, já que pode gerar cobrança ou alertas de segurança no provedor de nuvem. ## Instalando as ferramentas A maioria dessas ferramentas se instala com um gerenciador de pacotes comum: ```bash brew install jadx apktool gitleaks trufflehog uv tool install apkleaks uv tool install apkid docker pull opensecurity/mobile-security-framework-mobsf ``` ## Por que a ordem importa Rodar os scanners antes da leitura manual tende a gerar uma lista longa e desorganizada, difícil de priorizar porque falta o contexto de como as partes do app se conectam. Rodá-los depois transforma essa mesma lista numa checagem cruzada: cada achado do scanner é comparado contra o que já foi visto manualmente, e, nesse ponto, qualquer coisa nova que aparecer merece atenção redobrada, já que passou despercebida na primeira leitura. No próximo artigo: a mesma pergunta de análise estática, só que no lado iOS, onde o binário, o `Info.plist` e os entitlements contam uma história parecida, mas com ferramentas diferentes.