Metadatos de WhatsApp: que revelan y como se analizan en un peritaje forense

Los metadatos son mi arma secreta como perito informático forense. Cuando un abogado me entrega un teléfono para analizar una conversacion de WhatsApp, casí siempre espera que yo lea los mensajes. Pero lo primero que hago es extraer la base de datos y sumergirme en los metadatos: marcas de tiempo al milisegundo, confirmaciones de lectura, identificadores de dispositivo, hashes de archivos multimedía y registros de mensajes eliminados que siguen ahi aunque el usuario crea que desaparecieron.

He resuelto casos que parecian perdidos gracias exclusivamente al análisis de metadatos. Casos donde no quedaba un solo mensaje visible, donde el usuario habia borrado todo, donde la parte contraria presentaba capturas de pantalla retocadas como si fueran prueba irrefutable. En todos ellos, los metadatos contaban la historia real.

Según un estudio de la Universidad de New Haven sobre artefactos forenses en aplicaciones de mensajeria, los metadatos de WhatsApp pueden reconstruir hasta el 94% de la actividad del usuario incluso cuando el contenido del mensaje ha sido eliminado. En mi experiencia profesional con más de cien extracciones forenses, ese porcentaje es conservador: la combinacion de las tres bases de datos locales, los archivos WAL, los logs y los artefactos multimedía permite reconstruir practicamente toda la actividad.

Un dato que siempre impresiona a los jueces: el contenido de un mensaje puede falsificarse, pero los metadatos de la base de datos de WhatsApp son casí imposibles de manipular sin dejar rastro. Las bases de datos SQLite mantienen relaciones de integridad entre decenas de tablas, con secuencias autoincrementales, foreign keys y timestamps correlaciónados. Alterar un campo sin romper las cadenas de dependencia requiere un conocimiento técnico que, en la práctica, ninguna de las partes en un procedimiento civil o laboral posee.

Que son los metadatos de WhatsApp: explicación accesible

Antes de entrar en tecnicismos, quiero explicar que son los metadatos de una forma que cualquier persona pueda entender, porque es la misma explicación que doy a abogados y jueces durante la ratificación de mis informes periciales.

Imaginemos que envias una carta postal. El contenido de la carta es lo que escribes en el papel: el texto, las palabras, el mensaje. Los metadatos son todo lo demas: el sello postal con la fecha y hora de envio, el acuse de recibo firmado por el destinatario, el peso del sobre, el código postal de origen y destino, la huella dactilar del cartero que la entrego, la fotografia del buzon en el momento exacto de la entrega, e incluso el registro de que el destinatario abrio el sobre a las 14:32 del martes.

En WhatsApp, cada mensaje que envias genera entre 25 y 40 campos de metadatos que se almacenan automáticamente en bases de datos SQLite dentro del dispositivo. Estos campos incluyen:

• Cuando se envio el mensaje (con precision de milisegundos)
• Cuando fue recibido por el servidor de WhatsApp
• Cuando llego al dispositivo del destinatario
• Cuando el destinatario abrio la conversacion y leyo el mensaje
• Desde que dispositivo se envio (teléfono, WhatsApp Web, dispositivo vinculado)
• Que tipo de contenido era (texto, imagen, audio, video, documento, ubicacion, contacto)
• Si fue reenviado y cuantas veces
• Si se respondio a otro mensaje y a cual exactamente
• Si fue editado y cuando (desde la actualizacion de 2024)
• Si fue eliminado y cuando, pero conservando el registro original
• El hash criptográfico de cualquier archivo adjunto, que permite verificar que no ha sido manipulado

El usuario normal de WhatsApp no ve nada de esto. Solo ve el mensaje, los ticks azules y poco mas. Pero para un perito informático forense, estos metadatos son un tesoro de información que permite reconstruir los hechos con una precision que rara vez se consigue con otras pruebas.

Para entenderlo con otro ejemplo que uso frecuentemente en juicio: si dos personas discuten sobre si un mensaje fue enviado o no, las capturas de pantalla son como fotocopias de un documento que cualquiera puede fabricar en cinco minutos con Photoshop. Los metadatos extraidos de la base de datos son como el registro notarial del documento original con fecha, hora, firmantes y sellos verificables.

Tipos de metadatos: la clasificacion que uso en mis informes

Para organizar el análisis en mis informes periciales, clasifico los metadatos de WhatsApp en cinco categorías funcionales. Esta taxonomia facilita la comprension tanto para abogados como para jueces:

Metadatos de identificación: Determinan quien envio que a quien. Incluyen los JIDs (identificadores de número de teléfono), los identificadores de grupo, el campo key_from_me que distingue mensajes enviados de recibidos, y el sender_jid que identifica al remitente real en conversaciones de grupo. Son los metadatos que responden a la pregunta “quien fue”.

Metadatos temporales: Registran cuando ocurrio cada evento con precision de milisegundos. Incluyen el timestamp de envio, de recepcion por el servidor, de entrega al dispositivo, de lectura, de reproducción multimedia, de edicion y de eliminación. Son la columna vertebral de cualquier reconstruccion cronologica y responden a la pregunta “cuando fue”.

Metadatos de estado: Documentan que ocurrio con cada mensaje después de ser enviado. El campo status con sus valores (0=pendiente, 4=enviado, 5=entregado, 6=leido, 13=eliminado), los indicadores de reenvio, el edit_version y el starred entran en esta categoría. Responden a la pregunta “que paso después”.

Metadatos de contenido: Describen la naturaleza del mensaje sin revelar su contenido textual. El tipo de medía (media_wa_type), el tamaño del archivo, la duracion del audio o video, el hash criptográfico del archivo adjunto y el nombre del archivo original. Responden a la pregunta “que tipo de información se intercambio”.

Metadatos de dispositivo y red: Identifican desde donde y como se envio el mensaje. El campo origin que distingue entre teléfono, WhatsApp Web y dispositivos vinculados, los timestamps del servidor versus los del dispositivo, y la información de la tabla linked_devices. Responden a la pregunta “desde donde se envio”.

Esta clasificacion no es academica: la utilizo literalmente en la estructura de mis informes periciales porque permite al juez navegar el informe y localizar rápidamente la información relevante para cada cuestion debatida.

Por que los metadatos importan más que el contenido

Esta es una afirmacion que hago con frecuencia y que siempre genera sorpresa: en un peritaje forense, los metadatos suelen tener más valor probatorio que el contenido del mensaje.

La razón es triple:

Primero, el contenido es facilmente falsificable. Existen aplicaciones como WhatsFake, Fake Chat Conversations o incluso editores de bases de datos SQLite que permiten crear conversaciones de WhatsApp completamente inventadas que parecen reales en una captura de pantalla. Un abogado con 15 minutos y un tutorial de YouTube puede fabricar una captura perfecta. Pero fabricar un conjunto coherente de metadatos que resista un análisis forense es otra historia completamente distinta.

Segundo, los metadatos son objetivos. No dependen de la interpretacion del contenido ni del contexto. Un read_timestamp de 1709123400000 significa que el mensaje fue leido el 27 de febrero de 2026 a las 09:30:00.000 UTC. No hay margen para la ambiguedad, no hay doble interpretacion posible.

Tercero, los metadatos son verificables de forma cruzada. Puedo comparar los metadatos del dispositivo emisor con los del receptor, con los del backup en Google Drive, con los registros del servidor de WhatsApp obtenidos mediante requerimiento judicial y con los archivos WAL pendientes de consolidacion. Si todos coinciden, la prueba es practicamente irrefutable. Si hay discrepancias, detecto exactamente donde y por que.

La jurisprudencia reciente del Tribunal Supremo, especialmente la STS 629/2025, ha reforzado el valor de los metadatos como elemento de autenticación. Cuando la parte contraria impugna unas capturas de pantalla, los metadatos extraidos forense aportan el nivel de garantía técnica que el tribunal necesita para admitir la prueba. La STS 603/2025 va incluso más lejos, estableciendo que la carga de la prueba de la manipulación recae sobre quien impugna cuando existe un informe pericial que válida la integridad de los metadatos.

Tabla completa de metadatos en msgstore.db (Android)

Tras cientos de extracciones forenses, esta es la tabla completa de campos de metadatos que documento sistematicamente en cada peritaje. La organizo por relevancia forense:

Campos de identificación y origen

Campos temporales (timestamps)

Campos de estado y contenido

Campos de grupo

Cada uno de estos campos se almacena de forma independiente y tiene su propia marca temporal interna en el sistema de ficheros. Cuando un cliente me pregunta “pero si borro el mensaje, desaparece todo?”, la respuesta es que el campo status cambia a 13 pero el registro completo permanece en la base de datos con todos sus metadatos intactos.

Donde se almacenan: estructura completa de bases de datos

WhatsApp utiliza tres bases de datos SQLite principales en el dispositivo, más una coleccion de artefactos secundarios que analizo en cada peritaje. Voy a desglosar cada una porque entender la estructura es fundamental para valorar la profundidad del análisis.

Artefactos secundarios que analizo en cada peritaje

Además de las tres bases principales, WhatsApp genera una constelacion de artefactos forenses adicionales que aportan contexto crítico:

Archivos WAL (Write-Ahead Log): El archivo msgstore.db-wal es uno de los más valiosos y menos conocidos. SQLite utiliza un mecanismo de escritura anticipada donde los cambios se escriben primero en el WAL antes de consolidarse en la base principal. Esto significa que msgstore.db-wal puede contener mensajes y metadatos que fueron eliminados antes de que SQLite completara el checkpoint. He recuperado mensajes críticos de archivos WAL que habian sido borrados hacia menos de 24 horas, en casos donde el usuario creia haberlos eliminado definitivamente.

Archivos multimedía y miniaturas: WhatsApp almacena los archivos en Media/WhatsApp Images/, Media/WhatsApp Video/, Media/WhatsApp Audio/, etc. Los nombres de archivo incluyen timestamps y referencias al chat. Incluso cuando un usuario elimina una imagen de la conversacion, las miniaturas (thumbnails) persisten en las carpetas .Thumbs y en la tabla message_thumbnails de msgstore.db. He presentado miniaturas de imagenes como prueba en juicio cuando el archivo original habia sido eliminado.

Un detalle técnico que merece mencion: los nombres de archivo multimedía siguen un patrón predecible. Por ejemplo, IMG-20260309-WA0023.jpg indica que es la imagen número 23 recibida por WhatsApp el 9 de marzo de 2026. Los huecos en la numeracion secuencial (por ejemplo, saltar de WA0023 a WA0027) indican que las imagenes intermedias fueron recibidas y luego eliminadas del sistema de archivos, aunque sus registros y miniaturas persisten en la base de datos. He utilizado esta numeracion secuencial para demostrar la existencia de 4 imagenes eliminadas que la parte contraria afirmaba no haber recibido nunca.

Ademas, los metadatos EXIF de las imagenes (cuando no han sido eliminados por la compresion de WhatsApp) pueden revelar el modelo de camara, la fecha de captura y las coordenadas GPS del lugar donde se tomo la fotografia. WhatsApp elimina la mayoria de metadatos EXIF al comprimir las imagenes, pero las imagenes enviadas como “documento” (sin compresion) conservan todos sus metadatos EXIF originales. Este es un error frecuente de usuarios que no son conscientes de que al enviar una foto “como documento” estan compartiendo su ubicacion GPS exacta.

