Cómo encontrar el API oculto de una aplicación móvil: mitmproxy, Frida y proxies en 2026

```html

El sitio está cerrado por Cloudflare, Turnstile aparece en cada segundo intento, y el diseño cambia cada dos semanas. Sin embargo, el mismo servicio tiene una aplicación móvil que se conecta directamente al backend y recibe un JSON listo — sin desafíos, sin markup, con un esquema de campos estable. Este es el "API oculto": una interfaz no documentada, pero completamente funcional, que utiliza el cliente oficial.

Desglosamos paso a paso cómo encontrarlo usando mitmproxy, qué hacer con el pinning de certificados y por qué en la etapa de escalado de la recolección sin proxy todo se desmorona.

¿Por qué meterse en el tráfico de la aplicación?

El scraping de la versión web y la llamada a un API privado son tareas de costos diferentes. Comparen:

• Web. Se necesita un navegador sin cabeza, eludir el anti-bot, parsear HTML, reparar selectores regularmente. Una solicitud = megabytes de tráfico y segundos de tiempo de CPU.
• API privado. Una solicitud HTTP normal con un par de encabezados, la respuesta es un JSON compacto con campos tipados. A menudo devuelve más datos de los que muestra la interfaz: identificadores internos, flags, campos de servicio.

Los backends móviles históricamente están menos protegidos que la web. La razón es prosaica: las plataformas anti-bot están diseñadas para tráfico de navegador (desafíos JS, canvas, señales de comportamiento), y el cliente móvil simplemente no pasaría a través de ellas. En su lugar, los desarrolladores confían en una clave estática de la aplicación y el pinning de TLS — y ambas se eliminan en el dispositivo local.

Qué se necesita

1. mitmproxy — un proxy interceptador HTTPS de código abierto (más de 44,000 estrellas en GitHub, la rama actual 12.2.2 salió en abril de 2026, requiere Python 3.12+). Se instala con un solo comando: pip install mitmproxy. Entiende HTTP/1, HTTP/2, HTTP/3, WebSocket y TCP sin procesar, trabaja con TLS 1.2 y 1.3.
2. Dispositivo Android o emulador con root. La práctica muestra que lo más conveniente es Android 7–11: las nuevas versiones han endurecido mucho el trabajo con certificados.
3. ADB para comunicarse con el dispositivo y Frida (pip install frida-tools) — será necesario si la aplicación pinnea el certificado.

mitmproxy tiene tres interfaces sobre un solo motor: mitmproxy (TUI en terminal), mitmweb (interfaz web, más conveniente para principiantes) y mitmdump (sin cabeza, para scripts y automatización).

Paso 1. Levantar el interceptador

Iniciamos la interfaz web de manera que escuche conexiones externas, no solo localhost:

mitmweb --web-host 0.0.0.0

Por defecto, el proxy se levanta en el puerto 8080. En el primer inicio, mitmproxy crea su propia autoridad certificadora y coloca las claves en el directorio ~/.mitmproxy. Allí aparecerán cuatro archivos: mitmproxy-ca.pem (certificado junto con la clave privada), mitmproxy-ca-cert.pem (solo el certificado), mitmproxy-ca-cert.p12 para Windows y mitmproxy-ca-cert.cer — formato para Android.

Paso 2. Dirigir el dispositivo a través del proxy

En la configuración de Wi-Fi del teléfono, seleccionamos un proxy manual: la IP de su computadora en la red local y el puerto 8080. Luego, abrimos en el navegador del dispositivo un dominio especial mitm.it — esta es una página integrada en mitmproxy que detecta automáticamente la plataforma y proporciona el formato de certificado necesario con instrucciones.

En iOS, el procedimiento consta de tres partes, y todos olvidan la segunda mitad: descargar el perfil a través de Safari, instalarlo en "Configuración → General → VPN y gestión de dispositivos", y luego activar por separado la confianza total en "Configuración → General → Acerca de este dispositivo → Confianza en certificados". Sin el último paso, el certificado está instalado, pero no funciona.

Si no desea lidiar con la configuración de Wi-Fi, mitmproxy tiene un modo de servidor VPN: mitmweb --mode wireguard. El dispositivo se conecta con el cliente WireGuard estándar, y el tráfico se intercepta de manera transparente, sin necesidad de configurar manualmente el proxy en el sistema.

Paso 3. La principal barrera — confianza en el certificado

Aquí se rompen la mayoría de los intentos. Hay exactamente dos problemas, y son problemas diferentes.

CA personal no es bien recibida desde 2016

A partir de Android 7 Nougat (API 24), las aplicaciones por defecto solo confían en el almacén de certificados del sistema. La CA personalizada se ignora a menos que el desarrollador lo haya permitido explícitamente en la Configuración de Seguridad de la Red — a través del bloque <certificates src="user" /> en los anclajes de confianza. Esta fue una decisión consciente de Google para reducir la superficie de ataque, y no se puede eludir con la configuración del teléfono. Chrome, por cierto, tampoco confía en certificados personalizados. En Android 11, las restricciones se endurecieron aún más.

Conclusión práctica: en un dispositivo con root, el certificado mitmproxy debe colocarse en el almacén de certificados del sistema, no en el personal. Por eso el root está en la lista de requisitos, y no como "deseable".

Certificate pinning

La segunda barrera es el pinning: la aplicación lleva consigo la huella del certificado del servidor esperado y se niega a comunicarse con cualquier otro. Incluso la CA del sistema no ayuda aquí. Un estudio de ACM de 2022 mostró que el pinning es común en verticales de "alto riesgo" (bancos, taxis, criptomonedas), pero a menudo se implementa de manera incompleta y, por lo tanto, se puede eludir.

Hay varias herramientas para esta tarea, y resuelven el problema de diferentes maneras:

• Frida — modificación del comportamiento en tiempo de ejecución: interceptamos funciones de verificación de certificados y las obligamos a devolver éxito. La aplicación no se modifica en este caso — es la opción más flexible. Un lanzamiento típico: frida -U -f com.target.app -l ssl_bypass.js --no-pause.
• apk-mitm — elimina automáticamente el pinning del archivo APK de forma estática.
• android-unpinner — recompone el APK, inyectando Frida y scripts para eliminar el pinning.
• objection — toolkit sobre Frida, que funciona tanto en iOS como en Android.
• ssl-kill-switch2 — desactiva el pinning en aplicaciones de iOS y macOS.

Si un dominio específico está pinneado de forma rígida y obstaculiza el trabajo, se puede simplemente excluir de la interceptación con la opción ignore_hosts (acepta expresiones regulares) — el tráfico pasará por alto mitmproxy sin ser descifrado.

Paso 4. Encontrar la solicitud necesaria

A continuación, viene la rutina. Abrimos la aplicación, realizamos exactamente una acción significativa (abrir una tarjeta de producto, desplazarse por el feed, aplicar un filtro) y observamos qué solicitudes han aparecido. En la interfaz de terminal, esto se hace rápidamente: Z limpia la lista de flujos, Enter abre la solicitud seleccionada, E la exporta — incluida la opción lista de comandos curl.

Qué buscar en la solicitud interceptada:

• Endpoint y parámetros. A menudo hay muchos más de los que utiliza la interfaz de la aplicación.
• Clave del cliente. Clásico del género — un identificador estático, incrustado en la aplicación. En un conocido análisis del API público de MyAnimeList, esta clave resultó ser el encabezado x-mal-client-id con el valor 6591a087c62b3e94d769cd8e35ffe909, que abría el acceso a los endpoints api.myanimelist.net/v3/anime/season y /v3/anime con dos docenas de parámetros.
• User-Agent. En los clientes móviles es específico y sirve como parte del "pase" — en el mismo ejemplo, es MAL (ios, 139).
• Tokens y su tiempo de vida. Mire de inmediato si la clave es estática o se actualiza: esto afecta toda la arquitectura futura del recolector.

El curl exportado se puede convertir fácilmente en código a través de curlconverter — obtendrá una solicitud lista en requests, y luego trabajará con un cliente HTTP normal, sin necesidad de un navegador.

Paso 5. Escalado — y dónde todo se rompe

En este punto llega la decepción, familiar para todos los que han probado: desde una IP doméstica, el API privado responde perfectamente durante los primeros treinta minutos, y luego comienza a devolver 429 y 403. Los backends móviles están menos protegidos contra la suplantación del cliente, pero los límites por IP son más estrictos — el servidor asume que detrás de la dirección hay un solo teléfono, no un parser en veinte hilos.

De aquí se derivan conclusiones prácticas.

1. Mantenga el perfil de solicitudes creíble. Una aplicación real no hace 50 solicitudes por segundo y no sigue un horario estricto. El orden de las llamadas también es importante: un cliente real primero solicita la configuración de la sesión, luego el contenido.
2. Distribuya la carga entre direcciones. Una IP = un "teléfono". Sobre estrategias de rotación, retrasos con jitter y backoff exponencial se ha discutido en detalle en el material cómo eludir el límite de tasa de API al hacer scraping a través de proxies.
3. Tenga en cuenta la geolocalización. Muchos API móviles devuelven contenido y precios diferentes según el país de la dirección — esto es tanto una limitación como una oportunidad.

Es conveniente realizar la depuración sin salir de mitmproxy: puede conectarse a un proxy superior. El comando mitmdump --mode upstream:http://example.com:8081 envía todo el tráfico a upstream, y la autorización a él se establece con la opción --upstream-auth en el formato username:password. Así verá las mismas solicitudes que antes, pero se envían desde una dirección externa — puede verificar de inmediato cómo reacciona el API a un país o tipo de IP específico.

Qué tipo de proxy elegir para un API móvil

La elección aquí no es abstracta, se deriva de quién pretendes ser.

• Proxies móviles — la opción prioritaria. Imita el tráfico de la aplicación, y la dirección del operador celular se ve absolutamente orgánica para el backend: detrás de una dirección, gracias a CGNAT, realmente hay cientos de abonados, por lo que los límites para tales IP son más suaves. Se adaptan proxies móviles 4G/LTE.
• Proxies residenciales — un término medio funcional, si los volúmenes son grandes y la vinculación al operador no es crítica: las IP domésticas de los proveedores ofrecen una amplia cobertura geográfica a un precio razonable. Estos son proxies residenciales.
• Proxies de centros de datos — solo para endpoints sin verificación seria de la reputación de la dirección. Su ASN se identifica instantáneamente, y en el backend móvil esto se ve extraño: no hay teléfonos en los centros de datos.

Trampas que se descubren tarde

• HTTP/3. El soporte para QUIC en mitmproxy está presente y habilitado por defecto, pero en el tráfico móvil real está limitado: a menudo es necesario forzar la conexión a HTTP/2 mediante manipulaciones con ALPN. QUIC funciona mejor en modos reverse y WireGuard.
• API privado cambia sin previo aviso. No tiene obligaciones de compatibilidad hacia atrás — es una interfaz interna. La versión de la aplicación en User-Agent dejará de ser atendida en algún momento, y el recolector comenzará a recibir respuestas vacías en silencio. Monitoree no solo los códigos de respuesta, sino también la estructura del JSON.
• No confunda "encontré la clave" con "obtuve permiso". Una clave estática de cliente no es un permiso para la recolección ilimitada.

Sobre el aspecto legal

Interceptar tráfico en su propio dispositivo es una práctica legal y cotidiana de depuración, utilizada por desarrolladores móviles y especialistas en seguridad. Las fronteras comienzan más allá: cumpla con los términos de uso del servicio, no recolecte datos personales sin una base legal (en la UE esto está regulado directamente por el GDPR), no toque endpoints que requieren autorización ajena, y mantenga la carga en un nivel que no interrumpa el funcionamiento del servicio. Una guía práctica: si los datos son visibles en la aplicación para cualquier usuario sin iniciar sesión en una cuenta — está en una zona relativamente segura; si se necesita una cuenta ajena para acceder — ya está fuera de ella.

En resumen

El esquema es funcional y ahorra semanas de trabajo con anti-bots: levantamos mitmproxy, colocamos el certificado en el almacén de certificados del sistema del dispositivo con root, si es necesario eliminamos el pinning a través de Frida, capturamos una solicitud significativa, la exportamos a curl y la reescribimos en Python. Luego, la tarea de "eludir la protección" se convierte en una tarea de "distribuir la carga cuidadosamente" — y se resuelve rotando direcciones, con pausas razonables y el tipo correcto de proxy. Lo más fácil es comenzar con proxies móviles: están más cerca del tráfico que el backend espera ver.