Pentesting Android: análisis estático, dinámico, Frida y OWASP MASVS

El pentesting de aplicaciones móviles Android es una disciplina con herramientas y técnicas propias, distintas al web tradicional. Una aplicación Android empaquetada como .apk contiene código Java compilado (DEX), recursos, assets, certificados y configuración, y se ejecuta en un dispositivo con permisos distintos y modelo de aislamiento específico. Para auditar seguridad hay que combinar análisis estático (descompilar y revisar código), análisis dinámico (instrumentar en tiempo de ejecución con Frida o Objection), y análisis del tráfico de red (Burp + proxy).

Esta lección cubre el flujo completo de pentesting Android en 2026: extracción del APK de Play Store o del dispositivo, descompilación con jadx y apktool, análisis automático con MobSF, instrumentación con Frida para interceptar llamadas y bypass de controles (SSL pinning, root detection), intercepción de tráfico TLS, y las categorías de riesgo del OWASP MASVS (Mobile Application Security Verification Standard).

Es la primera de dos lecciones mobile de la Tanda 5 (la siguiente cubre iOS). Para pentesters que ya conocen web, el salto a mobile es natural pero requiere aprender un nuevo stack entero de herramientas.

Prueba solo contra aplicaciones propias o en bug bounty programs que autoricen mobile. Muchos programs excluyen reversing comercial; lee las policies.

Stack de un APK#

Un APK es un ZIP con estructura específica:

• AndroidManifest.xml: permisos, actividades, servicios, receivers. Binary XML (hay que decodificarlo).
• classes.dex: código Java/Kotlin compilado a Dalvik bytecode. A veces hay varios classes2.dex, classes3.dex.
• resources.arsc + res/: strings, layouts, imágenes.
• assets/: ficheros arbitrarios de la aplicación.
• lib/: código nativo por arquitectura (armeabi-v7a, arm64-v8a, x86, x86_64). Librerías .so.
• META-INF/: firma digital del paquete.

Obtener el APK#

Desde Play Store#

• Apkpure, Apkmirror, Aptoide: mirrors (verifica hash cuando puedas).
• Google Play, con cuenta: descargar con gplaycli.

Del dispositivo#

# Listar paquetes
adb shell pm list packages

# Path del paquete
adb shell pm path com.target.app
# package:/data/app/com.target.app-xxx/base.apk

# Pull
adb pull /data/app/com.target.app-xxx/base.apk

Análisis estático#

MobSF#

Mobile Security Framework: scanner automático que revisa docenas de controles:

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

Subes el APK, obtienes un reporte con:

• Permisos declarados y potencialmente peligrosos.
• Certificados.
• Hard-coded secrets, API keys.
• Insecure crypto.
• Network security config.
• Activities/services exportados sin permission.
• Patrones típicos de malware.

Para primera pasada, inmejorable.

jadx#

Descompila DEX a Java legible:

jadx -d output app.apk
# O GUI
jadx-gui app.apk

Navegas el código decompilado; buscas strings de interés (password, secret, token, dominios API), lógica de autenticación, validaciones de root/emulator.

apktool#

Desempaqueta el APK (incluye decodificar AndroidManifest):

apktool d app.apk -o app_decoded
# Modifica archivos, luego:
apktool b app_decoded -o modified.apk

Útil para modificar la app (añadir logs, deshabilitar checks) y recompilarla. Hay que re-firmar antes de instalar:

# Generar keystore una vez
keytool -genkey -keystore key.jks -alias mykey

# Firmar
apksigner sign --ks key.jks modified.apk

Secrets hunting#

Búsquedas útiles en el output de jadx:

# Strings con patrones típicos
grep -rE "(api[_-]?key|secret|password|token|bearer)" output/

# URLs/dominios
grep -rE "https?://[a-z0-9.-]+" output/

# AWS keys
grep -rE "AKIA[0-9A-Z]{16}" output/

# Google API keys
grep -rE "AIza[0-9A-Za-z_-]{35}" output/

Análisis dinámico con Frida#

Frida es un framework de instrumentación dinámica que inyecta JavaScript en procesos vivos. Para Android:

# En el dispositivo rooteado, correr frida-server
adb push frida-server /data/local/tmp/
adb shell "chmod +x /data/local/tmp/frida-server && /data/local/tmp/frida-server &"

# En tu laptop
frida-ps -U | grep target
frida -U -l hook.js com.target.app

Hook típico — bypass de root detection:

Java.perform(function () {
  var RootBeer = Java.use("com.scottyab.rootbeer.RootBeer");
  RootBeer.isRooted.implementation = function () {
    console.log("isRooted() → false (bypassed)");
    return false;
  };
});

Hook para SSL pinning:

Java.perform(function () {
  var CertificatePinner = Java.use("okhttp3.CertificatePinner");
  CertificatePinner.check.overload('java.lang.String', 'java.util.List').implementation = function () {
    return;
  };
});