Logs de aplicación: files/Logs/whatsapp.log y los archivos de registro en formato comprimido contienen eventos de la aplicación: errores de conexión, fallos de envio, actualizaciones de la app, cambios de versión y eventos de sincronizacion. En un caso complejo de supuesta interceptacion de comunicaciones, los logs revelaron que WhatsApp habia detectado un cambio de clave de cifrado en la sesion del interlocutor, sugiriendo que un tercero habia registrado el número en otro dispositivo.

Shared Preferences (Android): Los archivos XML en shared_prefs/ almacenan configuración persistente del usuario: número de teléfono registrado, última versión de la app utilizada, estado de la verificación en dos pasos, configuración de privacidad de “última vez visto” y la clave de cifrado de las notificaciones push. En iOS, el equivalente son los archivos .plist en el contenedor de la aplicación.

Archivos de backup local: En Android, las copias de seguridad se almacenan cifradas en sdcard/WhatsApp/Databases/ con nombres como msgstore.db.crypt15 (formato actual) o msgstore-2026-03-09.1.db.crypt15 (backups historicos diarios). WhatsApp mantiene hasta 7 backups locales rotativos, lo que significa que puedo acceder a versiones de la base de datos de hasta una semana atras. Esto es especialmente útil cuando el usuario ha manipulado la base de datos actual: el backup del día anterior al intento de manipulación puede contener los datos originales intactos.

iOS: ChatStorage.sqlite y sus particularidades

Cuando recibo un dispositivo Apple para peritaje, la estructura de metadatos cambia significativamente respecto a Android. En iOS, la base de datos principal se llama ChatStorage.sqlite y se ubica en el contenedor protegido de la aplicación (/var/mobile/Containers/Shared/AppGroup/.../ChatStorage.sqlite).

Las diferencias más relevantes para el análisis forense:

La conversion de timestamps es un detalle crítico que los peritos novatos suelen pasar por alto. En Android, el timestamp 1709121600000 es directamente interpretable como milisegundos desde el 1 de enero de 1970 (UNIX epoch). En iOS, el campo ZMESSAGEDATE usa el epoch de Core Data de Apple (1 de enero de 2001), y almacena los valores como números de punto flotante en segundos, no milisegundos. He visto informes periciales de otros profesionales donde la conversion erronea de timestamps de iOS produjo cronologias desplazadas 31 años, un error que habría sido devastador en juicio.

Otro aspecto exclusivo de iOS: la base de datos Spotlight/ index puede contener fragmentos de mensajes indexados por el sistema de busqueda de Apple, incluso de mensajes eliminados en WhatsApp. Esta fuente alternativa de datos me ha resultado útil en al menos tres casos donde ChatStorage.sqlite habia sido parcialmente corrompida.

wa.db: que revelan los metadatos de contactos

La base de datos de contactos merece una seccion propia porque contiene información que frecuentemente pasa desapercibida pero que puede ser determinante.

La tabla wa_contacts incluye estos campos relevantes:

En un caso de estafa BEC (Business Email Compromise) que perite, el campo display_name era “CEO Maria Lopez” pero el wa_name era “Ahmed”, y el número estaba registrado en un operador virtual prepago activado 72 horas antes del primer mensaje. Esa combinacion de metadatos de contacto fue suficiente para demostrar la suplantacion ante el juez.

chatsettings.db: configuración como evidencia

La base de configuración es la menos analizada por peritos inexpertos pero contiene datos que pueden cambiar el curso de un procedimiento:

• Chats archivados: Demuestra que el usuario archivo intencionadamente una conversacion, lo que refuta la alegacion de “no sabia que existia ese chat”
• Chats silenciados: Registra desde cuando esta silenciado un chat y si se configuro silencio por 8 horas, 1 semana o “siempre”. He utilizado este dato para contextualizar por que un directivo tardo días en responder a una comunicación crítica
• Mensajes temporales: Registra cuando se activo la autodestruccion de mensajes y que duracion se configuro (24 horas, 7 días, 90 días). La fecha de activacion es clave para demostrar conducta de destrucción de pruebas
• Chats fijados: Los primeros 3 chats fijados por el usuario revelan sus conversaciones prioritarias, información contextual valiosa en casos de acoso o relaciones inapropiadas
• Fondos personalizados: Un fondo de pantalla personalizado en un chat específico demuestra una relación más alla de lo casual con ese contacto
• Notificaciones personalizadas: Si el usuario configuro un tono de notificación especial para un contacto, queda registrado. Demuestra que el usuario habia personalizado la interacción con ese contacto específico
• Protección de chat con huella digital: Desde 2024, WhatsApp permite proteger chats individuales con biometria. La fecha de activacion de esta protección queda registrada y puede indicar que el usuario considero ese chat lo suficientemente sensible como para ocultarlo

Metadatos de backups: Google Drive e iCloud

Los backups en la nube son una fuente de metadatos que no reside en el dispositivo pero que puedo solicitar mediante requerimiento judicial. Cada plataforma tiene sus particularidades.

Google Drive (Android)

WhatsApp realiza backups automáticos a Google Drive según la frecuencia configurada por el usuario (diario, semanal, mensual o nunca). Cada backup genera metadatos propios:

• Fecha y hora del backup: Permite saber cuando se realizo la última copia
• Tamaño del backup: Un cambio drastico de tamaño entre backups sucesivos puede indicar eliminación masiva de contenido
• Cuenta de Google asociada: Vincula el backup a una identidad
• Cifrado E2E del backup: Desde octubre 2021, WhatsApp ofrece cifrado E2E de backups con clave de 64 digitos o password. Si esta activado, ni Google ni WhatsApp pueden acceder al contenido sin la clave del usuario
• Historial de backups: Google Drive mantiene metadatos de backups anteriores incluso después de que WhatsApp los sobreescriba. Mediante la API de Google Drive, he recuperado metadatos de backups de meses anteriores

Para acceder al backup con autorización judicial, se oficia a Google Ireland Limited (responsable para España bajo RGPD) solicitando el contenido del backup de WhatsApp asociado a la cuenta del investigado.

iCloud (iOS)

En iOS, los backups de WhatsApp se almacenan en iCloud Drive como parte del backup completo del dispositivo o como backup independiente de WhatsApp. Los metadatos accesibles incluyen:

• Fecha del último backup: En la carpeta de CloudKit
• Tamaño: Separado entre mensajes y multimedia
• Estado de cifrado E2E: Mismo sistema de clave de 64 digitos
• Protección avanzada de datos: Si el usuario activo Advanced Data Protection de iCloud, el backup esta cifrado con clave que Apple no posee

La solicitud a Apple se dirige a Apple Distribution International Ltd (Cork, Irlanda) con requerimiento judicial conforme al artículo 588 bis de la LECrim.

Comparacion cruzada entre backup y dispositivo

Una de las técnicas de validación más potentes que utilizo en mis peritajes es la comparación cruzada entre los metadatos del dispositivo y los del backup en la nube. Si el usuario tiene backup automático diario activado en Google Drive, puedo comparar:

• Mensajes presentes en el backup pero ausentes en el dispositivo: Indican que fueron eliminados después del último backup. Si el backup es de las 03:00 y un mensaje fue eliminado a las 10:00, el backup lo contiene pero el dispositivo no. Esto permite recuperar mensajes eliminados intencionadamente
• Mensajes presentes en el dispositivo pero ausentes en el backup: Si son mensajes recibidos después de las 03:00 (hora del backup), es normal. Si son de fecha anterior, puede indicar que se importo una base de datos de otra fuente
• Tamaño del backup vs tamaño de la base de datos actual: Una discrepancia significativa (por ejemplo, el backup de ayer ocupaba 500 MB y la base actual solo 200 MB) indica eliminación masiva de contenido entre ambos momentos
• Número de registros en la tabla messages: Si el backup tiene 15.000 mensajes y la base actual solo 12.000, hay 3.000 mensajes eliminados que potencialmente puedo recuperar del backup

Esta técnica me ha resultado especialmente útil en casos donde una de las partes entrego “voluntariamente” su teléfono pero habia limpiado conversaciones específicas la noche anterior. El backup automático de las 03:00 contenia las conversaciones intactas que habian sido eliminadas a las 09:00, dos horas antes de la entrega del dispositivo al juzgado.

Que almacena Meta: metadatos del lado del servidor

Un aspecto que siempre aclaro a los abogados: WhatsApp (Meta Platforms) no almacena el contenido de los mensajes cifrados E2E, pero si conserva metadatos del servidor que pueden ser extremadamente reveladores. Según la politica de información de WhatsApp para solicitudes legales, Meta puede proporcionar:

Para obtener esta información desde España, se requiere cooperacion judicial internacional: una comision rogatoria dirigida a las autoridades de Estados Unidos (sede principal de Meta en Menlo Park, California) tramitada a traves del Ministerio de Justicia conforme al MLAT (Mutual Legal Assistance Treaty) entre España y EEUU, o una European Production Order si el delito encaja en los criterios del e-Evidence Regulation de la UE.

En mi experiencia, el proceso tarda entre 3 y 8 meses, por lo que siempre recomiendo priorizar la extracción forense del dispositivo local, que es inmediata y contiene datos más completos.

Lo que Meta sabe y lo que revela el documento de transparencia

El Transparency Report de Meta pública semestralmente las solicitudes de información recibidas de autoridades gubernamentales. En el último informe disponible, España envio más de 3.500 solicitudes de datos a Meta en un semestre, de las cuales aproximadamente el 78% recibieron alguna información en respuesta. Sin embargo, hay que distinguir entre solicitudes de emergencia (amenaza a la vida, tipicamente respondidas en horas), ordenes judiciales nacionales (semanas) y comisiones rogatorias internacionales (meses).

Un dato que comparto con los abogados: Meta proporciona datos diferentes según el tipo de requerimiento legal:

• Solicitud de emergencia (peligro inminente): Datos de registro, IPs recientes, información básica de cuenta. Respuesta en 24-72 horas
• Orden judicial nacional (via cooperacion policial): Todo lo anterior más metadatos de mensajeria (sin contenido), lista de contactos, información de grupos. Respuesta en 30-90 días
• MLAT / Comision rogatoria: Todo lo anterior más logs de acceso completos, datos historicos extendidos, información de cuenta vinculada. Respuesta en 3-8 meses
• Orden de preservación (preservation request): Meta congela los datos de una cuenta durante 90 días (renovables) sin eliminar nada, mientras se tramita la solicitud formal. Esta es la primera gestión que recomiendo a los abogados: solicitar la preservación mientras se prepara la comision rogatoria

La preservation request es una herramienta infrautilizada por los abogados españoles. Meta acepta solicitudes de preservación directamente a traves de su Law Enforcement Response Team, sin necesidad de comision rogatoria. Esto garantiza que los metadatos del servidor no se eliminen mientras se tramita la solicitud formal, que puede tardar meses.

Anatomia de un mensaje: el viaje completo de los metadatos

Para entender la riqueza de los metadatos, merece la pena seguir el recorrido completo de un mensaje de WhatsApp desde que el emisor pulsa “enviar” hasta que el destinatario lo lee. En cada paso se generan metadatos diferentes:

