Continuamos con la 2da parte de una de las herramientas más básicas que todo forense digital debe conocer para dispositivos Android, adentrándonos en las copias forenses, la documentación y la preservación de la cadena de custodia.
Del dato más profundo al más superficial: el orden correcto
Antes de entrar en materia, vale la pena explicar la lógica que vamos a seguir y porque no es arbitraria. En forense digital existe el principio de orden de volatilidad: capturas primero lo que puede desaparecer antes. Una imagen de partición es el dato más permanente y lento de obtener; una captura de pantalla es el estado más efímero del dispositivo. Por eso, paradójicamente, la captura de pantalla debería hacerse antes que la imagen de disco en una intervención real. Pero contrariamente vamos a empezar por la imagen, seguiremos ese hilo pedagógico y al final verás por qué el orden importa.
El recorrido será:
imagen de partición → extraer BD de apps → capturar logs → captura de pantalla → verificar integridad.
1. Imagen de partición: la copia forense completa
Una imagen de partición es una copia exacta, bit a bit, de una partición del almacenamiento del dispositivo. No es una copia de archivos: es una fotografía del dispositivo de bloque completo, incluyendo el espacio no asignado, archivos borrados no sobreescritos, metadatos del sistema de archivos y fragmentos de datos residuales. Es la evidencia más completa que puedes obtener y la base de cualquier análisis posterior con herramientas como Autopsy.
Identificación de particiones con ADB:
Primero necesitas identificar qué particiones existen y cómo se llaman en ese dispositivo concreto, porque los nombres varían entre fabricantes:
# Listar todos los dispositivos de bloque disponibles
adb shell ls -la /dev/block/by-name/
# Salida típica:
# userdata → /dev/block/mmcblk0p28 ← la más valiosa
# system → /dev/block/mmcblk0p18
# cache → /dev/block/mmcblk0p21Una vez identificada la partición, la extracción bit-a-bit se hace canalizando dd desde el dispositivo hacia tu equipo:
# Imagen de la partición de datos de usuario (la más relevante)
adb shell "dd if=/dev/block/by-name/userdata bs=4096 conv=noerror,sync" \
> evidencia_userdata_$(date +%Y%m%d_%H%M%S).img
# Con progreso visible (requiere pv instalado en el equipo forense)
adb shell "dd if=/dev/block/by-name/userdata bs=4096 conv=noerror,sync" \
| pv > evidencia_userdata.imgLos flags de dd son importantes: conv=noerror hace que no se detenga si encuentra sectores defectuosos, y conv=sync rellena esos sectores con ceros, manteniendo la alineación exacta del dispositivo de bloque. Sin ellos, un sector dañado detiene la extracción y pierdes todo lo que había después.
La limitación real: en dispositivos modernos con FDE o FBE (cifrado completo o por archivo), la imagen extraída estará cifrada. Tendrás los bytes, pero sin la clave de descifrado son inútiles. La clave está derivada del PIN del usuario y del hardware del dispositivo, por lo que necesitarás o el PIN o técnicas de extracción forense avanzadas. Documenta siempre en el informe si el dispositivo tenía cifrado activo.
2. Extraer bases de datos de aplicaciones
La razón por la que esto viene inmediatamente después de entender las particiones es que son la misma información vista desde dos ángulos distintos: la imagen de partición te da el contenedor completo, la extracción de BD te da los archivos individuales ya listos para analizar. En la práctica, harás ambas.
Las aplicaciones Android almacenan casi todo en bases de datos SQLite dentro de su sandbox. Mensajes, conversaciones, historial de llamadas, búsquedas, contactos, tokens de autenticación — todo en archivos .db que puedes abrir directamente con cualquier visor SQLite.
# WhatsApp — mensajes y multimedia
adb pull /data/data/com.whatsapp/databases/msgstore.db
adb pull /data/data/com.whatsapp/databases/wa.db # Contactos de WA
# Telegram
adb pull /data/data/org.telegram.messenger/files/cache4.db
# SMS y MMS nativos del sistema
adb pull /data/data/com.android.providers.telephony/databases/mmssms.db
# Historial de llamadas
adb pull /data/data/com.android.providers.contacts/databases/calllog.db
# Contactos
adb pull /data/data/com.android.providers.contacts/databases/contacts2.db
# Chrome — historial de navegación, búsquedas, contraseñas guardadas
adb pull /data/data/com.android.chrome/app_chrome/Default/History
adb pull /data/data/com.android.chrome/app_chrome/Default/Login\ Data
# Gmail — correos cacheados localmente
adb pull /data/data/com.google.android.gm/databases/Una vez extraídos, puedes inspeccionarlos directamente desde la terminal sin herramientas adicionales:
# Ver todas las tablas de la base de datos de mensajes de WhatsApp
sqlite3 msgstore.db ".tables"
# Consulta forense: extraer mensajes con remitente, timestamp y contenido
sqlite3 msgstore.db "
SELECT
datetime(timestamp/1000, 'unixepoch', 'localtime') as fecha,
key_remote_jid as contacto,
data as mensaje
FROM messages
ORDER BY timestamp DESC
LIMIT 100;
"El problema del sandbox sin root ya lo vimos en la explicación del shell: muchas de estas rutas darán Permission denied en dispositivos no rooteados. La alternativa es usar el sistema de backup de Android, que extrae los datos de la app a través de su propio mecanismo de exportación:
# Backup específico de WhatsApp (si la app lo permite) adb backup -noapk com.whatsapp -f backup_whatsapp.ab # Convertir el backup a formato legible java -jar android-backup-extractor.jar backup_whatsapp.ab backup_whatsapp.tar tar -xf backup_whatsapp.tar
3. Capturar logs del sistema
Los logs son la memoria a corto plazo de Android: registran qué ocurrió en el sistema, qué errores lanzaron las apps, qué conexiones se establecieron y cuándo. Son especialmente valiosos en casos de malware, acceso no autorizado o cuando necesitas reconstruir una línea de tiempo de actividad.
Android tiene cuatro buffers de log separados, y cada uno cuenta una historia diferente:
# Buffer principal — actividad general de apps y sistema
adb logcat -b main -d > log_main.txt
# Buffer de radio — actividad de red móvil, SMS, llamadas
adb logcat -b radio -d > log_radio.txt
# Buffer de eventos — acciones del usuario e interacciones del sistema
adb logcat -b events -d > log_events.txt
# Buffer del sistema — mensajes del kernel y servicios de bajo nivel
adb logcat -b system -d > log_system.txt
# Todo de una vez — lo más completo para forense
adb logcat -b all -d > log_completo_$(date +%Y%m%d_%H%M%S).txtEl flag -d es crítico en forense: vuelca el buffer actual y sale inmediatamente. Sin él, logcat se queda escuchando indefinidamente y tu log nunca termina de escribirse.
Filtrar lo relevante dentro del log:
# Actividad de red — detectar exfiltración de datos
grep -i "network\|connect\|socket\|http" log_completo.txt
# Apps que se instalaron o desinstalaron
grep -i "install\|uninstall\|package" log_completo.txt
# Errores de seguridad y permisos
grep -i "permission\|denied\|security" log_completo.txt
# Actividad de cámara o micrófono (relevante en casos de espionaje)
grep -i "camera\|microphone\|audio\|record" log_completo.txtEl buffer de radio merece atención especial en casos que involucren comunicaciones: registra números marcados, SMS enviados y recibidos a nivel de modem, y eventos de red móvil con timestamps precisos que pueden ser más fiables que los metadatos de la propia app de mensajería.
4. Captura de pantalla
Este es el dato más volátil de todos y, paradójicamente, el más inmediato de documentar. Una captura de pantalla en el momento de la intervención preserva el estado exacto del dispositivo en ese instante: qué aplicación estaba abierta, qué conversación era visible, qué notificaciones había pendientes. Es evidencia directa del uso activo del dispositivo.
# Captura estándar — preserva el estado actual de la pantalla
adb exec-out screencap -p > pantalla_$(date +%Y%m%d_%H%M%S).png
# Secuencia de capturas cada 5 segundos durante 1 minuto
for i in $(seq 1 12); do
adb exec-out screencap -p > pantalla_$(date +%Y%m%d_%H%M%S).png
sleep 5
done
# Grabación de pantalla (máximo 3 minutos por limitación de Android)
adb shell screenrecord --time-limit 180 /sdcard/sesion.mp4
adb pull /sdcard/sesion.mp4
# Limpiar del dispositivo después de extraer
adb shell rm /sdcard/sesion.mp4Usa exec-out en lugar de shell screencap: el primero transmite los bytes en binario puro, mientras que el segundo puede corromper la imagen al pasar por el intérprete de shell si hay caracteres especiales en los datos.
5. Verificar integridad: el cierre de todo el proceso
Ahora que tienes todos los archivos extraídos, la verificación de integridad no es el último paso burocrático — es la demostración matemática de que nada cambió durante todo el proceso. Sin esto, cualquier abogado defensor puede argumentar que los datos fueron manipulados entre el dispositivo y el tribunal.
El protocolo es el mismo para cada archivo extraído, sea una imagen de partición de 64 GB o una captura de pantalla de 2 MB:
# Calcular hash de todos los archivos extraídos de una vez
sha256sum *.img *.db *.txt *.png > HASHES_EVIDENCIA.txt
# El archivo resultante contiene algo así:
# a3f9c12e... evidencia_userdata.img
# 7b2d841f... msgstore.db
# c91a3e57... log_completo.txt
# 4f8e2b90... pantalla_20241215_143022.png
# Verificar todos de una vez en cualquier momento posterior
sha256sum -c HASHES_EVIDENCIA.txt
# evidencia_userdata.img: OK
# msgstore.db: OK
# ...El archivo HASHES_EVIDENCIA.txt es en sí mismo un documento forense que debe firmarse digitalmente, fecharse y adjuntarse al expediente. En España, la firma con certificado digital reconocido (DNIe o certificado de la FNMT) añade validez legal al documento.
El orden que deberíamos haber seguido en el campo real
Ahora que tienes el panorama completo, el orden correcto en una intervención real habría sido el inverso al pedagógico que hemos seguido siempre que sea posible -recuerda el principio de volatilidad por encima de todo-:
primero la captura de pantalla (estado volátil inmediato), luego los logs (buffer que se sobreescribe continuamente), después las bases de datos de apps (persistentes pero sensibles a escrituras del sistema), a continuación la imagen completa de partición (lenta pero exhaustiva), y finalmente la verificación de integridad de todo lo extraído. La imagen de disco viene casi al final precisamente porque su extracción puede tardar horas y durante ese tiempo el resto de la evidencia volátil ya habrá desaparecido si no la capturaste antes.
La cadena de custodia: el eslabón entre la evidencia digital y la verdad judicial
Todo lo que hemos visto hasta ahora —el shell, las particiones, los logs, los hashes— tiene un único destino final: un tribunal. Y en ese tribunal, la pregunta que determinará si meses de trabajo forense sirven de algo no será qué encontraste, sino cómo puedes demostrar que lo que presentas es exactamente lo que había en el dispositivo, sin alteración, desde el momento en que lo incautaste hasta hoy.
La cadena de custodia es la respuesta documentada a esa pregunta. No es un formulario. Es la narrativa verificable de la vida de una evidencia y de nosotros depende que esté bien construida.
El marco legal en España
Antes de entrar en el procedimiento técnico, el contexto jurídico es imprescindible porque determina qué documentación es obligatoria y cuál es optativa.
En España, la evidencia digital se rige principalmente por la Ley de Enjuiciamiento Criminal (LECrim), reformada por la Ley 13/2015, que incorporó por primera vez regulación específica sobre evidencia electrónica. Los artículos 588 sexies a y b regulan el registro de dispositivos de almacenamiento masivo de información. El artículo 11 de la LOPJ establece que las pruebas obtenidas violando derechos fundamentales son nulas de pleno derecho, lo que en la práctica significa que una cadena de custodia rota no solo debilita la prueba: la elimina.
A nivel europeo, el marco de referencia técnico es la norma ISO/IEC 27037:2012, estándar internacional para la identificación, recopilación, adquisición y preservación de evidencia digital, adoptado como referencia por la mayoría de los laboratorios forenses acreditados en la UE.
La cadena completa: de la incautación al tribunal
Fase 1 — La incautación: donde todo empieza y donde todo se puede perder
El error más común y más devastador en forense digital es tratar la incautación como un trámite previo al trabajo real. La incautación es el trabajo real, porque es el único momento en que puedes documentar el estado original del dispositivo sin que nadie lo haya tocado antes que tú.
El acta de incautación debe recoger con precisión milimétrica:
ACTA DE INCAUTACIÓN DE EVIDENCIA DIGITAL
─────────────────────────────────────────
Expediente: [número de diligencias]
Fecha y hora: 15/04/2025 — 14:32:07 (hora certificada NTP)
Lugar: [dirección exacta]
Agente interviniente: [nombre, DNI, número de placa]
Perito presente: [nombre, número de colegiado]
Autorización: Auto judicial nº [xxx] del Juzgado [xxx]
DISPOSITIVO:
Marca/Modelo: Samsung Galaxy S23 Ultra
IMEI: 354721XXXXXXXXX (verificado marcando *#06#)
N.º de serie: R58M31XDKPL
Versión Android: 14 (compilación UP1A.231005.007)
Estado pantalla: Bloqueada con PIN, sin daños visibles
Nivel batería: 67%
Conectividad: WiFi activo — desactivado físicamente antes de actuar
Estado físico: Sin daños aparentes [fotografías adjuntas: IMG_001-006]
Precinto nº: FC-2025-04785
Firma del perito: _______________
Firma del agente: _______________El punto de la hora certificada merece atención especial. No vale con la hora del móvil de quien incauta ni con la del ordenador del laboratorio. En España, el sello de tiempo válido legalmente se obtiene a través de la Autoridad de Sellado de Tiempo de la FNMT o mediante un servidor NTP trazable. La razón es que cualquier discrepancia entre la hora del acta y los metadatos del dispositivo puede convertirse en un argumento de la defensa para sugerir manipulación.
Fase 2 — La bolsa Faraday: el eslabón que más se omite
Entre la incautación y el laboratorio existe un período de riesgo que muchos peritos subestiman: el traslado. Un dispositivo encendido durante el traslado puede recibir una orden de borrado remoto mediante MDM corporativo, un comando de localización que modifica registros del sistema, o simplemente sincronizarse con un servidor y sobreescribir datos locales.
La bolsa Faraday bloquea todas las comunicaciones electromagnéticas —GSM, WiFi, Bluetooth, NFC— aislando el dispositivo del mundo exterior. Es el equivalente digital de los guantes en la escena del crimen físico.
REGISTRO DE TRANSFERENCIA DE CUSTODIA
──────────────────────────────────────
Transferido por: [nombre + firma] Cargo: [cargo]
Recibido por: [nombre + firma] Cargo: [cargo]
Fecha/hora: [timestamp certificado]
Condición: Precinto FC-2025-04785 intacto — verificado
Medio de traslado: Bolsa Faraday ref. [modelo] + caja acolchada
Observaciones: Batería al 61% al llegar al laboratorioCada transferencia de custodia —del agente al perito, del perito al laboratorio, del laboratorio al juzgado— necesita su propio registro firmado por ambas partes. La cadena se rompe en cualquier transferencia no documentada.
Fase 3 — El registro de extracción: la columna vertebral técnica
Ya lo vimos en detalle en la explicación anterior sobre documentación para juicio, pero en el contexto de la cadena de custodia hay un elemento adicional que merece profundidad: el registro del entorno forense.
No basta con documentar qué comandos ejecutaste. Debes documentar también desde dónde los ejecutaste, porque si tu equipo forense tenía software que podría haber escrito en el dispositivo, toda la extracción es cuestionable:
# Documentar el entorno forense al inicio de cada sesión
echo "=== ENTORNO FORENSE ===" >> registro_sesion.txt
date >> registro_sesion.txt
uname -a >> registro_sesion.txt # OS del equipo forense
adb version >> registro_sesion.txt # Versión exacta de ADB
echo "Write blocker: Tableau TD3 S/N: [xxxxx]" >> registro_sesion.txt
echo "Perito: [nombre] — Colegiado nº [xxx]" >> registro_sesion.txt
echo "Expediente: [número]" >> registro_sesion.txt
echo "========================" >> registro_sesion.txt
# A partir de aquí, toda la sesión queda grabada
script -t 2>timestamps_sesion.log sesion_completa.logEl archivo sesion_completa.log generado por script es legalmente muy robusto porque registra no solo los comandos sino los tiempos exactos entre pulsación y respuesta, lo que hace prácticamente imposible argumentar que fue fabricado a posteriori.
Fase 4 — El análisis sobre copia: la regla que no admite excepciones
Esta regla es tan fundamental que merece su propia sección aunque parezca obvia: nunca se analiza la evidencia original. Siempre se trabaja sobre una copia forense verificada mediante hash.
La razón no es solo técnica. Es jurídica. Si analizas el original y la defensa solicita una pericia contradictoria, su perito no podrá verificar que el estado del dispositivo es el mismo que cuando tú trabajaste. Si tienes una imagen verificada con hash, el perito de la defensa puede trabajar sobre una copia de esa imagen y llegar a los mismos resultados, o señalar discrepancias — que es exactamente lo que debe poder hacer en un sistema judicial garantista.
# Crear dos copias de trabajo idénticas a partir de la imagen original
cp evidencia_original.img copia_trabajo_perito.img
cp evidencia_original.img copia_custodia_juzgado.img
# Verificar que las tres son idénticas
sha256sum evidencia_original.img \
copia_trabajo_perito.img \
copia_custodia_juzgado.img
# Las tres deben mostrar el mismo hash
# a3f9c12e... evidencia_original.img
# a3f9c12e... copia_trabajo_perito.img
# a3f9c12e... copia_custodia_juzgado.img
# Precintar el original — no se vuelve a abrir salvo por orden judicialLa copia destinada al juzgado se entrega en un soporte físico precintado junto con el hash impreso y firmado. La copia de trabajo es la que usas en Autopsy, Cellebrite o cualquier herramienta de análisis. Si en algún momento necesitas repetir el análisis desde cero, dispones del original intacto.
Fase 5 — El informe pericial: donde la técnica se convierte en lenguaje jurídico
El informe es el producto final de todo el proceso y el documento que un juez sin conocimientos técnicos debe poder entender. Esto crea una tensión constante: necesitas ser técnicamente preciso y al mismo tiempo comprensible para alguien que nunca ha usado ADB.
La estructura que los tribunales españoles esperan, alineada con la doctrina del Tribunal Supremo (especialmente la STS 300/2015 sobre prueba pericial digital):
1. Objeto y encargo pericial — Una sola frase. Qué se analiza, para qué procedimiento y quién lo encargó.
2. Documentos y materiales examinados — Lista exacta de cada elemento recibido con su precinto, hash y estado. Si recibiste un Samsung S23 precintado, lo dices. Si el precinto estaba intacto, lo dices. Si tenía alguna anomalía, también.
3. Metodología y herramientas — Aquí describes el proceso técnico en lenguaje accesible, con notas técnicas en anexo para el perito de la defensa. Menciona explícitamente la norma ISO/IEC 27037 como marco de referencia: señala que tu método es estándar de la industria, no una ocurrencia personal.
4. Cadena de custodia — Reproduce el registro completo de transferencias, con firmas escaneadas. Todo el mundo que tocó la evidencia aparece aquí.
5. Proceso de extracción — El log de sesión como anexo. En el cuerpo del informe, un resumen en prosa de qué se extrajo y cómo.
6. Tabla de integridad — Cada archivo extraído con su hash SHA-256 en origen y en destino. Esta tabla es el núcleo de la defensa de la integridad.
7. Hallazgos y análisis — Solo aquí aparecen tus conclusiones sobre el contenido. Separar el cómo del qué encontraste es fundamental para que el informe resista el contrainterrogatorio: si alguien cuestiona un hallazgo, no puede contaminar la validez del proceso de extracción, y viceversa.
8. Conclusiones — Numeradas, una por párrafo, en lenguaje directo. Sin ambigüedades ni hedging innecesario: o los datos demuestran algo o no lo demuestran.
9. Declaración de imparcialidad — El perito certifica que no tiene relación con ninguna de las partes, que su informe refleja su opinión técnica honesta y que está sujeto a las responsabilidades del artículo 459 LECrim sobre falso testimonio pericial.
10. Firma digital cualificada — En España, con certificado de la FNMT o DNIe. No es opcional: una firma manuscrita escaneada no tiene el mismo valor legal que una firma electrónica cualificada reconocida por el Reglamento eIDAS.
Los vectores de ataque de la defensa: cómo anticiparlos
Un buen perito de la defensa no intentará demostrar que los datos son falsos. Intentará demostrar que el proceso fue suficientemente defectuoso como para generar duda razonable. Estos son los argumentos más frecuentes y cómo los neutraliza una cadena de custodia bien construida:
«No hay garantía de que el dispositivo no fue manipulado entre la incautación y el análisis.» La neutralizas con el registro de transferencia firmado en cada traspaso y el número de precinto verificado al abrir en el laboratorio, con fotografías de ese momento.
«Los hashes fueron calculados después del análisis, no antes.» La neutralizas con los timestamps del log de sesión generado por script, que incluye tiempos de respuesta y es prácticamente imposible de fabricar retroactivamente.
«El software del equipo forense pudo haber modificado el dispositivo.» La neutralizas documentando el write blocker, su número de serie y el modo de solo lectura activado, junto con la versión exacta del sistema operativo del equipo forense en el momento de la extracción.
«La imagen de partición está cifrada y no podemos verificar su contenido.» Esto no invalida la cadena de custodia, pero debes haberlo documentado en el informe: el dispositivo tenía cifrado FBE activo, la imagen fue extraída en estado cifrado, y el análisis se realizó sobre los datos descifrados tras obtener el PIN mediante [método legalmente autorizado].
«El perito no es imparcial.» Se neutraliza exclusivamente con la declaración formal del apartado 9 y con el historial profesional del perito. No hay documentación técnica que supla esto: la credibilidad personal del perito es, al final, parte de la evidencia.
La paradoja final: la cadena de custodia no protege la evidencia del acusado
Merece una reflexión que va más allá de lo técnico. La cadena de custodia no existe para facilitar las condenas. Existe para garantizar que tanto la inocencia como la culpabilidad pueden demostrarse de forma verificable. Una cadena de custodia rota no solo perjudica a la acusación: impide que la defensa pueda demostrar que los datos fueron manipulados para incriminar a alguien.
Cuando documentas cada paso con la precisión que hemos descrito a lo largo de esta serie, no estás construyendo un caso contra nadie. Estás construyendo un registro de la verdad técnica que el sistema judicial puede examinar, cuestionar y verificar. Eso es exactamente lo que debe hacer la ciencia forense.
Deja una respuesta