SQL Datenbanken zusammenführen

[Marvolo]

Hi,

kennt sich jemand mit SQL Datenbanken aus und kann mir bei meinem (vermutlich doch eher komplexen) Problem weiterhelfen? Ich versuche zwei Datenbanken zusammenzuführen, das heißt, ich habe 2 mit nach Zeitstempeln (UNIX Zeitformat) chronologisch aufgelisteten Daten.

Die eine hört im Dezember auf. Die andere beginnt im Januar. Jetzt sollen beide in eine gemeinsame überführt werden, sodass die neuere dort anfängt, wo die ältere aufhört.

Auf Github habe ich gelesen, dass Leute das schon hinbekommen haben mittels Python + Julia. Anscheinend durch einen selbst erstellten Code. Machbar muss es also irgendwie sein - nur bin ich was das angeht, leider ein völliger Neuling. Habe mich bislang nicht wirklich mit diesen Dingen oder Coding befasst.

Vielen Dank

PS: Oder wisst ihr, ob es Foren gibt so wie dieses hier, die sich aber rein nur mit Informatik/Programm-Code etc. befassen, sodass ich dort vielleicht am ehesten jemand finde, der sich damit auskennen könnte?

 

[guzzisti]

Tabellenname und Struktur sind identisch?

Dann brauchst Du keinen Code, sondern erzeugst von einer der beiden DBs einen logischen Dump, der nur die Daten enthält. Tools dazu gibts für jedes gängige DB-Systeme (von welchem reden wir denn?) in unterschiedlicher Ausprägung.
Der Dump enthält die Daten in der Regel als einfache INSERT-Statements.

Anschließend kannst Du den Dump einfach in die andere DB einspielen und hast die Summe aus beiden.
Voraussetzung: keine doppelten Zeitstempel.

 

[DHC]

Ich bin zwar nicht der Datenbank-Spezialist.
Vor über 10 Jahren hatte ich mal Kontakt mit dem Thema.

Wie @guzzisti schon sagte. Wenn die Strukturen etc. gleich sind, wäre es wohl am einfachsten mit einem SQL-Dump.

 

[Marvolo]

Anschließend kannst Du den Dump einfach in die andere DB einspielen und hast die Summe aus beiden.
Voraussetzung: keine doppelten Zeitstempel.

Das ist vermutlich das Problem.
Es geht bei mir konkret um WhatsApp Chat-Datenbanken. Ich habe ab Januar herum notgedrungenermaßen auf ein vorübergehend zweites Handy gewechselt und konnte die alten Chats leider nicht mitnehmen.

Die Folge ist nun also:

Erste Datenbank: Alle Chats bis Dezember
Zweite Datenbank: neue Chats AB Januar, aber ohne alte Chats bis Dezember
Dritte Datenbank (gegenwärtiger Status Quo): wieder zurück aufs alte / wieder funktionierende Handy und dort weitergeschrieben, wo es im Dezember aufgehört hat. Ergo: Alle Chats bis Dezember und nun AB April.

Vorhaben: Die zweite Datenbank nun in die dritte so einfügen, dass die Lücke zwischen Dezember und April wieder geschlossen ist.

DASS das geht, weiß ich wie gesagt. Da habe ich auf Github schon einiges gelesen dazu. Aber leider wollte oder konnte mir die Person dort nicht genau sagen, wie sie es vollbracht hat. Ich weiß nur, dass sie es mit Python & Julia irgendwie gemacht hat.

Am Ende muss die modifizierte Datenbank dann wieder verschlüsselt werden, da WA-Datenbanken ja von Natur aus als *crypt"-Dateien vorliegen. Für diesen Schritt habe ich von Github eine Anleitung - das könnte also theoretisch hinhauen.

Aber mir fehlt halt erstmal der mittlere Schritt - nämlich die Datenbanken miteinander zu verschmelzen...