Paso 1 - Redaccion y envio: El usuario escribe el mensaje y pulsa enviar. WhatsApp genera un key_id único, registra el timestamp en milisegundos UNIX, asigna el media_wa_type correspondiente, establece key_from_me = 1 y crea el registro en la tabla messages con status = 0 (pendiente). Si el mensaje incluye un archivo adjunto, calcula el hash SHA256 y lo almacena en media_hash. Si es una respuesta a otro mensaje, registra el quoted_row_id. Si es un reenvio, incrementa el contador forwarded. Todo esto ocurre en milisegundos, antes de que el mensaje salga del dispositivo.

Paso 2 - Transmisión al servidor: El mensaje cifrado E2E se transmite a los servidores de WhatsApp. El servidor registra la recepcion y genera el receipt_server_timestamp. En el dispositivo emisor, el status cambia a 4 (enviado) y aparece un tick gris. Meta almacena en sus servidores los metadatos de conexión (IP del emisor, timestamp) pero no puede leer el contenido cifrado.

Paso 3 - Entrega al destinatario: El servidor envia el mensaje al dispositivo receptor. Cuando llega, se registra el received_timestamp en el dispositivo del destinatario y el status cambia a 5 (entregado) en ambos dispositivos. Aparece el doble tick gris. Si el destinatario tiene multiples dispositivos vinculados, el mensaje se entrega a cada uno y cada dispositivo genera su propio received_timestamp.

Paso 4 - Lectura: Cuando el destinatario abre la conversacion, se registra el read_timestamp. El status cambia a 6 (leido) en ambos dispositivos y los ticks se vuelven azules (si las confirmaciones de lectura estan activadas). Si el destinatario tiene desactivadas las confirmaciones, el tick azul no aparece en el dispositivo emisor pero el read_timestamp si se registra localmente en el dispositivo receptor. Este es un dato que muchos desconocen y que tiene implicaciones forenses significativas.

Paso 5 - Acciones posteriores: Si el mensaje es destacado, starred cambia a 1. Si es reenviado, se crea un nuevo registro con forwarded incrementado. Si es editado (dentro de los 15 minutos), se actualiza edit_version y edit_timestamp. Si es eliminado, status cambia a 13. Cada una de estas acciones genera su propio rastro de metadatos, inmutable e independiente.

Este recorrido genera un mínimo de 7 timestamps verificables por cada mensaje, cada uno registrado en un campo diferente de la base de datos. La coherencia entre estos timestamps es la prueba más solida de autenticidad que puedo presentar en un juicio.

Que ocurre con los mensajes en grupo

En los grupos de WhatsApp, el recorrido es más complejo porque cada mensaje genera metadatos en los dispositivos de todos los participantes. Un mensaje enviado a un grupo de 50 personas genera:

• 1 registro de envio en el dispositivo del emisor
• 49 registros de entrega (uno por cada receptor)
• Hasta 49 registros de lectura individuales
• Metadatos de grupo actualizados (último mensaje, actividad del participante)

Esto multiplica la superficie forense disponible. Si necesito demostrar que un mensaje fue enviado a un grupo, puedo verificarlo no solo en el dispositivo del emisor sino potencialmente en los 49 dispositivos de los receptores. En la práctica, obtener acceso a uno o dos dispositivos adicionales del grupo suele ser suficiente para la validación cruzada.

Los metadatos de grupo también registran eventos administrativos: quien creo el grupo (y cuando), quien cambio el nombre del grupo, quien anadio o expulso a cada miembro, quien cambio la foto del grupo y quien modifico los permisos de administración. Todos estos eventos se almacenan con timestamps y JIDs en las tablas group_participants y group_participants_history, creando un historial completo de la vida del grupo que ninguna captura de pantalla puede replicar.

El caso especial de los estados (stories)

Los estados de WhatsApp (equivalentes a las stories de Instagram) también generan metadatos que analizo cuando son relevantes. Los estados se almacenan en tablas separadas de msgstore.db y registran: quien público el estado, cuando, que tipo de contenido era, cuantas personas lo vieron y quienes fueron exactamente esas personas (con timestamps individuales de visualizacion).

En un caso de difamacion que perite en 2025, un usuario público un estado injurioso visible para sus 200 contactos y lo elimino a las 3 horas. Los metadatos demostraron que 87 personas lo habian visto antes de la eliminación, que el demandante lo vio a los 12 minutos de su publicacion (confirmado con read_timestamp), y que el autor del estado lo elimino 4 minutos después de recibir un mensaje amenazante del demandante. La cronologia de metadatos reconstruyo toda la secuencia de eventos con precision de minutos.

10 escenarios donde los metadatos son determinantes

En mi práctica profesional, los metadatos de WhatsApp han sido la prueba decisiva en estos escenarios concretos:

1. Cronologia exacta de los hechos

Los timestamps con precision de milisegundos permiten reconstruir una secuencia de eventos con una granularidad que ninguna otra prueba ofrece. En un caso de despido improcedente, los metadatos demostraron que el mensaje de dimision “voluntaria” fue enviado a las 23:47 de un sabado, no en horario laboral como afirmaba la empresa. Adicionalmente, el campo origin revelo que el mensaje fue enviado desde WhatsApp Web, no desde el teléfono del trabajador, lo que planteo serias dudas sobre quien redacto realmente esa dimision.

2. Confirmaciones de lectura como prueba de conocimiento

El campo read_timestamp demuestra que el destinatario abrio la conversacion y tuvo conocimiento del contenido. Esto es especialmente relevante en casos de notificación de incumplimiento contractual, requerimientos previos a demanda, comunicaciones de despido y avisos de vencimiento de plazos. En un caso de responsabilidad contractual, el read_timestamp demostro que el contratista leyo el requerimiento de subsanacion 72 horas antes del plazo limite y no actuo, lo que descarto la alegacion de desconocimiento.

3. Mensajes eliminados que siguen en la base de datos

Cuando un usuario “elimina para todos” un mensaje, WhatsApp cambia el status a 13 y sustituye el texto visible por “Este mensaje fue eliminado”. Pero el registro original, incluyendo timestamps, remitente, tipo de contenido y frecuentemente fragmentos del texto, permanece intacto en msgstore.db. He recuperado mensajes eliminados que fueron clave en procedimientos por certificación de mensajeria instantanea. En un caso de acoso, la parte acosadora habia eliminado 47 mensajes amenazantes. Los 47 seguian en la base de datos con todos sus metadatos.

4. Contenido reenviado vs contenido original

El campo forwarded permite distinguir un mensaje original de uno reenviado, e incluso indica cuantas veces ha sido reenviado (los mensajes con más de 5 reenvios se marcan como “reenviado muchas veces”). Esto es crítico cuando una parte presenta capturas de pantalla como si fueran mensajes directos del interlocutor, pero el análisis forense revela que fueron reenviados desde otra conversacion. He documentado esta discrepancia en tres casos de difamacion donde la supuesta “declaración directa” era en realidad un mensaje reenviado desde un grupo de terceros.

5. Identificación del dispositivo emisor

Los campos origin y la tabla message_link permiten determinar si un mensaje fue enviado desde el teléfono principal, desde WhatsApp Web, desde la aplicación de escritorio o desde un dispositivo vinculado. En un caso de suplantacion de identidad empresarial, los metadatos revelaron que los mensajes supuestamente enviados por el director financiero provenian de WhatsApp Web en un navegador Chrome que se habia vinculado al número corporativo sin autorización. El timestamp de vinculación del dispositivo en linked_devices también quedo registrado.

6. Inferencia de ubicacion

Aunque WhatsApp no registra la geolocalizacion de cada mensaje, los metadatos permiten inferencias de ubicacion: mensajes de tipo media_wa_type = 5 (ubicacion compartida), la correlación de timestamps con conexiones a redes WiFi específicas (accesible en los logs del sistema operativo), y las direcciones IP del servidor registradas por Meta. En un caso de coartada falsa, combine los metadatos de WhatsApp con los registros WiFi del dispositivo para demostrar que el sospechoso no estaba donde declaraba al momento de enviar ciertos mensajes.

7. Dinamicas de grupo

En grupos de WhatsApp, los metadatos incluyen group_participants con roles (admin, superadmin, miembro), fechas de entrada y salida, y que participante envio cada mensaje. He utilizado esta información para demostrar que un empleado fue anadido a un grupo confidencial de la empresa, tuvo acceso durante 14 días y leyo 87 mensajes (verificado con read_timestamp), refutando su alegacion de que “nunca tuvo acceso” a esa información estrategica. El historial de group_participants_history también registro quien lo anadio y cuando.

8. Edicion de mensajes

Desde la actualizacion de 2024 que introdujo la edicion de mensajes, WhatsApp registra los campos edit_version (número de edicion) y edit_timestamp (cuando se edito por última vez). Un mensaje con edit_version mayor que 0 fue modificado después de enviarse. He utilizado este campo en un caso contractual donde una parte afirmaba que las condiciones acordadas por WhatsApp eran X, pero los metadatos demostraron que el mensaje habia sido editado 3 horas después de su envio original. WhatsApp solo permite editar mensajes dentro de los 15 minutos posteriores al envio, pero el campo persiste indefinidamente como registro historico.

9. Suscripciones a canales y comunidades

Los canales de WhatsApp (introducidos en 2023) generan metadatos sobre que canales sigue el usuario, cuando se suscribio, la actividad de lectura y las reacciones a publicaciones. Las comunidades, por su parte, registran la pertenencia del usuario a la comunidad principal y a cada grupo asociado.

En una investigación de radicalizacion, los metadatos de suscripción a canales demostraron que el investigado seguia canales de propaganda desde una fecha concreta, meses antes de los hechos investigados. Estos metadatos se almacenan en tablas específicas de msgstore.db y no son visibles en la interfaz habitual de WhatsApp. Ademas, el número de publicaciones leidas (con sus respectivos timestamps) permitio establecer el nivel de engagement del usuario con el contenido del canal.

Las comunidades de WhatsApp son particularmente interesantes desde la perspectiva forense porque crean una estructura jerarquica de grupos: un grupo de anuncio principal (controlado por administradores) y multiples subgrupos tematicos. Los metadatos registran en que subgrupos participa el usuario, cuando se unio a cada uno, y su actividad en cada subgrupo individualmente. En un caso de filtracion de información corporativa, los metadatos de comunidad demostraron que un empleado se habia unido voluntariamente a un subgrupo de “información confidencial” de la comunidad corporativa, refutando su alegacion de que la información le habia llegado de forma no solicitada.

10. Metadatos de pagos

En los paises donde WhatsApp Pay esta disponible (Indía desde 2020, Brasil desde 2021), los metadatos de transacciones incluyen importes, timestamps, estados de la transaccion y UPI IDs. Aunque en España WhatsApp Pay no esta operativo a fecha de este artículo, los metadatos de pago son relevantes en investigaciones internacionales y en casos donde el investigado utilizo WhatsApp Pay en el extranjero.

Tabla resumen: escenarios y metadatos clave

Retos prácticos de la extracción: lo que no cuentan los manuales

Los manuales de herramientas forenses describen procesos limpios y lineales. La realidad del día a día en mi laboratorio es considerablemente más complicada. Estos son los retos que enfrento con frecuencia y que afectan directamente al análisis de metadatos:

Dispositivos con patrón de desbloqueo desconocido: Si el propietario no proporciona el código de desbloqueo (frecuente en investigaciones penales), la extracción depende de la capacidad de la herramienta forense para explotar vulnerabilidades del chipset. En dispositivos Qualcomm recientes (Snapdragon 8 Gen 2+), Cellebrite puede requerir semanas para obtener acceso mediante su servicio Premium. En iPhones con iOS 17+, la extracción BFU (Before First Unlock) solo proporciona datos parciales. Los metadatos de WhatsApp estan cifrados por la protección del sistema operativo hasta que se desbloquea el dispositivo por primera vez después de un reinicio.

