Metodología de pentest móvil

El pentest móvil abarca la app (el binario APK/IPA), su comunicación con el backend, y cómo almacena datos en el dispositivo. A diferencia de la web, aquí el código corre en un dispositivo que el usuario (y el atacante) controla físicamente, así que todo lo que la app guarde o decida localmente puede inspeccionarse y manipularse. La referencia es el OWASP MASVS/MASTG, que estructura todo el proceso.

Las tres superficies

1. La app (análisis estático): el binario, su código, secretos, configuración
2. La app en ejecución (análisis dinámico): comportamiento, almacenamiento, memoria
3. La comunicación: tráfico con el backend (API) -> aplican los ataques de la sección Web

Análisis estático vs dinámico

Estático (SAST): descompilar el APK/IPA y revisar el código, recursos, permisos y secretos sin ejecutar la app. Rápido para encontrar claves hardcodeadas, endpoints, configuración insegura.
Dinámico (DAST): ejecutar la app (en dispositivo/emulador) e instrumentarla (Frida, ver Frida y análisis dinámico) para observar y modificar su comportamiento en vivo: almacenamiento, cifrado, autenticación, SSL pinning.

OWASP MASVS: las categorías

MASVS-STORAGE     almacenamiento de datos (ver mob-storage)
MASVS-CRYPTO      uso de criptografía
MASVS-AUTH        autenticación y autorización
MASVS-NETWORK     comunicación (TLS, pinning -> mob-ssl)
MASVS-PLATFORM    interacción con la plataforma (IPC, deeplinks -> mob-deeplinks)
MASVS-CODE        calidad del código y protecciones
MASVS-RESILIENCE  anti-tampering, anti-debugging, ofuscación

Flujo de trabajo

1. Obtener el binario (APK de Android, IPA de iOS)
2. Análisis estático: descompilar, revisar manifest/Info.plist, permisos, secretos, endpoints
3. Preparar el entorno: dispositivo rooteado/jailbroken o emulador; proxy (Burp)
4. Análisis dinámico: ejecutar + instrumentar (Frida)
5. Almacenamiento: inspeccionar qué guarda y cómo (mob-storage)
6. Red: interceptar tráfico; saltar SSL pinning si lo hay (mob-ssl)
7. Lógica/plataforma: deeplinks, IPC, componentes exportados (mob-deeplinks)
8. Backend: probar la API como una webapp (sección Web)
9. Documentar según MASVS

Entorno de pruebas

Android:  emulador (AVD/Genymotion) o dispositivo rooteado; adb; Burp como proxy
iOS:      dispositivo con jailbreak (más restrictivo); o técnicas sin jailbreak
Herramientas transversales: Frida/Objection, MobSF (análisis automatizado), Burp

Lo que casi siempre se encuentra

Secretos hardcodeados: API keys, credenciales, URLs internas en el código/recursos.
Almacenamiento inseguro: datos sensibles en claro en SharedPreferences/plist/SQLite (Almacenamiento inseguro).
Tráfico sin cifrar o pinning ausente/evitable (SSL pinning y bypass).
Componentes exportados / deeplinks que permiten acceso no autorizado (Deeplinks e IPC).
Autenticación/autorización rota en el backend (la API es el verdadero objetivo).

Para la defensa

Seguir MASVS: no confiar en el cliente, cifrar datos sensibles, TLS + pinning, validar en el backend.
No hardcodear secretos en la app (el binario es inspeccionable); usar backend/secret management.
Anti-tampering/anti-debugging/ofuscación (MASVS-RESILIENCE) elevan el coste del atacante, no lo impiden.
Tratar la API como superficie principal: toda la seguridad real debe estar en el backend.

Checklist de prueba

Obtener el binario (APK/IPA)
Análisis estático: manifest/permisos/secretos/endpoints (MobSF)
Entorno: dispositivo root/jailbreak o emulador + proxy
Análisis dinámico con Frida/Objection
Almacenamiento inseguro (Almacenamiento inseguro)
Red: interceptar + saltar SSL pinning (SSL pinning y bypass)
Deeplinks/IPC/componentes exportados (Deeplinks e IPC)
Backend/API probado como webapp (sección Web)