Da mir das persönlich schon wichtig ist und auch einen hohen ideellen Wert für mich hat, wäre ich sogar bereit, ne kleine Aufwandsentschädigung zu leisten, falls das jemand hinkriegen würde oder mir zumindest step-by-step erklären könnte... Bislang habe ich da aber noch niemanden gefunden, bis auf eben jenen User auf Github, der das identische Problem wie ich hatte und es aber irgendwie hinbekommen hat. Aber der hat da leider keine Zeit, zu helfen, wie er meinte. Ist wohl auch glaub aus den USA oder so.

 

[LuxSkywalker]

was manche für einen Aufwand treiben für einen WA Chatverlauf 🙊

 

[Marvolo]

Tja, manche sammeln Briefmarken - ein Aufwand, der sich MIR z.B. auch nie erschließen würde...

Back to Topic:
ich bin mittlerweile schon mal so weit, dass ich meine Datenbanken entschlüsselt vorliegen habe, als *db-Datei. Ich kann sie auch öffnen mit DB Browser for SQlite und kann mir die einzelnen Tabellen dort auch anschauen. Dort ist auch die "Messages"-Tabelle, die alle Chats enthält. Die Chats werden nach Chat-IDs gelistet. Die Chat-IDs verweisen dann auf eine JID-Tabelle, wo die jeweilge Chat-ID dann mit einer Handynummer verknüpft ist, sodass WA weiß, von welcher Nummer der Chat-Eintrag ist.

Also Beispielsweise Chat_ID 5 verweist auf JID 10 und JID 10 = Handynummer XYZ.

Ergänzung (1. Mai 2024)

Falls es hilft, könnte ich hier aus DB Browser mal das jeweilige "Schema" exportieren und hier hochladen. Also nur das Schema der Datenbank, keine Inhalte (Chats) natürlich.

 

[Micke]

PS: Oder wisst ihr, ob es Foren gibt so wie dieses hier, die sich aber rein nur mit Informatik/Programm-Code etc. befassen, sodass ich dort vielleicht am ehesten jemand finde, der sich damit auskennen könnte?

da bist du hier schon richtig

jeweilige "Schema" exportieren und hier hochladen

Wenn du die Tabellen selbst kopieren möchtest, und es dir um die konkreten befehle geht, müsstest du das. Wenn du Antwort #2 folgst, brauchst du das nicht.

aus Neugier: sind die DB's eigentlich alle mit dem gleichen Schlüssel versiegelt ?

 

[Marvolo]

aus Neugier: sind die DB's eigentlich alle mit dem gleichen Schlüssel versiegelt ?

Da hatte ich in einem anderen Beitrag erst meine Erkenntnisse zu gepostet. Eine offizielle Antwort habe ich nicht, vermutlich will da WhatsApp auch keinen Einblick geben, aber von meinen eigenen Tests her scheint es wohl so zu sein, als ob WA die Keys regelmäßig rotiert bzw. abändert nach einem bestimmten Zeitraum. Oder aber auch, wenn auf neue Geräte gewechselt wird oder man die App neu installiert.

Mit meinem Key vom Dezember 2023 Backup kann ich frühere Backups bis Oktober 2022 öffnen. Ein April-2022 Backup geht damit dann schon leider nicht mehr. Es muss zu diesem Zeitpunkt also auch wieder ein Key-Wechsel stattgefunden haben.

Meine momentanen Backups, um die es hier geht, funktionieren alle mit dem selben Key - kann aber sein, dass da bald wieder ein Key-Wechsel stattfindet und ich die dann mit dem dann neuen Key nicht mehr öffnen kann. Aber ich habe die aktuellen Keys ja gespeichert, dann kann ich die also bis in alle Ewigkeit öffnen.

Ergänzung (1. Mai 2024)

Wenn du die Tabellen selbst kopieren möchtest, und es dir um die konkreten befehle geht, müsstest du das. Wenn du Antwort #2 folgst, brauchst du das nicht.

Also hier ist mal im Anhang (zip-Datei) das exportierte Schema (nur Schema, keine Daten) aus DB Browser SQLite für die aktuelle WhatsApp Database-Datenbank.

Weiß nicht, ob man da allzu schlau draus wird. In DB Browser sieht es dann doch um einiges aufgeräumter aus, aber ich verstehe leider nicht alle Tabellen/Werte und Einträge, auch noch nicht, wie welche Tabelle mit welcher anderen wie zusammenhängt.

