Eine beschädigte WhatsApp-Datenbank (msgstore.db) wiederherstellen

Eine WhatsApp-Datenbank ist eine ganz gewöhnliche SQLite-Datei, also ein flaches Array aus Seiten fester Größe (der Standardwert von SQLite liegt oft bei 4 KB). Die ersten 16 Byte sind die magische Zeichenkette SQLite format 3\0; der Rest der Seite 1 enthält den Datei-Header und das sqlite_schema, das jede Tabelle auflistet. Jede Tabelle ist ein B-Baum (b-tree): Die inneren Seiten tragen Zeiger, die zu den Blattseiten hinabführen, und die Blattseiten enthalten deine eigentlichen Zeilen.

Die Tabellen, die für den Chatverlauf zählen, sind vorhersehbar. Moderne WhatsApp-Versionen speichern die Nachrichten in einer Tabelle message (ältere Versionen verwendeten messages), die Liste der Unterhaltungen in chat und die Kennungen für Telefonnummern/Gruppen in jid. Der Nachrichtentext liegt in einer Textspalte (text_data im modernen Schema, data im alten), und jede Zeile trägt einen Zeitstempel in Millisekunden der Unix-Epoche. Hilfstabellen wie message_media, message_thumbnail, message_quoted und call_log runden das Ganze ab. Und ganz entscheidend: Die Fotos, Videos und Sprachnachrichten selbst liegen nicht in der Datenbank — das sind separate Dateien im Ordner Media von WhatsApp, und die Datenbank speichert nur deren Dateipfade sowie kleine Miniaturansichten (Thumbnails).

WhatsApp betreibt die Datenbank im WAL-Modus (Write-Ahead Logging), sodass du auf dem Telefon zwei Geschwisterdateien daneben siehst: msgstore.db-wal und msgstore.db-shm. Kürzlich bestätigte Nachrichten können ausschließlich in der Datei -wal liegen, bis sie per Checkpoint in die Haupt-.db übertragen werden. Wenn du diese Begleitdatei hast, bewahre sie auf: Ihre bestätigten Frames sind die neuesten Zeilen.

SQLite löst SQLITE_CORRUPT (Ergebniscode 11) aus — angezeigt als "database disk image is malformed" (Datenträgerabbild der Datenbank ist fehlerhaft) — in dem Moment, in dem es einem Zeiger folgt und auf etwas landet, das keine gültige B-Baum-Seite ist: eine mit Nullen gefüllte Seite, ein falscher Zell-Offset, eine Seitenzahl, die nicht zur Dateigröße passt. Es hält bei der ersten Unstimmigkeit an, und deshalb reißt eine einzige beschädigte innere Seite die ganze Datei mit, während die unberührten Blattseiten dahinter deine Nachrichten weiterhin bewahren. Ein verwandter Fehler, "file is not a database," (Datei ist keine Datenbank) bedeutet, dass die 16 Byte lange magische Kennung des Headers selbst verstümmelt wurde — die Seiten dahinter sind oft in Ordnung.

Der Schaden stammt fast immer von einem unterbrochenen Schreibvorgang. Wenn man die msgstore.db über USB oder mit einem Dateimanager vom Telefon holt, während WhatsApp sie noch geöffnet hat, kann eine zerrissene, halb per Checkpoint geschriebene Datei kopiert werden; ein gekipptes Byte auf einer ausfallenden SD-Karte oder während einer Synchronisierung, oder ein Gerät, das mitten im Schreibvorgang die Stromzufuhr verlor, bewirken dasselbe. Eine abgeschnittene Kopie verliert einfach die Seiten, die sich am Ende befanden.

Eine Falle erwischt fast jeden zuerst: Die Datei im Backup-Ordner von WhatsApp ist keine normale Datenbank. Die Sicherungen heißen msgstore.db.crypt14 oder msgstore.db.crypt15 und sind mit AES-GCM verschlüsselt (der Schlüssel liegt unter /data/data/com.whatsapp/files/key oder, bei crypt15, hinter deinem Passwort für die Ende-zu-Ende-verschlüsselte Sicherung). Eine .crypt14/.crypt15-Datei liest sich als hochentropisches Rauschen — sie hat überhaupt keinen SQLite-Header, sodass die Seiten-Rettung sie nicht anfassen kann, bis sie zurück zu einer normalen msgstore.db entschlüsselt wurde. Dieses Werkzeug arbeitet mit der bereits entschlüsselten Datenbank, nicht mit der verschlüsselten Sicherung.

Statt den kaputten Zeigern zu vertrauen, liest das Werkzeug die Datei Seite für Seite: Es baut das Schema neu auf, durchläuft den B-Baum jeder Tabelle und greift für alles, was die Zeigerkette nicht mehr erreichen kann, auf einen rohen Seiten-Suchlauf zurück, der die selbstbeschreibenden Datensätze direkt aus den Blattseiten dekodiert. Es baut die B-Bäume von Grund auf um die gefundenen Zeilen herum neu auf und schreibt sie in eine brandneue Datenbank, die du herunterlädst — dieselbe Strategie wie der .recover-Befehl von SQLite selbst. Zeilen, die sich keiner bekannten Tabelle zuordnen lassen, landen in einer Tabelle lost_and_found, statt verworfen zu werden, und wenn du die Begleitdatei msgstore.db-wal beisteuerst, werden ihre bestätigten Frames zuerst darübergelegt, damit das Ergebnis deine zuletzt bestätigten Nachrichten widerspiegelt und nicht nur den letzten Checkpoint.

Die ehrlichen Grenzen: Bytes, die physisch überschrieben oder am Ende der Datei abgeschnitten wurden, sind verloren, und kein Werkzeug kann sie erfinden. Die Werte kommen mit ihrer Speicherklasse von der Festplatte zurück, sodass sich die Affinität einer Spalte verschieben kann. Da der Suchlauf auch die Seiten der Freelist und die nicht kompaktierten Seiten liest, können manche zuvor gelöschten Nachrichten wieder auftauchen. Wiederhergestellte Daten sind immer verdächtig — das sagen die eigenen Dokumente von SQLite —, prüfe sie also gegen eine vertrauenswürdige Quelle, bevor du dich darauf verlässt. Und die Mediendateien liegen weiterhin im separaten Ordner Media; die Datenbank gibt dir den Text und die Verweise, nicht die Bilder selbst.

Warum das im Browser tun? Die Datenbank eines Chats ist die denkbar schlechteste Datei, die man einem Server übergeben kann, den man nicht kontrolliert: Sie kann jede Nachricht, jede Telefonnummer und jeden Zeitstempel enthalten, die du je ausgetauscht hast. "Reparatur"-Werkzeuge, die die Datei hochladen, kopieren sie auf eine Infrastruktur, die du nicht prüfen kannst, unter Aufbewahrungsbedingungen, die du nicht verfasst hast. Hier wird die Datei von deiner Festplatte gelesen und in deinem Tab neu aufgebaut; du kannst den Netzwerk-Tab (Network) öffnen und bestätigen, dass 0 Byte der Datenbank dein Gerät verlassen.