Reverse Engineering no desenvolvimento móvel: o que é, ferramentas e métodos de análise

O que é Reverse Engineering?

Reverse Engineering (engenharia reversa) é a disciplina de análise de software focada em recuperar as características, lógica e estrutura de um aplicativo a partir de sua representação binária. Para aplicativos móveis, os objetos de análise são arquivos APK (Android) e IPA (iOS), que contêm código compilado, recursos, manifestos e certificados. O resultado da engenharia reversa é a extração de algoritmos, protocolos, chaves de criptografia, esquemas de API e lógica de negócios.

Os objetivos da engenharia reversa dividem-se em legítimos e ilegítimos. Legítimos: análise de malware para criar ferramentas de segurança, auditoria de aplicativos próprios em busca de vulnerabilidades, garantia de compatibilidade com protocolos fechados, análise de patentes e educação. Ilegítimos: roubo de propriedade intelectual, burla de restrições de licença, criação de cópias piratas e modificação de aplicativos para roubar dados de usuários. De acordo com Google Play Protect (2025), 78% das modificações maliciosas de aplicativos bancários são criadas a partir do APK original processado por engenharia reversa.

A metodologia da engenharia reversa inclui duas direções principais: análise estática (sem executar o aplicativo) e análise dinâmica (durante a execução). Cada abordagem fornece um nível diferente de informação. A análise estática oferece uma imagem completa do código, mas sem dados de execução. A análise dinâmica revela o comportamento real, o fluxo de dados e as chamadas de rede, mas apenas dentro de um cenário de execução específico. A engenharia reversa profissional sempre combina ambas as abordagens.

Ferramentas de análise estática

A análise estática é a primeira etapa da engenharia reversa. O APK ou IPA original é descompactado e cada componente é analisado separadamente. Os principais alvos: bytecode DEX, recursos, manifesto, bibliotecas nativas (.so, .dylib) e metadados.

jadx — descompilador de DEX para Java

jadx é a principal ferramenta para análise estática de aplicativos Android. Ele converte bytecode DEX em código Java legível com perda mínima. jadx suporta: descompilação multidex, reconhecimento de lambdas e classes Kotlin embutidas, e exportação para projeto Gradle. Para código ofuscado (ProGuard), jadx exibe código com nomes a, b, c, mas a estrutura de classes e a sequência de chamadas são preservadas. De acordo com testes independentes, jadx descompila corretamente 85–92% do código mesmo com ofuscação.

apktool — descompactação de recursos

apktool decodifica APK em código smali (assembler DEX) e restaura recursos em formato legível: AndroidManifest.xml é convertido de AXML para XML legível, layouts tornam-se marcação XML, strings.xml torna-se texto simples. apktool permite modificar recursos e reconstruir o APK. Após descompactar via apktool e substituir recursos, o aplicativo pode ser instalado com conteúdo modificado.

Ghidra — análise de bibliotecas nativas

Ghidra (NSA) é um framework de engenharia reversa essencial para analisar bibliotecas .so no Android e .dylib no iOS. Ghidra desmonta código ARM64, reconstrói pseudocódigo C e constrói grafos de chamadas. Para engenharia reversa móvel, Ghidra é usada para analisar implementações nativas de criptografia e mecanismos DRM. Ghidra suporta scripting em Python e Java para automatizar a análise.

# Descompactação e descompilação de APK
$ jadx -d output_dir app.apk

# Descompactação de recursos via apktool
$ apktool d app.apk -o app_unpacked

# Análise de bibliotecas nativas via Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Busca de constantes de string em DEX
$ strings classes.dex | grep -i api_key

Ferramentas de análise dinâmica

A análise dinâmica é realizada em um aplicativo em execução. O analisador conecta-se ao processo e intercepta chamadas de função, argumentos e valores de retorno em tempo real.

Frida — ferramenta de instrumentação universal