In DB Browser sieht das Ganze so aus:

Und hier speziell die "Messages"-Tabelle:

Ergänzung (1. Mai 2024)

da bist du hier schon richtig

Naja, ich weiß nicht. Die WA-Datenbank ist ja schon speziell und anscheinend auch sehr komplex. Und man sieht's ja an vergangenen Antworten, bzw. einer bestimmten, dass da sich offenbar noch niemand hier die Mühe gemacht hat , oder den Sinn darin gesehen hat, sich mit zu befassen.

 

[Yuuri]

Der Prozess ist zumindest logisch ganz einfach.

Du öffnest deine Merge-DB, attachst beide Quell-DBs, klonst das Schema in deinen Merge und kopierst die Daten einfach rüber. Wichtig ist, dass du hierbei am Besten alles in eine dritte DB verfrachtest und immer auch mit Kopien arbeitest. Problem ist eben, dass du von einer DB (die Kleinere wäre wohl sinnvoller) alle Primary und Foreign Keys neu setzen musst, da ja sonst die Datensätze überschrieben bzw. falsche/keine Daten referenziert werden würden.

Ganz einfach gesprochen:

• Eine DB ziehst du komplett rüber (die Größere ist hierbei sinnvoller)
• Danach holst du dir von jeder Tabelle den entsprechenden PK-Offset/AutoIncrement/SequenceNumber
• Dann analysierst du die zweite DB und rechnest entsprechend jedes dieser Offsets auf deine Keys drauf (wie gesagt PKs und FKs)
• Wenn das geklappt hat, kannst du genauso die zweite in die Merge-DB kopieren.

Durch Schritt 3 ist der Prozess halt "sehr leicht" aufgeblasen worden.

Eine Idee wäre, wenn die Cascades auf Foreign Key Constraints entsprechend gesetzt sind, dass man einfach die PKs um den Offset verschiebt und sich die FKs dann automatisch mit updaten. Dann hast du zumindest das Problem der FKs nicht. Aber da musst du halt vorher ggf. alle Tabellen updaten, dein Offset durchführen und die Constraints dann wieder entfernen. Mit ner entsprechenden Anzahl an Datensätzen kann das gut und gern "lange" (auch gern mehrere Stunden) dauern, wenn die Constraints beim Update aktiv bleiben und auch greifen sollen.

Je nachdem wieviel Daten da drin stecken, kann Methode 1 (mit deaktivierten Checks) oder 2 (mit aktivierten Checks) schneller sein... Dann musst du aber auch noch die Daten in die Merge DB überführen und hierbei greifen die Constraints dann entweder genauso oder halt nicht.

Hierbei musst du aber darauf vertrauen, dass alle Keys korrekt gesetzt wurden. Wenn irgendwo einer fehlt, wünsch ich dir jetzt schon viel Spaß beim Suchen.

Keine Ahnung ob dir das was hilft, erste Treffer bei Google:

• https://github.com/natario1/whatsapp-database-merger
• https://github.com/SenCodeMaker/whatsapp-database-merger (hilft dir quasi nichts, weil das Schema ne komplett veraltete Version hat und sich auch nicht um die FKs gekümmert wird, aber der Prozess sollte dir damit einleuchten)

Dass der Prozess auch nur klappt, wenn beide DB Schemas identisch sind, brauch ich wohl nicht erwähnen.

 

[Marvolo]

@Yuuri

Endlich mal jemand, der sich (nach wochenlanger Recherche und Suche meinerseits) anscheinend mit der Thematik auszukennen scheint.
Vielen Dank für die Instructions, wenn auch für mich zu 60% alles nur Bahnhof ist. Wie gesagt, ich habe mich bisher noch nie wirklich mit Datenbanken befasst - ich ging auch davon aus, dass es da (wie für Skype mit dem tollen "Skyperious") ein automatisiertes Tool gäbe, das einem ein Zusammenführen ruckzuck von alleine macht. Damit hab das selbst ich hingekriegt, verschiedene Skype-DB zu mergen.

