Récupérer une base de données WhatsApp corrompue (msgstore.db)

Une base de données WhatsApp est un fichier SQLite ordinaire : c'est donc un tableau plat de pages de taille fixe (la valeur par défaut de SQLite est souvent de 4 KB). Les 16 premiers octets sont la chaîne magique SQLite format 3\0 ; le reste de la page 1 contient l'en-tête du fichier et le sqlite_schema, qui énumère chaque table. Chaque table est un arbre-b (b-tree) : les pages internes portent des pointeurs qui descendent vers les pages feuilles, et les pages feuilles contiennent vos lignes réelles.

Les tables qui comptent pour l'historique des conversations sont prévisibles. Les versions récentes de WhatsApp conservent les messages dans une table message (les anciennes versions utilisaient messages), la liste des conversations dans chat et les identifiants de numéro de téléphone/groupe dans jid. Le texte du message vit dans une colonne de texte (text_data sur le schéma moderne, data sur l'ancien), et chaque ligne porte un horodatage en millisecondes de l'époque Unix. Des tables auxiliaires comme message_media, message_thumbnail, message_quoted et call_log complètent l'ensemble. Point crucial : les photos, les vidéos et les notes vocales elles-mêmes ne sont pas dans la base de données ; ce sont des fichiers distincts dans le dossier Media de WhatsApp, et la BD ne stocke que leurs chemins d'accès et de petites vignettes.

WhatsApp exécute la base de données en mode WAL (write-ahead logging, journalisation par écriture anticipée) : sur le téléphone, vous verrez donc deux fichiers frères à ses côtés, msgstore.db-wal et msgstore.db-shm. Les messages récents déjà validés (committed) peuvent ne vivre que dans le fichier -wal jusqu'à ce qu'ils soient consolidés (checkpoint) dans le .db principal. Si vous avez ce fichier annexe, conservez-le : ses frames validés sont les lignes les plus récentes.

SQLite lève SQLITE_CORRUPT (code de résultat 11) — qui apparaît sous la forme "database disk image is malformed" — dès qu'il suit un pointeur et atterrit sur quelque chose qui n'est pas une page b-tree valide : une page à zéro, un décalage de cellule erroné, un nombre de pages qui ne concorde pas avec la taille du fichier. Il s'arrête à la première incohérence, et c'est pourquoi une seule page interne endommagée fait tomber le fichier entier alors que les pages feuilles intactes situées derrière contiennent toujours vos messages. Une erreur apparentée, "file is not a database," (« le fichier n'est pas une base de données ») signifie que la chaîne magique de 16 octets de l'en-tête elle-même a été altérée ; les pages derrière elle sont souvent intactes.

Le dommage provient presque toujours d'une écriture interrompue. Sortir le msgstore.db du téléphone par USB ou avec un gestionnaire de fichiers alors que WhatsApp le tient encore ouvert peut copier un fichier déchiré, avec le checkpoint à moitié fait ; un bit retourné sur une carte SD défaillante ou pendant une synchronisation, ou un appareil qui a perdu son alimentation en pleine écriture, produisent le même résultat. Une copie tronquée perd simplement les pages qui se trouvaient à la fin.

Un piège attrape à peu près tout le monde d'abord : le fichier situé dans le dossier de sauvegarde de WhatsApp n'est pas une base de données ordinaire. Les sauvegardes s'appellent msgstore.db.crypt14 ou msgstore.db.crypt15 et sont chiffrées en AES-GCM (la clé se trouve dans /data/data/com.whatsapp/files/key ou, pour crypt15, derrière votre mot de passe de sauvegarde chiffrée de bout en bout). Un fichier .crypt14/.crypt15 se lit comme un bruit à haute entropie : il n'a aucun en-tête SQLite, si bien que la récupération par pages ne peut rien en faire tant qu'il n'est pas déchiffré pour redevenir un msgstore.db ordinaire. Cet outil travaille sur la base de données déjà déchiffrée, pas sur la sauvegarde chiffrée.

Plutôt que de se fier aux pointeurs cassés, l'outil lit le fichier page par page : il reconstruit le schéma, parcourt le b-tree de chaque table et, pour tout ce que la chaîne de pointeurs ne peut plus atteindre, se rabat sur un balayage brut des pages qui décode les enregistrements autodescriptifs directement depuis les pages feuilles. Il reconstruit les b-trees de zéro autour des lignes qu'il trouve et les écrit dans une base de données neuve que vous téléchargez : exactement la stratégie de la propre commande .recover de SQLite. Les lignes qui ne peuvent être rattachées à une table connue sont placées dans une table lost_and_found plutôt que jetées, et si vous fournissez le fichier annexe msgstore.db-wal, ses frames validés sont superposés en premier pour que le résultat reflète vos derniers messages validés, et pas seulement le dernier checkpoint.

Les limites honnêtes : les octets qui ont été physiquement écrasés ou tronqués à la fin du fichier sont perdus, et aucun outil ne peut les inventer. Les valeurs reviennent avec leur classe de stockage sur disque, de sorte que l'affinité d'une colonne peut changer. Comme le balayage lit aussi les pages de la liste libre (freelist) et les pages non compactées, certains messages précédemment supprimés peuvent réapparaître. Les données récupérées sont toujours suspectes — la documentation même de SQLite le dit — alors vérifiez-les contre une source fiable avant de vous y fier. Et les fichiers multimédias vivent toujours dans le dossier Media à part ; la base de données vous donne le texte et les références, pas les images elles-mêmes.

Pourquoi faire cela dans le navigateur ? La base de données d'une conversation est le pire fichier que vous puissiez confier à un serveur que vous ne contrôlez pas : elle peut contenir chaque message, chaque numéro de téléphone et chaque horodatage que vous avez jamais échangés. Les outils de « réparation » qui téléversent le fichier le copient sur une infrastructure que vous ne pouvez pas inspecter, sous des délais de rétention que vous n'avez pas écrits. Ici, le fichier est lu depuis votre disque et reconstruit dans votre onglet ; vous pouvez ouvrir le panneau Réseau (Network) et vérifier que 0 octet de la base de données ne quitte votre machine.