Bases de datos corruptas: Una extracción física incompleta o un corte de energia durante el proceso puede producir una base de datos SQLite parcialmente corrupta. SQLite es robusto pero no inmune. Cuando recibo una base corrupta, utilizo el comando PRAGMA integrity_check para diagnosticar el alcance del daño y sqlite3 corrupt.db ".recover" | sqlite3 recovered.db para recuperar lo máximo posible. He logrado recuperar más del 80% de los metadatos en bases de datos con corrupcion parcial.

WhatsApp actualizado a crypt15: Los backups locales cifrados con crypt15 requieren la clave de cifrado almacenada en los servidores de Google. Sin acceso a la cuenta de Google del usuario (por credenciales o por requerimiento judicial), el backup local cifrado es inaccesible con las herramientas disponibles. La extracción física del dispositivo es la alternativa, pero requiere capacidades avanzadas en dispositivos modernos.

Dispositivos con factory reset: Si el usuario ha realizado un restablecimiento de fabrica antes de entregar el dispositivo, la base de datos local no existe. En estos casos, las alternativas son: backup en Google Drive/iCloud (si no fue eliminado), solicitud de metadatos a Meta (via cooperacion judicial), o en casos extremos, recuperación de datos del almacenamiento flash mediante técnicas de chip-off que pueden rescatar fragmentos de la base de datos anterior al factory reset. La tasa de exito en este último escenario es baja (estimacion del 15-25% de recuperación parcial) pero en casos de alta cuantia o gravedad penal, merece el intento.

Multiples cuentas de WhatsApp en un dispositivo: Desde que Android permite espacios duales y WhatsApp permite una segunda cuenta, un dispositivo puede contener dos bases de datos msgstore.db independientes en diferentes contenedores de usuario. He encontrado casos donde la actividad delictiva se realizaba desde la segunda cuenta mientras la primera (la visible) aparecia limpia. Siempre verifico la existencia de contenedores de usuario multiples y espacios privados.

Detección de manipulación: como descubrir bases de datos alteradas

Una de las funciones más importantes de un perito es detectar si la base de datos ha sido manipulada. Los metadatos son precisamente la herramienta que permite descubrir manipulaciones. Estas son las verificaciones que ejecuto sistematicamente:

Coherencia de secuencias _id: La columna _id de la tabla messages es autoincremental. Si existen huecos en la secuencia (por ejemplo, los IDs saltan de 4.523 a 4.530), puede indicar que se eliminaron registros directamente de la base de datos, no mediante la función “eliminar” de WhatsApp. Un usuario que “elimina para todos” cambia el status a 13 pero el registro conserva su _id original. Un _id faltante es una senial de manipulación a nivel de base de datos.

Coherencia temporal: Si received_timestamp es anterior a timestamp (el mensaje fue “recibido antes de enviado”), hay manipulación. Si read_timestamp es anterior a received_timestamp (fue “leido antes de recibido”), hay manipulación. Verifico que la cadena timestamp menor que receipt_server_timestamp menor que received_timestamp menor que read_timestamp se cumpla para todos los mensajes recibidos.

Integridad de hashes multimedia: Comparo el media_hash almacenado en la tabla con el hash SHA256 real del archivo multimedía en disco. Si no coinciden, el archivo fue sustituido después de registrarse en la base de datos.

Consistencia entre tablas: Un mensaje con media_wa_type = 1 (imagen) debería tener un registro correspondiente en la tabla message_media con sus campos de tamaño, duracion y hash. Si el mensaje existe pero el registro en message_media no, indica manipulación.

Verificación del WAL: Comparo el contenido del archivo WAL con la base principal. Si el WAL contiene registros que difieren de los consolidados en msgstore.db, puede indicar que se modifico la base principal después de una escritura legítima. El WAL es especialmente revelador porque es un archivo temporal que los usuarios que intentan manipular la base de datos suelen desconocer. He descubierto intentos de manipulación donde el usuario modifico msgstore.db con DB Browser pero no toco el WAL, que contenia los registros originales inalterados.

Comparacion cruzada emisor-receptor: La validación más potente. Si tengo acceso a ambos dispositivos, los metadatos de un mensaje deben ser coherentes entre el emisor y el receptor. Un key_id que existe en un dispositivo pero no en el otro, o timestamps con desfases superiores a la latencia de red esperable, son indicadores de manipulación.

Análisis de la página de metadatos SQLite: Cada base de datos SQLite tiene una página interna de metadatos que incluye el número de cambios realizados (change_count), el número de versión del formato (schema_version) y la configuración de autoaspirado. Estas páginas internas son raramente manipuladas porque requieren conocimiento profundo de las estructuras internas de SQLite. El change_count es especialmente útil: si la base tiene 50.000 mensajes pero el change_count es 200.000, las 150.000 operaciones adicionales podrían corresponder a actualizaciones, eliminaciones o, potencialmente, a intentos de modificación.

Análisis del freelist: SQLite mantiene una lista de páginas libres (freelist) que contiene páginas que fueron utilizadas y luego liberadas. Estas páginas pueden contener restos de registros eliminados. Un perito con experiencia puede recuperar fragmentos de datos de las freelist pages, incluyendo metadatos de mensajes que fueron eliminados no solo mediante la función “eliminar” de WhatsApp sino también mediante herramientas de edicion de bases de datos. Esta es la última linea de defensa contra la manipulación: incluso si alguien elimina registros completos de la base de datos, los restos pueden permanecer en el espacio libre.

Consultas SQL que utilizo en mis peritajes

Estas son cinco consultas reales que ejecuto en la mayoria de mis peritajes WhatsApp, con explicación de que buscan y como interpreto los resultados.

Consulta 1: recuperación de mensajes eliminados

SELECT m._id, m.key_remote_jid, m.key_from_me,
       datetime(m.timestamp/1000, 'unixepoch', 'localtime') AS fecha_envio,
       m.data AS texto_residual,
       m.media_wa_type, m.media_size,
       m.status
FROM messages m
WHERE m.status = 13
ORDER BY m.timestamp DESC;

Esta consulta localiza todos los mensajes marcados como eliminados. El campo data frecuentemente conserva fragmentos del texto original. El media_wa_type indica si el mensaje eliminado era texto, imagen, audio u otro tipo. He ejecutado esta consulta en un caso donde el investigado habia eliminado 200+ mensajes y recupere el tipo de contenido y timestamps de cada uno.

Consulta 2: validación de integridad temporal

SELECT m._id, m.key_remote_jid,
       datetime(m.timestamp/1000, 'unixepoch', 'localtime') AS enviado,
       datetime(m.received_timestamp/1000, 'unixepoch', 'localtime') AS recibido,
       datetime(m.receipt_server_timestamp/1000, 'unixepoch', 'localtime') AS servidor,
       datetime(m.read_timestamp/1000, 'unixepoch', 'localtime') AS leido,
       CASE
         WHEN m.received_timestamp > 0 AND m.received_timestamp < m.timestamp
           THEN 'ANOMALIA: recibido antes de enviado'
         WHEN m.read_timestamp > 0 AND m.read_timestamp < m.received_timestamp
           THEN 'ANOMALIA: leido antes de recibido'
         WHEN m.receipt_server_timestamp > 0 AND m.receipt_server_timestamp < m.timestamp
           THEN 'ANOMALIA: servidor antes de envio'
         ELSE 'OK'
       END AS validación
FROM messages m
WHERE m.key_from_me = 0
  AND m.timestamp > 0
ORDER BY m.timestamp DESC;

Esta consulta cruza los cuatro timestamps principales de cada mensaje recibido y marca automáticamente las anomalias. Cualquier resultado distinto de “OK” requiere investigación adicional y se documenta con capturas en el informe pericial.

Consulta 3: timeline de actividad en un periodo concreto

SELECT datetime(m.timestamp/1000, 'unixepoch', 'localtime') AS fecha_hora,
       CASE WHEN m.key_from_me = 1 THEN 'ENVIADO' ELSE 'RECIBIDO' END AS dirección,
       c.display_name AS contacto,
       CASE m.media_wa_type
         WHEN 0 THEN 'Texto'
         WHEN 1 THEN 'Imagen'
         WHEN 2 THEN 'Audio'
         WHEN 3 THEN 'Video'
         WHEN 4 THEN 'Contacto'
         WHEN 5 THEN 'Ubicacion'
         WHEN 7 THEN 'Documento'
         WHEN 8 THEN 'Sticker'
         ELSE 'Otro (' || m.media_wa_type || ')'
       END AS tipo,
       substr(m.data, 1, 100) AS texto_truncado,
       m.status
FROM messages m
LEFT JOIN wa_contacts c ON m.key_remote_jid = c.jid
WHERE m.timestamp BETWEEN 1709078400000 AND 1709164800000
ORDER BY m.timestamp ASC;

Esta consulta genera un timeline completo de toda la actividad de WhatsApp durante un periodo específico (en el ejemplo, las 24 horas del 28 de febrero de 2026). Cruza datos de msgstore.db con wa.db para mostrar nombres de contactos en lugar de JIDs. Es la consulta que más utilizo para presentar cronologias en informes periciales. Requiere tener ambas bases de datos adjuntas (ATTACH DATABASE 'wa.db' AS contacts).

Consulta 4: análisis de reenvios y origen de contenido

SELECT m._id,
       datetime(m.timestamp/1000, 'unixepoch', 'localtime') AS fecha,
       m.key_remote_jid AS conversacion,
       m.forwarded AS veces_reenviado,
       m.media_wa_type AS tipo,
       substr(m.data, 1, 80) AS contenido_parcial,
       CASE
         WHEN m.forwarded = 0 THEN 'ORIGINAL'
         WHEN m.forwarded BETWEEN 1 AND 4 THEN 'Reenviado'
         WHEN m.forwarded >= 5 THEN 'Reenviado muchas veces'
       END AS clasificacion
FROM messages m
WHERE m.forwarded > 0
ORDER BY m.forwarded DESC, m.timestamp DESC;

Esta consulta identifica todos los mensajes reenviados, clasificados por número de reenvios. Un mensaje con forwarded >= 5 muestra el indicador “Reenviado muchas veces” en la interfaz de WhatsApp, lo que indica contenido viral. He utilizado esta consulta para demostrar que una supuesta “confesion directa” era en realidad un mensaje reenviado varias veces desde un grupo ajeno.

Consulta 5: detección de huecos en secuencia de IDs

SELECT m1._id AS id_existente,
       m1._id + 1 AS id_faltante,
       m2._id AS id_siguiente,
       (m2._id - m1._id - 1) AS registros_faltantes,
       datetime(m1.timestamp/1000, 'unixepoch', 'localtime') AS fecha_anterior,
       datetime(m2.timestamp/1000, 'unixepoch', 'localtime') AS fecha_siguiente
FROM messages m1
JOIN messages m2 ON m2._id = (
  SELECT MIN(_id) FROM messages WHERE _id > m1._id
)
WHERE m2._id - m1._id > 1
ORDER BY registros_faltantes DESC;

