Gelöschte Windows-Benachrichtigungen wiederherstellen

Kurz gesagt. Wird in SQLite eine Zeile gelöscht, markiert SQLite ihren Speicher als frei; die Bytes bleiben erhalten, bis er wiederverwendet wird (sofern secure_delete nicht aktiv ist). Für wpndatabase.db heißt das: Geschlossene und abgelaufene Benachrichtigungen — auch Chat-Vorschauen — lassen sich oft aus freiem Speicher in Seiten, aus der Freelist und aus älteren Seitenabbildern in der Datei und der WAL wiederherstellen. Behandeln Sie jede wiederhergestellte Zeile als Spur, nicht als gesicherten Datensatz.

Wo sich gelöschte Zeilen verbergen

Das SQLite-Dateiformat bietet vier Stellen:

1. Freeblocks. Der Speicher einer gelöschten Zelle wird zu einem Freeblock in derselben B-Tree-Seite. Nur die ersten vier Bytes werden überschrieben (der Zeiger auf den nächsten Freeblock und die Blockgröße); der Rest des Datensatzes — einschließlich Payload — bleibt intakt.
2. Die Freelist. Enthält eine Seite keine Zeile mehr, landet sie samt Inhalt in der Freelist, bis SQLite wieder eine Seite benötigt.
3. Überholte Seiten in der Datenbankdatei. Liegt eine WAL vor, enthält die Datei die Seite im Zustand des letzten Checkpoints. Hat eine spätere Transaktion eine Zeile gelöscht, steckt sie noch im alten Seitenabbild.
4. WAL-Frames. Die WAL enthält aufeinanderfolgende Versionen von Seiten. Ältere Frames und Frames einer früheren WAL-Generation können Zeilen enthalten, die in neueren Versionen fehlen.

Eine Benachrichtigungsdatenbank eignet sich gut dafür: Payloads sind wenige hundert Byte charakteristisches XML, Zeilen wechseln ständig, und die Datei wird selten mit VACUUM bereinigt.

Wie der Parser sie wiederherstellt

Der Windows Notification Parser nutzt zwei Verfahren:

• Durch die WAL gelöscht. Zeilen, die in der gecheckpointeten Datenbank vorhanden sind, nach Anwendung der WAL aber fehlen, sind exakt: Der Parser liest sie mit dem normalen Record-Decoder und kennzeichnet sie als „durch eine Transaktion in der WAL gelöscht“.
• Payload-verankertes Carving. Jedes <toast, <tile, <badge oder <?xml, das in einer Seite oder einem WAL-Frame gefunden wird, ist ein möglicher Beginn eines Payload-Werts. Für jeden Treffer sucht der Parser rückwärts nach einem Record-Header, dessen Serial Types zum aktiven Notification-Schema passen und den Payload genau an diesem Offset platzieren. Spaltentypen, ein plausibler FILETIME-Wert und ein ASCII-Type müssen ebenfalls stimmen. Payloads, die auf Overflow-Seiten ausgelagert wurden, werden aus der Kette zusammengesetzt, sofern sie noch vorhanden ist; andernfalls wird die Zeile als unvollständig markiert.

Zeilen, die mit einer aktiven Zeile identisch sind, werden verworfen. Eine gecarvte Zeile mit derselben Id wie eine aktive, aber abweichendem Inhalt wird als frühere Version angezeigt.

Eine wiederhergestellte Zeile lesen

Jede wiederhergestellte Benachrichtigung gibt ihre Herkunft an, zum Beispiel free space in page 4, freelist page 12 oder WAL frame 3 (page 5). Prüfen Sie drei Dinge, bevor Sie sie verwenden:

• Ist sie vollständig? Einer unvollständigen Zeile fehlt ein Teil des Payloads oder es fehlen Felder.
• Existiert ihr Handler noch? HandlerId wird gegen die aktive Handler-Tabelle aufgelöst; ein fehlender Handler ist möglich.
• Passt sie in die Zeitlinie? Eine Eingangszeit mitten in anderer Aktivität ist ein gutes Zeichen; eine Zeit weit außerhalb der Daten verdient Misstrauen.

Grenzen

• Speicher wird wiederverwendet, sobald neue Benachrichtigungen eintreffen: Je länger die Löschung zurückliegt, desto schlechter die Wiederherstellung.
• VACUUM schreibt die Datei neu und verwirft freien Speicher.
• Hat ein Build secure_delete aktiviert, wird freigegebener Inhalt mit Nullen überschrieben. Ob ein Windows-Build dies tut, ist nicht dokumentiert; ein leeres Ergebnis beweist nicht, dass nichts vorhanden war.
• Ein Datensatz, dessen Header überschrieben wurde, lässt sich mit diesem Verfahren nicht wiederherstellen. Es gibt andere Carving-Ansätze; dieser setzt auf wenige False Positives.

FAQ

Lassen sich gelöschte Windows-Benachrichtigungen wiederherstellen?

Oft ja, solange SQLite den Speicher nicht wiederverwendet. Eine gelöschte Zeile bleibt als Freeblock in der Seite, ganze Seiten wandern in die Freelist, und ältere Seitenabbilder verbleiben in der Datenbankdatei und in der WAL. Wiederhergestellte Zeilen sind Best-Effort-Beweismittel und sollten entsprechend gekennzeichnet werden.

Zerstört das Öffnen der Datenbank gelöschte Datensätze?

Das kann passieren. Wird eine WAL-Datenbank mit SQLite geöffnet und wieder geschlossen, kann ein Checkpoint die WAL übernehmen und zurücksetzen, und Schreibzugriffe verwenden freien Speicher wieder. Arbeiten Sie mit gehashten Kopien.