Recuperar una base de datos de WhatsApp dañada (msgstore.db)

Una base de datos de WhatsApp es un archivo SQLite corriente, así que es una matriz plana de páginas de tamaño fijo (el valor por defecto de SQLite suele ser 4 KB). Los primeros 16 bytes son la cadena mágica SQLite format 3\0; el resto de la página 1 contiene la cabecera del archivo y el sqlite_schema, que enumera cada tabla. Cada tabla es un árbol-b (b-tree): las páginas interiores llevan punteros que descienden hacia las páginas hoja, y las páginas hoja contienen tus filas reales.

Las tablas que importan para el historial de chats son predecibles. Las versiones modernas de WhatsApp guardan los mensajes en una tabla message (las versiones antiguas usaban messages), la lista de conversaciones en chat y los identificadores de número de teléfono/grupo en jid. El texto del mensaje vive en una columna de texto (text_data en el esquema moderno, data en el antiguo), y cada fila lleva una marca de tiempo en milisegundos de época Unix. Tablas de apoyo como message_media, message_thumbnail, message_quoted y call_log completan el conjunto. Y algo clave: las fotos, los vídeos y las notas de voz en sí no están en la base de datos; son archivos aparte en la carpeta Media de WhatsApp, y la base de datos solo guarda sus rutas de archivo y pequeñas miniaturas.

WhatsApp ejecuta la base de datos en modo WAL (write-ahead logging), así que en el teléfono verás dos archivos hermanos junto a ella: msgstore.db-wal y msgstore.db-shm. Los mensajes recientes ya confirmados pueden vivir solo en el archivo -wal hasta que se consolidan (checkpoint) en el .db principal. Si tienes ese archivo lateral, guárdalo: sus frames confirmados son las filas más nuevas.

SQLite lanza SQLITE_CORRUPT (código de resultado 11) —que aparece como "database disk image is malformed"— en cuanto sigue un puntero y aterriza en algo que no es una página b-tree válida: una página en ceros, un desplazamiento de celda erróneo, un recuento de páginas que no cuadra con el tamaño del archivo. Se detiene en la primera inconsistencia, por eso una sola página interior dañada tumba el archivo entero mientras las páginas hoja intactas que hay detrás siguen guardando tus mensajes. Un error emparentado, "file is not a database," significa que la cadena mágica de 16 bytes de la cabecera quedó alterada; las páginas que hay detrás suelen estar bien.

El daño casi siempre viene de una escritura interrumpida. Sacar el msgstore.db del teléfono por USB o con un gestor de archivos mientras WhatsApp todavía lo tiene abierto puede copiar un archivo roto, con el checkpoint a medias; un byte volteado en una tarjeta SD que falla o en una sincronización, o un dispositivo que se quedó sin batería a mitad de escritura, hacen lo mismo. Una copia truncada simplemente pierde las páginas que estaban al final.

Hay una trampa que pilla a casi todo el mundo primero: el archivo de la carpeta de copias de seguridad de WhatsApp no es una base de datos normal. Las copias se llaman msgstore.db.crypt14 o msgstore.db.crypt15 y están cifradas con AES-GCM (la clave está en /data/data/com.whatsapp/files/key o, para crypt15, detrás de tu contraseña de copia de seguridad cifrada de extremo a extremo). Un archivo .crypt14/.crypt15 se lee como ruido de alta entropía: no tiene cabecera SQLite alguna, así que la recuperación por páginas no puede tocarlo hasta que se descifra y vuelve a ser un msgstore.db normal. Esta herramienta trabaja sobre la base de datos ya descifrada, no sobre la copia cifrada.

En lugar de fiarse de los punteros rotos, la herramienta lee el archivo página a página: reconstruye el esquema, recorre el b-tree de cada tabla y, para todo lo que la cadena de punteros ya no puede alcanzar, recurre a un barrido de páginas en crudo que decodifica los registros autodescriptivos directamente desde las páginas hoja. Reconstruye los b-trees desde cero alrededor de las filas que encuentra y las escribe en una base de datos nueva que te descargas: la misma estrategia que el propio comando .recover de SQLite. Las filas que no se pueden atribuir a una tabla conocida van a una tabla lost_and_found en vez de descartarse, y si aportas el archivo lateral msgstore.db-wal, sus frames confirmados se superponen primero para que el resultado refleje tus últimos mensajes confirmados, no solo el último checkpoint.

Los límites honestos: los bytes que se sobrescribieron físicamente o quedaron truncados al final del archivo se han perdido, y ninguna herramienta puede inventarlos. Los valores vuelven con su clase de almacenamiento en disco, así que la afinidad de una columna puede cambiar. Como el barrido también lee las páginas de la lista libre (freelist) y las no compactadas, algunos mensajes previamente borrados pueden reaparecer. Los datos recuperados siempre son sospechosos —lo dicen los propios documentos de SQLite—, así que verifícalos contra una fuente fiable antes de confiar en ellos. Y los archivos multimedia siguen en la carpeta Media aparte; la base de datos te da el texto y las referencias, no las imágenes en sí.

¿Por qué hacer esto en el navegador? La base de datos de un chat es el peor archivo que puedes entregar a un servidor que no controlas: puede contener cada mensaje, número de teléfono y marca de tiempo que hayas intercambiado. Las herramientas de "reparación" que suben el archivo lo copian a una infraestructura que no puedes inspeccionar, bajo unos plazos de retención que tú no escribiste. Aquí el archivo se lee desde tu disco y se reconstruye en tu pestaña; puedes abrir el panel Red (Network) y comprobar que 0 bytes de la base de datos salen de tu equipo.