Android / Intermedio / 18 min de lectura

Análisis de Android con REA: ¿adónde envía solicitudes este APK?

Analiza un APK de Android con REA. Encuentra el código que construye solicitudes, sigue quienes lo invocan y distingue las direcciones candidatas del tráfico de red observado.

En esta página
Qué obtendrás

Una cadena anotada desde una función hasta el constructor de su solicitud, con posibles hosts, rutas y parámetros.

Qué necesitas

Un APK que puedas inspeccionar, un JDK 17+ completo y un JAR de jadx-headless-mcp 0.7.1 ya instalado. Comprueba la compatibilidad del proveedor con tu equipo.

01. Elegir una sola pantalla o acción

«Enumera todas las API» suele ser demasiado amplio. Empieza por una operación visible, como cargar un catálogo público. Anota la versión del APK y el nombre de la pantalla. Buscas el código que construye esa solicitud, no todas las cadenas con aspecto de URL del paquete.

Esto es una inspección estática. El APK no se ejecuta. Las cadenas incorporadas pueden incluir hosts abandonados, entornos de prueba o rutas que se combinan con la configuración en tiempo de ejecución.

Pídeselo a tu agente de programación
Inspecciona /absolute/path/app.apk con REA. Localiza el código que carga el catálogo público. Sigue desde una posible clase de pantalla o repositorio hasta su método de red. Informa de posibles hosts, rutas, métodos HTTP y parámetros con pruebas de clases y métodos. Distingue las declaraciones estáticas del tráfico confirmado en ejecución.

02. Conectar el proveedor de Android

Usa un JDK completo, incluido su módulo compilador. Indica a REA la ubicación del JAR del proveedor que ya instalaste. Si REA se ejecuta mediante tu agente, configura el mismo entorno para ese servidor y reinícialo; establecer una variable en otra terminal no actualiza un proceso existente.

Terminal
export REA_JADX_MCP_JAR="/absolute/path/jadx-headless-mcp-0.7.1-all.jar"
npx -y [email protected] inspect-android-package "/absolute/path/app.apk" --json
npx -y [email protected] search-android-classes "/absolute/path/app.apk" Catalog --json

03. Inspeccionar la clase y después seleccionar el método

La búsqueda de clases encuentra nombres de clases, no cadenas arbitrarias dentro de los cuerpos de los métodos. Prueba nombres de funciones y nombres habituales de red como Api, Service o Repository. Los paquetes ofuscados pueden necesitar otro punto de entrada, como una actividad del manifiesto cuyas dependencias se siguen después.

Sustituye la clase siguiente por un nombre exacto devuelto por la búsqueda. Inspecciona sus miembros antes de elegir un método. Cuando varios métodos sobrecargados comparten nombre, usa el índice de sobrecarga devuelto por el inventario de la clase.

Terminal
npx -y [email protected] inspect-android-class "/absolute/path/app.apk" com.example.CatalogRepository --json
npx -y [email protected] inspect-android-method "/absolute/path/app.apk" com.example.CatalogRepository loadCatalog --json

04. Seguir por separado la construcción y quienes llaman al método

Lee dónde se construye la solicitud y dónde se llama al método. Una URL base constante es solo una pieza: un constructor puede sustituirla, un interceptor puede añadir parámetros y una biblioteca nativa puede ocultar parte del proceso. Registra cada límite.

Las referencias entrantes muestran relaciones estáticas conocidas por el motor de análisis. La reflexión y el código cargado dinámicamente pueden quedar fuera de ese conjunto. Si el resultado devuelve smali en vez de Java, trátalo como otra representación del mismo método e inspecciónalo explícitamente.

Terminal
npx -y [email protected] trace-android-references "/absolute/path/app.apk" com.example.CatalogRepository --method-name loadCatalog --json
  • ¿Qué llamada conecta este método con la función elegida?
  • ¿La URL base es un literal, un recurso, un valor de configuración o un resultado en ejecución?
  • ¿Qué campos se añaden realmente a la solicitud?
  • ¿Dónde termina el seguimiento estático?

05. Convertir los hallazgos en una pequeña especificación

Escribe una tabla con el método candidato, la construcción de la URL, los nombres de parámetros y las referencias a métodos que los respaldan. Deja como desconocidos los valores exclusivos de la ejecución. Usa un servidor simulado local para crear un prototipo de tu propio cliente según esta especificación.

No cuentes una lista estática de endpoints como una captura correcta de solicitudes. Para afirmarlo, necesitas una ejecución registrada por separado de la versión correspondiente de la aplicación en un entorno de prueba adecuado. Este tutorial proporciona el flujo de inspección; no afirma haber probado un APK ni capturado una respuesta de API.

Comandos comprobados con REA 6.4.0. Los resultados específicos dependen de tu artefacto y proveedor. Leer la fuente original y su alcance →

Seguir investigandoElegir tu próximo tutorial →

¿Acabas de conocer la herramienta? ¿Qué es REA? · Cómo revisamos nuestras guías