Windows.edb vs. Windows.db: Suchindex in Windows 10 und 11

Kurz gesagt. Gleiches Datenmodell, anderer Behälter. Windows 10 und älter speichern den Index in einer einzigen ESE-Datei, Windows.edb, mit einer breiten Zeile pro Element in SystemIndex_PropertyStore und Spalten wie 4447-System_ItemPathDisplay. Windows 11 verteilt ihn auf SQLite-Dateien: Windows.db enthält SystemIndex_1_PropertyStore als schmale Zeilen (WorkId, ColumnId, Value) plus eine Metadatentabelle, die jede ColumnId benennt, und Windows-gather.db enthält die Gather-Tabellen. Beide halten jüngste Änderungen außerhalb der Hauptdatei (ESE-Protokolle bzw. SQLite-WAL). Ein Parser muss die Windows-11-Zeilen wieder zu einem Datensatz pro Element pivotieren und das WAL lesen, sonst zeigt er einen veralteten Index.

Auf einen Blick

Der Speicherort ist derselbe: C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. Microsofts Troubleshooting-Leitfaden spricht von Windows.edb unter Windows 10 und Windows.db unter Windows 11. Veröffentlichte Quellen sind sich über die genaue Windows-11-Version des Formatwechsels nicht einig. Ein aktualisierter Rechner kann zudem eine alte Datei mitschleppen. Besser nachsehen, was tatsächlich im Ordner liegt, und die Dateiheader prüfen (SQLite format 3 gegenüber der ESE-Signatur), statt aus der Versionsnummer zu schließen.

Windows 10: eine breite Tabelle

In Windows.edb hat SystemIndex_PropertyStore eine Spalte für jede Eigenschaft, die der Indexer kennt, Hunderte davon. Die Spaltennamen tragen ein numerisches Präfix und den kanonischen Eigenschaftsnamen, Punkte durch Unterstriche ersetzt:

WorkID
4447-System_ItemPathDisplay
4414-System_FileName
4498-System_Size
4520-System_Search_GatherTime
4516-System_Search_AutoSummary
...

(Die Nummern unterscheiden sich zwischen Datenbanken. Immer nach dem Namen hinter dem Bindestrich gehen.)

Die meisten Spalten sind in den meisten Zeilen leer, und genau dafür gibt es die Tagged Columns von ESE: dünn besetzte Werte, die keinen Platz belegen, wenn sie fehlen. Lange Werte, etwa ein großer Inhaltsauszug, können außerhalb der Zeile in einem separaten Long-Value-Baum stehen, und viele Textspalten sind komprimiert. Wie das auf der Platte funktioniert, steht in ESE-Grundlagen für Forensiker.

Windows Vista und 7 nutzten eine Tabelle namens SystemIndex_0A mit eigener Wertkodierung. Wer mit diesen Systemen arbeitet, sollte prüfen, ob der eigene Parser sie unterstützt. Der Windows Search Index Parser dekodiert diese Kodierung noch nicht.

Windows 11: Zeilen aus Eigenschaften

Windows.db normalisiert dieselben Daten. Eine einzelne Datei sähe in SystemIndex_1_PropertyStore so aus:

Und SystemIndex_1_PropertyStore_Metadata verrät, dass ColumnId 4447 System.ItemPathDisplay ist, mit einem UniqueKey wie 4447-System_ItemPathDisplay (derselbe String, der in ESE der Spaltenname war) und einem Speichertyp. Die Forschung von Stroz Friedberg von 2023 und Kasperskys Beitrag zu den Artefakten von Windows 11 beschreiben beide diesen Aufbau.

Folgen für die Analyse:

• Pivotieren ist Pflicht. Ein SELECT * liefert Eigenschaftssuppe. Nach WorkId gruppieren, die Metadaten verknüpfen und jede ColumnId in ein benanntes Feld verwandeln.
• Werte sind über die Metadaten typisiert, nicht über die Spalte. Öffentliche Forschung und die Dekodierung des Parsers behandeln Speichertyp 11 als String und 12 als 8-Byte-Little-Endian-Ganzzahl oder FILETIME. Microsoft dokumentiert die Codes nicht; ein sorgfältiger Parser rät beim Rest und bewahrt die Rohbytes.
• Auf den Tabellentyp achten. Eine Tabelle mit dem Schlüssel (WorkId, ColumnId) kann als WITHOUT ROWID angelegt sein; dann liegen ihre Zeilen in einem Index-B-Tree statt in einem Tabellen-B-Tree. Einfache SQLite-Leser, die nur Rowid-Tabellen durchlaufen, sähen nichts. Der Parser beherrscht beides.
• Ordnerpfade kommen aus der Gather-Datenbank. SystemIndex_GthrPth ist ein Baum aus Bereichsnamen (Scope, Parent, Name). Den vollständigen Pfad durch Hochlaufen der Eltern rekonstruieren und dann FileName aus SystemIndex_Gthr anhängen.

