Whatsapp Chats verschwunden

[Laura99]

das sind ja auch nur Backups.
Nicht die genutzten.

Diese Backups sind doch dann auch nur direkte Kopien, meinem Verständnis nach.
Wenn diese in meinem Fall nicht funktionieren, wie soll dann die Main Datei, an die ich ohne root nicht rankomme, funktionieren?

 

[maik005]

wie soll dann die Main Datei

die ist ja sowieso weg.

 

[Laura99]

Das verstehe ich schon, das ist ja bereits bei dem Fehlschlagen des Wiederherstellens Freitag Abend passiert.
Mir geht's ums Prinzip bzw, für mein Verständnis.

Update 3:
Ich glaube ich habe es geschafft.
Geholfen haben mir ein paar Beiträge und ein bestimmter Kommentar von reddit.

Ich schreibe morgen noch etwas mehr dazu, mir graust es gerade schon auf den Wecker zu schauen.

 

[maik005]

Mir geht's ums Prinzip bzw, für mein Verständnis.

so wie ich es verstanden habe ist die Datenbank ja in einem Verzeichnis, auf dasd du keinen Zugriff hast.
Dort ist sie nicht verschlüsselt (.cryptxy) sondern unverschlüsselt.
Wird ein Backup erstellt, so wird diese Datenbank dann verschlüsselt was ggf. zu Problemen führt.

@Kreacher bitte korrigieren wenn meine Vermutung falsch ist.

 

[Kreacher]

Ich weiß nicht, aus welchem Tool unter welchem OS der Screenshot stammt.

Das ist die reguläre Standardansicht unter Windows 10.

Beiträge automatisch zusammengeführt: 05.11.2024

Diese Backups sind doch dann auch nur direkte Kopien, meinem Verständnis nach.

FAST identische Kopien der Systemdatei. Die Backups enthalten nicht alle Tabellen der WhatsApp-("Main")-Systemdatei. Meine Tests haben ergeben, dass WhatsApp offensichtlich die Tabellen für die Indexierung der Suchfunktion (sodass man innerhalb und außerhalb von Chats nach Wörtern/Begriffen suchen kann) und einige andere Funktionen nicht in die Backups mit einschließt. Das heißt, WhatsApp fügt diese Funktionen bei jedem Wiederherstellen eines Backups dann automatisch wieder hinzu, basierend auf dem jeweiligen Wörter- bzw. Chatstand.

Das wird relevant, wenn man nun verschiedene Backup/Chatstände oder auch Chats aus anderen WhatsApp-Accounts / Nummern miteinander verschmelzen möchte. Für dein Problem hier ist das aber irrelevant.

so wie ich es verstanden habe ist die Datenbank ja in einem Verzeichnis, auf dasd du keinen Zugriff hast.
Dort ist sie nicht verschlüsselt (.cryptxy) sondern unverschlüsselt.
Wird ein Backup erstellt, so wird diese Datenbank dann verschlüsselt was ggf. zu Problemen führt.

Ja, das ist im Großen und Ganzen richtig so. Für den reibungslosen Betrieb kann es sich WhatsApp gar nicht leisten, seine Datenbanken zu verschlüsseln, denn es muss ja jede Sekunde geschrieben und gelesen werden. Deswegen befindet sich im Root-Verzeichnis unter android/data/data/com.whatsapp/databases/ eine sogenannte msgstore.db, die keine "crypt"-Endung hat, und damit unverschlüsselt vorliegt.

Die ist auch laufend in Benutzung, erkennbar daran, dass neben der msgstore.db noch zwei Cache-Ableger genutzt werden, msgstore.db-wal und msgstore.db-shm.
Löst man nun ein Backup aus, wird von dieser unverschlüsselten msgstore.db eine Kopie erstellt und gemäß AES entweder crypt14 oder crypt15 verschlüsselt (je nach Einstellungen) und dabei aber einige wenige (die oben genannten) Tabellen aus der Main-Datenbank herausgenommen, vermutlich um Dateigröße zu sparen.

Deswegen empfiehlt es sich, falls man nun vorhätte, verschiedene Chatstände bzw. Datenbanken miteinander zu verschmelzen oder sonst irgendwie Änderungen vorzunehmen, immer die unverschlüsselte Haupt-Datenbank als Arbeitsdatei zu benutzen.
Wenn man die crypt-Backup-Datei entschlüsselt, fehlen eben einige Tabellen. Meist haben die nicht wirklich Auswirkungen auf die Änderungen, die man geplant hat, aber ich habe herausgefunden, dass sich die entschlüsselten Backup-Dateien anders verhalten als die unverschlüsselten Systemdatenbank-Dateien.

Was hier nun bei @Laura99 passiert sein könnte, ist folgendes:
WhatsApp hat aus irgendeinem Grund die Systemdatenbank resettet. Dasselbe passiert, wenn man in den Android-Einstellungen bei Apps unter WhatsApp auf "Daten löschen" klickt. Dies löscht den com.whatsapp-Systemordner unter android/data/data im Rootverzeichnis.
Ergo legt WhatsApp dann nach Eingabe der Handynummer eine komplett neue Datenbank an und nur die Gruppen, in denen man weiterhin Mitglied ist, bleiben bestehen.

