Entendendo teardown mobile no dia a dia
Teardown mobile é basicamente o processo de abrir uma aplicação Android ou iOS e examinar seu conteúdo, arquitetura, configuração e dependências sem precisar ter acesso ao código-fonte original. No Android, você pega o APK, que na verdade é um arquivo ZIP renomeado, e extrai tudo que está dentro: recursos, bibliotecas, arquivos de compiled code, o AndroidManifest.xml, e por aí vai. No iOS, o processo é mais restrito porque os IPA são assinados e compactados, mas ainda dá para fazer análise estática se você tiver o binário. O que muita gente não percebe na hora que começa é que o resultado raramente é organizado. Você vai encontrar pastas com nomes aleatórios, classes ofuscadas, e recursos que não fazem sentido nenhum sem contexto. Eu passei semanas tentando entender um APK de um app de delivery que tinha mais de 200 classes ofuscadas com nomes como a, b, c. O único caminho foi rastrear chamadas de rede e mapear por onde o app se comunicava com o backend, usando termos como "pedido", "usuario", "status" que sobreviviam mesmo na ofuscação.
O que usar para teardown mobile
Para Android, o pacote standard do setor é o apktool. Ele descompila o APK e reconstrói, mantendo os recursos intactos. Junto com ele, você vai precisar do JADX para ver o código Java/Kotlin de forma legível, e do dex2jar como alternativa quando o JADX travar em alguns arquivos. No iPhone, as opções são mais limitadas: o ldid e o class-d ajudam a olhar a estrutura de classes Objective-C e Swift, mas sem acesso root no dispositivo ou sem o código-fonte, você fica muito na mão. Tem também o frida, que é outra coisa completamente diferente. Frida não faz teardown estático. Ele injeta código em tempo de execução no app rodando no dispositivo, o que permite interceptar chamadas de rede, manipular dados na memória e ver o que acontece enquanto o app está sendo usado. Se você só quer saber como o app é estruturado, Frida é overkill. Se precisa descobrir como uma criptografia é aplicada em tempo real, é a ferramenta certa.
Pitfalls que todo mundo erra
A primeira armadilha é achar que descompilar o APK já te dá o código original. Não dá. O bytecode Java pode ser lido, mas informações como nomes de variáveis, comentários e estrutura exata do código-fonte somem no processo de compilação. Dependendo de como o build foi configurado, você vai ter linhas cheias de nulls e estruturas que parecem randomizadas. A ofuscação com ProGuard ou R8 piora isso drasticamente, mas mesmo sem ofuscação, o que você vê é uma aproximação, não o original. A segunda armadilha é ignorar as bibliotecas. Um app moderno pode ter 50 ou 60 dependências incluídas no APK. Muitas delas são transitivas. Se você não verificar quais bibliotecas estão realmente sendo usadas pelo app e quais são apenas peso morto, seu relatório final vai ter páginas de informação irrelevante. Eu perdi dois dias mapeando um app inteiro porque não havia verificado que três das bibliotecas principais eram da mesma origem e podiam ser consolidadas em uma análise só.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro problema comum é não distinguir entre o que está hardcodado e o que vem do servidor. URLs de API, chaves de terceiros, configurações de feature flags. Muita gente lista tudo como "segredo exposto" quando na verdade aquele dado é completamente controlado pelo backend e muda a cada deploy. Classificar corretamente o que é estático e o que é dinâmico economiza tempo e evita alertas falsos em revisões de segurança.
Um caso específico que encontrou meu caminho
Eu estava analisando um app de fintech cuja criptografia de comunicação dependia de uma chave embutida no binário, mas a chave era gerada dinamicamente a partir de um seed que mudava a cada build. O interessante é que o seed estava em um arquivo .so (biblioteca nativa), então o JADX sozinho não resolves nada. Eu precisei usar o ghidra para analisar o código ARM, identificar a função que gerava o seed, e depois rodar o app em um emulator com Frida para capturar o valor em tempo real. Sem o Frida, eu teria ficado preso apenas na parte estática e nunca conseguiria rastrear a comunicação cifrada até o endpoint final. O workaround prático que funcione nesse cenário foi criar um script Python que usava o Frida para fazer hook na função nativa no momento exato da geração do seed, imprimir o valor na saída padrão, e então usar esse valor para decifrar pacotes capturados com o mitmproxy. Levei cerca de quatro horas para montar o fluxo, mas depois disso a análise completa do canal de comunicação levou uns quinze minutos.
Limitações reais do teardown mobile
Teardown não resolve tudo. Se o app usa code signing forte com keystore proprietário, reconstruir o APK modificado pode quebrar a assinatura e o app simplesmente não vai rodar no dispositivo. No iOS, isso é regra, não exceção. Sem acesso ao certificado de desenvolvimento da empresa, qualquer modificação no IPA resulta em falha na instalação. Apps com anti-tampering e jailbreak detection também vão dificultar ou impossibilitar o uso do Frida em dispositivos físicos. Nesses casos, o único caminho viável costuma ser a análise estática combinada com engenharia reversa do binário nativo, o que exige conhecimento de assembly e paciência considerável. Não existe atalho aqui. Às vezes o mais inteligente é pedir ao desenvolvedor que forneça documentação ou acesso ao código, se o objetivo for legítimo e houver relação profissional.
Downloads e ferramentas
O apktool aparece no site oficial do projeto, disponível para Windows, macOS e Linux, e o instalador via package manager é sempre a opção mais rápida. O JADX tem release direto no GitHub com versões para todas as plataformas. O Frida segue o mesmo padrão, mas exige atenção à versão do Python e às dependências do sistema. Para análise de bibliotecas nativas, o ghidra da NSA é gratuito e bastante capaz, embora a curva de aprendizado seja mais íngreme que a do JADX. Se você está começando agora, o caminho mais simples é baixar um APK público qualquer, rodar o apktool, abrir no JADX, e tentar responder três perguntas: quais endpoints o app conversa, quais dados sensíveis trafegam, e quão fácil seria modificar o comportamento básico. Isso já cobre a maior parte do que se precisa num primeiro teardown e mostra rapidamente onde estão as fronteiras do que a técnica consegue entregar.