Dass es hier bei WhatsApp wohl nur manuell geht, ist schade. Ich denke, mit einer Schritt-für-Schritt-Anleitung würde ich es als absoluter Neuling wohl noch hinbekommen, bzw. mit einer visuellen Anleitung auf YouTube, wo ich die Schritte dann bloß nachmachen müsste.
Aber ob ich das jetzt einfach so hinkriege, trotz der doch sehr detaillierten Ausführung - ich glaube eher nicht.

Was ich noch erfahren habe: auf Github hatte einer genau dasselbe Problem wie ich und es aber gelöst bekommen mittels Python & Julia Scripts. Der hat mir aber erzählt, dass die WA-Datenbank wohl bestimmte Trigger eingebaut hat und sobald man an einer Stelle eine Änderung vornimmt, würden u.U. bestimmte Trigger ausgelöst, die dann an irgendeiner anderen Stelle ungewollt irgendwas verändern.

Um dem vorzubeugen hat er, so sagte er mir, in seinem Programm sämtliche "creation commands" aller Trigger gesammelt, diese gespeichert, dann gelöscht, danach die Änderungen an der Datenbank vorgenommen und abschließend die Trigger wieder aktiviert anhand der gespeicherten Commands.

Ist das hier also auch notwendig so ein Schritt?

Dass der Prozess auch nur klappt, wenn beide DB Schemas identisch sind, brauch ich wohl nicht erwähnen.

Dadurch, dass beide Backups aus derselben (aktuellsten) WA-Version stammen, sollten beide vom Aufbau her identisch sein. Schwieriger würde es wohl sein, ein Backup von vor 5 Jahren mit einem heutigen zu mergen, denn da sind die Schemas anders.
In der Theorie müsste man das alte Backup erst regulär in WhatsApp (aktuellste Version) einspielen und danach in WA ein manuelles Backup auslösen, dann wird gemäß der neusten Version automatisch auf das neuste Schema upgedatet.

 

[Yuuri]

Aber ob ich das jetzt einfach so hinkriege, trotz der doch sehr detaillierten Ausführung - ich glaube eher nicht.

Im Detail ist es halt kein simples Unterfangen und ohne Kenntnisse in wenigstens SQL sowieso nicht machbar. Es kommt auch speziell auf die Implementierung selbst an.

Das Ganze in ein allgemeingültiges Script zu packen sollte aber problemlos möglich sein. Ist dann eben entsprechender Aufwand. Du müsstest dich dann "lediglich" tiefer in Programmierung einarbeiten, damit du halbwegs verstehst, wie Dependencies (FK -> PK) u.ä. aufgelöst werden sollten und das Ganze dann auch rekursiv nach unten arbeiten kann. Ist aber natürlich komplett optional und nur für mehrfache Anwendung sinnvoll. Ggf. auch ein Tool schreiben, was die DB analysiert und lediglich die relevanten Querys ausspuckt.

Den Prozess selbst hab ich dir wie gesagt oben dargelegt. Wie das Schema im Detail aussieht und auf was du achten musst, hängt eben von der DB selbst ab und wieviel "Magie" da enthalten ist. Musst halt nachsehen, wie du das jeweils in SQL umsetzt. Das würde für nen manuellen Durchlauf ja reichen. Am Besten in ein eigenständiges Script packen, dann kannst du iterativ zum Ziel kommen.

Du könntest dich hierbei etwas an dem zweiten Link von mir orientieren. Da hast du zumindest eine Behandlung der PKs (wenn auch etwas eigenartig) und müsstest das "nur" für die FKs selbst hinbasteln. Die FKs sind hier natürlich der komplexere Teil.

Das ist an der Stelle aber auch kein korrekter Merge. Also technisch ja, dadurch dass die IDs dann aber "gestapelt" auftreten, ist es logisch zumindest nicht der Fall. Keine Ahnung ob das für WA ggf. relevant ist. In dem Fall müsstest du komplett alles mit neuen IDs versehen. Je nach Fall wäre das ggf. sogar der einfachere Weg.

Ist das hier also auch notwendig so ein Schritt?