Esta consulta detecta huecos en la secuencia autoincremental de IDs, lo que puede indicar que se eliminaron registros directamente de la base de datos (no mediante la función “eliminar” de WhatsApp). Si la consulta devuelve resultados con huecos grandes (más de 3-5 registros consecutivos), investigo la causa y la documento como posible indicador de manipulación.

Herramientas profesionales para análisis de metadatos

Estas son las herramientas que utilizo en mis peritajes, con detalle sobre sus capacidades reales y limitaciones que he comprobado en la práctica:

En la práctica, mi flujo de trabajo combina Cellebrite para la extracción, AXIOM para la reconstruccion visual y timeline, y Autopsy con consultas SQL personalizadas para el análisis detallado de metadatos. Las herramientas open source las utilizo como validación independiente: si Cellebrite y Autopsy muestran los mismos datos, la integridad de la extracción esta verificada por doble via.

Los costes de licencia los asumo como inversion del laboratorio y no se repercuten como extra al cliente. Estan incluidos en la tarifa del peritaje.

Mi flujo de trabajo real paso a paso

Para que se entienda como encajan estas herramientas en la práctica, describo el flujo completo que sigo en un peritaje típico de metadatos WhatsApp:

Fase 1 - Extracción (Cellebrite UFED, 30-120 minutos): Conecto el dispositivo a la estacion Cellebrite y selecciono el método de extracción más adecuado según el modelo y versión del SO. Para Android con acceso root o vulnerabilidad explotable, realizo extracción física completa. Para dispositivos sin acceso root, intento extracción lógica avanzada que incluye las bases de datos de WhatsApp. Cellebrite genera un informe de extracción con hashes de cada archivo.

Fase 2 - Verificación (Autopsy, 15-30 minutos): Cargo la imagen forense en Autopsy y verifico que las bases de datos de WhatsApp se extrajeron correctamente. Ejecuto los modulos de WhatsApp de la comunidad de Autopsy para un análisis automático inicial. Comparo los hashes reportados por Cellebrite con los calculados por Autopsy como validación cruzada.

Fase 3 - Análisis automático (AXIOM, 1-3 horas): Importo la imagen en Magnet AXIOM y ejecuto el parsing completo de WhatsApp. AXIOM genera automáticamente un timeline visual de todos los mensajes, una galeria de multimedía con miniaturas, y una reconstruccion de conversaciones con formato similar a la interfaz de WhatsApp. Este timeline automático me da una vision panoramica del caso antes de profundizar.

Fase 4 - Análisis manual de metadatos (DB Browser + SQL, 2-8 horas): Esta es la fase donde realmente se produce el análisis forense. Abro msgstore.db en DB Browser for SQLite y ejecuto mis consultas personalizadas: recuperación de mensajes eliminados, validación de integridad temporal, detección de huecos en secuencias, análisis de reenvios, correlación con wa.db y chatsettings.db. Documento cada consulta y cada resultado con capturas de pantalla.

Fase 5 - Redaccion del informe (3-5 días): Redacto el informe pericial con la estructura judicial requerida, incluyendo todas las tablas de metadatos relevantes, las capturas de las consultas SQL, el timeline reconstruido y mis conclusiones técnicas. Cada afirmacion del informe esta respaldada por una consulta SQL reproducible y un hash que vincula los resultados al archivo original.

Este flujo se adapta a cada caso. Un caso sencillo (un dispositivo, periodo acotado) puede completarse en 3 días. Un caso complejo (multiples dispositivos, análisis de grupos, verificación de integridad exhaustiva) puede requerir 2-3 semanas.

Cifrado E2E vs metadatos locales: que protege y que no

Es importante ser transparente sobre lo que los metadatos pueden y no pueden demostrar. El cifrado de extremo a extremo de WhatsApp, implementado con el protocolo Signal desde 2016, genera confusion frecuente entre abogados y jueces sobre que datos son accesibles.

Lo que el cifrado E2E protege

• Contenido de los mensajes en transito: El texto, imagenes, audios y videos estan cifrados desde el dispositivo emisor hasta el receptor. Ni WhatsApp, ni Meta, ni un atacante man-in-the-middle pueden leer el contenido durante la transmisión
• Contenido en los servidores de WhatsApp: Los mensajes se almacenan temporalmente en los servidores de WhatsApp solo hasta su entrega, y permanecen cifrados E2E
• Claves de cifrado: Las claves privadas se generan y almacenan solo en los dispositivos de los usuarios

Lo que el cifrado E2E NO protege

• Metadatos locales en el dispositivo: Las bases de datos SQLite contienen todos los campos en texto plaño una vez descifrado el archivo crypt15 con la clave local. El cifrado E2E protege el transito, no el almacenamiento local
• Metadatos del servidor: WhatsApp conserva metadatos de conexión (IP, timestamps, contactos frecuentes, grupos) aunque no pueda leer el contenido
• Backups sin cifrado E2E: Si el usuario no activo el cifrado E2E de backups, las copias en Google Drive o iCloud estan accesibles para Google/Apple y mediante requerimiento judicial
• Miniaturas y previsualizaciones: Las miniaturas de imagenes se generan localmente y se almacenan sin cifrado adicional
• Notificaciones push: El contenido de las notificaciones puede quedar registrado en los logs del sistema operativo, fuera del cifrado E2E

La implicacion práctica para el peritaje es clara: si tengo acceso físico al dispositivo (o a un backup descifrado), el cifrado E2E es irrelevante porque los datos ya estan en su forma descifrada en el almacenamiento local. El cifrado protege frente a interceptacion en transito, no frente a análisis forense del dispositivo.

Esta distincion es algo que explico frecuentemente en juicio porque genera confusion. Los abogados de la parte contraria a veces argumentan que “WhatsApp tiene cifrado de extremo a extremo, por tanto los datos del informe pericial no pueden ser autenticos”. Es un argumento técnica y juridicamente incorrecto. El cifrado E2E protege el canal de comunicación entre dos dispositivos, como un tubo opaco por el que pasa la información. Pero una vez que la información llega al destino, se almacena descifrada en las bases de datos locales. Es como argumentar que una carta certificada no puede ser leida porque el sobre estaba sellado: el sello protege durante el transporte, pero una vez que el destinatario abre el sobre, el contenido es accesible.

Cifrado local vs cifrado E2E: no son lo mismo

Hay que distinguir claramente entre dos tipos de cifrado que coexisten en WhatsApp:

1. Cifrado E2E (protocolo Signal): Protege el contenido de los mensajes durante la transmisión entre dispositivos. Utiliza claves efimeras generadas por cada par de dispositivos. Ni WhatsApp ni Meta tienen acceso a las claves privadas. Este cifrado es transparente para el usuario y siempre esta activo.

2. Cifrado local (crypt15): Protege el backup local de la base de datos almacenado en la tarjeta SD o almacenamiento interno. La clave de cifrado se genera a partir de las credenciales de la cuenta de Google asociada y se almacena tanto en el servidor de Google como en el dispositivo. Este cifrado protege contra el acceso casual al archivo de backup, pero no contra una extracción forense con herramientas que acceden a las claves.

3. Cifrado E2E de backup (opcional desde 2021): Si el usuario activa esta opcion, el backup en Google Drive o iCloud se cifra con una clave de 64 digitos o una contraseña elegida por el usuario. En este caso, ni Google, ni Apple, ni Meta pueden descifrar el backup. Solo el usuario tiene la clave. Este es el único escenario donde un backup en la nube es genuinamente inaccesible sin la cooperacion del usuario.

La base de datos que reside en el almacenamiento interno del dispositivo (/data/data/com.whatsapp/databases/msgstore.db) esta protegida por el sandbox del sistema operativo de Android, no por ningun cifrado adicional de WhatsApp. Una extracción física del dispositivo accede directamente a este archivo sin necesidad de descifrado de WhatsApp. Es el sistema operativo el que protege el acceso, no la aplicación.

Metadatos efimeros

WhatsApp genera datos temporales en la memoria RAM del dispositivo que no se escriben en las bases SQLite: estados de “escribiendo…”, indicadores de “en linea”, confirmaciones de entrega transitorias y el estado de las llamadas VoIP en curso. Estos datos existen solo en memoria y desaparecen al cerrar la aplicación o al reiniciar el dispositivo.

Por eso, en casos donde estos datos son relevantes, la velocidad de la extracción forense es crítica. He tenido casos donde llegar 24 horas antes o después marcaba la diferencia entre poder recuperar o no ciertos artefactos volatiles almacenados en RAM o en el WAL.

Comparacion con otras aplicaciones de mensajeria

Los abogados me preguntan frecuentemente como se comparan los metadatos de WhatsApp con los de otras aplicaciones. Esta tabla resume mi experiencia pericial:

La conclusión práctica: WhatsApp es la aplicación de mensajeria con el ecosistema forense más maduro porque es la más usada globalmente (2.000 millones de usuarios) y la que más herramientas comerciales soportan. Signal es la más difícil de peritar por su diseño orientado a la privacidad, con cifrado SQLCipher de la base de datos local y metadatos de servidor mínimos. Telegram es paradojicamente la más fácil en muchos casos porque los chats normales (no secretos) se almacenan en la nube de Telegram sin cifrado E2E, accesibles con las credenciales de la cuenta.

Un dato relevante para abogados: cuando un caso involucra multiples aplicaciones de mensajeria, la correlación temporal entre los metadatos de diferentes apps puede ser extremadamente reveladora. En un caso de fraude empresarial, los metadatos de WhatsApp mostraban que el sospechoso recibio un mensaje a las 14:23 y, 4 minutos después, los metadatos de Telegram registraban el reenvio de información confidencial a un contacto externo. Sin la correlación entre ambas apps, la conexión entre ambos eventos habría sido invisible. Por eso, en peritajes complejos, siempre analizo todas las aplicaciones de mensajeria presentes en el dispositivo, no solo la que el cliente solicita.

Metadatos y la cadena de custodia: el eslabon crítico

De nada sirve un análisis de metadatos brillante si la cadena de custodía tiene defectos. En mi práctica he desarrollado un protocolo específico para metadatos de WhatsApp que va más alla de lo que exige la norma ISO 27037 generica, porque los dispositivos móviles presentan retos que los discos duros no tienen.

El problema de la volatilidad

Un disco duro apagado no cambia. Un smartphone encendido esta cambiando constantemente: recibe mensajes nuevos, actualiza estados, ejecuta backups automáticos, recibe actualizaciones de la aplicación. Cada uno de estos eventos modifica los metadatos de la base de datos. Si no aislamos el dispositivo inmediatamente, los metadatos que queremos analizar pueden verse alterados por actividad posterior.

Mi protocolo de preservación:

1. Modo avión inmediato: En cuanto recibo el dispositivo, activo el modo avión antes de cualquier otra accion. Esto detiene la recepcion de nuevos mensajes, la sincronizacion de backups y las actualizaciones de la aplicación. Documento la hora exacta de activacion del modo avión
2. Documentación fotografica del estado actual: Capturo el estado de la pantalla, las notificaciones visibles, el nivel de bateria y la versión del sistema operativo. Si hay notificaciones de WhatsApp visibles, las fotografio porque contienen datos que podrían desaparecer
3. Jaula de Faraday para transporte: Si necesito transportar el dispositivo al laboratorio, lo introduzco en una bolsa de Faraday que bloquea todas las seniales de radio. Un dispositivo que sale del modo avión accidentalmente y recibe mensajes compromete la cadena de custodia
4. Bloqueo de actualizaciones: Antes de conectar el dispositivo a la estacion de extracción, verifico que no hay actualizaciones de WhatsApp pendientes. Una actualizacion de la app puede modificar la estructura de la base de datos durante la instalación
5. Extracción en entorno controlado: La extracción se realiza en un laboratorio sin cobertura móvil ni WiFi activo, o con el dispositivo en modo avión confirmado. El ordenador de extracción no tiene conexión a internet para evitar que herramientas como Cellebrite envien datos de telemetria