Die Gather-Tabellen: in beiden dasselbe Prinzip

SystemIndex_Gthr hat eine Zeile pro Dokument, das der Crawler kennt: ScopeID, DocumentID, FileName, LastModified, TransactionFlags und mehr. SystemIndex_GthrPth liefert den Bereichsbaum. Der Stroz-Friedberg-Beitrag listet diese Spalten für beide Versionen. Die DocumentID entspricht der WorkId des Eigenschaftenspeichers; darüber werden beide verknüpft.

Unter Windows 11 liegen sie in einer eigenen Datei mit eigenem WAL. Wer nur Windows.db gesichert hat, verliert die Pfadrekonstruktion und vor allem den Vergleich „im Eigenschaftenspeicher, aber nicht in der Gather-Tabelle“, einen der besseren Hinweise auf eine gelöschte Datei.

Jüngste Änderungen: Protokolle vs. WAL

Beide Engines protokollieren vor dem Schreiben, doch die forensischen Folgen unterscheiden sich.

ESE schreibt Änderungen zuerst in MSS*.log und überträgt sie später in Windows.edb. Eine im laufenden Betrieb kopierte Datenbank ist als Dirty Shutdown markiert. Die neuesten Änderungen stehen nur in den Protokollen, bis man sie mit esentutl /r nachspielt. Siehe Windows.edb nach Dirty Shutdown reparieren.

SQLite hängt bestätigte Seiten an Windows.db-wal an. Sie werden bei einem Checkpoint in die Datenbank übernommen, standardmäßig wenn das WAL 1.000 Seiten erreicht oder die letzte Verbindung geschlossen wird, laut SQLite-Dokumentation. Leser schauen zuerst ins WAL. Für Analysten gibt es keinen „Nachspiel“-Schritt: Ein WAL-fähiger Parser liest einfach die neueste Version jeder Seite. Noch besser: Der Vergleich der Datenbank mit und ohne WAL zeigt, welche Elemente die jüngsten Transaktionen hinzugefügt oder geändert haben. Deshalb markiert der Windows Search Index Parser Elemente als nur im WAL oder im WAL geändert. Siehe Windows.db-Forensik: SQLite und das WAL.

Womit arbeitet es sich leichter?

Für Forensiker ist Windows 11 leichter zu lesen und schwerer vollständig zu lesen.

• Leichter: SQLite ist dokumentiert, und jede Sprache hat einen Leser. Die Ausgabe eines Parsers lässt sich mit sqlite3 auf einer Kopie in Minuten prüfen.
• Schwerer: Pivot, typisierte Blobs, getrennte Gather-Datenbank und WAL müssen alle stimmen, und die Speichertyp-Codes sind nicht dokumentiert.
• ESE ist das Gegenteil: ein schwereres Format (Katalog, B+-Bäume, Tagged Columns, Long Values, Kompression), aber eine eigenständige Datei, deren Aufbau libesedb gut dokumentiert.

Was das Tool mit beiden macht

Der Windows Search Index Parser verarbeitet beide im Browser:

• Windows.db: eigener SQLite- + WAL-Leser (WITHOUT-ROWID-fähig), pivotiert SystemIndex_1_PropertyStore zu einem Element pro WorkId, verknüpft Windows-gather.db über DocumentID, rekonstruiert Ordnerpfade und markiert Elemente nur im WAL bzw. im WAL geändert. Ein WAL, das zu einer anderen Datenbank gehört, wird erkannt und ignoriert. Da die genaue Windows-11-DDL nicht dokumentiert ist, beruhen Pfadrekonstruktion und Teile der Dekodierung auf öffentlicher Forschung und Heuristiken.
• Windows.edb: eigener schreibgeschützter ESE-Leser (Katalog, B+-Bäume, feste / variable / Tagged Columns, Long Values, 7-Bit- und XPRESS-Kompression), der SystemIndex_PropertyStore und die Gather-Tabellen liest. Ehrlicher Vorbehalt: Dieser Leser wurde bisher nur an synthetischen Datenbanken validiert. Seine Ausgabe als Hinweis behandeln und zentrale Befunde mit einem anderen Tool bestätigen.

Verwandte Artikel

• Windows-Search-Index-Forensik: der vollständige Leitfaden
• Die Eigenschaften des Windows-Search-Index erklärt
• ESE-Grundlagen für Forensiker