Frida é a ferramenta líder para análise dinâmica de aplicativos móveis. Frida injeta um mecanismo JavaScript no processo do aplicativo (Android ART ou iOS) e permite interceptar chamadas tanto de funções Java/Objective-C quanto C/C++. Com Frida, engenheiros reversos podem: registrar todas as chamadas ao método AES.decrypt() com parâmetros, substituir valores de retorno arbitrariamente, desativar SSL-pinning via Universal Android SSL Unpin e rastrear chamadas nativas via Stalker. Frida funciona sem modificar o APK/IPA, tornando-a indispensável para testes de penetração.

Objection — wrapper do Frida

Objection fornece comandos prontos para tarefas comuns de engenharia reversa sem escrever scripts JavaScript: disable-pinning (desativação de SSL pinning), dump-keychain (iOS), explore (navegação pela hierarquia de classes), memory search (busca de strings na memória). Objection permite realizar uma análise dinâmica completa sem uma única linha de código. Para aplicativos iOS, Objection encontra e registra automaticamente chamadas para NSURLSession, CFNetwork e NSKeyedArchiver.

Xposed Framework

Xposed é um framework para Android que funciona substituindo o arquivo app_process no Zygote. Ao contrário do Frida, Xposed não requer acesso root após a instalação. Módulos Xposed podem interceptar chamadas de métodos em qualquer aplicativo. Para engenharia reversa, Xposed é conveniente para análise de longo prazo: o módulo é instalado e funciona continuamente, registrando o comportamento do aplicativo em diferentes cenários. Xposed suporta Android até a versão 8.1; para Android 9+, é usado EdXposed baseado em SandHook.

// Frida: interceptação do método decrypt() em um aplicativo
let aesClass = Java.use("javax.crypto.Cipher");

aesClass.doFinal.overload(
    "[B", "int", "int"
).implementation = function(
    input, offset, len
) {
    console("[AES] decrypt called, len=" + len);
    return this.doFinal(input, offset, len);
};

Processo de engenharia reversa de um aplicativo Android

O fluxo de trabalho padrão de engenharia reversa consiste em etapas sequenciais, cada uma fornecendo um determinado nível de informação.

Etapa 1: Coleta de informações

O analista examina o APK no nível de metadados: targetSdk, uses-permission (quais permissões são solicitadas), intent-filter e componentes exportados. As permissões podem revelar quais APIs são usadas (android.permission.CAMERA → câmera, android.permission.RECORD_AUDIO → áudio). Atividades exportadas identificam pontos de entrada sem autorização. Esta etapa é realizada via aapt ou ApkAnalyzer e leva de 1 a 2 minutos.

Etapa 2: Descompilação DEX

O APK é descompactado e classes.dex (ou multidex) é alimentado ao jadx. A saída é código Java/Kotlin organizado em pacotes. O analista procura classes-chave: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, e verifica quais algoritmos são usados. Se o código contém strings como AES/CBC/PKCS5Padding, o aplicativo usa criptografia e a chave precisa ser encontrada. Nesta etapa, são identificados: chaves hardcodadas, URLs de API, tokens OAuth e segredos. Sem ofuscação, todo o código do aplicativo é lido como um projeto Java comum.

Etapa 3: Análise de tráfego

Após configurar Frida ou Objection para desativar o SSL-pinning, o analista inicia o aplicativo e intercepta o tráfego de rede via Burp Suite ou mitmproxy. Os dados de tráfego revelam o esquema da API: quais endpoints, quais parâmetros e em qual formato. Se possível, o analista modifica as requisições e verifica a resposta do servidor a dados incorretos ou maliciosos. A falta de validação do lado do servidor é uma vulnerabilidade direta descoberta nesta etapa.

Etapa 4: Registro em data.json

Os resultados da análise são registrados em formato estruturado. Para cada ponto vulnerável encontrado, é indicado: classe e método, descrição da vulnerabilidade, vetor de exploração e recomendação de correção. Este conjunto de dados é enviado à equipe de desenvolvimento ou usado para compilar um relatório de teste de penetração. Em ambientes automatizados (MobSF), o relatório é gerado automaticamente com base nos resultados da análise estática e dinâmica.

Características da engenharia reversa em iOS

A engenharia reversa de aplicativos iOS é mais difícil que a do Android devido à arquitetura de segurança mais rigorosa da Apple e à falta de acesso direto ao sistema de arquivos em dispositivos padrão. É necessário jailbreak para análise iOS.

