Ingeniería inversa móvil: método, herramientas y buenas prácticas

Objetivo y límites

La ingeniería inversa móvil consiste en partir de un artefacto compilado, por ejemplo una aplicación Android .apk o iOS .ipa, para entender cómo funciona. El objetivo puede ser aprender, auditar tu propia aplicación, verificar prácticas de seguridad o documentar un comportamiento.

Esta guía no busca saltarse autenticaciones, acceder a datos privados, abusar de APIs no documentadas ni rastrear usuarios sin autorización. Usa estas técnicas solo en aplicaciones propias, entornos de prueba, laboratorios vulnerables de forma intencional o auditorías explícitamente autorizadas.

Definir el marco legal

Antes de analizar, documenta el alcance:

Aplicación:
Versión:
Plataforma: Android / iOS
Objetivo: aprendizaje / auditoría interna / bug bounty / pentest
Autorización: sí / no
Fechas de prueba:
Acciones permitidas:
Acciones prohibidas:
Contacto de seguridad:

Que una aplicación pueda descargarse públicamente no autoriza automáticamente a extraer secretos, automatizar APIs privadas, saltarse protecciones o acceder a datos ajenos. Trabaja preferiblemente con tus propias apps, aplicaciones open source, labs OWASP Mobile, entornos de preproducción o programas de bug bounty con reglas explícitas.

Análisis estático y dinámico

El análisis estático inspecciona la app sin ejecutarla: manifiesto, permisos, archivos de configuración, recursos, cadenas, código decompilado, certificados y librerías incluidas.

El análisis dinámico observa la app mientras se ejecuta: logs, archivos locales, preferencias guardadas, bases de datos locales, escenarios de usuario y, dentro de un marco autorizado, intercambios de red.

El análisis estático da el mapa; el dinámico muestra el comportamiento real.

Preparar el entorno

Separa el entorno de análisis de tu teléfono personal. Idealmente usa:

• un ordenador Linux, macOS o Windows;
• un teléfono Android de prueba o un emulador;
• una cuenta de prueba dedicada;
• ningún dato personal sensible en el dispositivo;
• datos ficticios para los escenarios.

Herramientas útiles

En Android, las herramientas habituales son:

• adb para comunicarte con el dispositivo;
• jadx para decompilar un APK a Java/Kotlin aproximado;
• apktool para decodificar recursos y manifiesto;
• Android Studio para emulador, logs e inspección;
• MobSF para una primera pasada automatizada;
• mitmproxy, Burp Suite, Proxyman o Charles Proxy para observación de tráfico autorizada;
• Frida para instrumentación dinámica en un marco de pruebas estricto.

En iOS, el análisis suele estar más limitado. Puedes encontrar Xcode, Console.app, MobSF, Frida, herramientas Mach-O y a veces class-dump o alternativas modernas. Para empezar, Android suele ser más accesible.

Recuperar y documentar el APK

Desde un dispositivo Android de prueba, localiza la app:

adb shell pm list packages | grep nombre.app
adb shell pm path com.example.application

Después extrae el archivo:

adb pull /data/app/ruta/base.apk ./application.apk

Según la versión de Android, una app puede estar dividida en varios APK: base.apk, split de idioma, split de arquitectura o split de densidad. Documenta la versión:

aapt dump badging application.apk
sha256sum application.apk

El hash evita ambigüedades en el informe.

Primera pasada con apktool

apktool decodifica recursos y manifiesto:

apktool d application.apk -o application_decoded

Obtendrás una estructura como:

application_decoded/
├── AndroidManifest.xml
├── apktool.yml
├── res/
├── smali/
└── assets/

El manifiesto describe paquete, actividades, servicios, receivers, providers, deep links, permisos y configuración de red. La pregunta útil no es solo "qué permisos pide", sino "son coherentes con la funcionalidad anunciada".

Componentes exportados y permisos

Un componente exportado puede ser llamado por otras aplicaciones:

<activity
    android:name=".SomeActivity"
    android:exported="true" />

No es automáticamente una vulnerabilidad, pero merece revisión. Comprueba también permisos sensibles como ubicación, cámara, contactos, almacenamiento, micrófono o notificaciones. Todo permiso debe tener una justificación de producto clara.

Decompilar con JADX

JADX ofrece una representación Java/Kotlin aproximada:

jadx-gui application.apk
jadx -d jadx_output application.apk

El resultado puede estar incompleto, ofuscado o ser distinto del código fuente original. Aun así, sirve para entender arquitectura, modelos, librerías y zonas sensibles.

Búsquedas útiles:

http, https, api, baseUrl, retrofit, okhttp, graphql,
firebase, sentry, amplitude, mixpanel,
token, auth, jwt, bearer, secret, client_id

Estas búsquedas sirven para mapear riesgos en una auditoría defensiva, no para reutilizar secretos.

Recursos y configuración

Inspecciona assets/, res/raw/ y res/xml/. Puedes encontrar URLs de entorno, flags, JSON, configuración Firebase, certificados públicos o reglas de seguridad de red.

Una configuración de red Android puede verse así:

<application
    android:networkSecurityConfig="@xml/network_security_config">