Documentación específica para metadatos

Además de la documentación estandar de la cadena de custodía (actas de entrega, fotografias, hashes), para metadatos de WhatsApp documento:

• Hash SHA256 de cada base de datos individual (msgstore.db, wa.db, chatsettings.db, archivos WAL)
• Tamaño exacto en bytes de cada archivo (un cambio de 1 byte invalida la integridad)
• Fecha de última modificación del archivo según el sistema de ficheros (no confundir con el timestamp del último mensaje)
• Versión de WhatsApp instalada (determina la estructura de la base de datos)
• Número de registros en la tabla messages (permite detectar eliminaciones posteriores)
• Resultado de las consultas de validación de integridad ejecutadas inmediatamente después de la extracción

Toda esta información se incluye en un Anexo Técnico del informe pericial que funciona como “certificado de nacimiento” de los metadatos analizados. Si otro perito quiere verificar mi trabajo, puede replicar el análisis exacto sobre los mismos archivos con los mismos hashes.

Que ocurre cuando la cadena de custodía se rompe

En mi experiencia testificando en juicio, la pregunta más frecuente del abogado de la parte contraria es: “puede usted garantizar que la base de datos no fue modificada entre la entrega del dispositivo y su análisis?”. La respuesta depende integramente de la cadena de custodia.

Si el dispositivo fue entregado directamente por el juzgado con acta notarial, la cadena es solida. Si lo entrego un particular que lo tuvo en su posesion durante días antes de contactarme, la cadena tiene un eslabon debil. En estos casos, refuerzo la validación ejecutando las consultas de integridad con especial atencion a anomalias temporales, y documento explicita y transparentemente la limitación en mi informe. La honestidad sobre las limitaciones de la cadena de custodía refuerza la credibilidad del perito ante el tribunal.

Como documento los metadatos en un informe pericial

La extracción de metadatos por si sola no tiene valor judicial si no se acompana de una metodología rigurosa. En cada peritaje que realizo, sigo un protocolo basado en la norma ISO/IEC 27037 y en las exigencias procesales del sistema judicial español:

Este protocolo es lo que permite que mis informes resistan el escrutinio del perito de la parte contraria durante la contradictoria y las preguntas del tribunal durante la ratificación judicial. En los más de cien peritajes WhatsApp que he realizado, ningun informe mio ha sido invalidado por defectos metodologicos.

5 casos reales donde los metadatos fueron decisivos

Comparto cinco casos reales anonimizados que ilustran el poder de los metadatos en diferentes jurisdicciones y tipos de procedimiento.

Caso 1: el mensaje de dimision que no escribio el trabajador

Un trabajador fue despedido por “abandono de puesto” después de no presentarse a una reunion crítica. La empresa afirmaba haberle comunicado la reunion por WhatsApp. El trabajador negaba haber recibido ningun mensaje.

El abogado del trabajador me contrato como perito WhatsApp para analizar ambos dispositivos. Lo que encontre en los metadatos:

En el teléfono de la empresa (emisor):

• Mensaje enviado: timestamp = 1709121600000 (27 Feb 2026, 09:00:00.000 UTC)
• Estado: status = 6 (leido)
• Tipo: media_wa_type = 0 (texto)

En el teléfono del trabajador (receptor):

• Mensaje recibido: received_timestamp = 1709121602347 (27 Feb 2026, 09:00:02.347 UTC)
• Mensaje leido: read_timestamp = 1709123400000 (27 Feb 2026, 09:30:00.000 UTC)
• Estado: status = 13 (eliminado por el usuario)

Los metadatos demostraron tres hechos que el trabajador no pudo rebatir: el mensaje fue entregado 2.347 milisegundos después de ser enviado, fue leido exactamente 30 minutos después, y el trabajador elimino el mensaje posteriormente. El juzgado declaro el despido procedente.

Caso 2: acoso laboral con mensajes eliminados

Una empleada denuncio acoso laboral por parte de su supervisor. El supervisor habia eliminado todos los mensajes comprometedores usando “eliminar para todos”. La empleada solo tenia capturas de pantalla que la empresa impugnaba.

Analice el teléfono de la empleada y el del supervisor (entregado por orden judicial). En el dispositivo de la empleada, 47 registros con status = 13 correspondian a mensajes eliminados por el supervisor. Aunque el texto ya no era visible en la interfaz, los metadatos mostraban: timestamps que coincidian con las capturas de pantalla de la empleada, key_from_me = 0 (confirmando que los mensajes fueron recibidos, no enviados por ella), y media_wa_type que confirmaba el tipo de contenido de cada mensaje.

Adicionalmente, en el dispositivo del supervisor encontre que los 47 mensajes habian sido eliminados en un intervalo de 12 minutos a las 23:15 del día posterior a la denuncia formal. Los _id de los registros eliminados estaban intactos, demostrando que la eliminación fue mediante la función “eliminar para todos” (que cambia status a 13) y no mediante manipulación directa de la base de datos (que habría dejado huecos en la secuencia).

Resultado: La empresa fue condenada por acoso laboral con indemnizacion por daños morales. Los metadatos transformaron capturas impugnables en evidencia corroborada. El juez destaco en la sentencia que “la prueba pericial informática acredita no solo la existencia de los mensajes sino su eliminación deliberada posterior a la denuncia, lo que refuerza la credibilidad del testimonio de la demandante”.

Caso 3: estafa BEC detectada por metadatos de dispositivo

Una PYME recibio un mensaje de WhatsApp supuestamente de su proveedor principal solicitando un cambio de cuenta bancaria para una factura de 85.000 EUR. El mensaje parecia legítimo. La empresa realizo la transferencia.

Cuando me contrataron para peritar el caso, los metadatos revelaron: el campo origin indicaba que el mensaje fue enviado desde WhatsApp Web (no desde un teléfono), el JID del remitente correspondía a un número prepago activado 48 horas antes del mensaje (verificado con wa.db y el registro de operador), y el push_name del contacto era “Logistica MKN” pero el número no figuraba en ningun directorio empresarial del proveedor real.

La comparación con conversaciones anteriores con el proveedor real mostro un JID completamente diferente, timestamps de actividad que se remontaban 3 años atras y un push_name distinto. El peritaje demostro la suplantacion y contribuyo a la investigación policial que identifico al autor.

Lo que hizo este caso especialmente revelador fue la comparación de metadatos entre las conversaciones historicas con el proveedor real (acumuladas durante 3 años) y la conversacion fraudulenta. Los patrones de actividad eran completamente diferentes: el proveedor real enviaba mensajes en horario comercial español (09:00-18:00), usaba WhatsApp Business con catálogo de productos, y tenia un patrón de respuesta de 30-60 minutos. El impostor enviaba mensajes en horario nocturno español (que correspondía a horario diurno de otra zona horaria), usaba WhatsApp personal sin perfil Business, y respondía en menos de 2 minutos. Estos patrones de comportamiento, extraidos exclusivamente de metadatos sin leer el contenido de los mensajes, fueron suficientes para que el juez instructor considerase acreditada la suplantacion.

Caso 4: custodía de menores y confirmaciones de lectura

En un procedimiento de familia, un progenitor afirmaba no haber recibido las comunicaciones del otro sobre cambios en el régimen de visitas. El juzgado me encargo un peritaje de los metadatos de WhatsApp de ambas partes.

Los campos read_timestamp demostraron que los 12 mensajes sobre cambios de horario habian sido leidos por el progenitor demandado, con lecturas documentadas entre 1 y 47 minutos después de la recepcion. Ademas, el campo starred = 1 en tres de esos mensajes indicaba que el demandado habia marcado como destacados precisamente los mensajes que negaba haber recibido.

La tabla chatsettings.db mostro que la conversacion con el otro progenitor no estaba archivada ni silenciada, descartando la alegacion de que los mensajes “se perdieron entre otras conversaciones”.

Adicionalmente, el análisis de wa.db revelo que el contacto del otro progenitor tenia display_name personalizado (no era solo el número), lo que indicaba una relación activa y reconocida en la agenda del demandado. El push_name del contacto (nombre de perfil de WhatsApp) también coincidio con el nombre real del otro progenitor, descartando la improbable posibilidad de una confusion de contactos.

Resultado: El juzgado de familia modifico el régimen de visitas con medidas específicas de comunicación documentada, citando el informe pericial como prueba de la falta de colaboración del progenitor demandado.

Caso 5: grupo de WhatsApp como prueba de confabulacion

En una investigación por competencia desleal, mi cliente sospechaba que tres exempleados habian coordinado su salida simultanea para fundar una empresa competidora, llevandose información confidencial. Los exempleados negaban haberse coordinado y afirmaban que la coincidencia fue casual.

Analice el teléfono corporativo de uno de los exempleados (que fue devuelto a la empresa al cesar) y solicite judicialmente la extracción de los otros dos dispositivos. Los metadatos de grupo en msgstore.db revelaron:

• Existia un grupo de WhatsApp creado 47 días antes de las tres dimisiones, con los tres exempleados como únicos miembros
• El group_participants_history mostraba que el grupo fue creado por el exempleado A a las 23:15 de un domingo
• Se intercambiaron 342 mensajes en ese grupo durante 47 días, con actividad predominante en horario nocturno y fines de semana (fuera del horario laboral)
• Los media_wa_type incluian 23 documentos (tipo 7), cuyo media_name referenciaba nombres de archivos internos de la empresa (“plan-comercial-2026.pdf”, “cartera-clientes-Q1.xlsx”)
• Los hashes de los documentos compartidos coincidian con los hashes de archivos almacenados en el servidor corporativo

El timeline de metadatos demostro la planificación coordinada durante 47 días y la extracción de documentos confidenciales. La empresa obtuvo una sentencia favorable por competencia desleal y vulneración del deber de buena fe contractual.

Caso 6: contrato verbal confirmado por timeline de metadatos

Dos empresas discrepaban sobre los terminos de un acuerdo comercial. No existia contrato escrito pero si una conversacion de WhatsApp donde supuestamente se habian acordado condiciones específicas. Una parte afirmaba que las condiciones eran las del mensaje original, la otra que habian sido modificadas después.

El análisis de metadatos revelo que el mensaje clave tenia edit_version = 2, lo que significaba que habia sido editado dos veces después de su envio original. El edit_timestamp indicaba que la última edicion se realizo 14 minutos después del envio, dentro del plazo de 15 minutos que permite WhatsApp. Sin embargo, el campo timestamp original mostraba que el primer envio fue a las 10:23 y el edit_timestamp a las 10:37.

Cruce esta información con los read_timestamp del dispositivo receptor: el destinatario habia leido el mensaje por primera vez a las 10:25, es decir, antes de la edicion. Esto significaba que el destinatario leyo la versión original, no la editada. Los metadatos establecieron que existieron dos versiones del mensaje y que las condiciones que el destinatario acepto eran las de la primera versión, no las de la versión editada.