Objection#

Wrapper de Frida con comandos pre-escritos:

objection -g com.target.app explore
# Dentro:
> android sslpinning disable
> android root disable
> android hooking list classes
> android hooking watch class_method com.target.app.API.login

Más rápido que escribir hooks a mano para casos comunes.

Intercepción TLS#

Setup Burp#

• Instalar cert CA de Burp en el device: Install CA cert as system cert (requiere root).
• Configurar proxy WiFi en el device apuntando a Burp.
• Launch app → tráfico pasa por Burp.

Si hay SSL pinning, la app rechaza el cert de Burp. Mitigaciones:

• Frida script para bypass (visto arriba).
• Objection android sslpinning disable.
• Reempaquetar APK con network_security_config.xml que acepte user CAs:

<network-security-config>
  <base-config>
    <trust-anchors>
      <certificates src="system"/>
      <certificates src="user"/>
    </trust-anchors>
  </base-config>
</network-security-config>

OWASP MASVS#

Mobile Application Security Verification Standard es el equivalente mobile de ASVS. 8 categorías:

• MASVS-STORAGE: almacenamiento local seguro.
• MASVS-CRYPTO: uso correcto de criptografía.
• MASVS-AUTH: autenticación y autorización.
• MASVS-NETWORK: tráfico de red cifrado, cert pinning.
• MASVS-PLATFORM: uso seguro de APIs del sistema.
• MASVS-CODE: integridad de código, firmas, parches.
• MASVS-RESILIENCE: resistencia a reverse engineering y tampering.
• MASVS-PRIVACY (nuevo en v2): datos PII.

MSTG (Mobile Security Testing Guide) del mismo OWASP cubre test cases detallados para cada control.

Bypass común de defensas#

• Root detection: hookear métodos de detección.
• Emulator detection: hookear Build.MODEL, getSerial, sensores.
• SSL pinning: hookear CertificatePinner, X509TrustManager, ssl_pinning libraries.
• Debugger detection: hookear android.os.Debug.isDebuggerConnected.
• Obfuscation: usar ProGuard mappings si disponibles; si no, instrumentation dinámica.

Herramientas que lo hacen más fácil: RMS-Runtime Mobile Security, house, Medusa.

Vulnerabilidades típicas#

• Hard-coded secrets: tokens API, claves de firma, credenciales en código.
• Insecure storage: SharedPreferences sin cifrar con datos sensibles, SQLite plano, external storage.
• WebView XSS: aplicaciones con WebView que cargan contenido sin sanitizar.
• Deeplinks mal validados: links a actividades exportadas sin check de permisos.
• Content provider exportado: permite leer datos de otras apps.
• Debug mode en producción: android:debuggable="true" en manifest.
• Broken TLS validation: aceptan cualquier cert, TrustManager vacío.
• Backup habilitado: allowBackup="true" permite extraer datos del device.

Mitigación#

• OWASP MASVS compliance.
• Certificate pinning con fallback de rotación.
• ProGuard / R8 para ofuscar código (dificulta reversing).
• SafetyNet / Play Integrity para verificar integridad del dispositivo.
• NDK para lógica crítica (código nativo es más difícil de reversar).
• Secrets en backend, no en el APK.
• Encrypted SharedPreferences (androidx.security).
• Network Security Config sin trust de user CAs en producción.

Walkthrough: audit canónica de una APK#

Para fijar el flujo, el patrón típico contra una APK nueva.

Paso 1 — MobSF pasada rápida:

docker run -p 8000:8000 opensecurity/mobile-security-framework-mobsf
# Subir APK, dejar scan 5 minutos

Reporte identifica: hard-coded strings, permisos sospechosos, exported activities, crypto débil. Priorizas por severity.

Paso 2 — jadx para profundizar:

jadx -d output/ app.apk
# Buscar:
grep -rE "api_key|secret|token" output/
# Encuentras: API_KEY = "AIzaSyX..." → leak

Paso 3 — Dinámico con Frida:

# Setup frida-server en emulador
# Launch con hooks
frida -U -l hooks.js com.target.app

Hooks: bypass SSL pinning, bypass root detect, log de network calls.

Paso 4 — Burp interceptando tráfico:

Con pinning saltado, Burp ve todas las peticiones API. Busca:

• IDOR en IDs predecibles.
• Mass assignment en PATCH.
• JWT con alg:none aceptado.
• Endpoints internos no documentados.

Paso 5 — Audit de deep links:

# Ver scheme + host declarados
grep -A5 "intent-filter" AndroidManifest.xml

# Probar con adb
adb shell am start -a android.intent.action.VIEW -d "myapp://action/delete-all-data"

Si una actividad sensible es exportada y aceptada sin verificación: hallazgo crítico.

Paso 6 — Reporte con CVSS y impact de negocio.

