Parseurs Windows.edb comparés : SIDR, ESEDatabaseView…

En bref. Pour la collecte à l'échelle d'un parc et des rapports standardisés sous Windows 10 comme 11, utilisez SIDR (Stroz Friedberg / LevelBlue). Pour récupérer des enregistrements supprimés dans Windows.edb, WinSearchDBAnalyzer. Pour un regard brut sur n'importe quelle table ESE, ESEDatabaseView (interface Windows) ou esedbexport de libesedb (ligne de commande multiplateforme). Pour Windows 11, le shell sqlite3 sur une copie est votre vérité de référence. Utilisez le Windows Search Index Parser quand vous voulez zéro installation, zéro envoi, une ligne pivotée par élément pour les deux formats, les différences liées au WAL et des signalements de triage. Son lecteur ESE n'a été validé que sur des données synthétiques : recoupez avec l'un des autres. Quand les constatations comptent, lancez deux outils et comparez.

Aucun outil ne fait tout ici, et le format est suffisamment peu documenté pour que deux parseurs divergent sur des données réelles. Voici à quoi sert chaque outil, d'après sa propre documentation et ce que j'ai pu vérifier, sans benchmarks que je ne peux pas reproduire.

Les outils

SIDR

SIDR (Search Index Database Reporter) a été publié par Stroz Friedberg en même temps que les travaux de 2023 de Kulkarni et Paluch. Selon son README, il parcourt un répertoire à la recherche de Windows.edb et Windows.db et produit trois rapports nommés d'après la machine : un File Report, un Internet History Report et un Activity History Report, en JSON ou CSV. Il est fourni avec un artefact Velociraptor velosidr.yaml pour l'exécuter sur les postes. Licence Apache 2.0.

sidr -f csv -o D:\case\reports D:\case\search

À privilégier quand vous traitez de nombreuses machines, voulez des rapports homogènes d'une affaire à l'autre, ou avez besoin de l'historique d'activité et de l'historique internet déjà séparés. À garder en tête : il produit des rapports sélectionnés plutôt que toutes les propriétés brutes, et en tant qu'outil en ligne de commande il suppose que la collecte et la relecture se font ailleurs.

WinSearchDBAnalyzer

Écrit par Jeonghyeon Kim (moaistory), présenté sur son blog et publié sur GitHub sous licence MIT. Son README met en avant la récupération d'enregistrements supprimés dans Windows.edb, l'extraction depuis un système actif, l'analyse de fichiers « quel que soit leur état » et des catégories comme le courrier, les titres OneNote, l'historique internet et l'historique d'activité. Des forks de reprise existent, dont un d'Andrew Rathbun.

À privilégier quand vous avez besoin d'enregistrements qui ne sont plus actifs dans la base ESE. C'est précisément le manque que la plupart des parseurs, celui-ci compris, laissent ouvert. À garder en tête : il cible le format ESE de Windows 10 et antérieurs, pas le Windows.db SQLite de Windows 11, et c'est une application Windows à interface graphique.

ESEDatabaseView

La visionneuse ESE générique de NirSoft. Elle ouvre n'importe quelle base ESE (Windows.edb, SRUDB.dat, WebCacheV01.dat et d'autres), permet de parcourir et filtrer les tables et de les exporter en CSV, HTML, XML, JSON et d'autres formats, depuis l'interface ou la ligne de commande. NirSoft précise qu'elle n'a pas besoin de esent.dll. Sa documentation reconnaît franchement que, sur des tables à structure complexe, certains champs peuvent afficher des valeurs incorrectes ou vides.

À privilégier quand vous voulez voir le SystemIndex_PropertyStore brut ou les tables gather exactement telles qu'elles sont stockées, ou vérifier une colonne qu'un autre outil affiche vide. À garder en tête : elle connaît ESE, pas Windows Search. Pas de pivot, pas de reconstruction des chemins depuis l'arbre gather, pas d'interprétation des propriétés, et pas de prise en charge de Windows 11 puisque Windows.db est en SQLite.

