Como encontrar a API oculta de um aplicativo móvel: mitmproxy, Frida e proxies em 2026

```html

O site está fechado pelo Cloudflare, o Turnstile aparece a cada segundo pedido, e o layout muda a cada duas semanas. Ao mesmo tempo, o mesmo serviço possui um aplicativo móvel que se conecta diretamente ao backend e recebe um JSON pronto — sem desafios, sem formatação, com um esquema de campos estável. Este é o "API oculto": uma interface não documentada, mas totalmente funcional, que é utilizada pelo cliente oficial.

Vamos analisar passo a passo como encontrá-lo usando o mitmproxy, o que fazer com o certificate pinning e por que na fase de escalonamento a coleta sem proxy falha.

Por que se meter no tráfego do aplicativo

O scraping da versão web e a chamada do API privado são tarefas de custo diferente. Compare:

• Web. É necessário um navegador headless, contornar o anti-bot, parsing de HTML, reparo regular de seletores. Uma solicitação = megabytes de tráfego e segundos de tempo de CPU.
• API Privado. Um pedido HTTP comum com alguns cabeçalhos, a resposta — um JSON compacto com campos tipados. Muitas vezes, fornece mais dados do que a interface mostra: identificadores internos, flags, campos de serviço.

Os backends móveis historicamente são menos protegidos do que a web. A razão é prosaica: as plataformas anti-bot são projetadas para tráfego de navegador (desafios JS, canvas, sinais comportamentais), e o cliente móvel simplesmente não passaria por elas. Em vez disso, os desenvolvedores confiam em uma chave estática do aplicativo e no TLS pinning — ambos são gerenciados no dispositivo local.

O que será necessário

1. mitmproxy — um interceptador de proxy HTTPS de código aberto (mais de 44.000 estrelas no GitHub, a versão atual 12.2.2 foi lançada em abril de 2026, requer Python 3.12+). É instalado com um único comando: pip install mitmproxy. Suporta HTTP/1, HTTP/2, HTTP/3, WebSocket e TCP bruto, funciona com TLS 1.2 e 1.3.
2. Dispositivo Android ou emulador com root. A prática mostra que as versões Android 7–11 são as mais convenientes: versões mais novas tornaram o trabalho com certificados muito mais rigoroso.
3. ADB para comunicação com o dispositivo e Frida (pip install frida-tools) — será necessário se o aplicativo pinning o certificado.

O mitmproxy possui três interfaces sobre um único motor: mitmproxy (TUI terminal), mitmweb (interface web, mais conveniente para iniciantes) e mitmdump (headless, para scripts e automação).

Passo 1. Levantar o interceptador

Inicie a interface web para que ela escute conexões externas, e não apenas localhost:

mitmweb --web-host 0.0.0.0

Por padrão, o proxy é levantado na porta 8080. Na primeira execução, o mitmproxy cria seu próprio centro de certificação e coloca as chaves no diretório ~/.mitmproxy. Quatro arquivos aparecerão lá: mitmproxy-ca.pem (certificado junto com a chave privada), mitmproxy-ca-cert.pem (apenas o certificado), mitmproxy-ca-cert.p12 para Windows e mitmproxy-ca-cert.cer — formato para Android.

Passo 2. Direcionar o dispositivo através do proxy

Nas configurações de Wi-Fi do telefone, escolha o proxy manual: IP do seu computador na rede local e porta 8080. Em seguida, abra no navegador do dispositivo o domínio especial mitm.it — esta é uma página embutida no mitmproxy que detecta automaticamente a plataforma e fornece o formato necessário do certificado com instruções.

No iOS, o procedimento consiste em três partes, e a segunda metade todos esquecem: baixar o perfil através do Safari, instalá-lo em "Ajustes → Geral → VPN e gerenciamento de dispositivo", e então ativar separadamente a confiança total em "Ajustes → Geral → Sobre este dispositivo → Confiar em certificados". Sem o último passo, o certificado é instalado, mas não funciona.

Se não quiser mexer nas configurações de Wi-Fi, o mitmproxy tem um modo de servidor VPN: mitmweb --mode wireguard. O dispositivo se conecta com o cliente WireGuard padrão, e o tráfego é interceptado de forma transparente, sem configuração manual do proxy no sistema.

Passo 3. A principal barreira — confiança no certificado

Aqui a maioria das tentativas falha. Existem exatamente dois problemas, e são problemas diferentes.

CA personalizados não são bem vistos desde 2016

A partir do Android 7 Nougat (API 24), os aplicativos confiam por padrão apenas no armazenamento de certificados do sistema. CA personalizado é ignorado, a menos que o desenvolvedor explicitamente o permita na Configuração de Segurança da Rede — através do bloco <certificates src="user" /> nos trust anchors. Esta foi uma decisão consciente do Google para reduzir a superfície de ataque, e não pode ser contornada com as configurações do telefone. O Chrome, aliás, também não confia em certificados personalizados. No Android 11, as restrições foram ainda mais rigorosas.

Conclusão prática: no dispositivo com root, o certificado do mitmproxy deve ser colocado no armazenamento de sistema, e não no armazenamento de usuário. É por isso que o root está na lista de requisitos, e não como "desejável".

Certificate pinning

A segunda barreira é o pinning: o aplicativo contém uma impressão digital do certificado esperado do servidor e se recusa a conversar com qualquer outra. Mesmo o CA do sistema não ajuda aqui. Uma pesquisa da ACM de 2022 mostrou que o pinning é comum em "verticais de alto risco" (bancos, táxis, criptomoedas), mas muitas vezes é implementado de forma incompleta e, portanto, pode ser contornado.

Existem várias ferramentas para a tarefa, e elas a resolvem de maneiras diferentes:

• Frida — edição do comportamento em tempo de execução: interceptamos funções de verificação de certificado e as forçamos a retornar sucesso. O aplicativo, nesse caso, não é modificado — a opção mais flexível. Um lançamento típico: frida -U -f com.target.app -l ssl_bypass.js --no-pause.
• apk-mitm — remove automaticamente o pinning do arquivo APK de forma estática.
• android-unpinner — recompila o APK, injetando Frida e scripts para remover o pinning.
• objection — toolkit sobre Frida, que funciona tanto para iOS quanto para Android.
• ssl-kill-switch2 — desativa o pinning em aplicativos iOS e macOS.

Se um domínio específico está pinning de forma rígida e impede o funcionamento, ele pode ser simplesmente excluído da interceptação com a opção ignore_hosts (aceita expressões regulares) — o tráfego passará pelo mitmproxy sem decodificação.

Passo 4. Encontrar a solicitação necessária

Em seguida, é rotina. Abra o aplicativo, execute exatamente uma ação significativa (abrir a ficha de um produto, rolar o feed, aplicar um filtro) e veja quais solicitações apareceram. Na interface terminal, isso é feito rapidamente: Z limpa a lista de fluxos, Enter abre a solicitação selecionada, E exporta — incluindo um comando curl pronto.

O que procurar na solicitação interceptada:

• Endpoint e parâmetros. Muitas vezes, há muito mais do que a interface do aplicativo utiliza.
• Chave do cliente. Clássico do gênero — um identificador estático embutido no aplicativo. Em uma análise conhecida do API público MyAnimeList, essa chave era o cabeçalho x-mal-client-id com o valor 6591a087c62b3e94d769cd8e35ffe909, que abria acesso aos endpoints api.myanimelist.net/v3/anime/season e /v3/anime com duas dezenas de parâmetros.
• User-Agent. Nos clientes móveis, ele é específico e serve como parte do "passaporte" — no mesmo exemplo, é MAL (ios, 139).
• Tokens e seu tempo de vida. Veja imediatamente se a chave é estática ou se é atualizada: isso determina toda a arquitetura futura do coletor.

O curl exportado pode ser facilmente transformado em código através do curlconverter — você obterá uma solicitação pronta em requests, e então trabalhará com um cliente HTTP comum, sem navegador.

Passo 5. Escalonamento — e onde tudo quebra

Neste ponto, a decepção chega, familiar a todos que tentaram: de um IP doméstico, o API privado responde perfeitamente nos primeiros trinta minutos, e depois começa a retornar 429 e 403. Os backends móveis são menos protegidos contra falsificação de cliente, mas os limites por IP são mais rígidos — o servidor presume que por trás do endereço está um único telefone, e não um parser em vinte fluxos.

Daqui, as conclusões práticas.

1. Mantenha o perfil de solicitações plausível. Um aplicativo real não faz 50 solicitações por segundo e não opera estritamente de acordo com um cronograma. A ordem das chamadas também é importante: um cliente real primeiro solicita a configuração da sessão, depois o conteúdo.
2. Distribua a carga entre os endereços. Um IP = um "telefone". Sobre estratégias de rotação, delays com jitter e backoff exponencial, discutimos detalhadamente no material como contornar a limitação de taxa de API ao fazer scraping através de proxies.
3. Considere a geolocalização. Muitos APIs móveis fornecem conteúdo e preços diferentes dependendo do país do endereço — isso é ao mesmo tempo uma limitação e uma oportunidade.

É conveniente depurar sem sair do mitmproxy: ele pode se conectar a um proxy upstream. O comando mitmdump --mode upstream:http://example.com:8081 redireciona todo o tráfego para o upstream, e a autorização para ele é definida pela opção --upstream-auth no formato username:password. Assim, você verá as mesmas solicitações que antes, mas elas sairão de um endereço externo — você pode verificar imediatamente como o API reage a um país específico ou tipo de IP.

Que tipo de proxy usar para API móvel

A escolha aqui não é abstrata, ela decorre de quem você está fingindo ser.

• Proxies móveis — a opção prioritária. Você imita o tráfego do aplicativo, e o endereço do operador celular parece absolutamente orgânico para o backend: por trás de um único endereço, graças ao CGNAT, realmente estão centenas de assinantes, portanto, os limites para esses IPs são mais suaves. Proxies móveis 4G/LTE são adequados.
• Proxies residenciais — um meio termo viável, se os volumes forem grandes e a vinculação ao operador não for crítica: IPs domésticos de provedores oferecem ampla cobertura geográfica a um preço razoável. Esses são proxies residenciais.
• Data center — apenas para endpoints sem verificação séria da reputação do endereço. Seu ASN é identificado instantaneamente, e em um backend móvel isso parece estranho: não existem telefones em data centers.

Armadilhas que são descobertas tarde demais

• HTTP/3. O suporte a QUIC no mitmproxy existe e está ativado por padrão, mas no tráfego móvel real é limitado: frequentemente, a conexão precisa ser forçada a reverter para HTTP/2 através de manipulações com ALPN. O QUIC funciona melhor em modos reverse e WireGuard.
• API privado muda sem aviso. Ele não tem obrigações de compatibilidade retroativa — é uma interface interna. A versão do aplicativo no User-Agent deixará de ser suportada em algum momento, e o coletor começará a receber respostas vazias silenciosamente. Monitore não apenas os códigos de resposta, mas também a estrutura do JSON.
• Não confunda "encontrou a chave" e "obteve permissão". Uma chave de cliente estática não é uma autorização para coleta ilimitada.

Sobre o aspecto legal

Interceptar tráfego em seu próprio dispositivo é uma prática legal e comum de depuração, utilizada por desenvolvedores móveis e especialistas em segurança. As fronteiras começam mais adiante: cumpra os termos de uso do serviço, não colete dados pessoais sem base legal (na UE, isso é diretamente regulado pelo GDPR), não toque em endpoints que exigem autorização de terceiros, e mantenha a carga em um nível que não atrapalhe o funcionamento do serviço. Um guia prático: se os dados são visíveis no aplicativo para qualquer usuário sem entrar na conta — você está em uma zona relativamente segura; se o acesso requer uma conta de outra pessoa — você já está fora dela.

Resumindo

O esquema é funcional e economiza semanas de trabalho com anti-bots: levantamos o mitmproxy, colocamos o certificado no armazenamento de sistema do dispositivo com root, se necessário, removemos o pinning através do Frida, capturamos uma solicitação significativa, exportamos para curl e reescrevemos em Python. A partir daí, a tarefa da categoria "contornar proteção" se transforma na tarefa de "distribuir carga cuidadosamente" — e é resolvida com rotação de endereços, pausas razoáveis e o tipo certo de proxy. Começar é mais fácil com proxies móveis: eles estão mais próximos do tráfego que o backend espera ver.