Wenn dort Trigger gesetzt sind, dann müssen die notfalls eben deaktiviert werden. Keine Ahnung ob SQLite das zur Runtime kann. Sonst musst du die eben auch vorher löschen, deine Updates machen und wieder hinzufügen. Für Foreign Keys gibts immerhin https://www.sqlite.org/pragma.html#pragma_foreign_keys.

Python und Julia braucht man dafür zumindest nicht bzw. sind das eben auch nur Werkzeuge. Das sollte auch notfalls mittels einfachstem Bash umsetzbar sein, je nachdem wie komplex du das gestaltet oder welche Komplexität der Daten dich so erwarten. PowerShell unter Windows, aber da hast du ja zum Glück das ganze .NET im Hintergrund, mit welchem du arbeiten kannst.

 

[Marvolo]

Im Detail ist es halt kein simples Unterfangen und ohne Kenntnisse in wenigstens SQL sowieso nicht machbar.

Und genau die fehlen mir halt leider als völliger Anfänger. Genau deshalb hatte ich im ersten Beitrag ja auch geschrieben, dass ich auf der Suche bin nach einem Forum oder Ort, wo Hobbyinformatiker oder auch professionelle Informatiker - gerne auch gegen eine kleine Aufwandsentschädigung - "Aufträge" suchen und annehmen, um mir dabei zu helfen. Ich weiß aber nicht, ob und wo es so eine Plattform gibt, wo man sich mit Aufträgen suchend an wissende und fähige Leute wenden könnte.

Ich denke, für jemanden, der die Grundprinzipien dahinter versteht und weiß, wie das alles zusammenhängt, sollte es vielleicht schnell (bzw. wesentlich schneller als für mich) machbar sein, da irgendwas zu schreiben, das dann genau das macht, was ich brauche. Es wurde ja wie schon gesagt in der Vergangenheit schon von mehreren bewerkstelligt - also es wäre ja kein noch nie dagewesenes Unterfangen.

Auf meiner Suche bin ich auch auf diese Methode hier gestoßen, was sich wohl ausschließlich nur auf DB Browser SQlite bezieht und eine Art SQL Execution sein soll:

https://crackowrld.wordpress.com/2015/02/17/merge-two-whatsapp-database-into-one/

Da dieser Artikel, wie auch der große XDA Thread zum Thema WA-Database-Merging (wo auch einige von Erfolgen sprachen) aber beide von vor 10 Jahren sind, bezweifle ich, dass das so heute noch funktioniert. WA von vor 10 Jahren ist ja ein ganz anderes als das heute.

Ich denke, die am ehesten funktionierende Methode ist die, von eben jenem Nutzer auf Github, der das Ganze für sich selber erst vor 3 Monaten erfolgreich hinbekommen hat. Den hatte ich natürlich auch schon nach Hilfe bzw. Unterstützung gefragt - auch gegen eine kleine Aufwandsentschädigung - aber ihm ist das zeitlich wohl nicht möglich. Und leider weiß ich auch im Detail nicht, wie er das gemacht hat, außer, dass er sich was selber geschrieben hat mit Python & Julia und dass er mich auf die Gefahr der "Trigger" hingewiesen hat, die man vorher wohl alle deaktivieren sollte.

Also halten wir fest: unmöglich scheint das nicht zu sein und auch mit der aktuellsten Version im Jahre 2024 wurde das gerade erst vor wenigen Monaten so durchgeführt von einem User. Nur fehlen mir persönlich dafür das Verständnis und die Werkzeuge, um das zu machen.

Wenn, wie gesagt, irgendwo eine ausführliche Schritt-für-Schritt-Anleitung wäre, die ich abarbeiten könnte, dann würde ich es u.U. selber hinbekommen bzw. traue ich mir das damit schon zu. Aber ohne so eine Hilfe, stehe ich da, wie die Kuh vor'm Berg und weiß gar nicht erst, wo, wie und womit ich anfangen soll.

 

[Micke]

ich schau mir das mal mit an .... aktuell suche ich im Android aber noch das key file für die DB

 

[M-X]

gegen eine kleine Aufwandsentschädigung - "Aufträge" suchen und annehmen

https://www.fiverr.com/

 

[Marvolo]

ich schau mir das mal mit an .... aktuell suche ich im Android aber noch das key file für die DB

