Ahora que Google está a punto de cerrar una de las pocas puertas que quedaban abiertas en su sistema operativo: la instalación de aplicaciones fuera de su tienda oficial, una decisión que, en un ecosistema que presume de ser abierto, resulta cuando menos contradictoria, os mostramos y enseñamos a usar ADB, una herramienta sencilla, básica y asequible para tareas de análisis en entornos legales con escasos recursos, pero que con un buen aprendizaje puede llegar a ser tan potente como software mucho más avanzado.
¿Por qué es indispensable en forense digital?
La razón central es que si todavía no dominamos herramientas más avanzadas o estamos carentes de recursos para posibilidades más avanzadas, ofrece el acceso privilegiado al sistema de archivos y procesos del dispositivo, lo cual nos permite:
Adquisición de evidencia — ADB permite extraer copias de bases de datos de aplicaciones (WhatsApp, Telegram, historial de llamadas), logs del sistema, ubicaciones GPS almacenadas y mucho más, sin necesidad de desbloquear el dispositivo visualmente.
Preservación de integridad — Puedes hacer una copia forense (imagen bit-a-bit) de particiones o directorios críticos antes de que la batería muera o el sospechoso tenga acceso.
Análisis en vivo — Mientras el dispositivo está encendido, puedes examinar procesos activos, conexiones de red abiertas, archivos en memoria temporal y el estado actual del sistema.
Bypass de bloqueos de pantalla — En versiones antiguas de Android o con permisos de root, ADB permite acceder al sistema aunque la pantalla esté bloqueada.
Extracción de apps y APKs — Para análisis de malware, puedes extraer directamente las aplicaciones instaladas.
A continuación veamos una tabla de comandos donde destacamos la última columna: Riesgo forense pues en contexto de investigación es muy relevante.
| Comando | Descripción | Riesgo |
|---|---|---|
| Conexión y reconocimiento inicial | ||
adb devices | Lista los dispositivos conectados y su estado | Lectura |
adb shell getprop ro.build.version.release | Versión de Android instalada | Lectura |
adb shell getprop ro.product.model | Modelo exacto del dispositivo | Lectura |
adb shell dumpsys battery | Estado de batería (relevante para establecer timestamps) | Lectura |
| Extracción de datos | ||
adb pull /sdcard/DCIM/ | Copia la galería completa al ordenador | Lectura |
adb pull /data/data/com.android.contacts/databases/ | Extrae la base de datos SQLite de contactos | Lectura |
adb pull /data/data/com.whatsapp/databases | Extrae los mensajes y medios de WhatsApp | Lectura |
adb backup -apk -all -f backup.ab | Genera un backup completo cifrado del dispositivo | Precaución |
adb shell content query --uri content://call_log/calls | Consulta el registro completo de llamadas | Lectura |
| Imagen de disco | ||
adb shell dd if=/dev/block/mmcblk0p28 | dd of=imagen.img | Copia bit-a-bit de una partición del dispositivo | Lectura |
| Análisis de red y procesos en vivo | ||
adb shell netstat -tulnp | Conexiones de red activas y puertos en escucha | Lectura |
adb shell ps -A | Lista todos los procesos en ejecución | Lectura |
adb logcat -d > log_completo.txt | Vuelca todos los logs del sistema a un archivo | Lectura |
| Geolocalización e historial | ||
adb shell dumpsys location | Estado completo del servicio de localización | Lectura |
adb shell dumpsys location | grep "Last Known" | Filtra solo la última posición GPS conocida | Lectura |
adb pull /data/data/com.google.android.apps.maps/ | Extrae historial de búsquedas y rutas de Google Maps | Lectura |
| Integridad y documentación forense | ||
adb shell md5sum /ruta/archivo | Calcula hash MD5 para verificar integridad del archivo | Lectura |
adb exec-out screencap -p > pantalla.png | Captura el estado actual de la pantalla como evidencia | Lectura |
| Comandos a evitar en contexto forense | ||
adb push [archivo] [destino] | Escribe archivos en el dispositivo — invalida la evidencia | Modifica |
adb install [apk] | Instala una aplicación — contamina la escena digital | Modifica |
adb shell rm [archivo] | Elimina archivos — destrucción de evidencia | Modifica |
El principio más importante: no contaminar la escena
Igual que en la forense física nunca tocas una escena sin guantes, en ADB la regla de oro es no modificar el dispositivo. Esto implica:
Usar exclusivamente comandos adb pull y adb shell en modo lectura. Nunca ejecutar adb push (escritura al dispositivo) ni adb install durante una investigación activa. Calcular el hash SHA-256 de cada archivo extraído antes y después para demostrar que no fue alterado. Y activar el modo avión físicamente (no desde software, que puede ser manipulado) antes de comenzar, para prevenir un borrado remoto mientras trabajas.
ADB no es solo una herramienta técnica: es el puente entre el dispositivo del sospechoso y la sala de un tribunal. Recuerda que cada comando que ejecutas puede construir o destruir un caso.
Habilitar la depuración USB en Android para uso forense
Esta es una de las fases más delicadas de toda la investigación. El problema es que habilitar la depuración USB requiere interactuar con el dispositivo, y cada toque que das antes de documentarlo es potencialmente cuestionable en juicio. La clave es hacerlo de forma mínima, ordenada y completamente documentada.
Antes de tocar nada: el protocolo previo
Lo primero es fotografiar el dispositivo en su estado exacto de recepción: pantalla bloqueada, estado de la batería visible si es posible, y los cuatro lados físicos. Solo entonces puedes proceder.
Comprueba también si la depuración ya estaba activada. Si el sospechoso era técnico o desarrollador, puede que no necesites activar nada, lo cual simplifica enormemente tu posición:
adb shell settings get global adb_enabled
# Devuelve 1 si ya estaba activa, 0 si no
El punto crítico: la huella RSA y sus implicaciones
Cuando conectas el dispositivo al ordenador forense por primera vez, Android muestra un diálogo pidiendo que apruebes la huella RSA del equipo. Esta interacción debe quedar documentada porque implica una modificación del dispositivo: se escribe la clave pública de tu equipo en el almacén de claves de confianza del teléfono.
Para documentarlo correctamente anota en el acta la huella RSA de tu equipo forense antes de la sesión:
bash
# En tu ordenador forense, antes de conectar el dispositivo
adb keygen /tmp/clave_forense
# Guarda la huella que aparece — va en el informe pericialEsto permite demostrar que la única modificación realizada fue la autorización de ese equipo concreto, en ese momento concreto.
Consideraciones según el estado del dispositivo
El escenario ideal es recibir el dispositivo encendido y desbloqueado, pero raramente ocurre. Estas son las situaciones reales más habituales:
Dispositivo encendido con pantalla bloqueada. Puedes activar la depuración desde ADB solo si ya estaba habilitada. Si no lo estaba, necesitas desbloquear la pantalla, lo que en muchos casos requiere el PIN del sospechoso o una orden judicial específica para técnicas de bypass.
Dispositivo apagado. Encenderlo ya es una intervención que debes documentar. Una vez encendido, si tiene pantalla bloqueada, aplica el caso anterior. Algunos dispositivos ofrecen opciones de desarrollador accesibles desde el recovery mode, pero esto es terreno muy delicado legalmente.
Dispositivo con pantalla rota pero encendido. Aquí entran los adaptadores OTG con teclado y ratón para navegar el menú táctilmente desde hardware externo. Documenta el adaptador usado como material de la intervención.
El bloqueador de escritura: imprescindible pero a menudo omitido
La depuración USB en Android no es solo lectura por defecto. El protocolo ADB permite escritura, y sin un bloqueador de escritura hardware (write blocker) interpuesto entre el cable y tu ordenador, cualquier proceso del sistema operativo —un antivirus, una actualización automática, el indexador— podría teóricamente escribir en el dispositivo.
Los más usados en entornos forenses son el Tableau TD3 y el WiebeTech USB WriteBlocker. Si no tienes acceso a hardware físico, puedes activar el modo de solo lectura a nivel de sistema operativo:
# En Linux, montar en modo solo lectura
blockdev --setro /dev/sdX
# Verificar que está en modo lectura
blockdev --getro /dev/sdX
# Debe devolver 1Documenta el número de serie del bloqueador hardware o el comando ejecutado. Sin esto, la defensa tiene un argumento sólido para cuestionar la integridad de cualquier dato extraído.
Lo que jamás debes hacer
Nunca actives la depuración USB desde una cuenta de desarrollador propia instalando una app auxiliar en el dispositivo. Aunque es técnicamente posible, implica instalar software en el dispositivo intervenido, lo cual en España constituye una modificación de la escena digital que puede hacer inadmisible toda la evidencia posterior bajo el artículo 11 de la LOPJ.
El comando adb devices: la primera comprobación de toda sesión forense
adb devices es el comando de diagnóstico que lanza el servidor ADB en tu ordenador y le pregunta a todos los dispositivos conectados por USB (o por red) quiénes son y en qué estado están. Es siempre el primer comando que ejecutas, y su salida te dice si puedes trabajar o si hay un problema que resolver antes de continuar.
Anatomía de la salida
La respuesta tiene siempre la misma estructura: una cabecera fija, y luego una línea por cada dispositivo detectado con dos columnas separadas por un tabulador.
List of devices attached
SERIALNUMBER STATELa columna izquierda es el identificador único del dispositivo. La columna derecha es el estado de la conexión, y es donde está toda la información relevante.
Los cinco estados posibles y qué significan
| Estado | Qué significa | ¿Puedo trabajar? | Cómo resolverlo |
|---|---|---|---|
| authorized | Dispositivo conectado, depuración USB activa y la huella RSA de tu equipo está aceptada. Estado ideal para trabajar. | Sí — listo | Nada. Comienza la extracción y documenta el serial. |
| unauthorized | El dispositivo está conectado y tiene depuración activa, pero no ha aceptado la huella RSA de tu equipo. Aparece el diálogo en pantalla esperando confirmación. | No aún | Desbloquear pantalla del dispositivo y pulsar «Permitir» en el diálogo RSA. Documenta esta acción en el acta.adb kill-server && adb start-server |
| offline | ADB detecta el dispositivo pero no puede comunicarse con él. Suele indicar un problema de cable, driver o que el daemon del dispositivo falló. | No | Cambiar cable USB. Reiniciar servidor ADB.adb kill-server && adb start-server |
| recovery | El dispositivo está arrancado en modo recovery, no en Android normal. Acceso muy limitado al sistema de archivos de usuario. | Parcial | Algunos comandos funcionan. Útil para acceder a particiones de sistema, no a datos de usuario. |
| sideload | El dispositivo está en modo de instalación de paquetes desde recovery. No es un estado forense útil. | No | Reiniciar el dispositivo normalmente. Documenta que estaba en este estado al recibirlo. |
| (lista vacía) | No se detecta ningún dispositivo. La depuración USB puede estar desactivada, el driver no está instalado en el equipo forense, o el cable no transmite datos. | No | Verificar drivers ADB, probar otro cable (muchos cables USB solo cargan, no transmiten datos), confirmar que la depuración está activa en el dispositivo. |
Ejemplos reales de salida y cómo leerlos
Caso ideal — dispositivo listo para trabajar:
List of devices attached
R58M31XDKPL deviceEl estado device es sinónimo de authorized en versiones modernas de ADB. El serial R58M31XDKPL es lo que debes anotar en el acta forense — es el identificador único de esa sesión.
Caso más habitual en campo — esperando autorización:
List of devices attached
R58M31XDKPL unauthorizedEl teléfono tiene la pantalla bloqueada o el usuario no ha aceptado el diálogo RSA todavía. Sin desbloquear la pantalla no puedes avanzar.
Varios dispositivos conectados simultáneamente:
List of devices attached
R58M31XDKPL device
emulator-5554 device
192.168.1.45:5555 deviceAquí ves un dispositivo físico (serial alfanumérico), un emulador y una conexión ADB por red (WiFi). En contexto forense, si aparecen varios dispositivos, todos los comandos posteriores necesitan el flag -s para especificar sobre cuál actúas:
bash
adb -s R58M31XDKPL shell getprop ro.product.modelSin ese flag, ADB devuelve error si hay más de uno conectado — y ese error en mitad de una sesión forense documentada es exactamente el tipo de ruido que la defensa puede usar para cuestionar el rigor del proceso.
El serial como huella de sesión
El número de serie que aparece en adb devices no es arbitrario — es el mismo que está grabado en el dispositivo y que puedes cruzar con:
bash
adb shell getprop ro.serialno # Serial por software
adb shell getprop ro.boot.serialno # Serial de bootloaderSi los tres coinciden (el de adb devices, ro.serialno y ro.boot.serialno), tienes confirmación triple de que estás trabajando sobre el dispositivo correcto. Anota los tres en el informe pericial.
El shell de ADB: entrando al sistema del dispositivo
Si adb devices es el apretón de manos, adb shell es cruzar la puerta. Es el comando que te da acceso a una terminal Linux completa ejecutándose directamente dentro del dispositivo Android — el mismo entorno que usa el propio sistema operativo para funcionar. Para un forense digital, es la diferencia entre mirar un edificio desde fuera y poder recorrer cada habitación.
Qué es exactamente el shell de Android
Android está construido sobre un núcleo Linux. Debajo de la interfaz táctil, las apps y Google Play existe un sistema de archivos Unix completo con usuarios, permisos, procesos y daemons. adb shell te conecta a ese sistema mediante el daemon adbd que corre en el dispositivo, dándote una sesión de terminal similar a conectarte por SSH a un servidor.
La diferencia crítica respecto a un Linux convencional es el usuario con el que entras:
Dos modos de uso: interactivo y directo
El shell tiene dos formas de invocarse, y en forense digital la elección importa porque afecta al log de comandos:
Modo interactivo — abres una sesión y ejecutas comandos uno a uno:
bash
adb shell
# Ahora estás dentro del dispositivo
$ whoami
shell
$ pwd
/
$ ls /sdcard/
DCIM Download Pictures WhatsApp...
$ exitModo directo — ejecutas un solo comando y obtienes la salida inmediatamente, sin abrir sesión. Es el preferido en forense porque cada comando queda como una línea independiente y fechada en el log:
bash
adb shell whoami
adb shell ls /sdcard/
adb shell getprop ro.product.model
```
Para documentación forense, el modo directo es más limpio: cada invocación es atómica, aparece con su propio timestamp en el log de sesión, y no hay riesgo de que comandos de navegación interactiva (como `cd`) afecten a los siguientes.
---
### El sistema de archivos que verás desde el shell
```
/
├── data/ ← Datos de aplicaciones (requiere root para la mayoría)
│ ├── data/ ← Sandbox de cada app instalada
│ └── media/ ← Almacenamiento interno (accesible sin root)
├── sdcard/ ← Enlace simbólico al almacenamiento externo o interno
├── system/ ← Sistema operativo Android (solo lectura normalmente)
├── proc/ ← Información del kernel en tiempo real (procesos, red...)
├── dev/ ← Dispositivos de bloque — particiones físicas
└── cache/ ← Caché del sistema (interesante para recuperación)La ruta más valiosa forensemente es /data/data/, donde vive la base de datos de cada aplicación instalada — mensajes, contactos, historial de búsquedas, tokens de sesión. El problema es que sin root solo puedes acceder a ella mediante los Content Providers expuestos por Android, no directamente.
Comandos del shell que más información forense generan
Reconocimiento del sistema:
adb shell getprop # Todas las propiedades del sistema de una vez
adb shell uname -a # Versión exacta del kernel
adb shell df -h # Espacio usado/libre por partición
adb shell mount # Sistemas de archivos montados y sus opcionesUsuarios y procesos:
adb shell ps -A -o pid,user,name,cmd # Procesos con usuario que los ejecuta
adb shell top -b -n 1 # Snapshot de uso de CPU y memoria
adb shell service list # Servicios del sistema activosRed (muy relevante en casos de exfiltración de datos):
adb shell netstat -tulnp # Conexiones activas y puertos
adb shell cat /proc/net/arp # Tabla ARP — dispositivos vistos recientemente
adb shell dumpsys wifi | grep -i ssid # Redes WiFi conocidas y conectadas
adb shell dumpsys telephony.registry # Estado de la red móvilActividad reciente del usuario:
adb shell dumpsys usagestats # Qué apps se usaron y cuándo
adb shell dumpsys notification # Historial de notificaciones
adb shell content query --uri content://browser/bookmarks # Marcadores del navegador
adb shell dumpsys activity recents # Últimas apps abiertas (recientes)La trampa del sandbox: por qué el shell no lo es todo
El límite más importante que encontrarás es el modelo de permisos de Android. Cada aplicación corre con su propio usuario de sistema (u0_a67, u0_a134…) y sus datos en /data/data/ son inaccesibles para el usuario shell. Desde el shell sin root verás el directorio pero no podrás leer su contenido:
bash
adb shell ls /data/data/com.whatsapp/databases/
# opendir failed, Permission deniedAquí el shell te muestra exactamente su límite, lo cual es en sí mismo información forense útil: sabes que los datos existen, sabes la estructura del directorio, pero necesitas un vector diferente para acceder. Las alternativas legítimas son el backup mediante adb backup (si la app lo permite), los Content Providers públicos de la app, o la extracción con herramientas especializadas en dispositivos rooteados.
Por qué el shell es irreemplazable aunque tengas herramientas automatizadas
Cellebrite, Oxygen o MSAB hacen lo mismo que el shell pero con interfaz gráfica y generación automática de informes. Sin embargo, el shell directo tiene tres ventajas que ninguna herramienta comercial puede darte. Primera, la granularidad: puedes ejecutar exactamente el comando que necesitas para un caso concreto, sin que la herramienta decida qué extrae y qué no. Segunda, la transparencia: el informe muestra exactamente qué se ejecutó, sin caja negra. Y tercera, la disponibilidad: el shell funciona con cualquier ordenador con ADB instalado, sin licencias, sin dongles y sin dependencia de que el fabricante soporte ese modelo de dispositivo. En campo, esa independencia puede ser la diferencia entre perder evidencia volátil y preservarla.
Con toda la información de que dispones ya deberías ser capaz de iniciar una conexión, la semana que viene seguiremos con la captura de log, la imagen de partición etc. Pero hasta entonces mi consejo para practicar, es conseguir, al menos media docena de antiguos y nuevos móviles Android y sus correspondientes cables de conexión de tus amigos, una tienda de segunda mano u otra fuente. La práctica es muy importante y verás que incluso dentro de una familia de SOs y equipos el ecosistema es bastante diferente y la conexión puede variar ligeramente.
Deja una respuesta