Windows.edb frente a Windows.db: índice de Windows 10 y 11

En resumen. Mismo modelo de datos, distinto contenedor. Windows 10 y anteriores guardan el índice en un único archivo ESE, Windows.edb, con una fila ancha por elemento en SystemIndex_PropertyStore y columnas con nombres como 4447-System_ItemPathDisplay. Windows 11 lo reparte en archivos SQLite: Windows.db contiene SystemIndex_1_PropertyStore como filas estrechas (WorkId, ColumnId, Value) más una tabla de metadatos que da nombre a cada ColumnId, y Windows-gather.db contiene las tablas gather. Ambos guardan los cambios recientes fuera del archivo principal (registros ESE frente a WAL de SQLite). Un analizador tiene que volver a pivotar las filas de Windows 11 en un registro por elemento y leer el WAL; si no, te muestra un índice desfasado.

De un vistazo

La ubicación es la misma: C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. La guía de solución de problemas de Microsoft habla de Windows.edb en Windows 10 y de Windows.db en Windows 11. Las fuentes publicadas no coinciden en la versión exacta de Windows 11 que cambió de formato. Una máquina actualizada también puede arrastrar un archivo antiguo. Mira lo que hay realmente en la carpeta y las cabeceras de los archivos (SQLite format 3 frente a la firma ESE) en lugar de suponerlo a partir del número de versión.

Windows 10: una única tabla ancha

En Windows.edb, SystemIndex_PropertyStore tiene una columna por cada propiedad que conoce el indexador, cientos de ellas. Los nombres de columna llevan un prefijo numérico y el nombre canónico de la propiedad con guiones bajos en lugar de puntos:

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

(Los números varían entre bases. Guíate siempre por el nombre que sigue al guion.)

La mayoría de las columnas están vacías en la mayoría de las filas, que es justo para lo que sirven las columnas tagged de ESE: valores dispersos que no ocupan espacio cuando no existen. Los valores largos, como un fragmento de contenido grande, pueden guardarse fuera de la fila en un árbol de valores largos separado, y muchas columnas de texto están comprimidas. Cómo funciona todo esto en disco se explica en fundamentos de ESE para analistas forenses.

Windows Vista y 7 usaban una tabla llamada SystemIndex_0A con una codificación de valores propia. Si trabajas con esos sistemas, comprueba que tu analizador la admite. El Windows Search Index Parser todavía no decodifica esa codificación.

Windows 11: filas de propiedades

Windows.db normaliza los mismos datos. Un archivo tendría este aspecto en SystemIndex_1_PropertyStore:

Y SystemIndex_1_PropertyStore_Metadata te dice que el ColumnId 4447 es System.ItemPathDisplay, con una UniqueKey como 4447-System_ItemPathDisplay (la misma cadena que era el nombre de columna en ESE) y un tipo de almacenamiento. La investigación de Stroz Friedberg de 2023 y el artículo de Kaspersky sobre artefactos de Windows 11 describen esta estructura.

Consecuencias para el análisis:

• Hay que pivotar. Un SELECT * te da una sopa de propiedades. Agrupa por WorkId, une los metadatos y convierte cada ColumnId en un campo con nombre.
• Los valores se tipan por los metadatos, no por la columna. La investigación pública, y la decodificación del propio analizador, tratan el tipo de almacenamiento 11 como cadena y el 12 como entero little-endian de 8 bytes o FILETIME. Microsoft no documenta esos códigos, así que un analizador cuidadoso recurre a heurísticas para el resto y conserva los bytes en bruto.
• Ojo con el tipo de tabla. Una tabla con clave (WorkId, ColumnId) puede declararse WITHOUT ROWID; en ese caso sus filas viven en un b-tree de índice y no en uno de tabla. Los lectores SQLite ligeros que solo recorren tablas con rowid no verían nada. El analizador maneja ambos casos.
• Las rutas de carpetas vienen de la base gather. SystemIndex_GthrPth es un árbol de nombres de ámbito (Scope, Parent, Name). Reconstruye la ruta completa subiendo por los padres y añade el FileName de SystemIndex_Gthr.

