Saltearse al contenido

Pentesting Android

Android es la plataforma móvil más abierta y, por tanto, la más fácil de auditar: las apps se distribuyen como APK (un ZIP con el código compilado a DEX, recursos y el manifest), y con herramientas estándar puedes descompilarlas, leer su código casi como el original, instrumentarlas en ejecución e interceptar su tráfico. Esta ficha cubre el flujo específico de Android: obtener el APK, análisis estático, dinámico y los vectores típicos.

APK = ZIP con:
AndroidManifest.xml permisos, componentes, deeplinks, exported, debuggable
classes.dex bytecode Dalvik (el código de la app)
resources.arsc / res/ recursos, strings, layouts
lib/ librerías nativas (.so)
assets/ ficheros embebidos (a veces secretos/config)
# desde el dispositivo (app instalada)
adb shell pm list packages | grep target
adb shell pm path com.target.app # ruta del APK
adb pull /data/app/.../base.apk
# o descargarlo de una tienda/mirror (APKPure, etc.)
# descompilar a smali + recursos legibles
apktool d base.apk # manifest y smali
# DEX -> Java (lectura cómoda)
jadx-gui base.apk # decompilador a Java
d2j-dex2jar base.apk ; jd-gui # alternativa
# todo automatizado
mobsf # análisis estático+dinámico con informe

Qué revisar:

AndroidManifest.xml
android:debuggable="true" # app depurable -> extraes datos fácil
android:allowBackup="true" # backup extraíble (adb backup)
<activity ... android:exported="true"> # componentes accesibles por otras apps
<data android:scheme="..."> # deeplinks (ver mob-deeplinks)
# secretos en código/recursos/assets
grep -riE 'api_key|secret|password|BEGIN RSA|http' ./ # claves, endpoints
strings lib/*/*.so # secretos en código nativo
# emulador o dispositivo rooteado
adb devices ; adb shell
# proxy para interceptar tráfico (ver mob-ssl)
# configurar Burp como proxy + instalar su CA
# instrumentación en ejecución
frida / objection (ver mob-frida) # hooking, bypass de pinning/root detection
# componentes exportados (Activities, Services, Content Providers, Broadcast Receivers)
adb shell am start -n com.target/.AdminActivity # lanzar una activity exportada
adb shell content query --uri content://com.target.provider/users # Content Provider
# deeplinks (ver mob-deeplinks)
adb shell am start -W -a android.intent.action.VIEW -d "targetapp://..."
# almacenamiento inseguro (ver mob-storage)
adb shell run-as com.target cat /data/data/com.target/shared_prefs/*.xml
# WebViews inseguras: JavaScript habilitado, addJavascriptInterface -> RCE/XSS en WebView
# backup: adb backup -f backup.ab com.target (si allowBackup=true)

Los componentes exportados son una superficie clave: una Activity/Service/Provider/Receiver con exported="true" (o con intent-filter) puede ser invocado por cualquier otra app (o por adb), saltándose controles de la UI.

# enumerar componentes exportados (del manifest descompilado)
# probar inyección SQL en Content Providers, path traversal, acceso a datos
drozer # framework de análisis de IPC/componentes
  • No hardcodear secretos; debuggable=false, allowBackup=false en producción.
  • Minimizar componentes exportados; proteger los necesarios con permisos; validar toda entrada (intents, Content Providers).
  • Almacenamiento cifrado (ver Almacenamiento inseguro), TLS + pinning (SSL pinning y bypass).
  • WebViews seguras: sin addJavascriptInterface innecesario, sin cargar contenido no confiable.
  • Protecciones RESILIENCE (root/tamper/debug detection, ofuscación con R8/ProGuard) — elevan el coste, no sustituyen la seguridad del backend.
  • Obtener el APK (adb pull / tienda)
  • Descompilar (apktool/jadx) y revisar manifest
  • debuggable/allowBackup/exported en el manifest
  • Secretos en código/recursos/assets/.so
  • Componentes exportados e IPC (drozer, am/content)
  • Deeplinks (Deeplinks e IPC)
  • Almacenamiento inseguro (Almacenamiento inseguro)
  • Tráfico + SSL pinning (SSL pinning y bypass); WebViews; backend