Skip to content

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.

Veröffentlicht am 6 Min. Lesezeit

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

ToolFormateOberflächeBesondere StärkeQuelle
SIDRWindows.edb, Windows.dbCLI (Rust) + Velociraptor-ArtefaktDrei Standardberichte: Dateien, Internetverlauf, Aktivitätsverlaufstrozfriedberg/sidr
WinSearchDBAnalyzerWindows.edbWindows-GUIStellt gelöschte Datensätze wieder her; kann aus einem laufenden System extrahierenmoaistory/WinSearchDBAnalyzer
ESEDatabaseViewJede ESE-DateiWindows-GUI + Export per KommandozeileGenerischer Tabellen-Viewer, viele Exportformate, ohne Abhängigkeit von esent.dllNirSoft
esedbexport (libesedb)Jede ESE-DateiPlattformübergreifende CLI / C-BibliothekOffene, dokumentierte Implementierung des Formats; exportiert jede Tabellelibyal/libesedb
sqlite3 / DB Browser for SQLiteWindows.db, Windows-gather.dbCLI / GUIReferenz-Engine von SQLite: Grundwahrheit für Windows 11sqlite.org
Windows Search Index ParserWindows.edb, Windows.db (+ WAL, Gather-Datenbank)Browser, WebAssembly, ohne InstallationPivotierte Elemente, WAL-Markierungen, Gather-Abgleich, Triage, rein lokaldiese 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 -wal und Windows-gather.db) und Windows.edb mit 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 der SystemIndex_0A-Werte von Vista / 7; kein XPRESS9 / XPRESS10 / LZ4.
  • Keine CLI, keine Automatisierung. Manuelle Triage, keine Pipeline.

Welche Kombination für welche Aufgabe

AufgabeErstes ToolGegenprüfen mit
Schnelle Triage eines Hosts, ohne Installation, sensible DatenWindows Search Index Parsersqlite3 (Win 11) oder ESEDatabaseView / esedbexport (Win 10)
Viele Hosts, StandardberichteSIDR (+ Velociraptor)Stichprobe eines Hosts mit einem zweiten Tool
Gelöschte Datensätze in Windows.edbWinSearchDBAnalyzerAktive Datensätze in einem beliebigen Parser
Rohprüfung einer ESE-TabelleESEDatabaseView oder esedbexportDas jeweils andere
Fragen zum WAL von Windows 11Windows 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:

  1. Unterschiedliche Eingaben. Ein Tool bekam das WAL oder die nachgespielte ESE-Datenbank, das andere nicht. Siehe die Anleitung zum Dirty Shutdown.
  2. 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.
  3. Mehrwertige Spalten, auf den ersten Wert reduziert.
  4. Zeitdekodierung: Bytereihenfolge und UTC gegenüber Ortszeit.
  5. 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.

Verwandte Artikel

Verwandte Artikel