</application>

Comprueba si se permite HTTP en claro, dominios específicos, diferencias debug/release, certificados de confianza y posible certificate pinning.

Almacenamiento local

En un entorno autorizado, suele inspeccionarse:

/data/data/com.example.application/
├── shared_prefs/
├── databases/
├── files/
├── cache/
└── no_backup/

Busca tokens, datos personales, historiales, preferencias sensibles, archivos temporales o datos de sesión. Las buenas prácticas incluyen almacenamiento mínimo, cifrado de datos sensibles, expiración de sesiones, ausencia de secretos estáticos y ausencia de datos sensibles en logs.

Logs y tráfico de red

Los logs Android se leen con:

adb logcat
adb logcat | grep com.example.application

Una app de producción nunca debería registrar tokens, contraseñas, emails, ubicaciones, pagos o datos de negocio confidenciales.

La observación de red debe estar autorizada: cuenta de prueba, datos ficticios, entorno de test y endpoints cubiertos explícitamente. Puedes documentar dominios contactados, formatos JSON, códigos de respuesta, errores, uso de TLS y coherencia de controles del servidor. Sin autorización explícita, evita saltarte TLS, pinning, repetir peticiones o automatizarlas.

Ofuscación

Con R8 o ProGuard, el código puede parecerse a:

public final class a {
    public final String b;
    public final int c;
}

Para orientarte, parte de las cadenas, sigue llamadas de red, identifica modelos de datos, busca anotaciones Retrofit o de serialización y reconstruye poco a poco el grafo de llamadas.

MobSF para una primera pasada

MobSF automatiza un informe inicial:

docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Luego abre:

http://localhost:8000

MobSF puede identificar permisos, trackers, URLs, archivos sensibles, certificados, librerías, manifiesto y configuraciones débiles. Un informe automático no es una verdad absoluta: es un punto de partida.

Metodología de auditoría

Un análisis limpio sigue un método reproducible:

1. Identificar la app: nombre, paquete, versión, hash, fuente, fecha.
2. Inspeccionar el manifiesto: permisos, componentes exportados, deep links, providers, servicios, configuración de red.
3. Mapear dependencias: analytics, crash reporting, red, pagos, autenticación, publicidad, cifrado.
4. Ubicar zonas sensibles: auth, sesiones, almacenamiento local, logs, WebView, deep links, temporales.
5. Probar dinámicamente con una cuenta de test.
6. Redactar un informe claro: resumen, impacto, condiciones, evidencias, riesgo y recomendación.

Mini-análisis ficticio

Para una app ficticia DemoBike, el manifiesto puede pedir:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

Es coherente para mostrar estaciones cercanas. En network_security_config.xml, una buena señal sería:

<base-config cleartextTrafficPermitted="false" />

En el código decompilado podrías ver Retrofit:

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .build();

En un informe público, evita exponer detalles sensibles si la URL real es privada. Documenta el tipo de comunicación y el riesgo.

Señales de alerta frecuentes

Problemas comunes:

• secretos dentro del APK;
• controles de seguridad solo en el cliente;
• logs demasiado verbosos;
• WebView mal configurada;
• deep links demasiado permisivos;
• tokens o datos personales en claro en almacenamiento local;
• configuración de red permisiva;
• sesiones sin expiración clara.

Todo lo que está dentro de un APK puede extraerse tarde o temprano. Los secretos críticos deben quedarse en el servidor.

Qué evitar

Evita usar endpoints privados descubiertos por ingeniería inversa, saltarte protecciones, acceder a datos ajenos, publicar secretos, automatizar llamadas sin permiso, probar en producción sin acuerdo o generar carga excesiva.

Regla simple: si no podrías explicar tranquilamente la acción en un informe enviado al propietario de la app, no la hagas.

Aprender sin riesgo

Usa objetivos pensados para aprender: apps vulnerables intencionalmente, labs OWASP Mobile, apps open source, proyectos propios, CTF móviles o bug bounties con alcance claro.

Competencias a desarrollar: Android internals, Kotlin/Java, HTTP/TLS, OAuth/OIDC, almacenamiento seguro, criptografía aplicada, arquitectura backend y redacción de informes.

Checklist rápida

[ ] APK obtenido legalmente
[ ] Versión y hash documentados
[ ] Manifiesto analizado
[ ] Permisos revisados
[ ] Componentes exportados identificados
[ ] Deep links inspeccionados
[ ] Network security config comprobada
[ ] Código decompilado revisado
[ ] Dependencias principales listadas
[ ] Almacenamiento local analizado
[ ] Logs revisados
[ ] Tráfico observado solo dentro del marco autorizado
[ ] Datos sensibles buscados
[ ] Informe redactado
[ ] Vulnerabilidades reportadas responsablemente

Conclusión

La ingeniería inversa móvil está entre desarrollo, seguridad, arquitectura e investigación técnica. Bien utilizada, mejora la seguridad de las aplicaciones y ayuda a convertirse en mejor desarrollador.

Mal utilizada, puede volverse intrusiva o ilegal. La diferencia suele depender de una cosa: la autorización.