Análise estática Mach-O

Um arquivo IPA contém um binário Mach-O, o formato universal de arquivos executáveis da Apple. Para descompilação, usa-se Hopper Disassembler ou IDA Pro. Ao contrário do Android DEX, que descompila em Java com perda mínima, Mach-O contém código ARM64 nativo que é reconstruído em pseudocódigo C com menor precisão. Hopper alcança 60–70% de reconstrução; o restante deve ser analisado em nível de assembly.

Análise dinâmica com Frida para iOS

Frida no iOS requer jailbreak e instalação do frida-server. Após a conexão, Frida intercepta métodos Objective-C através do roteamento de mensagens da API. Para aplicativos iOS, um cenário típico inclui: interceptar NSURLSession.dataTaskWithRequest para registrar requisições HTTP, interceptar NSKeyedUnarchiver para analisar dados serializados e rastrear consultas CoreData via frida-trace. Frida tornou-se disponível para iOS 15–17 com o lançamento do jailbreak Dopamine.

Modificação de IPA

A engenharia reversa pode envolver a modificação do IPA seguida de reempacotamento e instalação no dispositivo. As ferramentas incluem: ipatool para descompactar, MachOView para visualizar seções e optool para injeção de código. Após a modificação, o IPA é assinado via ldid ou fastlane sigh para instalação em um dispositivo com jailbreak. Para iOS 16+, a assinatura de código é verificada no nível do Secure Enclave, e um IPA modificado não será executado em um dispositivo sem jailbreak.

// Frida: interceptação de requisições HTTP em um aplicativo iOS
if (ObjC.available) {
    let NSURLSession = ObjC.classes.NSURLSession;
    let dataTaskWithRequest = ObjC.protocol("NSURLSessionDelegate")
        .method("- URLSession:dataTask:didReceiveData:");
    Interceptor.attach(dataTaskWithRequest.implementation, {
        onEnter(args) {
            let data = ObjC.Object(args[3]);
            console("[HTTP Response]", data.toString());
        }
    });
}

Métodos de proteção contra engenharia reversa

A proteção contra engenharia reversa segue o princípio de segurança em camadas: nenhum método único oferece 100% de proteção, mas a combinação torna a engenharia reversa economicamente inviável.

Ofuscação de código

O nível básico é o ProGuard para Android, que substitui nomes de classes e métodos por nomes de um único caractere. Para proteção aprimorada, o DexGuard adiciona indução de sobrecarga (vários métodos com assinaturas diferentes e o mesmo nome) e criptografia de strings AES-256. A ofuscação aumenta o tempo de análise do código de 5 minutos para 5–20 horas, dependendo do nível. DexGuard adicionalmente ofusca o fluxo de controle, tornando o código ilegível para o jadx.

Criptografia de constantes

Todas as constantes de string — URLs, chaves, tokens, consultas SQL — são criptografadas em tempo de compilação e descriptografadas em tempo de execução. Isso protege contra análise estática de strings em arquivos DEX. Um invasor executando strings em app.apk não verá nenhum endpoint de API. Mesmo após a descompilação, todas as strings aparecem como dados binários. Cada string pode usar uma chave separada, complicando a desofuscação.

RASP e verificações de integridade

Um agente RASP dentro do aplicativo detecta Frida e depuração em tempo de execução. Verificações de integridade via hash SHA-256 do APK impedem a execução de uma versão modificada do aplicativo. Se o hash do APK não corresponder ao hash de referência (armazenado na camada nativa), o aplicativo é encerrado. Isso bloqueia ataques baseados em modificação do APK, incluindo reempacotamento.

Proteção do lado do servidor

A lógica de negócios crítica deve ser executada no servidor, não no cliente. Mesmo que um invasor descompile completamente o aplicativo, o código do servidor permanece inacessível. A validação do lado do servidor de todas as requisições e parâmetros impede a exploração de vulnerabilidades descobertas durante a engenharia reversa. A atestação do servidor via Play Integrity API ou App Attest confirma que a requisição vem de um aplicativo genuíno e não modificado.