esedbexport (libesedb)

libesedb, de Joachim Metz, est une bibliothèque C ouverte pour les fichiers ESE, accompagnée des outils esedbinfo et esedbexport. Sa documentation du format est la référence sur laquelle reposent la plupart des parseurs ESE, celui-ci compris. Le projet se présente lui-même comme expérimental.

esedbexport -t D:\case\export Windows.edb

À privilégier quand vous voulez un vidage scriptable et multiplateforme de toutes les tables, ou un second avis sur la couche ESE elle-même. À garder en tête : la sortie est un fichier texte par table, et l'interprétation vous revient.

sqlite3 et DB Browser for SQLite

Pour Windows.db, le moteur SQLite officiel est la référence. Joindre SystemIndex_1_PropertyStore à sa table de métadonnées sur une copie donne une vérité de terrain vérifiable. Les requêtes sont dans l'analyse forensique de Windows.db : SQLite et le WAL.

À garder en tête : travaillez uniquement sur une copie. Un client SQLite classique peut checkpointer le WAL à la fermeture et détruire la comparaison avant/après.

Le Windows Search Index Parser

Ce qu'il fait, d'après son propre README et son interface :

• Lit Windows.db (avec -wal et Windows-gather.db) et Windows.edb avec ses propres lecteurs SQLite et ESE, compilés de Rust en WebAssembly, dans un Web Worker. Rien n'est envoyé.
• Pivote toutes les propriétés de chaque élément en une ligne, joint les tables gather, reconstruit les chemins de dossiers.
• Marque les éléments présents uniquement dans le WAL ou modifiés dans le WAL ; signale les éléments absents de la table gather, les extraits de contenu, exécutables, archives, autres lecteurs, chemins réseau, dossiers modifiables par l'utilisateur et éléments indexés récemment.
• Accepte les dossiers et les ZIP KAPE / Velociraptor tels quels ; exporte en CSV (protégé contre l'injection de formules) et en JSON.

Ce qu'il ne fait pas, clairement :

• Validation ESE : son lecteur Windows.edb n'a été validé que sur des bases synthétiques. C'est pourquoi l'interface l'indique.
• Schéma Windows 11 : le décodage suit des recherches publiques ; le DDL et les codes de type de stockage ne sont pas documentés.
• Pas de carving : les enregistrements supprimés dans les pages ESE libres, les freelists SQLite ou les trames WAL périmées ne sont pas récupérés (les entrées ESE « defunct » sont comptées).
• Pas de rejeu des MSS*.log ; pas de décodage des valeurs SystemIndex_0A de Vista / 7 ; pas de XPRESS9 / XPRESS10 / LZ4.
• Pas de ligne de commande ni d'automatisation. Du triage mené par un humain, pas un pipeline.

Quelle combinaison pour quel besoin

Quand les parseurs divergent

Causes habituelles, dans l'ordre où je les vérifie :

1. Des entrées différentes. Un outil a reçu le WAL ou la base ESE rejouée, l'autre non. Voir le guide dirty shutdown.
2. Valeurs longues et compression. Un extrait présent dans un outil et vide dans l'autre signifie en général que l'un d'eux n'a pas suivi une référence de valeur longue ou n'a pas décodé une valeur compressée. Voir les bases d'ESE.
3. Colonnes multivaluées réduites à leur première valeur.
4. Décodage des dates : ordre des octets et UTC contre heure locale.
5. Sélection des enregistrements : enregistrements « defunct » affichés ou masqués ; enregistrements gather seuls inclus ou non.

Notez quel outil a produit chaque constatation et lequel l'a confirmée. C'est ce que demandera un relecteur.

Articles liés

• Comment ouvrir Windows.edb et Windows.db pas à pas
• Analyse forensique de l'index Windows Search : le guide complet
• Windows.edb ou Windows.db