Vulnerabilidades específicas 2026#

En 2026 hay nuevos vectores que las guías viejas no cubren:

• ML models en assets: modelos TensorFlow Lite embebidos pueden revelar datos de entrenamiento con model inversion.
• Flutter / React Native obfuscation: ninguno da seguridad real; se descompilan con herramientas específicas.
• Credentials en gradle.properties incluidas en el APK por accidente.
• Keystore de firma en el repo que permite forjar updates maliciosos.
• Firebase config filtrado: acceso a Firebase sin autenticación si rules están abiertas.

El hunting en cada uno sigue el patrón genérico: extracción → análisis → PoC → reporte. Frida sigue siendo el hilo común para dinámico.

Errores comunes#

• Confiar en código ofuscado como seguridad real.
• API keys hardcoded (se extraen en 10 segundos).
• No cifrar SharedPreferences con tokens.
• allowBackup="true" en producción.
• Deeplinks sin validación que ejecutan acciones privilegiadas.

Preguntas frecuentes#

¿Necesito device rooteado?#

Para análisis profundo sí. Emuladores (Android Studio, Genymotion) rooteables son suficientes para aprender. Device físico rooteado da experiencia realista.

¿Puedo reversar apps de Google Play comerciales?#

Legal: reversing para estudio es legalmente gris (varía por jurisdicción). Para bug bounty, cada program define sus reglas. Publicar la reverse engineering suele estar prohibido.

¿Cuánto cuesta un stack mobile pentest?#

Dispositivo rooteado (Pixel 4-5, 100-300 EUR), licencias Burp Pro (500/año), Jadx y Frida gratis. Barato comparado a cloud pentest.

¿App bundles (.aab) cambian el análisis?#

Un .aab es el formato de subida a Play; Google genera APKs específicos por device. Para análisis, el APK descargado se analiza igual. bundletool extrae APKs de un .aab si tienes acceso.

¿Dónde practico?#

El laboratorio signinbleed de whoami-labs incluye una APK con vulnerabilidades clásicas: hard-coded API key, SSL pinning weak, insecure storage, deeplink sin validar. Practicas el flujo completo con MobSF, jadx, Frida.

¿Qué pasa con las aplicaciones de banca que detectan root?#

Usan combinaciones: Play Integrity API (Google), SafetyNet legado, checks custom contra archivos típicos de root, hooks a system calls. Buenas implementaciones usan múltiples controles que hay que saltar individualmente. Las débiles usan solo isDeviceRooted() que Frida saltea en una línea.

¿Es ético publicar reverse engineering de apps de empresas?#

Depende de jurisdicción y licencia. Research académico suele estar protegido; publicación comercial o ayuda a piratería no. Reportar vulnerabilidades al vendor (responsible disclosure) es ético y legal en la mayoría de los casos.

¿Frida funciona en dispositivos no rooteados?#

En teoría no, pero hay técnicas: frida-gadget inyectado en el APK re-firmado funciona sin root. Objection patch automatiza. Útil cuando no tienes root pero quieres instrumentar.

¿Qué tan rápido evoluciona Android security?#

Cada versión mayor (Android 13, 14, 15) añade controles: scoped storage, runtime permissions más granulares, Privacy Dashboard, AdServices isolation. Un pentester mobile debe actualizar su stack cada 6-12 meses para seguir el ritmo.

Resumen#

• APK = ZIP con AndroidManifest + classes.dex + recursos + nativo.
• Estático: MobSF, jadx, apktool.
• Dinámico: Frida, Objection, hooks JS para bypass de controles.
• Tráfico: Burp + CA system install + SSL pinning bypass.
• OWASP MASVS v2: 8 dominios de verificación.
• Vulns típicas: secretos hardcoded, insecure storage, WebView XSS, deeplinks, backup habilitado.
• Defensa: cert pinning, R8/ProGuard, Play Integrity, NDK, secrets en backend.

En general, mobile pentesting es una rama especializada que premia la paciencia y la comodidad con reverse engineering y análisis dinámico. Muchos pentesters web nunca se mueven a mobile porque la curva inicial es alta: montar lab con emulador configurado adecuadamente, aprender Smali, manejar comandos adb, dominar Frida y sus scripts. Pero quien invierte ese tiempo descubre un nicho con alta demanda y relativamente poca oferta, tanto en consultoría corporativa como en bug bounty programs específicamente orientados a aplicaciones mobile.

La siguiente lección cubre pentesting iOS, con muchos conceptos comunes pero toolchain muy distinta: Objective-C/Swift en vez de Java/Kotlin, Mach-O en vez de DEX, jailbreak en vez de root, y un ecosistema más cerrado que presenta retos específicos de análisis.

Fuentes y lecturas recomendadas#

• OWASP MASVS
• OWASP MSTG
• Frida
• MobSF