Errores frecuentes de peritos inexpertos

A lo largo de mi carrera he revisado informes periciales de otros profesionales, tanto como perito de parte contraria como en auditorias técnicas. Estos son los errores más comunes que encuentro y que pueden invalidar un informe ante el tribunal:

Error 1: analizar solo msgstore.db. Muchos peritos extraen unicamente la base de datos principal y omiten wa.db y chatsettings.db. Sin wa.db, los JIDs quedan como números anónimos sin correlación con identidades reales. Sin chatsettings.db, se pierden datos de configuración que pueden ser determinantes (chats archivados, silenciados, mensajes temporales). En un peritaje contradictoria, seniale que el informe de la otra parte no habia extraido chatsettings.db, omitiendo que el demandado habia activado mensajes temporales 24 horas después de los hechos investigados.

Error 2: conversion erronea de timestamps iOS. Como explique en la seccion de iOS, los timestamps de ChatStorage.sqlite usan el epoch de Core Data de Apple (1 enero 2001), no el epoch UNIX (1 enero 1970). La diferencia son 978.307.200 segundos (31 años). He visto informes con cronologias desplazadas 31 años por esta conversion incorrecta, un error que destruye la credibilidad del perito.

Error 3: no verificar integridad antes de analizar. Algunos peritos se lanzan directamente al análisis de contenido sin ejecutar las validaciones de coherencia temporal y secuencial. Si la base de datos fue manipulada y el perito no lo detecta, todo su informe se construye sobre datos potencialmente falsos. Siempre ejecuto las consultas de validación como primer paso, antes de cualquier análisis de contenido.

Error 4: ignorar el archivo WAL. El Write-Ahead Log puede contener datos críticos que no estan en la base principal, incluyendo mensajes eliminados muy recientemente. He encontrado mensajes determinantes en archivos WAL que el perito anterior habia descartado.

Error 5: presentar capturas de la interfaz en lugar de consultas SQL. Un informe pericial que presenta capturas de pantalla de la aplicación WhatsApp tiene un valor probatorio muy inferior a uno que presenta los resultados de consultas SQL ejecutadas directamente sobre la base de datos. Las capturas de la interfaz son tan manipulables como las capturas de cualquier otra aplicación. Las consultas SQL sobre la base de datos extraida con cadena de custodía son verificables y reproducibles.

Error 6: no calcular hashes de las bases de datos. Sin hashes SHA256 de los archivos originales registrados en el acta de extracción, el perito de la parte contraria puede cuestionar la integridad de todo el análisis alegando que los archivos fueron modificados después de la extracción.

Error 7: confundir “eliminado para mi” con “eliminado para todos”. Ambas acciones producen efectos diferentes en los metadatos. “Eliminar para mi” solo afecta al dispositivo local del usuario que ejecuta la accion, mientras que “eliminar para todos” envia una senial al dispositivo del interlocutor para que también oculte el mensaje. En el dispositivo de la parte contraria, los metadatos pueden diferir según que tipo de eliminación se ejecuto. Un perito que no distingue entre ambos mecanismos puede llegar a conclusiones erroneas sobre el estado de la conversacion.

Error 8: no considerar la sincronizacion multi-dispositivo. Desde que WhatsApp implemento la sincronizacion multi-dispositivo en 2021, un mensaje puede tener diferentes metadatos en el teléfono principal y en los dispositivos vinculados (WhatsApp Web, escritorio, tablets). El received_timestamp puede diferir entre dispositivos por segundos o incluso minutos dependiendo de la conectividad de cada uno. Un perito que analiza solo un dispositivo y encuentra una discrepancia temporal con el dispositivo de la parte contraria podría gritar “manipulación” cuando en realidad la diferencia se debe a la sincronizacion multi-dispositivo. Siempre verifico cuantos dispositivos vinculados tenia el usuario consultando la tabla linked_devices.

Error 9: presentar metadatos sin contexto técnico. Un timestamp aislado no significa nada para un juez. El perito debe contextualizar cada metadato: explicar que significa UNIX epoch, por que los milisegundos son relevantes, que implica cada valor del campo status, como se interpretan las relaciones entre tablas. Un informe pericial que presenta tablas de números sin explicación accesible es un informe que pierde su impacto probatorio.

Preguntas frecuentes

Los metadatos de WhatsApp se pueden falsificar?

Falsificar metadatos individuales es posible con herramientas de edicion SQLite como DB Browser, pero falsificar un conjunto coherente de metadatos que resista un análisis forense competente es extremadamente difícil. Las bases de datos de WhatsApp mantienen relaciones de integridad entre tablas: foreign keys, secuencias _id autoincrementales, timestamps correlaciónados entre messages, receipts, message_media y message_thumbnails. Cualquier manipulación rompe alguna de estas relaciones y es detectable. En mis peritajes, verifico sistematicamente la coherencia de al menos 12 campos cruzados entre 4 tablas diferentes para validar la autenticidad. La comparación cruzada con el backup en la nube o con el dispositivo de la otra parte hace practicamente imposible una falsificación exitosa que pase inadvertida ante un perito cualificado.

WhatsApp guarda metadatos de mensajes eliminados?

Si. Cuando un usuario elimina un mensaje (tanto “eliminar para mi” como “eliminar para todos”), WhatsApp cambia el campo status en la tabla messages de msgstore.db pero no elimina el registro de la base de datos. El timestamp original, el remitente, el tipo de contenido (media_wa_type), los campos de medía y en algunos casos fragmentos del texto permanecen accesibles mediante consultas SQL directas. Según documentación técnica de Oxygen Forensics, incluso las miniaturas de imagenes eliminadas persisten en .Thumbs y en la tabla message_thumbnails. En mis peritajes, he documentado tasas de recuperación de metadatos de mensajes eliminados superiores al 95%.

Se necesita root o jailbreak para extraer metadatos de WhatsApp?

Depende del dispositivo y la versión del sistema operativo. En Android 7 e inferior, herramientas como WhatsApp Key/DB Extractor pueden obtener la base de datos sin root mediante un backup ADB. En Android 8 y superior, se requiere acceso privilegiado (root) o herramientas comerciales como Cellebrite que explotan vulnerabilidades a nivel de chipset para extracción física. En iOS, sin jailbreak solo se puede acceder a un backup lógico de iTunes (que puede incluir las bases de datos de WhatsApp si el backup esta descifrado). Los backups en Google Drive (Android) o iCloud (iOS) son una alternativa si se dispone de las credenciales de la cuenta o de autorización judicial.

Para ser más específico sobre las capacidades actuales por plataforma:

• Android con Qualcomm Snapdragon: Cellebrite y MSAB soportan extracción física en la mayoria de chipsets hasta Snapdragon 8 Gen 2. Los modelos más recientes pueden requerir servicio Premium de Cellebrite (envio del dispositivo a sus laboratorios en Israel)
• Android con MediaTek: Amplio soporte de extracción física mediante el protocolo BROM (Boot ROM) nativo de MediaTek
• Android con Samsung Exynos: Soporte variable, los modelos con Knox pueden ser más resistentes
• iPhone con chip A14 o anterior: Extracción AFU (After First Unlock) posible con checkm8 exploit
• iPhone con chip A15 o posterior: Requiere herramientas actualizadas, soporte limitado en algunos modelos
• Tablets y dispositivos vinculados: Extracción lógica suele ser suficiente ya que WhatsApp replica las bases de datos en todos los dispositivos vinculados

Cuanto tiempo tarda un análisis forense de metadatos WhatsApp?

Depende de la complejidad del caso. Una extracción y análisis básico (un dispositivo, periodo de tiempo acotado, un interlocutor) puede completarse en 3-5 días hábiles. Un caso complejo (dos dispositivos, multiples interlocutores, análisis de grupos, verificación de integridad, comparación cruzada con backup cloud) puede requerir 10-15 días hábiles. El informe pericial suele representar un 40% del tiempo total, porque cada afirmacion técnica debe estar respaldada por la consulta SQL que la sustenta y la captura de pantalla que la documenta.

Los metadatos de WhatsApp Business son diferentes?

WhatsApp Business genera metadatos adicionales significativos respecto a WhatsApp personal. Las tablas adicionales incluyen:

• Etiquetas de contacto (labels): Categorias personalizadas que la empresa asigna a cada contacto (ej: “Cliente potencial”, “Pedido pendiente”, “Reclamación”). Revelan la relación comercial con cada contacto
• Catalogo de productos: Historial de productos publicados con precios, descripciones y fechas de creacion/modificación
• Mensajes automatizados: Templates de mensajes de bienvenida, ausencia y respuestas rápidas, con timestamps de configuración y estadisticas de envio
• Estadisticas de mensajeria: Número de mensajes enviados, entregados, leidos y respondidos por contacto y por periodo temporal
• Horario de atencion: Configuración de horarios comerciales con historial de cambios

En un caso de publicidad engañosa, los metadatos de WhatsApp Business demostraron que la empresa habia enviado mensajes promocionales automatizados a 1.200 contactos sin consentimiento expreso, dato relevante para una sanción RGPD. Las etiquetas de contacto revelaron que la empresa tenia una categoría “Base datos comprada” que asignaba a contactos que nunca habian interactuado con la empresa, evidencia directa de spam comercial.

En otro caso de incumplimiento contractual, los metadatos de respuestas rápidas demostraron que la empresa tenia un template predefinido que prometia “entrega en 24 horas” como respuesta automática a pedidos, cuando la capacidad real de entrega era de 7-10 días. El timestamp de creacion del template y el número de veces que fue utilizado (registrado en las estadisticas de WhatsApp Business) fueron pruebas determinantes.

Que diferencia hay entre metadatos locales y metadatos de servidor?

Los metadatos locales (los que estan en el dispositivo) son mucho más completos que los que Meta almacena en sus servidores. Localmente se registran timestamps de envio, recepcion, lectura y reproducción, contenido residual de mensajes eliminados, hashes de archivos y configuración de chats. Meta solo retiene metadatos de conexión (IPs, timestamps de actividad), información de registro y datos de grupos. La ventaja de los metadatos de servidor es que son independientes del dispositivo y no pueden ser manipulados por el usuario. La desventaja es que requieren cooperacion judicial internacional para obtenerlos y son menos detallados.

Como afecta la función de “mensajes temporales” a los metadatos?

Cuando un usuario activa mensajes temporales en un chat, los mensajes se eliminan automáticamente después del periodo configurado (24 horas, 7 días o 90 días). Sin embargo, hay varios matices forenses importantes. La fecha de activacion de los mensajes temporales queda registrada en chatsettings.db con timestamp preciso, lo que permite demostrar cuando el usuario tomo la decisión de activar esta función. Los mensajes que ya se entregaron y leyeron antes de la eliminación automática conservan sus metadatos de read_timestamp y received_timestamp en el archivo WAL y en los backups anteriores, aunque el contenido se borre de la base principal. Ademas, los backups diarios automáticos anteriores a la activacion de mensajes temporales pueden contener los mensajes completos sin modificar. He utilizado esta combinacion de datos para demostrar que un directivo activo los mensajes temporales selectivamente en una conversacion comprometedora 48 horas después de recibir una carta de despido, lo que el tribunal interpreto como un indicio de destrucción deliberada de pruebas.

Pueden los metadatos determinar la ubicacion geografica del emisor?