Normalerweise macht WA dann täglich / nachts ein lokales Backup und legt damit eine verschlüsselte Kopie der Systemdatenbank im Userverzeichnis als crypt-Datei an. Dies wird wohl die hier im Screenshot gezeigte msgstore.db.crypt14-Datei sein, die nur 600KB groß ist.

Die anderen/ältere Dateien dürften von der Größe her noch der alte Chatstand sein. Warum sie sich nicht wiederherstellen lassen, ist merkwürdig. Eine nicht bestätigte Theorie wäre, dass WhatsApp beim täglichen Erstellen eines Backups eben nicht nur die msgstore.db.crypt14 Hauptdatei abändert, sondern vermutlich auch gewisse Infos an den älteren, bestehenden Backupdateien mit abändert.

Widerlegt werden könnte diese Theorie, wenn es hier im Forum Beweise gäbe, dass ein Wiederherstellen einer dieser älteren Backupdateien durch Umbenennen in msgstore.db.crypt14 zweifellos geklappt hätte. Ist mir auf die Schnelle nichts bekannt. Ich hatte ohnehin schon immer Zweifel, ob das mit dem Umbenennen einer älteren Backupdatei, die von WhatsApp nicht als "Hauptdatei" gebranntmarkt wurde, so klappen könnte.

Eine zweite Theorie wäre "Key-Change", was ja leider mit Crypt14, wie wir mittlerweile wissen (ansonsten siehe oben verlinkte Anleitung zum Backup-Management) unumgänglich ist. Eventuell hat WhatsApp beim Resetten der Systemdatenbank auch direkt die Keys gewechselt. Dagegen spricht allerdings, dass WA das Backup aber erkannt und auch angefangen hat wiederherzustellen. Dies wäre bei einem Key-Wechsel so eigentlich nicht mehr möglich - zumindest nicht bei der offiziellen WhatsApp-Version.
Bei einer inoffiziellen WhatsApp-Version wie Fuaod-WhatsApp oder wie sie alle heißen, habe ich es geschafft, ein Backup, von dem ich wusste, dass es keine Keys mehr gibt und das die offizielle WA-Version gar nicht erst als Backup mehr erkannt hat, zumindest genau wie hier im Beispiel wiederherstellen zu lassen, bis es dann aber bei 100% plötzlich genau dieselbe Meldung brachte wie hier.

Der Key für eine verschlüsselte Datenbank bei Crypt14 liegt ebenso im Rootverzeichnis wie die unverschlüsselte Systemdatenbank - nämlich unter android/data/data/files

So wie es gegenwärtig scheint, bleibt wohl nur noch der Versuch, das vorhandene Google Drive Backup einzuspielen. Da dies aber von Juli ist, könnte es auch hier schon sein, dass WA mittlerweile die Keys geändert hat. Eventuell seit Reset der Systemdatenbank könnte nun auch der entsprechende Key auf den WhatsApp-Servern weg sein und damit auch das Drive-Backup nichts weiter als verschlüsselter Datenmüll sein...

Deswegen sage ich ja immer: schnellstens auf crypt15 wechseln und anfangen, seine Keys selber zu verwalten......

 

[maik005]

Widerlegt werden könnte diese Theorie, wenn es hier im Forum Beweise gäbe, dass ein Wiederherstellen einer dieser älteren Backupdateien durch Umbenennen in msgstore.db.crypt14 zweifellos geklappt hätte.

ich bin ziemlich sicher, dass wir hier schon mehrere Fälle hatten, wo das funktionierte.

 

[Laura99]

Update 3:
Ich glaube ich habe es geschafft.
Geholfen haben mir ein paar Beiträge und ein bestimmter Kommentar von reddit.

Ich schreibe morgen noch etwas mehr dazu, mir graust es gerade schon auf den Wecker zu schauen.

So wie es gegenwärtig scheint, bleibt wohl nur noch der Versuch, das vorhandene Google Drive Backup einzuspielen. Da dies aber von Juli ist, könnte es auch hier schon sein, dass WA mittlerweile die Keys geändert hat. Eventuell seit Reset der Systemdatenbank könnte nun auch der entsprechende Key auf den WhatsApp-Servern weg sein und damit auch das Drive-Backup nichts weiter als verschlüsselter Datenmüll sein...

Im Moment scheine ich ich auf den Stand der Database "msgstore-2024-11-02.1.db.crypt14" wiederhergestellt zu haben.

 

[Kreacher]

@Laura99

Und ist das der Stand, den du wolltest?
Wie genau bist du nun vorgegangen bzw. was hast du nun anders gemacht als vorher?

Ich sehe gerade dein Edit bzgl. Reddit-Kommentar. Scheint wohl irgendein Bug zu sein bei WhatsApp, der mit dieser Methode umgangen werden kann.

 

[Laura99]

