±Forensic Focus Partners
|New Today: 0||Overall: 36783|
|New Yesterday: 2||Visitors: 187|
Windows Search forensicsBack to top Back to main Skip to menu
Windows Search forensics
The definition of the database tables and indexes are stored in a table referred to as the catalog.
The name of this table is 'MSysObjects'. Each ESE database contains a catalog and its backup named ''MSysObjectsShadow'.
The data of tables and indexes are stored in a hierarchy of pages (or page-tree). These page-trees are traversed by means of (page) keys.
Eseutil can be used to print table information, e.g. the table information of the 'MSysObjects' table of a Windows Vista Search ESE database (Windows.edb).
eseutil.exe /mm /tMSysObjects Windows.edb
Initiating FILE DUMP mode...
******************************* META-DATA DUMP *******************************
Name Type ObjidFDP PgnoFDP
Windows.edb Db 1 1
MSysObjects Tbl 2 4
Name Idx 4 7
RootObjects Idx 5 10
From the output we can learn that the 'MSysObjects' table has two corresponding indexes: 'Name' and 'RootObjects'. 'ObjidFDP' refers to an unique 'object' identifier for each table or index. 'PgnoFDP' contains the page number of the Father Data Page (FDP), which basically is the root page of the page-tree.
Eseutil can be used to print all the tables and indexes of the database.
eseutil.exe /mm Windows.edb
The libesedb project comes with a tool called esedbinfo which does a similar print all of the tables and indexes in the database.
For some tables eseutil will print a line containing 'Long Values'.
SystemIndex_0A Tbl 21 1125
<Long Values> LV 261 743
Long values are used by ESE to store 'large' amount of data in a separate page values; in effect also a separate page-tree. According to [MSDN]:
ESE stores the long value separated if it is larger than 1024 bytes or if the record would not fit on a single database page if stored in record.
2. Analysis of a Windows Search database
Windows Search stores its data in a file named:
%Profiles%/All Users/Application Data/Microsoft/Search/Data/Applications/Windows/Windows.edb
Note that '%Profile%' is dependent on the Windows version. To access the Windows.edb file the the Windows Search service needs to be deactivated and the necessary access rights are required. If the database is in a 'dirty' state it might be necessary to copy the transaction logs as well. According to Mark Woan, author of EseDbViewer, copying the entire Windows Search application directory often does the trick.
Access to the ESE database format is only a small step closer to the information in a Windows Search database. As far as I know, forensic tools like EnCase or Forensic Toolkit do not support the Windows Search database; although they support some types of ESE databases. Additional specialized investigative tools like Windows Search Index Examiner or EseDbViewer are necessary; at least EseDbViewer directly uses the ESE. You could also consider to write a tool for a quick-and-dirty export of the values in the tables using ESE yourself.
From a forensic point of view using ESE is not the preferred method, because the engine alters the data; at minimum ESE sets the database state to 'dirty'. However ignoring possible evidence is not an option either. Another issue is that ESE will not open 'dirty' databases.
The approach of exporting data directly from a Windows XP Search database works fairly well. However when it comes to Windows Vista you're out of luck. Most of the columns have changed from the text to a binary format. Also the binary data in these columns is no longer readable; they have been compressed and obfuscated. Windows 7 Search uses native ESE compression and has largely switched back to text columns again.
One of the more interesting columns 'System_Search_AutoSummary', which contains part of the content of an indexed item, is compressed and obfuscated in the XP, Vista and 7 versions of Windows Search.
2.1. Data obfuscation
According to [TECHNET]:
Index files are lightly obfuscated.
If the obfuscation is removed, meaningful data from documents can be extracted. The data structures of the index files do not lend themselves to easy reconstruction of a complete document. However, someone with enough tenacity and time could reconstruct the text for the majority of a document.
Actually the obfuscation method is fairly straight forward. The obfuscation method uses a XOR with a bitmask based on the location of the byte in the data and an initial 32-bit bitmask.
The initial bitmask is created by a 32-bit XOR of the values in the Windows NT security identifier (SID):
The SID is stored as the following byte values:
01 01 00 00 00 00 00 05 12 00 00 00
This results in a 32-bit bitmask of:
The data is obfuscated using a method similar to the one below.
bitmask32 = 0x05000113;
bitmask32 ^= (uint32_t) encoded_data_size;
for( encoded_data_iterator = 0;
encoded_data_iterator < encoded_data_size;
switch( encoded_data_iterator & 0x03 )
bitmask = (uint8_t) ( ( bitmask32 >> 24 ) & 0xff );
bitmask = (uint8_t) ( ( bitmask32 >> 16 ) & 0xff );
bitmask = (uint8_t) ( ( bitmask32 >> 8 ) & 0xff );
bitmask = (uint8_t) ( bitmask32 & 0xff );
bitmask ^= encoded_data_iterator;
data[ data_iterator++ ] = encoded_data[ encoded_data_iterator ]
2.2. Data compression
Windows Search compresses the data before obfuscating it. For this it uses multiple compression methods. All these compression methods and obfuscation correction are incorporated in the function 'MSSUncompressText' stored in a Windows Search specific DLL. The name of the DLL differs per version of Windows Search. A quick-and-dirty approach could be to call the function directly to decompress the binary data.
Some of the obfuscation correction and decompression techniques have been integrated into esedbexport which is included in libesedb project [ESEDB09]. For a Windows Search database esedbexport tries to convert the compressed values it knows about. Note that the libesedb project is still in alpha status and you might want to validate findings, if possible, with other tools.
2.3. Investigative artifacts and usefulness
So what makes the Windows Search database so interesting for forensic analysis? For starters the Windows Search database contains a table named 'SystemIndex_0A' which contains vast amount
of values about various of artifacts found on a Windows system, e.g. files and directories, emails, appointments, attachments, images, audio and video, Microsoft Internet Explorer (MSIE) history, etc.
Better yet, on Windows Vista and 7, Windows Search is activated by default running as a system service, silently collecting this data on the background. Most users will be totally unaware that Windows Search is actually indexing potential evidence; talk about a system ready for investigation.
A Windows Search database can contain metadata and partial content data of deleted files. For now it is unknown how long Windows Search retains its data. From personal experience I can say that a Windows Search database on my test system still contained metadata about a file I thought I had thoroughly erased from that system a half year before.
Windows Search also can index items from other sources like an Exchange sever; yet another location to find (deleted) emails.