No directamente. WhatsApp no registra la geolocalizacion de cada mensaje en los metadatos locales. Sin embargo, hay métodos indirectos: mensajes de tipo ubicacion compartida (media_wa_type = 5) contienen coordenadas exactas, las direcciones IP registradas por Meta pueden geolocalizarse a nivel de ciudad, y los logs del sistema operativo (fuera de WhatsApp) registran conexiones WiFi y datos de celda que permiten triangulacion. En un peritaje completo, cruzo los timestamps de WhatsApp con los registros de conectividad del dispositivo para establecer ubicaciones aproximadas.

Los metadatos de una videollamada de WhatsApp se registran?

Si. Las llamadas y videollamadas de WhatsApp generan registros en la tabla call_log de msgstore.db que incluyen: timestamp de inicio y fin de la llamada, duracion en segundos, JID del interlocutor, tipo de llamada (voz o video), si fue contestada o pérdida, y si fue individual o grupal. Estos metadatos han sido relevantes en casos donde una parte afirmaba no haber tenido contacto con otra persona en un periodo determinado.

Cual es la validez legal de los metadatos como prueba en España?

Los metadatos de WhatsApp extraidos con cadena de custodía y metodología forense documentada (ISO 27037) son admisibles como prueba pericial en todas las jurisdicciones españolas: civil, penal, laboral y contencioso-administrativa. La STS 629/2025 y la STS 603/2025 del Tribunal Supremo han reforzado específicamente el valor de los metadatos como elemento de autenticación cuando la parte contraria impugna conversaciones de WhatsApp. El artículo 588 bis de la LECrim regula la obtención de comunicaciones electrónicas con autorización judicial. En la jurisdicción laboral, los Tribunales Superiores de Justicia admiten sistematicamente informes periciales de metadatos WhatsApp en procedimientos de despido, acoso y vulneración de derechos fundamentales.

Que pasa si el teléfono esta roto o no enciende?

Es una situación más frecuente de lo que parece, especialmente en casos de violencia domestica o empresarial donde el dispositivo ha sido danado deliberadamente. Las opciones forenses dependen del tipo de daño:

Daño de pantalla (pantalla rota pero dispositivo funcional): La extracción forense es posible sin necesidad de interacción con la pantalla. Cellebrite y AXIOM pueden comunicarse con el dispositivo a traves de USB. Si se conoce el código de desbloqueo, se puede inyectar mediante ADB en Android o mediante herramientas especializadas en iOS. En estos casos, los metadatos son completamente accesibles.

Daño lógico (dispositivo no arranca pero hardware intacto): Herramientas de extracción física como Cellebrite pueden acceder directamente al chip de memoria mediante extracción JTAG (Joint Test Action Group) que se conecta a los pines de testeo de la placa base, o mediante extracción chip-off donde se desuelda fisicamente el chip de memoria flash y se lee con un lector especializado.

Daño físico severo (placa danada, chip parcialmente destruido): Existen laboratorios de recuperación de datos especializados con salas limpias que pueden reconstruir parcialmente las bases de datos SQLite a partir de chips danados. El coste es significativamente mayor (puede superar los 2.000-5.000 EUR solo por la recuperación), pero en casos con cuantias elevadas o implicaciones penales graves, merece la inversion.

Dispositivo destruido completamente: Si el dispositivo es irrecuperable, la alternativa es el backup en Google Drive o iCloud (solicitado mediante requerimiento judicial), los metadatos del servidor de Meta (via comision rogatoria), y los metadatos presentes en los dispositivos de los interlocutores. Incluso sin el dispositivo original, es posible reconstruir una parte significativa de la actividad de WhatsApp del investigado a partir de las bases de datos de las personas con las que se comunicaba.

Cuanto cuesta un peritaje forense de metadatos WhatsApp?

El coste depende de la complejidad del caso y del número de dispositivos a analizar. Para orientar a los abogados y clientes, estas son las franjas habituales en mi servicio:

El informe pericial completo y la ratificación en juicio estan incluidos en todas las tarifas. Los costes de licencia de herramientas forenses (Cellebrite, AXIOM) los asumo como inversion del laboratorio. Ofrezco una consulta gratuita por videollamada para valorar el caso antes de presupuestar. En esa primera consulta evaluo la viabilidad técnica, el alcance necesario y proporciono un presupuesto cerrado sin compromiso.

Pueden los metadatos demostrar que alguien mintio sobre no haber leido un mensaje?

Si, es uno de los usos más directos y más impactantes de los metadatos en juicio. El campo read_timestamp registra el momento exacto en que el destinatario abrio la conversacion, independientemente de que tuviera desactivadas las confirmaciones de lectura (ticks azules).

Este es un punto técnico que muchas personas no comprenden: las confirmaciones de lectura son una función de la interfaz visual de WhatsApp. El destinatario puede desactivar que el emisor vea los ticks azules en la configuración de privacidad. Pero el read_timestamp se registra igualmente en la base de datos local del dispositivo receptor, porque es un metadato interno que WhatsApp utiliza para gestionar las notificaciones y el orden de las conversaciones. Es invisible para el usuario pero perfectamente visible para un perito.

Si tengo acceso al dispositivo del destinatario (por orden judicial, entrega voluntaria o como parte de un proceso pericial contradictorio), puedo demostrar exactamente cuando leyo cada mensaje, aunque los ticks azules no fueran visibles para el emisor. He utilizado este dato en más de veinte procedimientos donde una parte afirmaba no haber recibido o no haber leido comunicaciones relevantes.

Incluso cuando las confirmaciones estan desactivadas, hay otro metadato revelador: si el destinatario respondio a algun mensaje posterior en la misma conversacion, su read_timestamp para ese mensaje necesariamente demuestra que abrio la conversacion y, por tanto, tuvo acceso visual a todos los mensajes no leidos que le precedian en la pantalla. Este argumento técnico ha sido aceptado por varios juzgados españoles como prueba indirecta de lectura.

El futuro de los metadatos forenses en WhatsApp

Los metadatos de WhatsApp evolucionan con cada actualizacion de la aplicación, y como perito necesito mantenerme al día de estos cambios. Estas son las tendencias que observo y que afectaran al análisis forense en los próximos meses:

Edicion de mensajes expandida: Desde que WhatsApp introdujo la edicion de mensajes en 2024, el campo edit_version se ha convertido en un artefacto forense de primera linea. Es probable que Meta extienda el plazo de edicion (actualmente 15 minutos) o permita multiples ediciones con historial de versiones. Cada cambio ampliara la superficie de metadatos disponibles para el perito.

Mensajes de voz transcripcion: WhatsApp ha comenzado a desplegar la transcripcion automática de mensajes de voz. Esta funcionalidad genera metadatos adicionales: el texto de la transcripcion, el idioma detectado, y el nivel de confianza de la transcripcion. Estos datos se almacenan en tablas adicionales de msgstore.db y pueden contener fragmentos de información incluso de audios eliminados.

Canales y comunidades: La expansion de canales y comunidades de WhatsApp genera nuevas tablas de metadatos con información sobre suscripciones, roles de administración, permisos de publicacion y metricas de lectura. En investigaciones de difusion de desinformacion o contenido ilícito, estos metadatos serán cada vez más relevantes.

Inteligencia artificial integrada: Meta esta integrando Meta AI directamente en WhatsApp. Las interacciones con la IA generan metadatos propios: consultas realizadas, respuestas recibidas, imagenes generadas. Estos datos amplian el perfil de actividad del usuario y pueden ser relevantes en ciertos tipos de investigación.

Cifrado E2E de backups por defecto: Meta ha anunciado planes para habilitar el cifrado E2E de backups por defecto en futuras versiones. Cuando esto ocurra, el acceso a backups en Google Drive e iCloud mediante requerimiento judicial será significativamente más difícil, ya que ni Google ni Apple podrán descifrar el backup sin la clave del usuario. Esto refuerza aun más la importancia de la extracción forense del dispositivo físico como fuente primaria de metadatos.

Registro de actividad de IA: A medida que WhatsApp integra funcionalidades de inteligencia artificial (resumenes de conversaciones, respuestas sugeridas, busqueda inteligente), la base de datos local acumulara nuevas tablas con metadatos sobre las interacciones del usuario con estas funcionalidades. Un usuario que pide a Meta AI que “resuma la conversacion con X” genera un registro que revela su interes específico en esa conversacion, información contextual potencialmente relevante en investigaciones.

Regulación europea e-Evidence: El Reglamento europeo e-Evidence (en vigor desde agosto 2023, con periodo de aplicación hasta agosto 2026) establecera un mecanismo directo para que los jueces de un estado miembro de la UE soliciten datos electrónicos a prestadores de servicios de otro estado miembro o de terceros paises con representante legal en la UE. Meta tiene representante legal en Irlanda, lo que significa que, una vez plenamente aplicable, los jueces españoles podrán solicitar metadatos directamente sin necesidad de comision rogatoria via EEUU. Esto reducira drasticamente los plazos de obtención de metadatos del servidor.

Para abogados que estan planificando estrategias de litigio a medio plazo, mi recomendación es preservar los dispositivos lo antes posible. Los metadatos que existen hoy en un dispositivo pueden desaparecer manana si el usuario actualiza la aplicación y WhatsApp modifica la estructura de la base de datos, algo que ocurre con cada actualizacion mayor.

Enlaces relacionados

• Perito WhatsApp: servicio completo de análisis forense
• Análisis forense WhatsApp: validez judicial en 2025
• Certificación de mensajeria instantanea
• WhatsApp forense: glosario técnico
• Cadena de custodía digital: guía ISO 27037
• Como presentar WhatsApp como prueba judicial

Glosario rápido de terminos técnicos

Para facilitar la lectura de este artículo y de los informes periciales que elaboro, incluyo definiciones breves de los terminos técnicos más utilizados:

Referencias y fuentes

1. WhatsApp Security Whitepaper - cifrado extremo a extremo - Meta Platforms, 2024
2. Forensic Analysis of WhatsApp Messenger on Android Smartphones - Digital Investigation, Anglaño (2014)
3. WhatsApp Forensics: Decryption of Encrypted Databases on Non-Rooted Android Devices - Forensic Science International: Digital Investigation, Thakur (2018)
4. Información que WhatsApp puede proporcionar en respuesta a solicitudes legales - WhatsApp FAQ
5. INCIBE - Guía para la gestión de incidentes de seguridad - INCIBE-CERT
6. ISO/IEC 27037:2012 - Directrices para la identificación, recopilación, adquisición y preservación de evidencia digital - ISO
7. Oxygen Forensic Detective - WhatsApp artifacts analysis - Oxygen Forensics
8. Signal Protocol: Technical Documentation - Signal Foundation
9. STS 629/2025 - Admisibilidad de conversaciones WhatsApp como prueba - Tribunal Supremo, Sala Segunda
10. Ley de Enjuiciamiento Criminal, artículo 588 bis - BOE
11. SQLite Write-Ahead Logging - SQLite Documentation
12. WhatsApp Multi-Device Architecture - Meta Engineering Blog, 2021
13. NIST SP 800-101 Rev. 1 - Guidelines on Mobile Device Forensics - National Institute of Standards and Technology
14. Cellebrite UFED - Mobile forensic solutions - Cellebrite
15. Magnet AXIOM - Digital forensics platform - Magnet Forensics
16. WhatsApp Business API Documentation - Meta for Developers
17. Reglamento General de Protección de Datos (RGPD) - Diario Oficial de la Union Europea