Idealerweise wäre der Stand gewesen von Freitag, gegen 19:00.
Der Fehler selbst, habe in meiner Kommunikation mit einer Freundin nachgeschaut, trat um 19:27 auf.

Soweit wir das ja hier gemeinsam beurteilen konnten, war die aktuellste Database Version, auf die ich noch Zugriff habe, die
"msgstore-2024-11-02.1.db". Die aus dem Drive ist ja so oder so älter.

Dann habe ich vorerst die Ansätze von euch durchprobiert, sprich jeweils die DB eingesetzt und versucht durch Neuinstallation von WA diese für den Wiederaufbau zu nehmen. Folglich benenne ich diese 4 Varianten, die Beobachtungen während des Prozesses und die Schlussfolgerungen, die ich mir logisch versucht habe herzuleiten, basierend auf meinem Halbwissen seit Freitag.

Variante 1:
"msgstore-2024-11-02.1.db.crypt14" wird zu "msgstore.db.crypt14"
Rest raus

Variante 2:
"msgstore-2024-10-30.1.db.crypt14" wird zu "msgstore.db.crypt14"
Rest raus

Variante 3:
"msgstore-2024-11-02.1.db.crypt14" wird zu "msgstore.db.crypt14"
kleine "msgstore.db.crypt14" (von Freitag nach dem Fehler) raus + Rest drin

Variante 4:
"msgstore-2024-10-30.1.db.crypt14" wird zu "msgstore.db.crypt14"
kleine "msgstore.db.crypt14" (von Freitag nach dem Fehler) raus + Rest drin

V3+4 basieren auf dem Ansatz aus Antwort #31.

Ich habe dann gestern Abend angefangen, nachdem ich diese 4 Varianten mal habe laufen lassen ohne genauer drauf zu gucken, genauer beobachtet, um vielleicht etwas daraus zu lernen.
Meine Annahme war, dass der Großteil der Datenbank ja funktionieren sollte, nur irgendwo, vielleicht analog zu der fehlerhaften Gruppe, welche am Freitag das ganze Malheur ausgelöst hat, irgendwo der Wurm drin sein sollte.

Also habe ich habe ich erneut V1 bis 4 mehrmals durchgeführt und grob die Zeiten gemessen + den prozentualen Verlauf beobachtet.
Der Anfang bei allen Vieren war gleich: es wurde mit einer durchschnittlichen Geschwindigkeit von 2-3% pro Sekunde der Prozess durchgeführt. Anschließend hängten die Wiederherstellung bei 99% für eine gewisse Zeit, bis dann der Fehler ausgespuckt wurde.
Diese Zeiten, aufgeschlüsselt mal hier:
V1: 1 Minute 30 Sekunden - 2 Minuten
V2: 1 Minute 30 Sekunden - 2 Minuten
V3: 7:30 - 8 Min
V4: 7:30 - 8 Min

Sobald der Prozess dann die 99% erreichte und dann dort hing (ob er mehrere Anläufe macht oder was genau versucht wird, kann ich nicht beurteilen), habe ich WA mit Hilfe von Einstellungen > Apps > Apps gestoppt, Handy neu gestartet, WA ausgeführt.

Anschließend wurde ich von der Seite bei WA willkommen geheißen, bei der ich Benutzername + Profilbild vergeben sollte, was ich tat, und hatte dann meine Chats so vorgefunden, wie in der Sicherung vom 30.10 um 02:00 Uhr.

Theorie:
In meinen Augen klappt also der Großteil der Ganzen Wiederherstellung, sonst würde in dem Prozess der Fehler bei einer geringeren Prozent-Zahl auftreten, kann aber, aus einem mir nicht ersichtlichen Grund, nicht abgeschlossen werden.
Als ich dann den besagten Post las, dachte ich mir "Vielleicht schreibt er ja die neue DB Datei bis zu einem gewissen Punkt, aber wenn er mehrfach den Fehler aus der Backup Datei nicht erfolgreich verarbeiten kann und bricht den ganzen Rebuild ab, spuckt den Fehler aus, legt eine neue DB an."
Also verhindere ich durch den Abbruch des Prozesses, dass er die rebuildete DB bis zu dem Anteil stehen lässt, nicht löscht und keine neue / leere DB anlegt.
Hat ja scheinbar geklappt.

 

[Kreacher]

Weiteres Vorgehen:

jetzt wechselst du als allererstes direkt mal auf Crypt15, notierst dir deinen 64-stelligen Master-Key sehr sorgfältig, sodass du ihn nie mehr verlierst und speicherst das neue Backup (crypt15) sicher irgendwo, am besten auf dem PC, samt Medien.

Somit hast du dann zumindest mal diesen Chatstand sicher. Danach kannst du die gleiche Prozedur ja nochmal mit dem gewünschten Chatstand machen, vielleicht kommst du damit auch ans Ziel.
Danach dann natürlich auch direkt wieder auf Crypt15 gehen. Wieder neuen Masterkey sichern und das wäre dann künftig auch der endgültige für alle künftigen Backups...