Windows.edb-Parser im Vergleich: SIDR, ESEDatabaseView
Ein fairer Vergleich von Parsern für den Windows-Search-Index: SIDR, WinSearchDBAnalyzer, ESEDatabaseView, esedbexport, sqlite3 und dieser Browser-Parser.
Kurz gesagt. Für flottenweite Sicherung und Standardberichte unter Windows 10 und 11: SIDR (Stroz Friedberg / LevelBlue). Zur Wiederherstellung gelöschter Datensätze aus Windows.edb: WinSearchDBAnalyzer. Für einen Rohblick auf beliebige ESE-Tabellen: ESEDatabaseView (Windows-GUI) oder esedbexport aus libesedb (plattformübergreifende CLI). Unter Windows 11 ist die sqlite3-Shell auf einer Kopie die Referenz. Der Windows Search Index Parser passt, wenn keine Installation, kein Upload, eine pivotierte Zeile pro Element über beide Formate, WAL-basierte Unterschiede und Triage-Markierungen gefragt sind. Sein ESE-Leser ist nur an synthetischen Daten validiert, also mit einem der anderen gegenprüfen. Wenn Befunde zählen, zwei Tools laufen lassen und vergleichen.
Kein Tool kann hier alles, und das Format ist so schlecht dokumentiert, dass zwei Parser bei echten Daten voneinander abweichen können. Im Folgenden, wofür jedes Tool gebaut ist, laut eigener Dokumentation und soweit ich es prüfen konnte, ohne Benchmarks, die ich nicht reproduzieren kann.
Die Tools
| Tool | Formate | Oberfläche | Besondere Stärke | Quelle |
|---|---|---|---|---|
| SIDR | Windows.edb, Windows.db | CLI (Rust) + Velociraptor-Artefakt | Drei Standardberichte: Dateien, Internetverlauf, Aktivitätsverlauf | strozfriedberg/sidr |
| WinSearchDBAnalyzer | Windows.edb | Windows-GUI | Stellt gelöschte Datensätze wieder her; kann aus einem laufenden System extrahieren | moaistory/WinSearchDBAnalyzer |
| ESEDatabaseView | Jede ESE-Datei | Windows-GUI + Export per Kommandozeile | Generischer Tabellen-Viewer, viele Exportformate, ohne Abhängigkeit von esent.dll | NirSoft |
| esedbexport (libesedb) | Jede ESE-Datei | Plattformübergreifende CLI / C-Bibliothek | Offene, dokumentierte Implementierung des Formats; exportiert jede Tabelle | libyal/libesedb |
| sqlite3 / DB Browser for SQLite | Windows.db, Windows-gather.db | CLI / GUI | Referenz-Engine von SQLite: Grundwahrheit für Windows 11 | sqlite.org |
| Windows Search Index Parser | Windows.edb, Windows.db (+ WAL, Gather-Datenbank) | Browser, WebAssembly, ohne Installation | Pivotierte Elemente, WAL-Markierungen, Gather-Abgleich, Triage, rein lokal | diese Website |
SIDR
SIDR (Search Index Database Reporter) wurde von Stroz Friedberg zusammen mit der Forschung von 2023 von Kulkarni und Paluch veröffentlicht. Laut README durchsucht es ein Verzeichnis nach Windows.edb und Windows.db und schreibt drei nach dem Host benannte Berichte: einen File Report, einen Internet History Report und einen Activity History Report, als JSON oder CSV. Es enthält ein Velociraptor-Artefakt velosidr.yaml, um es auf Endpunkten auszuführen. Apache-2.0-Lizenz.
sidr -f csv -o D:\case\reports D:\case\search
Die richtige Wahl, wenn viele Hosts zu verarbeiten sind, einheitliche Berichte über Fälle hinweg gewünscht sind oder Aktivitäts- und Internetverlauf bereits getrennt vorliegen sollen. Zu bedenken: Es erzeugt kuratierte Berichte statt aller Roh-Eigenschaften und setzt als CLI voraus, dass Sicherung und Sichtung anderswo stattfinden.
WinSearchDBAnalyzer
Geschrieben von Jeonghyeon Kim (moaistory), beschrieben in seinem Blog und auf GitHub unter MIT-Lizenz veröffentlicht. Das README hebt die Wiederherstellung gelöschter Datensätze aus Windows.edb hervor, die Extraktion aus einem laufenden System, das Parsen von Dateien „unabhängig vom Zustand“ sowie Kategorien wie Mail, OneNote-Titel, Internetverlauf und Aktivitätsverlauf. Es gibt Forks, die das Projekt weiterführen, darunter einen von Andrew Rathbun.
Die richtige Wahl, wenn Datensätze gebraucht werden, die in der ESE-Datenbank nicht mehr aktiv sind. Genau diese Lücke lassen die meisten Parser offen, dieser eingeschlossen. Zu bedenken: Es zielt auf das ESE-Format von Windows 10 und älter, nicht auf die SQLite-Windows.db von Windows 11, und ist eine Windows-GUI-Anwendung.
ESEDatabaseView
Der generische ESE-Viewer von NirSoft. Er öffnet jede ESE-Datenbank (Windows.edb, SRUDB.dat, WebCacheV01.dat und weitere), erlaubt das Durchsuchen und Filtern von Tabellen und den Export nach CSV, HTML, XML, JSON und in andere Formate, über die GUI oder die Kommandozeile. NirSoft gibt an, dass er esent.dll nicht benötigt. Die Dokumentation räumt offen ein, dass bei Tabellen mit komplexer Datenstruktur manche Felder falsche oder leere Werte zeigen können.
Die richtige Wahl, wenn man SystemIndex_PropertyStore oder die Gather-Tabellen roh so sehen will, wie sie gespeichert sind, oder eine Spalte prüfen will, die ein anderes Tool leer anzeigt. Zu bedenken: Er kennt ESE, nicht Windows Search. Kein Pivot, keine Pfadrekonstruktion aus dem Gather-Baum, keine Interpretation von Eigenschaften und keine Windows-11-Unterstützung, da Windows.db SQLite ist.
esedbexport (libesedb)
libesedb von Joachim Metz ist eine offene C-Bibliothek für ESE-Dateien mit den Tools esedbinfo und esedbexport. Ihre Formatdokumentation ist die Referenz, auf der die meisten ESE-Parser aufbauen, dieser eingeschlossen. Das Projekt bezeichnet sich selbst als experimentell.
esedbexport -t D:\case\export Windows.edb
Die richtige Wahl, wenn ein skriptbarer, plattformübergreifender Dump aller Tabellen oder eine zweite Meinung zur ESE-Schicht selbst gebraucht wird. Zu bedenken: Die Ausgabe ist eine Textdatei pro Tabelle, die Interpretation bleibt bei einem selbst.
sqlite3 und DB Browser for SQLite
Für Windows.db ist die offizielle SQLite-Engine die Referenz. Die Verknüpfung von SystemIndex_1_PropertyStore mit seiner Metadatentabelle auf einer Kopie liefert überprüfbare Grundwahrheit. Die Abfragen stehen in Windows.db-Forensik: SQLite und das WAL.
Zu bedenken: nur auf einer Kopie arbeiten. Ein normaler SQLite-Client kann das WAL beim Schließen checkpointen und den Vorher-Nachher-Vergleich zerstören.
Der Windows Search Index Parser
Was er laut eigenem README und eigener Oberfläche tut:
- Liest
Windows.db(mit-walundWindows-gather.db) undWindows.edbmit eigenen SQLite- und ESE-Lesern, kompiliert von Rust nach WebAssembly, in einem Web Worker. Nichts wird hochgeladen. - Pivotiert alle Eigenschaften jedes Elements zu einer Zeile, verknüpft die Gather-Tabellen, rekonstruiert Ordnerpfade.
- Markiert Elemente nur im WAL bzw. im WAL geändert; markiert Elemente ohne Gather-Eintrag, Inhaltsauszüge, ausführbare Dateien, Archive, andere Laufwerke, Netzwerkpfade, vom Benutzer beschreibbare Ordner und kürzlich indizierte Elemente.
- Nimmt Ordner und KAPE- / Velociraptor-ZIPs unverändert an; exportiert CSV (gegen Formel-Injection geschützt) und JSON.
Was er nicht tut, klar gesagt:
- ESE-Validierung: Sein
Windows.edb-Leser wurde nur an synthetischen Datenbanken validiert. Deshalb warnt die Oberfläche davor. - Windows-11-Schema: Die Dekodierung folgt öffentlicher Forschung; DDL und Speichertyp-Codes sind nicht dokumentiert.
- Kein Carving: Gelöschte Datensätze in freien ESE-Seiten, SQLite-Freelists oder veralteten WAL-Frames werden nicht wiederhergestellt (defunct ESE-Einträge werden gezählt).
- Kein Nachspielen von
MSS*.log; keine Dekodierung derSystemIndex_0A-Werte von Vista / 7; kein XPRESS9 / XPRESS10 / LZ4. - Keine CLI, keine Automatisierung. Manuelle Triage, keine Pipeline.
Welche Kombination für welche Aufgabe
| Aufgabe | Erstes Tool | Gegenprüfen mit |
|---|---|---|
| Schnelle Triage eines Hosts, ohne Installation, sensible Daten | Windows Search Index Parser | sqlite3 (Win 11) oder ESEDatabaseView / esedbexport (Win 10) |
| Viele Hosts, Standardberichte | SIDR (+ Velociraptor) | Stichprobe eines Hosts mit einem zweiten Tool |
| Gelöschte Datensätze in Windows.edb | WinSearchDBAnalyzer | Aktive Datensätze in einem beliebigen Parser |
| Rohprüfung einer ESE-Tabelle | ESEDatabaseView oder esedbexport | Das jeweils andere |
| Fragen zum WAL von Windows 11 | Windows Search Index Parser (nur im WAL / geändert) | sqlite3 auf Kopien mit und ohne WAL |
Wenn Parser sich widersprechen
Typische Ursachen, in der Reihenfolge, in der ich sie prüfe:
- Unterschiedliche Eingaben. Ein Tool bekam das WAL oder die nachgespielte ESE-Datenbank, das andere nicht. Siehe die Anleitung zum Dirty Shutdown.
- Long Values und Kompression. Ein Auszug, der in einem Tool vorhanden und im anderen leer ist, bedeutet meist, dass eines einer Long-Value-Referenz nicht gefolgt ist oder einen komprimierten Wert nicht dekodiert hat. Siehe ESE-Grundlagen.
- Mehrwertige Spalten, auf den ersten Wert reduziert.
- Zeitdekodierung: Bytereihenfolge und UTC gegenüber Ortszeit.
- Datensatzauswahl: defunct-Datensätze angezeigt oder ausgeblendet; reine Gather-Einträge enthalten oder nicht.
Festhalten, welches Tool welchen Befund geliefert und welches ihn bestätigt hat. Genau danach fragt ein Reviewer.