Da kann ich dir helfen. Den Key für deine Database bekommst du auf zwei Wegen:

Entweder dein Android ist gerootet, dann befindet sich der Key im WhatsApp Directory / Verzeichnis im Ordner "File".

Falls dein Android nicht gerootet ist, kriegt man den Key (inklusive direkt schon entschlüsselter Database) mittels des WhatsApp Key Database Extractors. Ich habe es mit Hilfe dieser visuellen YouTube-Anleitung gemacht und es direkt beim ersten Mal gleich hinbekommen.
Das Script funktioniert offline - braucht also keinerlei Internetverbindung und lädt deshalb auch nichts hoch oder runter im Hintergrund für diejenigen, die da Sorge hätten.

Es ist total simpel, das hab sogar ICH hingekriegt und das will dann schon was heißen. Dieses Tool holt sich mittels ADB-Pull und dem temporären draufspielen einer älteren Legacy Version von WhatsApp den aktuellen Key aus dem Root-Verzeichnis UND entschlüsselt direkt auch schon die Database, wofür du dann am Ende den Key eigentlich gar nicht mehr bräuchtest. Die Database liegt dann als *db vor. So wie bei mir im Screenshot oben.

Es ist kein Backup notwendig, es gehen keine Daten verloren. Nachdem das Script fertig ist, lädt es deine aktuelle WA-Version wieder drauf und alles ist direkt wieder so da, wie vorher. Nichtmal Neueingabe der Nummer oder Neu-Registrierung notwendig.

Aber Achtung: leider funktioniert dieses Tool aus irgendwelchen Gründen nicht mehr mit den aktuellsten Android-Versionen. Ich musste dafür mein WhatsApp migrieren auf ein älteres Huawei P30 Lite aus 2019. Damit ging es dann.
(Vermutung: Offensichtlich funktioniert ADB mit den neusten Android-Versionen nicht mehr?)

Bei meinem aktuellen S24 Ultra kommt beim Versuch, die Legacy WhatsApp-Version drauf zu spielen, ständig ein "No-matching-APIS"-Error. (Falls da jemand ne Lösung hätte, damit ich nicht ständig aufs alte Huawei ausweichen muss, wenn ich mal die aktuelle Database plus Key extrahieren möchte, wäre sicherlich auch sehr schön).

Danke dir jedenfalls, dass du dir das mal anschauen willst.

 

[Micke]

Entweder dein Android ist gerootet, dann befindet sich der Key im WhatsApp Directory / Verzeichnis im Ordner "File".

musste erst noch rooten ...

wofür du dann am Ende den Key eigentlich gar nicht mehr bräuchtest

Evtl., denn auch wenn dein Decrypt erfolgreich war, akzeptiert Whatsapp denn auch eine entschlüsselte DB ? Falls nicht, müsste man erst noch das Verschlüsseln klären, bevor man sich die Arbeit mit dem eigentlichen merge macht.
Hier ist ein guide für beide Richtungen wa-crypt-tools, hab ich aber noch nicht benutzt.

 

[Marvolo]

Evtl., denn auch wenn dein Decrypt erfolgreich war, akzeptiert Whatsapp denn auch eine entschlüsselte DB ?

Bei Root tut es das. Bzw. TAT es das in der Vergangenheit. Ob es das jetzt immer noch tut in der aktuellen Version, wäre nun die Frage. Aber falls nicht und das hast du ja schon selber herausgefunden:

Mit den WaEnCrypt-Tools kann man das Ganze erfolgreich wieder so verschlüsseln, dass WA es akzeptiert. Da steht ja sogar, wie genau, nämlich indem man den Header speziell modifiziert. Dieser User dort ist es übrigens auch, der das selber vor 3 Monaten bei sich gemacht hat - also Datenbank modifiziert / zusammengeführt etc und dann mit den WaEnCrypt-Tools wieder verschlüsselt und jetzt läuft das auf WA seiner Aussage nach, als wär es nie anders gewesen.