Las tablas gather: la misma idea en ambos

SystemIndex_Gthr tiene una fila por documento conocido por el rastreador: ScopeID, DocumentID, FileName, LastModified, TransactionFlags y más. SystemIndex_GthrPth aporta el árbol de ámbitos. El artículo de Stroz Friedberg enumera esas columnas para ambas versiones. El DocumentID coincide con el WorkId del almacén de propiedades, y así se correlacionan ambas partes.

En Windows 11 están en un archivo aparte con su propio WAL. Si solo adquiriste Windows.db, pierdes la reconstrucción de rutas y, sobre todo, la comparación «presente en el almacén de propiedades pero no en la tabla gather», uno de los mejores indicadores de un archivo borrado.

Cambios recientes: registros frente a WAL

Ambos motores usan registro de escritura anticipada, pero las consecuencias forenses difieren.

ESE escribe primero los cambios en MSS*.log y los aplica más tarde a Windows.edb. Una base copiada en caliente queda marcada como dirty shutdown. Los últimos cambios solo están en los registros hasta que los reproduces con esentutl /r. Ver reparar un Windows.edb en dirty shutdown.

SQLite añade las páginas confirmadas a Windows.db-wal. Se vuelcan en la base en un checkpoint, por defecto cuando el WAL alcanza 1000 páginas o cuando se cierra la última conexión, según la documentación de SQLite. Los lectores consultan primero el WAL. No hay paso de «reproducción» para el analista: un analizador que entiende el WAL simplemente lee la versión más reciente de cada página. Mejor aún: comparando la base con y sin el WAL puedes saber qué elementos se añadieron o modificaron en las transacciones más recientes. Por eso el Windows Search Index Parser marca los elementos solo en el WAL o modificados en el WAL. Ver análisis forense de Windows.db: SQLite y el WAL.

¿Con cuál es más fácil trabajar?

Para un analista forense, Windows 11 es más fácil de leer y más difícil de leer por completo.

• Más fácil: SQLite está documentado y todos los lenguajes tienen lector. Puedes verificar la salida de un analizador con sqlite3 sobre una copia en minutos.
• Más difícil: el pivote, los blobs tipados, la base gather separada y el WAL tienen que estar bien, y los códigos de tipo de almacenamiento no están documentados.
• ESE es lo contrario: un formato más pesado (catálogo, árboles B+, columnas tagged, valores largos, compresión), pero un único archivo autocontenido cuya estructura está bien documentada por libesedb.

Qué hace la herramienta con cada uno

El Windows Search Index Parser maneja ambos en el navegador:

• Windows.db: su propio lector SQLite + WAL (compatible con WITHOUT ROWID), pivota SystemIndex_1_PropertyStore en un elemento por WorkId, une Windows-gather.db por DocumentID, reconstruye las rutas de carpetas y marca los elementos solo en el WAL o modificados en el WAL. Un WAL que pertenece a otra base se detecta y se ignora. El DDL exacto de Windows 11 no está documentado, así que la reconstrucción de rutas y parte de la decodificación siguen la investigación pública y heurísticas.
• Windows.edb: su propio lector ESE de solo lectura (catálogo, árboles B+, columnas fijas / variables / tagged, valores largos, compresión de 7 bits y XPRESS) que lee SystemIndex_PropertyStore y las tablas gather. Advertencia honesta: ese lector solo se ha validado hasta ahora con bases sintéticas. Trata su salida como una pista y confirma los hallazgos clave con otra herramienta.

Artículos relacionados

• Análisis forense del índice de Windows Search: guía completa
• Las propiedades del índice de Windows Search explicadas
• Fundamentos de ESE para analistas forenses