Das Verschlüsseln ist aber der letzte Schritt - der zunächst wichtigere wäre die Bearbeitung der Datenbank in einer Weise, das alles korrekt miteinander abgestimmt ist und WA da nachher nicht rummuckt. Im XDA-Thread gab es nämlich auch Leute, die zwar den Merge irgendwie hinbekommen haben, aber danach berichtet haben, dass einzelne Nachrichten in WA teilweise in ganz anderen Chats wieder aufgetaucht sind, etc.. Also alles total durcheinander war.

 

[Micke]

Das Verschlüsseln ist aber der letzte Schritt

schon, aber bei 2 kritischen Schritten würde ich erst den einfacheren klären.

Die WaEnCrypt-Tools werfen bereits beim Decodieren einen Fehler. Muss ich noch klären warum.

temporären draufspielen einer älteren Legacy Version von WhatsApp

das ist mir zu viel
Vielmehr ist das nicht zielführend, deshalb vernachlässigt.

 

[Marvolo]

schon, aber bei 2 kritischen Schritten würde ich erst den einfacheren klären.

Die WaEnCrypt-Tools werfen bereits beim Decodieren einen Fehler. Das reduziert meinen Antrieb, wenn das zum eigentlichen Problem noch dazu kommt.

Die habe ich nie benutzt, deshalb kann ich da auch jetzt nicht viel dazu sagen, was da für Fehler kommen und woran es liegt. Müsste man u.U. dort auf Github mal in den Issues oder im Diskusionsboard nachschauen, ob der Fehler dort gelistet ist und wie man ihn auch behebt.

Wie gesagt, ich habe den oben verlinkten Database Key Extractor benutzt, der mir das ohne Probleme direkt beim ersten Durchgang ausgespuckt hat: Key-File und bereits entschlüsselte Database, mit der man dann fortan arbeiten kann in DB Browser.

das ist mir zu viel

Das müsstest du nun erläutern. Der User selber muss überhaupt nichts weiteres tun, als das Script anzuwerfen und den Rest macht das Script innerhalb von nicht mal 1 Minute von selbst. Am Ende vom Prozess hast du dein normales, akutelles WA wieder auf dem Gerät wie vorher auch. Du kriegst da im Grunde nicht mal groß was mit, dass das Script im Hintergrund was gemacht hat. Im oben verlinkten YouTube-Video ist das sogar noch visuell Schritt für Schritt erklärt.

Wie ja bereits geschrieben: das hab sogar ICH in nicht mal 2 Minuten hinbekommen und ich bin jetzt wirklich nicht gerade firm in diesem ganzen Coding-Zeug... Von Aufwand oder "zu viel Einsatz" kann zumindest bei diesem Schritt hier echt keine Rede sein, meiner Meinung nach.

Der eigentliche "große Einsatz" dürfte dann erst danach die Modifikation der Datenbank an sich sein, das würde ich selber so unterschreiben. Aber das reine Entschlüsseln mit diesem Script ist in unter 1 Minute erledigt...

 

[Marvolo]

Vielmehr ist das nicht zielführend, deshalb vernachlässigt.

Das verstehe ich nicht. Bei mir war es sogar maximal zielführend, nämlich insofern, dass es mir meine verschlüsselten Datenbanken direkt entschlüsselt hat (was ja das primäre Ziel ist) und als kleines Nebengeschenk sogar noch die Key-File mit ausgespuckt hat, plus weitere Dateien, wie die Handynummern-Datenbank.

Wenn du die Datenbank bearbeiten willst, muss sie entschlüsselt sein und genau das macht dieses Script. Inwiefern ist das jetzt nicht zielführend?

Das hier spuckt das Script nach nicht mal einer Minute aus - und das ist alles, was man braucht. Die msgstore.db ist die entschlüsselte Datenbank, um die es geht... Die Key-File wird mit ausgespuckt, aber die bräuchte man gar nicht, denn die Datenbanken hier sind ja alle schon entschlüsselt...

Eventuell kriegt man dasselbe auch mit deinen genannten WadeCrypt-Tools hin, dafür sollen sie ja angeblich gemacht sein. Aber wie gesagt, hab ich nie verwendet und mit dem Key-Database-Extractor-Script war das Thema in 1-2 Minuten gegessen.