You are on page 1of 151

CRANFIELD UNIVERSITYDEFENCE COLLEGE OF MANAGEMENT AND TECHNOLOGY DEPARTMENT OF INFORMATICS & SENSORS MSc THESIS

Academic Year 2008-2009

James McCulloch Gordon Finders Keepers A Forensic Examination of Windows Desktop Search (Version 3)

Supervisor: Prof Brian Jenkinson Feb 2009

This thesis is submitted in partial fulfilment of the requirements for the Degree of Master of Forensic Computing.

Cranfield University 2009. All rights reserved. No part of this publication may be reproduced without the written permission of the copyright owner.

Page 1 of 151

The message is that there are no "knowns." There are things we know that we know. There are known unknowns. That is to say there are things that we now know we don't know. But there are also unknown unknowns. There are things we don't know we don't know. So when we do the best we can and we pull all this information together, and we then say well thats basically what we see as the situation, that is really only the known knowns and the known unknowns. And each year, we discover a few more of those unknown unknowns.

Secretary Rumsfeld Press Conference at NATO Headquarters, Brussels, Belgium 6th June 06, 2002

Page 2 of 151

Abstract
Home users now have access to computers that hold vast storage capabilities and therefore the need to regularly housekeep is not as important as in days gone by. These modern computers are filled with a wide array of file types, including documents, pictures, emails, and music to name but a few. These files also contain a great deal of internal structure (metadata) giving information about them. One example is a word document that contains details of the author, last print date, created date, and modified date. These various file properties can be searched for when attempting to find particular files. Traditional methods of searching for files meant that every file would be read when attempting to locate a particular file. The greater the number of locations searched the longer the time it took to complete the search. Desktop search technologies index user data prior to the search being performed. The trade off on this occasion is that it takes time to initially build the index. Once the database index is completed a user can conducted a search very quickly. The ability of users to be able to find relevant files when required has led to the creation of several desktop indexing and search applications by Microsoft and other third party providers such as Google. It is known that such Desktop search applications contain cached copies of files after they have been deleted from the file system. This is a potential source of evidence for the forensic computing analyst. This project will seek to address the lack of information about the Windows Desktop Search application.

Page 3 of 151

Acknowledgements
The production of this thesis would not have been possible without the unwavering support and encouragement from several very important people. First, I must thank my wife Debbie for convincing me to keep going when I experienced hardships and wanted nothing more than to throw in the towel. As always she is right and I am glad she is. I also owe a huge debt of gratitude to Prof Brian Jenkinson for the encouragement and guidance that he has provided throughout the project year.

Page 4 of 151

List of Contents
Abstract ............................................................................................................................. 3 Acknowledgements .......................................................................................................... 4 List of Contents ................................................................................................................ 5 List of Tables .................................................................................................................... 9 List of Figures ................................................................................................................. 11 CHAPTER 1 Introduction .............................................................................................. 13 1.1 Background ........................................................................................................... 13 1.2 The Objectives ...................................................................................................... 14 1.3 The Structure of the report.................................................................................... 14 CHAPTER 2 - Literature Review ................................................................................... 17 2.1 Introduction .......................................................................................................... 17 2.2 Forensic Computing ............................................................................................. 17 2.3 Desktop Search Utilities ....................................................................................... 18 2.4 Written Material ................................................................................................... 19 2.4.1 Forensic Books and Journals ......................................................................... 19 2.5 Digital Material..................................................................................................... 22 2.6 The History of Desktop Search ............................................................................ 24 2.7 The History of Windows Operating System search facilities............................... 25 2.8 Windows Desktop Search Version 2 .................................................................... 25 2.9 Windows Desktop Search Version 3.0.1 .............................................................. 26 2.10 Microsoft Vista Desktop Search ......................................................................... 26 2.11 Windows Desktop Search Version 4 .................................................................. 26 2.12 Potential Implications for the Forensic Community........................................... 26 2.13 Conclusions ........................................................................................................ 27 CHAPTER 3 - Research Methodology .......................................................................... 28 Page 5 of 151

3.1 Introduction .......................................................................................................... 28 3.2 Research problem and motivation for the study ................................................... 28 3.3 The Research Objectives ...................................................................................... 28 3.4 ACPO Principals................................................................................................... 29 3.5 The Research Strategy .......................................................................................... 30 3.6 The Research Approach........................................................................................ 30 3.7 Tools Utilised ....................................................................................................... 33 3.7.1 Inctrl5............................................................................................................. 33 3.7.2 Process Monitor ............................................................................................. 33 3.7.3 EnCase Version 6 .......................................................................................... 34 3.7.4 Access Data Registry Viewer ........................................................................ 34 3.7.5 VMWare Workstation ................................................................................... 35 3.7.6 Decode ........................................................................................................... 35 3.8 Conclusions .......................................................................................................... 35 CHAPTER 4 - Windows Desktop Search Version 3.0.1 ............................................... 36 4.1 Introduction .......................................................................................................... 36 4.2 Foundation Experiment ........................................................................................ 36 4.3 Indexing options ................................................................................................... 37 4.4 Advanced options ................................................................................................. 38 4.5 Index Settings ....................................................................................................... 38 4.6 Files Type Tab ...................................................................................................... 39 4.7 Add UNC Location ............................................................................................... 43 4.8 Files created or modified ...................................................................................... 43 4.9 Examination of the Windows.edb file .................................................................. 45 4.10 How the Windows Desktop Search Application works ..................................... 52 4.10.1 Architecture ................................................................................................. 52

Page 6 of 151

4.10.2 The Indexing Process................................................................................... 53 4.10.3 Gatherer Queues .......................................................................................... 53 4.10.4 IFilter ........................................................................................................... 53 4.10.5 Property Store. ............................................................................................. 53 4.10.6 Content Change ........................................................................................... 54 4.11 Examination of the System Registry .................................................................. 55 4.12 Conclusions ........................................................................................................ 60 CHAPTER 5 - Experimentation ..................................................................................... 61 5.1 Experiment 1 Adding data ................................................................................. 61 5.2 New Technology File System [NTFS] ................................................................. 61 5.3 Dissecting the SystemIndex.Ntfy3.gthr ................................................................ 65 5.4 Dissecting the Windows.edb file .......................................................................... 69 5.5 Experiment 1 Phase 2 ........................................................................................... 73 5.6 Examination of the Indexer Transaction Log file ................................................. 75 5.7 Windows.edb file entry......................................................................................... 84 5.7.1 SystemIndex_Gthr entries ............................................................................. 86 5.8 Data Added Conclusions ...................................................................................... 92 5.9 Experiment 2 - Modifying Data........................................................................... 93 5.10 Data Modification Conclusions .......................................................................... 99 5.11 Experiment 3 - Deleting Data ........................................................................... 100 5.11.1 Examination of the Windows.edb file ....................................................... 102 5.11.2 Examination of the INFO2 file entry ......................................................... 102 5.12 Experiment 3 Phase 2 ....................................................................................... 103 5.13 File Content ...................................................................................................... 111 5.14 Deletion Test Conclusions ................................................................................ 112 5.15 Experiment 4 - Preview Exercise ..................................................................... 114

Page 7 of 151

Experiment 4 Phase 2 ............................................................................................... 118 Experiment 4 Phase 3 ............................................................................................... 123 5.15.1 System Registry ......................................................................................... 124 5.15.2 Enable History Key ................................................................................... 125 5.16 Preview Experiment Conclusions ..................................................................... 126 CHAPTER 6 - Critical Project Analysis and Review .................................................. 127 6.1 Introduction ........................................................................................................ 127 6.2 The Project Plan.................................................................................................. 127 6.3 The Focal Point of the Project ............................................................................ 129 6.4 Choice of Tools .................................................................................................. 129 6.5 Meetings with the Tutor ..................................................................................... 130 6.6 Management of the Project ................................................................................. 130 6.7 The Learning Experience.................................................................................... 131 6.8 Conclusions ........................................................................................................ 131 CHAPTER 7 - Results and Discussion......................................................................... 133 7.1 Introduction ........................................................................................................ 133 7.2 System Architecture ........................................................................................... 133 7.3 Methodology ....................................................................................................... 135 The Future................................................................................................................. 135 7.4 Conclusions ........................................................................................................ 135 References .................................................................................................................... 137 Bibliography ................................................................................................................. 142 Appendices ................................................................................................................... 143 Appendix A File Dump Output ............................................................................. 143 Appendix B Passware Search Index Examiner ..................................................... 147

Page 8 of 151

List of Tables
Table 1 List of Supported File Types .......................................................................... 42 Table 2 Windows.edb file Tables ................................................................................ 49 Table 3 Decoded FILETIME Stamps from $MFT Standard Information Attribute entry. ........................................................................................................................................ 63 Table 4 - Decoded FILETIME Stamps from $MFT File Name attribute. ..................... 64 Table 5 Comparison between Transaction Log entries. .............................................. 68 Table 6 SystemIndex_gthr table entries for test1.txt file............................................. 71 Table 7 Created time in $MFT for test files. ............................................................... 75 Table 8 - File compare results for Killiecrankie.txt Transaction log entries .................. 76 Table 9 File compare results for Bannockburn.txt Transaction log entries................. 78 Table 10 - File compare results for castle gordon.txt Transaction log entries ............... 80 Table 11 - File compare results for ye jacobites by name.txt Transaction log entries ... 83 Table 12 Windows.edb file entry for Experiment 1 Phase 2. ...................................... 84 Table 13 Document ID from SystemIndex.Gthr Table ............................................... 85 Table 14- SystemIndex_0A table entries........................................................................ 85 Table 15 Extracted values from Windows.edb file Haggistest.txt file ........................ 87 Table 16 - Extracted values from Windows.edb file Killiecrankie.txt file..................... 88 Table 17 - Extracted values from Windows.edb file Bannockburn.txt file .................... 89 Table 18 - Extracted values from Windows.edb file Castle Gordon.txt file .................. 90 Table 19 - Extracted values from Windows.edb file Ye Jacobites by Name.txt file...... 92 Table 20 Extracted $MFT Record properties for haggis.txt file ................................. 94 Table 21 Extracted systemindex_ghtr table entries ..................................................... 95 Table 22 Decoded values for Windows.edb file.......................................................... 95 Table 23 - Extracted $MFT Record properties for haggis.txt file after modification .... 97 Table 24 - Extracted systemindex_ghtr table entries after modification ........................ 98 Table 25 - Decoded values for Windows.edb file after modification ............................ 98 Table 26 - File compare results for $MFT entries after modification ............................ 99 Table 27 File Deletion FILETIME Stamps ............................................................... 106 Table 28: Decoded INFO2 File .................................................................................... 107 Table 29 File deletion comparison table.................................................................... 109

Page 9 of 151

Table 30 Procmon Log .............................................................................................. 115

Page 10 of 151

List of Figures
Figure 1: Screen shot of Indexing options ...................................................................... 37 Figure 2: screenshot of indexing locations ..................................................................... 38 Figure 3: screenshot of advanced options....................................................................... 39 Figure 4: screenshot of file types options ....................................................................... 40 Figure 5: screenshot of UNC locations tab ..................................................................... 43 Figure 6: screenshot of Encase view of indexing files ................................................... 44 Figure 7: Encase screenshot of SystemIndex directory .................................................. 45 Figure 8: Screenshot of esentutls.exe options ................................................................ 46 Figure 9: esentutls.exe File Dump options ..................................................................... 47 Figure 10: Output of esentutls.exe /mh switch command .............................................. 48 Figure 11: esentutls.exe File Dump output ..................................................................... 48 Figure 12 Screenshot of WinHex together with Microsoft Database Viewer. ............ 50 Figure 13 Screenshot of SystemIndex_0A table ......................................................... 51 Figure 14 - Screenshot of Windows Desktop Search Key opened with Access Data Registry Viewer ............................................................................................................................. 56 Figure 15 Screenshot of Windows Search key opened with Access Data Registry Viewer ........................................................................................................................................ 56 Figure 16 - Screenshot of SystemIndex sub key opened with Access Data Registry Viewer ........................................................................................................................................ 57 Figure 17 Location of the Windows.edb file opened with Access Data Registry Viewer5 8 Figure 18 NTUSER.dat Windows Desktop Search key opened with Access Data Registry Viewer ............................................................................................................................. 59 Figure 19 - NTUSER.dat Windows Search key opened with Access Data Registry Viewer ........................................................................................................................................ 59 Figure 20 Screenshot of test1.txt entry in EnCase (times in UTC+1) ......................... 64 Figure 21 Format of Entries in gather Log File ........................................................... 65 Figure 22: Screenshot of EnCase SystemIndex.Ntfy.3.gthr file..................................... 65 Figure 23 Screenshot of Test1.txt entry in SystemIndex_0A table ............................. 71 Figure 24 Possible values within the SystemIndex_0A table...................................... 73 Figure 25 Experiment 1 Phase 2 SystemIndex_Gthr table entries .............................. 86

Page 11 of 151

Figure 26: Encase screenshot prior to modification ....................................................... 93 Figure 27: Encase screenshot after to modification........................................................ 96 Figure 28 Screenshot of SystemIndex_Gthr table showing test2.txt entry before deletion test ................................................................................................................................. 100 Figure 29 SystemIndex_DeletedDocIds entry for Document 22 .............................. 102 Figure 30 INFO2 file details for deleted file ............................................................. 102 Figure 31: Screenshot of recycle bin ............................................................................ 107 Figure 32 - Screenshot of SystemInex_gthr table after multiple file deletion test. ..... 109 Figure 33 - SystemIndex_DeletedDocIds entry for multiple file deletion .................. 110 Figure 34 - Screenshot of System Search AutoSummary field .................................... 114 Figure 35 Screenshot of obfuscated data in the System Search AutoSummary field 116 Figure 36 View of Windows.edb showing obfuscated data. ..................................... 118 Figure 37 Microsoft Database Viewer Screenshot .................................................... 119 Figure 38 Obfuscated data in Windows.edb file prior to experiment ....................... 120 Figure 39 - Obfuscated data in Windows.edb file after experiment ............................. 120 Figure 40 Windows.edb file after experiment. .......................................................... 121 Figure 41 Screenshot of auto search summary field for ............................................ 122 Figure 42 Killiecrankie.txt file prior to change ......................................................... 122 Figure 43 Killiecrankie.txt file after change .............................................................. 123 Figure 44 Deskbar History ........................................................................................ 124 Figure 45 System Registry Search terms ................................................................... 125 Figure 46 System Registry after Experiment 4 Phase 3 ............................................ 126 Figure 47 Screenshot from Passware Web Site ......................................................... 147 Figure 48 View of output of Passwares Search Index Examiner ............................. 149 Figure 49 File Deletion Test Output Search Index Examiner ................................... 150

Page 12 of 151

CHAPTER 1 Introduction

1.1 Background

Computer usage has increased exponentially over recent years. Home users have access to computers that hold what will be seen historically as huge amounts of storage capability. In March 2005, the IDC white paper which was sponsored by Microsoft titled The Hidden Costs of Information Work [1] reported that Searching for and analyzing information both consume 24% of the typical information workers time (9.5 and 9.6 hours per week, respectively), making these tasks relatively straightforward candidates for better automation. This equated to an estimated $14,000 per worker per year just searching for information. In 2007 the global market intelligence company IDC produced a white paper sponsored by EMC titled The Expanding Digital Universe [2] stated Between 2006 and 2010, the information added annually to the digital universe will increase more than six fold from 161 exabytes to 988 exabytes. The report added that 70% of this increase would be attributable to home users. This increase in user storage has led to a need for users to manage and search through data quickly and efficiently in order to find information, i.e. for details of emails or pictures. A number of software developers have released applications to assist the user with searching through the computer hard drive for files Google Desktop Search [3], Filehawk [4] and Copernic [5] are typical examples. This approach involves indexing the contents of some directories thus aiding a subsequent search to retrieve data. The areas of a hard drive indexed typically include the user profile area including documents, pictures, music, videos as well as email content and attachments. The indexers, generally, do not include program or system files, as users will rarely want to search such content and their inclusion would greatly increase the length of time that it takes to build and search the index. The index can best be likened to the index of a book that helps the readers find information that is of

Page 13 of 151

interest to them. It can include information about the file name, modified date and various property tags added by the author. Once the index is built a user can search it significantly faster than searching through the entire contents of the hard drive. It became apparent to the author that user-generated indexes gather a whole wealth of information about the files that make up an individual users profile, including content, and could potentially provide a valuable source of information.

1.2 The Objectives

The objectives of this project are: 1. This document should become a reference guide to the forensic community on the functionality of the Windows Desktop Search application. 2. The document will provide a methodology for forensic computing analysts when examining computers that have the Windows Desktop Search application installed. Such methodologies will focus their search for traces of previously indexed files, their contents and useful forensic artefacts. Due to time constraints it is impossible to cover every file associated with the application, however a significant contribution can be made with this document to address the current total lack of reliable forensic reference material in this area.

1.3 The Structure of the report

The structure of this report follows the different phases of the research methodology: Chapter One - Introduction This chapter introduces the project and sets the scene for the report to follow.

Page 14 of 151

Chapter 2 Literature Review A summary of the digital and printed resources used to support the project. In addition a brief history of Desktop Search applications is outlined, together with an explanation of the functionality of the Windows Desktop Search application. This includes the main components that make up the indexer and how they relate to the functionality of the application. Chapter 3 The Research Methodology The fundamental nature of the research is stated and the purposes together with the objectives of the study are defined. Chapter 4 - Investigation of Windows Desktop Search version 3.0.1 An exploration of the Windows Desktop Search application, including: files that are created or modified on installation, indexing options, an overview of the main components of the architecture together with the user interface. Chapter 5 Experimentation and analysis Details of major experiments carried out in support of the project. Test scenarios were conducted in order to isolate particular key elements of the indexer. The results are detailed and conclusions discussed.

Page 15 of 151

Chapter 6 - Critical Project Analysis and Review. The issues discovered during the experimentation phase are highlighted and their relevance for the forensic computing community discussed. This chapter will have a potential bearing on the methodology used by forensic analysts when examining computers that have the Windows Desktop Search installed and includes the benefits as well as the shortcomings of this project. Chapter 7 Conclusions and Recommendations A major summary of findings identified as a result of the project. It includes some recommendations for progressing further work and the learning experience of the author.

Page 16 of 151

CHAPTER 2 - Literature Review


2.1 Introduction

This project is intended to establish what forensic artefacts are to be found during a forensic analysis of the Windows Desktop Search application. This review examines existing research, including published literature and digital material. The review will start with an introduction to forensic computing, followed by an overview of Desktop Search utilities. Current research into other desktop search applications shall be discussed; and the possibility that valuable artefacts can be retrieved will be highlighted. The review ultimately demonstrates that there is currently no completed study into Windows Desktop Search application. There is therefore an existing requirement for this project to be completed.

2.2 Forensic Computing

Forensic Computing is still in scientific terms, a new discipline that started to emerge during the 1990s. There is in fact a debate whether it can actually truly be called a Forensic Science. It may be helpful to establish some definitions for some of the main discussion points. The word science comes from the Latin "scientia," meaning knowledge. According to Webster's New Collegiate Dictionary, the definition of science is "knowledge attained through study or practice. [6] The Encarta Online Dictionary [7] defines science as the study of the physical world and its manifestations, especially by using systematic observation and experiment. It continued any activity that is the object of careful study or that is carried out according to a developed method. One of the first recorded examples of Forensic Science was the legend of Archimedes (287-212 BC) from which the term Eureka was derived. Archimedes was able to prove by examining the principles of water displacement that a crown was not made of gold (as it was fraudulently claimed) by its density and buoyancy.

Page 17 of 151

There have been many attempts to define Forensic Computing and indeed there are many terms used to describe it such as Digital Investigation, Cybercrime and Computing Forensics. Casey (2004 p 31) [8] points out that the term Computer Forensics is a syntactical mess with the noun computer being used as an adjective and the adjective forensics being used as a noun, resulting in an imprecise term. Casey prefers the term digital evidence examination as it encompasses all forms of data that can be used evidentially including digital images, audio and video. One of the earliest attempts to define the subject was by the Digital Forensic Research Workshop [DFRW] [9] as The use of scientifically derived and proven methods toward the preservation, collection, validation, identification, analysis, interpretation, documentation and presentation of digital evidence derived from digital sources for the purpose of facilitating or furthering the reconstruction of events found to be criminal, or helping to anticipate unauthorized actions shown to be disruptive to planned operations. This definition brings together the definitions of Science and Forensic Science and sets it within the context of computer investigations.

2.3 Desktop Search Utilities

Desktop search utilities are still a reasonably modern concept even in computing terms, with the first mainstream and perhaps best known, Google Desktop Search, appearing during mid 2004, although other well known ones include Yahoo and Coppernic. There are various articles on the Internet [10] comparing the various features of different desktop search utilities, these mainly discuss and compare user functionality and are not forensic by nature. Microsoft has its own MSDN Desktop Search forum [11] together with individual members of the development team having their own online journal [12]. These are aimed at developers and system administrators but do, however, also contain valuable information in terms of the functionality of the application. Similarly the Microsoft knowledge base has several articles relating to the desktop search family.

Page 18 of 151

2.4 Written Material

The author reviewed numerous books relating to Windows XP and Windows Vista operating systems for information relating to the desktop search application. It was discovered that all were set at a technically very low level and were written with the normal home user in mind. The following is a list of some of the books that the author has examined for information about the internal workings of the desktop search application: 1. Windows Vista Step by Step, Microsoft Press, Preppernau and Cox, 2007 2. Windows Vista, Beyond the Manual, APRESS, Campbell and Hassell, 2007 3. Microsoft Vista Unleashed, SAMS, McFedries, 2008 4. Microsoft Windows Vista, Visual Quick Start Guide, 5. Brilliant Windows XP, PRENTICE HALL, Johnston, 2005 6. Windows Vista, Bible Desktop Edition, WILEY & SONS, Simpson and Jones, 2007 Most of the Microsoft Vista books made reference to the search indexer, however, information given was mainly aimed at the home user. They inform the reader how to utilise the search index and how to optimise their search criteria, but give no depth of technical detail. 2.4.1 Forensic Books and Journals

The author particularly looked at various forensic computing books and journals to ascertain whether there was any previous research or information about the Windows Desktop Search. The following forensic books were examined but proved fruitless: 1. Windows Forensics and Incident Recovery, Addison Wesley, Carvey, 2005 2. Digital Evidence and Computer Crime, Elsevier Academic Press, Casey, 2004 3. Encase Computer Forensics, John Wiley & Sons; 2nd Edition, Bunting, 2007 4. Windows Forensic Analysis, Syngress, Carvey, 2007

Page 19 of 151

5. Microsoft Windows Internals, Fourth edition, Microsoft Press, Russinovich & Solomon. Examinations of specialist forensic journals proved more fruitful, in terms of articles about desktop search applications, but were written exclusively about Google Desktop Search. At the Australian Computer, Network and Information Forensics Conference during 2005 members of the University of South Australia gave a presentation on Google Desktop Search. This was followed by the publication of a white paper Googling Forensics [13]. The paper aimed to analyse the Google Desktop application and in particular identify how it operated, stored data and whether there were any limitations in its operation. Although referring to a different desktop search application it was decided that this paper could be a useful resource in terms of approach and methodology when examining such programs. The same authors published a further paper entitled Google Desktop as a Source of Digital Evidence [14], which detailed further experimentation into the application. The experiments outlined in the paper utilised dedicated machines and non-obtrusive analysis software. Unfortunately the white paper does not discuss in detail the methodology employed during the experiments other than the use of FileMon [15] and Regmon [16]. It did however note that the majority of the applications files were not in a human readable form. The paper notes that upon activation a series of Dynamic Link Libraries, [dll] files that are used for encryption and decryption of files were called. Additionally it was noted that one of the files installed in the Google folder was gzlib.dll, a compression library. The paper goes on to surmise that the most likely reason for the presence of encryption, in the absence of any other explanation, is that stored files are encrypted and compressed. Further evidence was adduced from Access Datas Forensic Toolkit, which conducts an entropy test designed to detect the likes of encrypted, compressed or obfuscated files. They concluded that the test highlighted one single file as using some

Page 20 of 151

form of encryption would identify files that were entirely encrypted and not where the file itself was not encrypted but its content were. The paper concluded that these were used for the encryption and decryption of files. The authors also surmised that the encryption and compression may account for the lack of structure in some of the application files ...it is not known how these are implemented or how to retrieve this information. The paper then discussed a methodology that involved copying files from the suspect machine onto the forensic machine and accessing the data through the application interface. The paper readily admitted limitations in the method proposed including the fact that data cannot be browsed and only specific criteria could be searched for. Significantly the authors did note that deleted files continued to exist within the cache of the application once the original had been deleted. In particular they highlighted PNG files and text files. Unfortunately they did not detail how they came to that conclusion or what tests had been conducted to prove the claim. One of the final conclusions of the paper was to note that Windows had released its own desktop search program and that it would be integrated into the latest operating system. The authors surmised that this would negate the need for such third party programs. The same authors published a further paper Developing a Process Model for the Forensic Extraction of Information from Desktop Search Applications [17]. The paper attempted to answer a number of research questions such as can information be data mined from desktop search applications using a variety of methods so that the information can be used to locate evidence and can the process be verified to abide by forensic rules so that the evidence is considered admissible in a court of law. The paper produced a process model for extraction application development. Members of the same team presented a further paper during January 2008 entitled Google Desktop Search Evidence Collector [18]: The development of a proof-ofconcept application for the forensically sound extraction of electronic evidence from

Page 21 of 151

Google Desktop Search at the 4th Annual IFIP Working Group 11.9 International Conference on Digital Forensics, at Kyoto, Japan. The paper is due to be published in the Advances in Digital Forensics Journal published by Springer. Other digital forensic journals that were searched without success for papers relating to desktop search technologies included Journal of Digital Forensic Practice and Digital Investigation, Elsevier. One paper that did mention the Windows Desktop Search indexer was found to be Forensic Implications of Windows Vista by Stewart [19]. In his paper, he briefly outlines the search indexer and lays out the structure of the index transaction log file. Stewart states that several experiments were conducted and activity monitored by Procmon. He further states that his experimentation revealed only one file of evidential value, the SystemIndex.NtfyX.gthr file. He claimed that his experiments revealed that entries were appended to this file whenever a file was created, modified, opened or closed. He identified that some fields within the file held valid FILETIMES [20] and at other times those fields held a zero value. He concluded by stating that time constraints prevented any further examinations of the indexer.

2.5 Digital Material

Digital material referencing the desktop search application was immediately far more fruitful than the published written material. In order to focus the search on forensic issues associated with the application a search was conducted during April 2008 of several well used forensic bulletin boards, these included the EnCase bulletin boards [21] with 11,143 members of which 1,465 are classed as active, the Digital Detective [22] 3,573 users and the Access Data bulletin board [23] with 2394 members. Although some posts were discovered on the EnCase bulletin board relating to the Google Desktop search not one single post in relation to the Windows Desktop Search utility was found.

Page 22 of 151

There were several references to how the desktop search application worked, the most fruitful not surprisingly being Microsofts own dedicated Windows Desktop Search web site. Information contained in a number of these web sites formed part of the experimentation phase of this project. The following is a brief summary of the contents of the sites accessed: http://www.microsoft.com/windows/products/winfamily/desktopsearch/default.mspx The home page of the Windows Desktop Search application with links to other pages of interest including: http://www.microsoft.com/windows/products/winfamily/desktopsearch/overview/videos.m spx. Windows Search Videos including Instant Search, File Organization and Navigation, Advanced Search Options, Search within Microsoft Office System and Advanced Query Options. http://www.microsoft.com/downloads/details.aspx?FamilyID=00645e54-70a8-4d05-906daf8773cbc728&DisplayLang=en Windows Search Administrators Guide that provides detailed information for a person who wishes to install and run the desktop search. http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=127&SiteID=1 Windows Desktop Search Developers Forum offers information from the developer community for integrating WDS functionality into useful tools. This was found to be a very good source of information however when some users requested technical information the moderators wouldnt always provide the most helpful information. http://www.microsoft.com/windows/products/winfamily/desktopsearch/technicalresources/i ndexing.mspx#EGB This page provided a detailed description of how the search indexer works

Page 23 of 151

http://www.microsoft.com/windows/products/winfamily/desktopsearch/technicalresources/ documentation.mspx Supporting documentation for Windows Search technologies for information on deploying, configuring, and customizing Windows Search In addition to the Microsoft web sites there were also a number of members of the Windows Desktop Search Team who have their own online journal (blog): http://brandonlive.com/ The blog of Brandon Paddock who is a member of the desktop search development team. This blog has informative postings on the desktop search and includes a link to download his sidebar gadget for Microsoft Vista that users can view and control the indexer. Many of these online resources were of value in respect of the functionality of the desktop search application. They were however focussed towards the application development and integration with existing Microsoft applications such as Outlook Express etc.

2.6 The History of Desktop Search

Although some form of indexing service have been around for a few years computer desktop search applications werent available until October 2004 when Google released their Desktop Search. Google naturally have a strong brand name in terms of search technology. The interface was familiar in that it looked identical to their highly successful and well-known Internet Search page. In April 2005 Apple released their next generation Operating System Tiger. One of the features was the indexing service Spotlight [24]. Spotlight is a full-text and metadata search engine, which can search everything from Word documents to iCal calendars to Address Book cards, as well as any text within PDF files. The feature is also used to build the concept of smart folders into the Finder. Spotlight will index files as they are saved, so

Page 24 of 151

they can be quickly and easily found through a search-as-you-type box in the menu bar. One of the other features of Spotlight is that it indexes external media that has been plugged into the host computer. Other attempts to provide a Desktop Search application by third party providers include Copernic Desktop Search for Windows Computers that was released during Sep 2006.

2.7 The History of Windows Operating System search facilities

The Windows Desktop Search toolbar was first released in beta form during December 2004. A Windows Desktop Search facility first appeared in the MSN Toolbar on 16th May 2005. The final release version of the Desktop Search arrived during May 2005 and was the initial attempt by Microsoft to bring desktop search functionality to their users. It was integrated into the MSN toolbar suite and allowed users to index 200 different file types including documents, emails and spreadsheets. Unlike Google Desktop Search the Windows Desktop Search did not index web pages visited by the user.

2.8 Windows Desktop Search Version 2

Windows Desktop Search Version 2 was first launched during November 2005 and introduced improved search functionality and stability over its tool bar predecessor. Improvements included an automatic temporary pause whilst the user is actively using their machine or whilst battery power was being used. The latest version 2.6.6 was released on 26th November 2006. The Microsoft knowledge base article 926356 detailed the minimum specification for any system running the latest version of Desktop Search as Microsoft Windows XP Service Pack 2 (SP2), together with 256 Mb of RAM, a 1 GHz or faster processor and 500 Mb of disk space free.

Page 25 of 151

2.9 Windows Desktop Search Version 3.0.1 Version 3.0.1 was released on 2nd March 2007 changes to the previous version include the fact that encrypted files are no longer indexed. This is the version of the Windows Desktop Search that was utilised using this project.

2.10 Microsoft Vista Desktop Search

Vista desktop search functionality has the same binaries as the XP version, but importantly the application is pre-installed. This fact may prove to be extremely fruitful to the forensic analyst, as users may not realise that by default the index is storing data about the contents of their hard drive.

2.11 Windows Desktop Search Version 4 Version 4 of the Windows Desktop Search was released 3rd June 2008. Changes compared to the Version 3 included the fact that the indexer was improved. A number of Windows Vista features were migrated into the Windows XP version. The most important of these features for the forensic examiner was to include support for EFS encrypted files. It should be noted that the ability to index encrypted files was removed with the release of the version that is the subject of this project.

2.12 Potential Implications for the Forensic Community

The Windows Desktop Search is an application that indexes the majority of files that an individual user adds to their user profile. The fact that such an index exists and that its independent of the operating system should be of great interest to the forensic computing community. It is accepted that should a file be present in the active file set then any forensic examination will recover the file. However there is potential for

Page 26 of 151

previously indexed documents to be available to the forensic examiner within the property store.

2.13 Conclusions

It can be seen that there are numerous sources of information about desktop search applications, including the Windows Desktop Search. These include dedicated desktop search web sites, blogs by members of the desktop development team and the Microsoft Developer Network [MSDN] forums, where there is one dedicated to Windows Desktop Search. None however have the detailed information required by a forensic computing analyst. A search of the most popular forensic computing bulletin boards revealed that although some research had been conducted into Google Desktop Search and analysts had posted articles about the forensic artefacts produced by that application not one single post could be found relating to Windows Desktop Search. The result of the Google Desktop Search paper revealed that there were artefacts of a forensic nature, which would be valuable to an analysts examination of a computer. Therefore, it is clear that there is a justifiable need for this project to establish if there are similar artefacts of an evidential nature associated with the Microsoft version. This is particularly relevant with the indexer being incorporated into the latest Microsoft Operating System Vista and being enabled by default.

Page 27 of 151

CHAPTER 3 - Research Methodology


3.1 Introduction

In this Chapter, the fundamental nature of the research is stated and the basic objectives of the study are defined. The purpose of the research was to establish by a series of experiments, observation and analysis, the forensic traces left by the use of the Windows Desktop Search application. The literature review highlighted a paper [ ] in which a research methodology had been proposed for the examination of desktop search applications. It was decided to start off by using part of the proposed methodology and to make any amendments where necessary.

3.2 Research problem and motivation for the study

The practical problem that this study addresses is the lack of knowledge within the forensic community about the internal workings of the Windows Desktop Search application, such as: how the information that is indexed by the application can be accessed and the contents analysed and presented evidentially. Currently no such study exists.

3.3 The Research Objectives

Given that the purpose of the research is to identify the forensic traces left by the use of the desktop indexing process, the objectives of the research phase were to establish: 1. What files are created by the application upon installation. 2. What changes to the system Registry are created by the application upon installation. 3. What data is indexed by the application. 4. How is the index maintained, for example when new content is added to a drive.

Page 28 of 151

5. What traces would be left of indexed contents once the parent material had been deleted.

3.4 ACPO Principals

The regulations by which computer forensic examinations are conducted are governed by the ACPO Principals. These are well-established principals and although specified only as guidelines, they are held in such high regard that failure to comply with them will almost certainly cause a case to fail at court. The first principal states, No action taken by Police or their agents should change data held on a computer or other media which may subsequently be relied upon in Court. The second principal states, In exceptional circumstances where a person finds it necessary to access original data held on a target computer that person must be competent to do so and to give evidence explaining the relevance and the implications of their actions. The third principal states, An audit trail or other record of all processes applied to computer based evidence should be created and preserved. An independent third party should be able to repeat those processes and achieve the same result. The final principal states, The onus rests with the Officer in charge of the case to ensure compliance with any law pertaining to the possession of, or access to, information contained on a computer. The officer must be satisfied that the use of any copying device or actions of any person having access to the computer complies with these laws.

Page 29 of 151

3.5 The Research Strategy

There are a number of different research strategies which may have be employed during the study, such as survey, case study, or archival research, to name but a few; however it was decided that in view of the lack of previous research into the Windows Desktop Search that the most appropriate form for this research would be the experimental strategy. Saunders et al [25] described the Experimental strategy as having ..their roots in natural science laboratory based research and the precision required means that the experiment is often the gold standard against which the rigour of other strategies is assessed. [p 135].

3.6 The Research Approach

It was decided to carry out the practical experiments in a manner and method consistent with how a forensic examination would be undertaken in real life. In other words that it should comply with the ACPO guidelines and would provide a forensically sound, verifiable result that could be repeated by a third party. A number of differing options were considered for examining the contents of the indexer. It was noted during the literature review that other desktop search applications, such as Google Desktop Search encrypted their data store and from various sources it appeared that the Windows Desktop Search did likewise. Cloning the hard drive of the test machine and accessing the index directly through the user interface was considered. The great benefit of this method would be the fact that any results output would be in a human readable form. There were however a number of issues which ultimately led to this method being discarded. The main one being the fact that any results returned from its use would be dependent on application extracting and interpreting results prior to presenting them to the user. The fact that the interface would be running in order to carry out the query

Page 30 of 151

would also mean that the indexer would potentially be changing data. This is not desirable within a forensic environment. It was therefore decided that, initially, directly accessing the data store would be the best method to employ. In order to ensure reliable results it was essential to provide a consistent testing platform. Initially this platform was provided by a 8.4 Gb Hard drive that was prepared by wiping it utilising the open source program dcfldd [26]. The computer was fitted with the hard drive and the Helix [27] live incident response disk inserted and the computer booted to run from the disk. The Helix disk recognised the drive and from a command shell the syntax dcfldd if=/dev/zero of=/dev/hda was executed. The wiping process was completed 7 times to ensure that the disk drive was forensically clean and then the drive was repartitioned and formatted with the New Technology File System [NTFS] filing system. Windows XP SP2 was then installed on the drive. In order to monitor changes to the file system, running processes or changes to the system registry the software application Procmon [29] was downloaded and installed on the subject disc. Once everything had installed correctly Windows was shutdown and the drive removed and imaged using EnCase Version 6. This was intended to provide a foundation level image that could be used to compare against and also able to restore the drive to as the various experiments were completed. During any particular experiment changes to the file or system Registry system and any process running were monitored and analysed. At the conclusion of a particular experiment the Operating System was shutdown and the hard disk imaged and the output of the Registry and file monitoring software examined. The flowchart below reveals the initial methodology used to establish a baseline image.

Page 31 of 151

Once the baseline was established further phases were conducted to establish what artefacts were created when data was added to the index, previously indexed data was modified or data was deleted from the index.

It was initially intended to use a physical hard drive when conducting experiments, however as the experimental phase of this project evolved, an alternative method of using VMware was used. The great benefit of using a virtual machine was the fact that the system could be reset to any particular state to re-run any experiment. This re-

Page 32 of 151

setting took a few moments rather than the lengthily time that would have been consumed restoring the drive to its original condition and having to build the index again. When it was necessary to create a forensic image of the current state of the virtual drive then a snapshot was taken of the system. Using the VMWare disk mount utility [34] the snapshot [vmdk file] was mounted as a logical drive by using the command line: vmware-mount [driveletter:] [path-to-vmdk] [options] FTK Imager was then used to create a forensically sound image file from which further examinations could be conducted or particular files copied out for examination by third party tools.

3.7 Tools Utilised

The following tools were utilised during this research:

3.7.1 Inctrl5

Inctrl5 [28] is a before-and-after utility designed to detect disk and registry changes that occur as a result of program execution. Inctrl5 allows the examiner to take a baseline snapshot of the system on which it is deployed, execute an unknown file, and generate an .HTML, .TXT, or .CSV report comparing the before-and-after execution results.

3.7.2 Process Monitor

The primary experimental monitoring tool utilised in this project was the Process Monitor [29] by Sysinternals. In 1996 Mark Russinovich and Bryce Cogswell created a website in order to host their systems utilities tools and technical information. The tools were designed to assist administrators and the likes with their diagnosis of Windows

Page 33 of 151

Systems and applications. In July 2006, Sysinternals was acquired by Microsoft. of the most used tools, which they designed, are Regmon and Filemon. These tools permit a user to view Registry and File activity in real time. Within the forensic

Two

computing discipline these tools are seen as mainstays of the analyst, permitting him to identify possible locations of forensic artefacts. It is an advanced monitoring tool for Windows and combines the features of the two legacy Sysinternals utilities, Filemon and Regmon, and adds a wide ranging list of improvements including non-destructive filtering, comprehensive event properties such session IDs and user names, reliable process information, full thread stacks with integrated symbol support for each operation, simultaneous logging to a file, and much more. Process Monitor runs on Windows 2000 SP4, Windows XP SP2, Windows Server 2003 SP1, and Windows Vista as well as x64 versions of Windows XP, Windows Server 2003 SP1 and Windows Vista. One of the improvements, which Process Monitor brought, was advanced filtering which can be used to reduce the size of log files generated and focus on particular processes or events.

3.7.3 EnCase Version 6

EnCase [30] by Guidance Software combines both imaging and analysis software. EnCase is seen as the worlds leading forensic computing software.

3.7.4 Access Data Registry Viewer

The AccessData Registry Viewer [31] gives the forensic analyst the ability to view independent Windows registry files, providing access to the "Protected Storage System Provider" key, which contains email and Internet passwords and settings. It additionally generates reports containing data from Registry keys of interest.

Page 34 of 151

3.7.5 VMWare Workstation

Although the initial experiment was conducted using a prepared hard drive it was seen that the process of imaging and relaying the image of the clean system could be very time consuming. It was therefore decided that, without compromising the forensic integrity of the experiments, VMWare Workstation [32] could be used to replace the physical drive. In order to carry out various experiments a Windows XP operating system was installed on a VMWare virtual disk. The virtual disk was configured with an 8 Gb Hard Disk and 256 Mb of Memory.

3.7.6 Decode Although WinHex has an inbuilt decoder for filetime it was decided to validate the findings with a third party tool. In order to do this Decode [33] an application written by Craig Wilson, which was designed to decode the various date/time values found embedded within binary and other file types were used.

3.8 Conclusions

This Chapter addressed the research process, design and methodology. It identified the problem and motivation behind the study together with the process that was employed. The experimental strategy was established to be the most appropriate form of research and the data collection method and tools were discussed.

Page 35 of 151

CHAPTER 4 - Windows Desktop Search Version 3.0.1

4.1 Introduction

Having researched the Windows Desktop Search application it was decided that a foundation experiment should be conducted to confirm what files are created upon installation of the indexer and to have a look at the application in its native environment.

4.2 Foundation Experiment

The initial test was to install Windows Desktop Search and establish what files are created or modified by the installation process. Additionally the system Registry was monitored for similarly created or modified hives. Once the disk was booted it was imaged using the FTK imager to an external hard drive. The image of the disk was then loaded into EnCase version 6 and a hash set created of the file set in order to quickly filter out files not changed when experiments were conducted during this project. The Windows Desktop Search cab file was copied to the desktop. Inctrl5 was then used to snapshot the system setup prior to installation and then when prompted the Windows Desktop Search application was installed. Upon completion of the process Inctrl5 was then invoked to carry out an after installation test. Inctrl5 creates a list of both created and modified files on the local file system and also within the System Registry. On completion the results were saved to a hypertext markup text file [html]. The output is available on the accompanying CD-ROM in the \Experiments\Foundation Experiment directory. At the conclusion of the installation the disk was then imaged in order to forensically examine the contents.

Page 36 of 151

4.3 Indexing options

During the installation process of Windows Desktop Search the user can select a number of options including which folders to include in the index. Should the user not select specific locations to be indexed then the application automatically indexes the Documents and Settings folder and email. After installation, should the user decide to change the default search settings he can select Desktop Search Indexing Options and modify search locations and change by either adding or removing locations to be indexed.

Figure 1: Screen shot of Indexing options

When the user selects Modify locations can be de-selected or enabled, other folders may also be added to the index. By default the locations indexed are the contents of the users Desktop, Favourites folder, My Documents Folder, My Recent Documents and

Page 37 of 151

Start Menu. In addition it indexes email and attachments from Microsoft outlook and Outlook express.

Figure 2: screenshot of indexing locations

4.4 Advanced options

When the Advanced Options tab is selected the user can modify Index Settings, File Types and add Uniformed Naming Convention (UNC) location. This is a naming convention for resources on a Wide Area Network (LAN). Such resources could be a server or another computer sharing directories or files on the LAN.

4.5 Index Settings

Closer examination of the Index Settings Tab revealed that the user could select to change file settings, rebuild the Index, or restore it to its original settings. Finally, the user can select to change the storage location of the index.

Page 38 of 151

Figure 3: screenshot of advanced options

4.6 Files Type Tab

When the user selects the File Type Tab they are presented with a list of files that can be indexed together with a description of the filter that is applied to the file type.

Page 39 of 151

Figure 4: screenshot of file types options

Of particular interest is the How should this file be indexed? property. The two options are Index Properties only or, Index properties and File Contents. This is crucial to any forensic examination if the properties only option is set for a particular file type then only metadata relating to the file will be indexed. Evidence that a particular file was present on the system may be sufficient to prove or disprove a case, however if file contents or metadata associated with a file could be retrieved then so much the better. As the user selects each type of file the index properties button will change to show the setting for that particular file type. Interestingly by selecting a file type where the filter Description is that of Microsoft Office Filter both the Index properties only and Index properties and File Contents Radio button are deselected. A user can add a file extension and select how that file extension should be filtered by adding it to the add new extension box at the bottom of the dialog box. The list of files that are indexed include by default:

Type E-mail

Entire Contents eml, msg

File and Metadata

Contacts Appointments Documents

vcf

vcard ics, vcs ade, adp, mpd, mde, mpc, mpp, mpv, vdx, mpx, vsl, vst, vsw, vsx, vtx

Text documents

doc, dot, htm, html, mht, one, rtf, txt, xml

dvi, eps, jnt, latex, pm, pm5, ps, pt5, rtx, tex, xml, pdf

Spreadsheets Presentations

xls, xlw pot, pps, ppt, xls,

csv, tsv, wks, xlb, xlc, xll, xlm ppz

Page 40 of 151

xlw Music aac,aif,aiff,amf,au,cda,dfs,dss,far, m3u, mid, midi, mp3, mus, okt, p16, psm, ra, ram, rmi, s3m, snd, sng, stm, ult, uw, voc, wav, wma, xm, xmi Pictures 3ds, a11, ai, ani, anm, art, b_w, b&w, b1n, b8, bga, bit, bld, bm, cdf, cdr, cmp, cps, cvs, dib, dip, dcx, dkb, dw2, dwg, fh3, fh4, fit, flc, fli, gcd, gif, gl, gsd, hrf, hs2, hsi, iax, ica, jas, jff, jpc, icb, jpe, jpeg, jpg, jtf, lbm, mpt, msp, nc, neo, pct, pcx, pda, pdd, pgm, pix, png, ppm, psd, pse, qdv, rgb, rif, rip, rix, rl4, rl8, sg1, tif, tiff, van, vda, vdr, wmf, xif, xpm Video asf, asx, avi, awm, cmv, m1v, mmm, mov, mp2, mpa, mpe, mpeg, mpg, mpv2, mwf, qt, vue, wmv, wvx Folders Other folder bat, c, cmd, cpp, cxx, Dif, disco, h, hpp, hxx, idl, inc, inf, inx, js, nws, pl, ppa, pwz, rc, reg, resx, slk, url, vbs, xla, xld, xlt, xlv, xsl Type E-mail Contacts Appointments Documents Entire Contents eml, msg vcf vcard ics, vcs ade, adp, mpd, mde, mpc, mpp, mpv, vdx, mpx, vsl, vst, vsw, vsx, vtx Text documents doc, dot, htm, html, mht, one, rtf, txt, xml Spreadsheets Presentations xls, xlw pot, pps, ppt, xls, xlw Music aac,aif,aiff,amf,au,cda,dfs,dss,far, m3u, mid, midi, mp3, mus, okt, p16, psm, ra, ram, rmi, s3m, snd, sng, stm, ult, uw, voc, wav, wma, xm, xmi csv, tsv, wks, xlb, xlc, xll, xlm ppz dvi, eps, jnt, latex, pm, pm5, ps, pt5, rtx, tex, xml, pdf File and Metadata acf, aifc, ascx, asm, asp, aspx, bmp, cab, Com, cpl, cs, css, cur, def, dic, emf, gz, hhc, ico, idq, ivf, ivf, jfif, lnk, mapiipm.Note, mda, mp2v, odc, pl, rle, scd, tar, tgz, tsp, wax, wbk, sch, wiz, wm, wmp, wmx, wmz, wri, wsz, wtx, xlk, z, zip

Page 41 of 151

Pictures

3ds, a11, ai, ani, anm, art, b_w, b&w, b1n, b8, bga, bit, bld, bm, cdf, cdr, cmp, cps, cvs, dib, dip, dcx, dkb, dw2, dwg, fh3, fh4, fit, flc, fli, gcd, gif, gl, gsd, hrf, hs2, hsi, iax, ica, jas, jff, jpc, icb, jpe, jpeg, jpg, jtf, lbm, mpt, msp, nc, neo, pct, pcx, pda, pdd, pgm, pix, png, ppm, psd, pse, qdv, rgb, rif, rip, rix, rl4, rl8, sg1, tif, tiff, van, vda, vdr, wmf, xif, xpm

Video

asf, asx, avi, awm, cmv, m1v, mmm, mov, mp2, mpa, mpe, mpeg, mpg, mpv2, mwf, qt, vue, wmv, wvx

Folders Other

folder bat, c, cmd, cpp, cxx, Dif, disco, h, hpp, hxx, idl, inc, inf, inx, js, nws, pl, ppa, pwz, rc, reg, resx, slk, url, vbs, xla, xld, xlt, xlv, xsl acf, aifc, ascx, asm, asp, aspx, bmp, cab, Com, cpl, cs, css, cur, def, dic, emf, gz, hhc, ico, idq, ivf, ivf, jfif, lnk, mapiipm.Note, mda, mp2v, odc, pl, rle, scd, tar, tgz, tsp, wax, wbk, sch, wiz, wm, wmp, wmx, wmz, wri, wsz, wtx, xlk, z, zip

Table 1 List of Supported File Types

Page 42 of 151

4.7 Add UNC Location

By selecting the Add UNC Locations Tab a user can add remote network shared locations to the Index.

Figure 5: screenshot of UNC locations tab

4.8 Files created or modified

Examination of the output from the Inctrl5 revealed that a total of 45 folders were created on installation of the Windows Desktop Search application.

Page 43 of 151

Figure 6: screenshot of Encase view of indexing files

Examination of the folders created during the installation process together with the various reference sources and documentation discovered during the research phase highlighted a number of files of interest to the forensic examiner. It is perhaps worthwhile to discuss them prior to the start of the experimentation phase proper of the project. The Search folder had two sub directories, Config and Data. The config directory contained a single file named msscolmn.txt. Examination of this file revealed that it contained a warning DO NOT EDIT THIS FILE. Examination of its contents revealed that it defined columns for windows search. The Data Directory had three sub directories Applications, Config and Temp. The Config directory contained two files; gathrprm.txt and schema.txt. The gathrprm.txt file was found to contain the global gatherer parameters such as the Maximum length permitted in the description column etc. The schema.txt was found have a warning DO NOT EDIT THIS FILE. The document itself contained the schema for the Windows Desktop Search and included the column name and among other properties

Page 44 of 151

the maximum size. An example is the Search.AutoSummary column where the maximum size for entries is set to 2048 bytes. The application directory contained a further sub directory named Windows. This directory contained three sub directories Config, GatherLogs and Projects. In addition to the three sub directories also present was the Windows.edb file, which is the property store. The Windows.edb file will be described in detail later in this chapter. The Projects directory contained a single sub directory named SystemIndex.

Figure 7: Encase screenshot of SystemIndex directory

As can be seen from the screenshot above the directory contained a number of files and sub directories. The SystemIndex.Ntfy4.gthr file was identified by Stewart [19] as the Transaction Log file for the Indexer. This file will be dissected in detail later during the report.

4.9 Examination of the Windows.edb file

From research it was known that the Windows.edb file is described as the property store. It was believed that this is where the indexed content together with properties of the indexed documents is stored. In order to examine the entries in the Windows.edb it was necessary to use a software application that would permit the author to view the various tables and entries that make Page 45 of 151

up the database. As was highlighted during the literature review section of the project the Windows.edb file is a Joint Engine Technology (JET) database. Although it was known that Microsoft Access could open JET databases, it was not until the experimentation phase that the author discovered that there are in fact two different types of JET Database [34]. Access can open JET Red databases, however the Windows.edb file is in fact an Extensible Storage Engine [35] (also known as JET Blue) and is not compatible with Access. Research on the subject of JET databases identified the ESENTUTL.exe [36] tool found in the system32 directory that can be used to extract metadata relating to the Windows.edb file.

Figure 8: Screenshot of esentutls.exe options

The help option shows the various options available. The one that is particularly helpful in respect of investigating the Windows.edb file is the File Dump switch. There are number of switches that could be used with the File Dump option.

Page 46 of 151

Figure 9: esentutls.exe File Dump options

The Windows.edb file was processed using the /mh switch with the output saved as test1wh.txt.
Microsoft(R) Windows(TM) Database Utilities Version 5.1 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... Database: C:\Documents and Settings\Jim\Desktop\WDS Test1\Test Data\Test1.edb File Type: Database Format ulMagic: 0x89abcdef Engine ulMagic: 0x89abcdef Format ulVersion: 0x620,9 Engine ulVersion: 0x620,9 DB Signature: Create time:11/18/2007 10:23:25 Rand:12652078 Computer: cbDbPage: 8192 dbtime: 35690 (0x8b6a) State: Clean Shutdown Log Required: 0-0 (0x0-0x0) Streaming File: No Shadowed: Yes Last Objid: 307 Scrub Dbtime: 0 (0x0) Scrub Date: 00/00/1900 00:00:00 Repair Count: 0 Repair Date: 00/00/1900 00:00:00 Last Consistent: (0x1B,38,3C) 09/10/2008 21:00:53 Last Attach: (0x18,9A,194) 09/10/2008 20:58:54 Last Detach: (0x1B,38,3C) 09/10/2008 21:00:53 Dbid: 1 Log Signature: Create time:11/18/2007 10:23:24 Rand:12682868 Computer: OS Version: (5.1.2600 SP 2) Previous Full Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Current Incremental Backup: Log Gen: 0-0 (0x0-0x0)

Page 47 of 151

Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Current Full Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Current snapshot backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 cpgUpgrade55Format: 0

Figure 10: Output of esentutls.exe /mh switch command

Examination of the exported file revealed the details of the size of a database page is 8192 bytes in size. It also revealed whether the database was shutdown cleanly or not. Other switches that could be used included esentutls.exe/mm <path to Windows.edb file>, which parses metadata. This provided a whole wealth of data. It revealed the names of the various tables within the database and in the case of the SystemIndex_0A table the various fields within the table. Examination of the exported file reveals that information in respect of the schema. The first part of the output is shown above.

Microsoft(R) Windows(TM) Database UtilitiesVersion 5.1Copyright (C) Microsoft Corporation. All Rights Reserved.Initiating FILE DUMP mode... Database: G:\WDS Test1\Test Data\windows.edb ******************************* META-DATA DUMP ******************************* Name Type ObjidFDP PgnoFDP ============================================================================== G:\WDS Test1\Test Data\windows.edb Db 1 1 MSysObjects Name RootObjects MSysObjectsShadow SystemIndex_0A ISystem_ApplicationName ISystem_Audio_ChannelCount ISystem_Audio_EncodingBitrate ISystem_Author ISystem_Calendar_Duration ISystem_Calendar_IsRecurring ISystem_Calendar_Location ISystem_Calendar_ReminderTime ISystem_Calendar_Resources ISystem_Calendar_ShowTimeAs ISystem_Calendar_ShowTimeAsText ISystem_Communication_AccountName ISystem_Communication_TaskStatus Tbl Idx Idx Tbl Tbl Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx 2 4 5 3 16 210 202 180 112 47 176 33 127 71 131 70 63 96 4 7 10 24 869 749 741 719 962 900 715 886 250 921 254 920 913 946

Figure 11: esentutls.exe File Dump output

The full output from this command is pages in length and so is attached at Appendix A.

Page 48 of 151

It can be seen that within the Windows.edb file are a series of tables and fields.
Name MSysObjects MSysObjectsShadow SystemIndex_0A SystemIndex_0P SystemIndex_DeletedDocIds SystemIndex_DeletedDocIds_S SystemIndex_Gthr SystemIndex_GthrPth SystemIndex_GthrPth_S SystemIndex_Gthr_RecCount SystemIndex_Gthr_S SystemIndex_MaxDoc SystemIndex_MaxDoc_S __NameTable__ ObjidFDP 2 3 16 15 225 306 11 8 300 7 302 221 304 6 PgnoFDP 4 24 869 769 1281 2049 513 257 613 133 1125 1025 1381 33

Table 2 Windows.edb file Tables

The list above shows the tables within the Windows.edb file. With the esentutls tool the structure of the database is becoming clear. It was time to look in greater detail at its contents. The problem remained of not being able to view the contents of the database file natively. Fellow Cranfield student John Douglas, who is an extremely competent programmer is currently developing a viewer and as can be seen in Appendix B, Passware Inc, released Search Index Examiner software during November 2008. Nonetheless at the time no such software existed. A major breakthrough came when contact through the Microsoft Law Enforcement portal resulted in the supply of a viewer for the database.

Page 49 of 151

The Windows.edb file was exported from the base image file and examined in order to establish what forensic artefacts were present. The file itself was seen to be 18 Mb in size. The file was inspected in Hexidecimal/ASCII viewing using WinHex application. When the author scrolled through the file various fields or properties were seen. The screenshot below reveals part of various fields within the Windows.edb file SystemIndex_Gthr table. The background view is the table when viewed in Winhex and in the foreground is the table when viewed in the Microsoft Database Viewer.

Figure 12 Screenshot of WinHex together with Microsoft Database Viewer.

Page 50 of 151

The Windows.edb file was opened using the Microsoft Database Viewer. The various tables within the database could now be seen and the content viewed.

Figure 13 Screenshot of SystemIndex_0A table

The screenshot above reveals the various columns within the SystemIndex_0A table. The benefit of having a viewer to be able to view the contents of the file cannot be overstated. Further detailed examination of the Windows.edb file will continue in the experimentation chapter.

Page 51 of 151

4.10 How the Windows Desktop Search Application works

The literature Review highlighted a number of sources outlining the functionality of the Windows Desktop Search application including Brandon Paddocks blog and the MSDN web site. The latter offers a detailed description of the main components of the indexer together with a explanation of its functionality. It is worthwhile at this point taking time to examine the functionality of the Windows Desktop Search application, prior to starting the experimentation phase of the project. A number of the sources revealed that when the application is installed an index is built of the files in a users profile. The initial build of the index can be time consuming, but is a one off event unless a user selects to rebuild the index at a later date. Having built the index the user can then search quickly for data provided that it is of a type that has been selected for indexing.

4.10.1 Architecture

The most important element of the Windows Search is the indexer without which there would be no database. The indexer crawls through the file system and maintains the index. Three processes are used to carry out this task. SearchIndexer.exe; responsible for maintaining the index, servicing queries, in addition to deciding when and what files to crawl. SearchProtocolHost.exe; hosts a Protocol Handler responsible for enumerating items in a specific store such as the file system, share etc. SearchFilterHost.exe; This process hosts the actual IFilters. These filters are responsible for processing individual items, such as files, in a data store.

Page 52 of 151

4.10.2 The Indexing Process

The MSDN web site has a detailed description of the indexing process [36]. Figure 14 below is taken from the description of the indexing process. The first stage of the index process involves the gatherer collating changes to the data stores such as the local file system. A comparison is then made against the known areas to be indexed, such as a users My Documents folder and a queue is then built of files to be traversed. [37]

4.10.3 Gatherer Queues

The second stage of the indexing process involves the gatherer actually crawling through the list of items to be crawled. It does that by the Protocol Handler [38], which passes the metadata back to the gatherer. This allows the Gatherer to select the correct filter to be able to extract the data. The final stage involves the updating of the actual index. Having received the list of files to be crawled the filter and correct property handler retrieve the content for the index. The Gatherer then updates the systemindex.

4.10.4 IFilter

In order to be able to scan the documents and extract the various property items such as text, Microsoft use IFilters [39]. These filters are critical to the whole process of indexing and as described above extract the various property items for the gatherer. In addition to the iFilters that Microsoft supply its possible for a user to write their own should they have a particular need.[40]

4.10.5 Property Store.

The various property items that make up the store of items found while indexing are recorded within the Windows.edb file. Such properties are lasted at Appendix A. These

Page 53 of 151

can include common items such as Size of an item or in respect of photographs System.Photo.DateTaken. A detailed examination of the Windows.edb file is detailed at Chapter 4 Section 4.9.

4.10.6 Content Change

When a file is changed in some way whether by being added, modified or deleted, there has to be a way of the indexer being notified in order to update the property store. Microsoft manages this through the User Change Journal [41] for the local file system. The User Change Journal is a method by which the NTFS file system monitors changes to a volume.

Figure 14 Top Level view of principal components and flow of data through the indexing process

Page 54 of 151

4.11 Examination of the System Registry

The examination of the system registry could easily become a project on its own; in fact there have been students who have submitted dissertations on the subject. Additionally there is a great quantity of material that has been published on the subject. Therefore the author will provide a brief overview of the registry in particular the functionality of the Registry in relation to the Windows Desktop Search. Before going any further it is perhaps worthwhile ensuring that the reader is conversant with a few points in respect of the Windows registry. The registry is essentially a hierarchical database of the system settings and configuration. In order to be able to read or edit specific settings users will generally use a registry editor, such as the one that is native to windows systems Regedit. Selecting Run from the start menu and typing Regedit will invoke the registry editor. In addition to Regedit an offline third party viewer, the Access Data Registry Viewer was also used. Examination of the output from Inctrl5 revealed that a total of 2017 keys were added to the system registry, upon installation. Detailed explanation of the huge amount of keys is outside the scope of this project as the focus is to provide an investigator with information of evidential value therefore only those keys that provide such information shall be highlighted. As the system used during the project was a Windows XP system, there are a number of locations that potentially could provide evidence of desktop search activity. When the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Desktop Search key was examined it was seen that there were a number of sub keys including the current version of Windows Desktop Search installed, in this case as can be seen from the screenshot below version 3.01.6000.72.

Page 55 of 151

Figure 15 - Screenshot of Windows Desktop Search Key opened with Access Data Registry Viewer

Examination of the remaining keys within the key provided nothing worthy of comment at this stage of the report. The output of Inctrl5 additionally highlighted that upon the installation of Windows Desktop Search a number of keys were created in the HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows\Windows Search hive. Examination of this revealed a number of keys of interest to the investigator.

Figure 16 Screenshot of Windows Search key opened with Access Data Registry Viewer

The above screenshot shows the sub keys within the Windows Search registry key. The key has not been fully opened due to the number of sub keys. On viewing the sub key

Page 56 of 151

names it can be seen that there are several that appear on first glance to be of interest to an investigator, such as CrawlScopeManager and Databases. As the author continued to browse through the sub keys it was noted that within the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\WindowsSearch\CatalogNam es\Windows\SystemIndex sub key were a number of entries relating to the catalog crawl.

Figure 17 - Screenshot of SystemIndex sub key opened with Access Data Registry Viewer

As can be seen from the above screenshot of the SystemIndex subkey there is a binary value that appears to be consistent with a 64 bit FILETIME. Further experimentation will have to be conducted to confirm that the binary value is in fact a FILETIME.

Page 57 of 151

The Databases\Windows subkey held an entry named FileName that recorded the current location of the Database Windows.edb file.

Figure 18 Location of the Windows.edb file opened with Access Data Registry Viewer

The above was just a cursory look at the various entries of the HKEY_LOCAL_MACHINE that holds the configuration detail for the computer itself. In Addition to the HKEY_LOCAL_MACHINE key each user on a system has a specific file within their profile settings called NTUSER.dat. The file is used to contain a large amount of information about a users activity such as their personal system settings for example their desktop picture and recently used documents to name but a few. The NTUSER.dat file associated with the user MSc was exported and examined using the Access Data Registry Viewer. It was seen that there were a number of registry keys that appeared very similar to the ones found in the local machine settings.

Page 58 of 151

Figure 19 NTUSER.dat Windows Desktop Search key opened with Access Data Registry Viewer

On examination these keys it could be seen that there was a string value (currently unset) named SearchStrings. This particular key was worthy of further examination as the experimentation phase continued. On continuing to browse the NTUSER.dat settings it was seen that there was also a Windows Search key.

Figure 20 - NTUSER.dat Windows Search key opened with Access Data Registry Viewer

The majority of these keys had a value not set and so were not of interest to an investigator at this stage.

Page 59 of 151

4.12 Conclusions

This Chapter gave a brief overview of the system files and registry keys created upon installation of the Windows Desktop Search. It highlighted and described some of the files and processes central to the indexer and outlined the indexing process. Examination of the Windows Registry revealed locations where a forensic analyst could potentially find data of an evidential nature, during any subsequent investigation. The Microsoft Database Viewer was briefly described, as were other software tools that are available to view the contents of the Windows.edb file.

Page 60 of 151

CHAPTER 5 - Experimentation

5.1 Experiment 1 Adding data

The purpose of the first experiment was to establish what changes occur to the file system or Registry when data was added to the index. The baseline hard drive with the Windows Desktop Search installed was booted and ProcMon was used to monitor file and registry activity. A text document named test1.txt was created in the C:\Documents and Settings\MSC Test\My Documents file path. The document had been created on 9th September 2008 at 21:21. A short period of time was allowed for the user change journal to notify the indexer that a file had been added to the file system and for the file to be indexed. The Procmon log file was saved in both PML and CSV file formats. To prevent the log files themselves being added to the index they were saved in the C:\Program Files file path. The computer was then shut down in the normal method and the drive removed for the computer. The drive was attached to a Tableau write blocker and imaged using FTK imager version 2.54.16. An Encase case file named MSc was created and the EnCase evidence files added and allowed to verify.

5.2 New Technology File System [NTFS]

Central to the NTFS file system used in this series of experiments is the Master File Table [MFT]. The MFT is essentially a database holding details of all of the files on the volume. It views each file as a set of file attributes. In order to establish a baseline in respect of the Test1.txt file the MFT record was extracted. The record itself is generally found to be 1024 bytes in length and is made up of various entries or attributes. One of these attributes named the standard information attribute stores four FILETIME stamps; File created FILETIME stamp, File modified FILETIME stamp, Entry Modified FILETIME stamp and

Page 61 of 151

Last Accessed FILETIME stamp. FILETIME is defined as a 64-bit value representing the number of 100 nanosecond intervals that have elapsed since January 1 1601. [20] The MFT entry was extracted and viewed with Winhex in hexadecimal view.
Offset 0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 FILE0 8 Q ! X / ` H |J R` R` jF 7 f \ ' |J t e s t 1 . t x t T X @ v ~ = ayG yG N e w T e x t x t yG D o c u m e n t . t ( )T 0 T |J |J |J p

46 49 4C 45 30 00 03 00 05 00 01 00 38 00 01 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7C 4A AC AA B9 12 C9 01 04 52 60 B7 B9 12 C9 01 20 00 00 00 00 00 00 00 00 00 00 00 66 01 00 00 B0 C6 5C 00 00 00 00 00 00 00 00 00 00 00 04 00 E2 27 00 00 00 00 01 00 7C 4A AC AA B9 12 C9 01 7C 4A AC AA B9 12 C9 01 00 00 00 00 00 00 00 00 09 03 74 00 65 00 73 00 78 00 74 00 54 00 58 00 00 00 00 00 00 00 05 00 76 0E FD F0 AC 7E DD 11 80 00 00 00 20 00 00 00 01 00 00 00 18 00 00 00 FF FF FF FF 82 79 47 11 20 00 00 00 00 00 00 00 20 00 54 00 65 00 78 00 63 00 75 00 6D 00 65 00 78 00 74 00 00 00 00 00 00 00 18 00 00 00 01 00 FF FF FF FF 82 79 47 11

51 1B 21 07 00 00 00 00 58 01 00 00 00 04 00 00 06 00 00 00 0F 2F 00 00 10 00 00 00 60 00 00 00 48 00 00 00 18 00 00 00 04 52 60 B7 B9 12 C9 01 6A 46 09 DB 90 37 C9 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 70 00 00 00 54 00 00 00 18 00 01 00 7C 4A AC AA B9 12 C9 01 7C 4A AC AA B9 12 C9 01 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 74 00 31 00 2E 00 74 00 40 00 00 00 28 00 00 00 10 00 00 00 18 00 00 00 BF 3D 00 0C 29 54 05 E6 00 00 18 00 00 00 01 00 61 FF FF FF 82 79 47 11 00 00 00 00 00 00 00 00 15 01 4E 00 65 00 77 00 74 00 20 00 44 00 6F 00 6E 00 74 00 2E 00 74 00 80 00 00 00 18 00 00 00 00 00 00 00 18 00 00 00 00 00 00 00 00 00 00 00

The standard information attribute can be seen at file offset 56 above and continues for a length of 56 bytes.

Page 62 of 151

Offset 48 64 80 96

9 10 11 12 13 14 15 ` H |J R` R` jF 7

10 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00 7C 4A AC AA B9 12 C9 01 04 52 60 B7 B9 12 C9 01 48 00 00 00 18 00 00 00 04 52 60 B7 B9 12 C9 01 6A 46 09 DB 90 37 C9 01

The four eight byte FILETIME stamps were decoded as the following:
Field Creation FILETIME Last Modified FILETIME Last MFT Record Change FILETIME Last Accessed FILETIME 6A 46 09 DB 90 37 C9 01 26th October 2008 at 17:32:44 hrs Hexidecimal Value 7C 4A AC AA B9 12 C9 01 04 52 60 B7 B9 12 C9 01 04 52 60 B7 B9 12 C9 01 Decoded Value 9th September 2008 at 20:21:39 hrs 9th September 2008 at 20:22:01 hrs 9th September 2008 at 20:22:01 hrs

Table 3 Decoded FILETIME Stamps from $MFT Standard Information Attribute entry.

The second attribute in the record is the FILE_NAME attribute. It records including other items FILETIME stamps. The FILE_NAME can be seen at file offset 152 and continues for a length of 112 bytes. This attribute records amongst other things detail of File creation FILETIME stamp, file Modification FILETIME stamp, MFT modification FILETIME stamp and file access time.
Offset 144 160 176 192 208 224 240 256 00 00 00 00 00 00 04 00 E2 27 00 00 00 00 01 00 7C 4A AC AA B9 12 C9 01 7C 4A AC AA B9 12 C9 01 00 00 00 00 00 00 00 00 09 03 74 00 65 00 73 00 78 00 74 00 54 00 58 00 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 T ' |J t e s t 1 . t x t T X |J |J |J p

30 00 00 00 70 00 00 00 54 00 00 00 18 00 01 00 7C 4A AC AA B9 12 C9 01 7C 4A AC AA B9 12 C9 01 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 74 00 31 00 2E 00 74 00

Page 63 of 151

Field Creation Time & Date Last Modified Time & date Last MFT Record Change Time & Date Last Accessed Time & Date

Hexidecimal Value 7C 4A AC AA B9 12 C9 01 7C 4A AC AA B9 12 C9 01 7C 4A AC AA B9 12 C9 01

Decoded Value 9th September 2008 at 20:21:39 hrs 9th September 2008 at 20:21:39 hrs 9th September 2008 at 20:21:39 hrs

7C 4A AC AA B9 12 C9 01

9th September 2008 at 20:21:39 hrs

Table 4 - Decoded FILETIME Stamps from $MFT File Name attribute.

As can be seen from the screenshot below these date and times corroborate the details decoded by Encase software.

Figure 21 Screenshot of test1.txt entry in EnCase (times in UTC+1)

Therefore the initial part of the experimental phase established the baseline in respect of the date and times for the added test file. The next part of the experiment was to conduct a text string search for the name of the file test1. This resulted in hits being recorded in a number of files that had been highlighted in the literature review; the SystemIndex.NtfyX.gthr and Windows.edb file.

Page 64 of 151

5.3 Dissecting the SystemIndex.Ntfy3.gthr

The SystemIndex.Ntfy3.gthr was exported and examined using WinHex. the format of an entry in the file as:

Stewart [19]

highlighted the SystemIndex.Ntfy3.gthr in his research into Vista forensics and described

HEADER BLOCK 4 bytes HeaderID 12 bytes Unknown 8 bytes Time 1 8 bytes Time 2 8 bytes Const_1 8 bytes Unknown

FILENAME variable byte size


FOOTER BLOCK 13 bytes 8 bytes 4 bytes Footer ID Time 3 Const_2 8 bytes 20 bytes Time 4 Unknown 8 bytes 8 bytes Time 5 Time 6 20 bytes Unknown

Figure 22 Format of Entries in gather Log File

He described the file as having a 67 byte header block that revealed that the file is a Microsoft Search Gatherer Transaction Log. Format Version 4.9. This can be seen in the extracted file with the recognisable ASCII characters starting at File offset 04.
Offset 00000000 00000016 00000032 00000048 00000064 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ? Microsoft Se

3F 00 00 00 4D 69 63 72 61 72 63 68 20 47 61 74 61 6E 73 61 63 74 69 6F 6F 72 6D 61 74 20 56 65 39 1A 00

6F 73 6F 66 74 20 53 65 68 65 72 65 72 20 54 72 6E 20 4C 6F 67 2E 20 46 72 73 69 6F 6E 20 34 2E

arch Gatherer Tr ansaction Log. F ormat Version 4.

Figure 23: Screenshot of EnCase SystemIndex.Ntfy.3.gthr file

Page 65 of 151

On browsing the file it was seen that each entry had as Stewart describes a 4 byte header ID. This can be seen to be 0x 4D 44 4D 44. The file test1.txt had two separate entries for when the file was added to the system. The first entry was seen at File Offset 2224. The entire entry was extracted to a new file test1_entry1.bin for examination.
Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144 00000160 00000176 00000192 0 4D AC 02 63 20 73 74 00 FF 00 99 00 00 1 44 45 00 3A 53 74 65 00 FF 00 C2 00 00 2 4D C0 00 5C 65 5C 73 FF A6 00 B9 01 3 44 B1 00 44 74 4D 74 FF 43 00 12 00 4 72 B9 00 6F 74 79 31 FF 99 00 C9 00 5 09 12 00 63 69 20 2E FF C2 00 01 00 6 00 C9 00 75 6E 44 74 04 B9 00 A6 00 7 00 01 00 6D 67 6F 78 52 12 00 43 00 8 00 B2 00 65 73 63 74 60 C9 00 99 00 9 10 11 12 13 14 15 00 8D 00 6E 5C 75 00 B7 01 00 C2 00 00 AA 00 74 4D 6D 00 B9 EC 00 B9 00 00 C4 00 73 53 65 00 12 F8 00 12 00 6B B9 3A 20 63 6E 00 C9 42 00 C9 00 01 12 00 61 20 74 00 01 7E 00 01 00 80 C9 00 6E 54 73 00 FF 0E A6 00 00 00 01 00 64 65 5C 00 FF 00 43 00 00 MDMDr k E : c:\Documents and Settings\MSc Te st\My Documents\ test1.txt R` C B~ C C

It can be seen that after the 4 byte header there are 12 bytes that Stewart describes as unknown. Examination of the entry reveals that it can be seen that the first two bytes are 72 09 with bytes 12, 13 and 14 being 6B 01 80 respectively. Examination of the other entries in the log file revealed that byte 5 of the entry appeared to increment by the value of one for each entry. Further testing was conducted to corroborate whether this is indeed a sequential counter, in this case being the ninth entry in the log. Bytes 16 23 it can be seen there is a FILETIME, which is decoded to 9th September 2008 at 20:21:51 hrs. At bytes 24 31 is a second FILETIME stamp that is decoded to 9th September 2008 at 20:22:23 hrs. There then follows 8 bytes with byte 32 recording the value 0x 02. The second set of 8 bytes has byte 44 showing a value of 0x 3A. When the value of 0x 3A is converted to decimal we get the value of 58, which is the string length of the File Path and File Name from 0. Further testing detailed in Chapter 5.5 was conducted to corroborate this

Page 66 of 151

artefact. Bytes 48 104 are the path and filename, followed by nine bytes of padding with 0x 00. Bytes 114 117 is the File Block Header 0x FF FF FF FF. The next 8 bytes are a further FILETIME stamp that is decoded to 9th September 2008 at 20:22:01 hrs. The next four bytes 126 129 are 0x FF FF FF FF. Bytes 130 137 are a further FILETIME stamp that is decoded to 9th September 2008 at 20:22:19 hrs. There then follows 20 bytes from byte 138, the first 5 bytes of which hold the values 0x EC F8 42 FE 0E. Bytes 158 165 are a further FILETIME stamp that is decoded to 9th September 2008 at 20:22:19 hrs. Bytes 166 173 are the final FILETIME stamp that decodes to 9th September 2008 at 20:22:19 hrs. The final 20 bytes have only one entry at byte 178 which is 0x 01. (You must justify the claims of bytes being dates and times) The second entry that related to the file test1.txt was also copied to a separate file test1_entry2.bin for analysis.
Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144 00000160 00000176 00000192 0 4D 16 02 63 20 73 74 00 FF 00 AF 00 00 1 44 33 00 3A 53 74 65 00 FF 00 C4 00 00 2 4D 53 00 5C 65 5C 73 FF 00 00 B9 01 3 44 B3 00 44 74 4D 74 FF 80 00 12 00 4 34 B9 03 6F 74 79 31 FF 3E 00 C9 00 5 0A 12 12 63 69 20 2E FF D5 00 01 00 6 00 C9 04 75 6E 44 74 04 DE 00 66 00 7 00 01 00 6D 67 6F 78 52 B1 00 52 00 8 00 66 02 65 73 63 74 60 9D 00 AF 00 9 10 11 12 13 14 15 00 52 00 6E 5C 75 00 B7 01 00 C4 00 00 AF 00 74 4D 6D 00 B9 FF 00 B9 00 00 C4 00 73 53 65 00 12 FF 00 12 00 69 B9 3A 20 63 6E 00 C9 FF 00 C9 00 01 12 00 61 20 74 00 01 FF 00 01 00 80 C9 00 6E 54 73 00 FF 0E 66 00 00 00 01 00 64 65 5C 00 FF 00 52 00 00 MDMD4 i 3S fR : c:\Documents and Settings\MSc Te st\My Documents\ test1.txt R` > fR fR

Byte 5 held the value 0A which converts to decimal 10. This increments the previous entry by the value of one. It was seen that bytes 16 23 contains a FILETIME that was decoded to 9th September 2008 at 20:21:54 hrs. Bytes 24 32 contains a further FILETIME of 9th September 2008 at 20:22:23 hrs. Bytes 118 125 contain a further FILETIME of 9th September 2008 at 20:22:01 hrs. Bytes 130 -137 that in the first entry held a FILETIME that decoded to 1st January 1970 at 00:00:00 hrs. At byte 142 was the value 0x 0e. Bytes

Page 67 of 151

158 -165 contain a further FILETIME of 9th September 2008 at 20:22:23 hrs. The same time is recorded at bytes 166 173. The remaining 20 bytes from 174 -193 were zeroed with the exception of byte 178 which held the value 0x 01. We can now reveal the various entries and compare them with the first entry in the table below. Notwithstanding the various FILETIME stamps the differences between the two have been highlighted.
Byte OffSet 03 4 - 15 Entry 1 4D 44 4D 44 72 09 00 00 00 00 00 00 6B 01 80 00 16 - 23 24 31 32 - 47 9th September 2008 20:21:51 hrs 9
th

Entry 2 4D 44 4D 44 34 0A 00 00 00 00 00 00 69 01 80 00 09 September 2008 20:21:54 09 September 2008 20:22:23 02 00 00 00 03 12 04 00 02 00 00 00 3A 00 00 00 Path & File name FF FF FF FF 9th September 2008 20:22:01 hrs FF FF FF FF 00 80 3E D5 DE B1 9D 01 FF FF FF FF 0E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9th September 2008 20:22:23 hrs 9th September 2008 20:22:23 hrs 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00

September 2008 20:22:23 hrs

02 00 00 00 00 00 00 00 00 00 00 00 3A 00 00 00

48 113 114 117 118 125 126 -129 130 137 138 157

Path & File name FF FF FF FF 9


th

September 2008 20:22:01 hrs

FF FF FF FF 9
th

September 2008 20:22:19 hrs F8 42 7E 0E 00 00 00 00 00 00 00 00 00 00 00 00 September 2008 20:22:19 hrs

158 - 165 166 173 174 - 193

EC 00 00 00 9th

9th September 2008 20:22:19 hrs 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00

Table 5 Comparison between Transaction Log entries.

It can be seen from the above table that after the record header that bytes 4 and 5 have changed in the second entry. Byte 4 changes from 0x 72 (translates to decimal 114) to 0x 34 (Decimal 52). Interestingly byte 5 has been incremented by one from 09 to 0A

Page 68 of 151

(translates to decimal 10). Byte 12 also changes from 0x 6B (decimal 107) to 0x 69 (decimal 105). The first two FILETIME stamps found between bytes 16 31 inclusive have remained the same. Bytes 36 38 inclusive have changed from holding a value of 0x 00 00 00 to 0x 03 12 04. The six FILETIME stamps between bytes 130 137 appears to have the FILETIME 1st January 1970 at 00:00:00 written to the second entry. This value is possibly a nil value used by the writers of the application. Bytes 138 -141 inclusive have the value 0x EC F8 42 7E changed to 0x FF FF FF FF, although both still have the value 0x OE which translates to decimal 14 after it. The two separate FILETIME stamps at bytes 158 165 and bytes 166 -173 have also been updated from 9th September 2008 20:22:19 hrs to 9th September 2008 20:22:23 hrs respectively. To corroborate what activity was occurring on the system around the time recorded in the log file entry the Procmon log file was examined when all activity concerning the Test1.txt file was filtered it was seen that at 20:22:01 hrs Notepad had completed creating the file. At 20:22:20 hrs entries linked to the SearchProtocolhost.exe process started. This is the process identified during the literature review as being responsible for enumerating items in a specific store (such as the File System, Outlook, UNC shares, Lotus, etc) It essentially gathers the content of files.

5.4 Dissecting the Windows.edb file

A text string search for the test file had revealed a keyword hit in the Windows.edb file at file offset 4247729. The Windows.edb file was extracted and viewed with Winhex, and the area of the text string hit exported as a separate file.

Page 69 of 151

Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144

9 10 11 12 13 14 15 & T _ > ) Z T E i T E S 1 . T X R` T _ i

00 00 00 26 00 7F DF 0C 00 54 00 09 31 00 2E 00 00 00 00 00 00 04 7F 80 FF 0C 5F 0E 00 00 00 FF 80 3E D5 DE B1 9D 01 00 12 C9 01 FF FF FF FF 29 FF FF FF 00 00 00 00 00 5A 8E AA 7F 13 C9 01 00 00 00 00 00 00 00 00 00 53 00 54 00 31 00 2E 00

FF 69 7F 54 00 45 00 53 54 00 58 00 09 54 00 00 00 00 0E 12 80 5F 00 69 FF FF FF 07 00 00 00 00 00 00 00 04 52 60 B7 B9 00 00 00 00 00 00 00 FF D3 CC C3 B9 12 C9 01 00 00 02 00 00 00 00 00 09 00 FC 14 00 54 00 45 00 54 00 58 00 54

S T 1 . T X T

It can be seen that the file name in Unicode starts at offset 13 and runs for 12 bytes. What appear to be four separate recognisable FILETIME entries can also be seen as highlighted above. In order to examine the entries in the Windows.edb it was necessary to use a software application that would permit the author to view the various tables and entries that make up the database. Contact with Microsoft through the Law Enforcement portal during September 2008 resulted in the supply of a viewer for the database. This viewer is not available for general release and any requests for a copy should be made by authorised users through the portal. The extracted Windows.edb file was opened in the Microsoft Database Viewer. It was seen that the test1.txt file is recorded in two tables, the SystemIndex_Gthr and the SystemIndex_0A. Examination of the SystemIndex_Gthr table of the database revealed that four FILETIME stamps are recorded for the entry.

Page 70 of 151

Doc ID 14

File Name

FirstAccess

LastAccess

LastModified

TimeMD5Changed

TEST1.TXT

09 September 2008 20:22:22 UTC

10 September 2008 19:59:00 UTC

09 September 2008 20:22:01 UTC

01 January 1970 00:00:00 UTC

Table 6 SystemIndex_gthr table entries for test1.txt file

When the various records were selected it could be seen that the test1.txt document was recorded as document ID 14. This is the same value that was found at byte 142 of the transaction log entries highlighted above. Having the benefit of being able to view the various tables and columns in the edb file we can now see that there are 4 FILETIME stamps. First Accessed, Last Accessed, Last Modified and Time MD5 Changed. From the extracted Windows.edb file entry above we can now establish what the 4 FILETIME stamps refer to: The FILETIME stamp for the Time MD5 Changed field was found between offset 63 and 70. The FILETIME stamp for the Last modified field was found between offsets 75 and 82. The FILETIME stamp for the First Accessed field is found between offset 103 and 110. The FILETIME stamp for the Last Accessed field is found between offset 111 and 118. Examination of the other fields populated in the SystemIndex_0A table and compared against the extracted file we can now attempt to deconstruct some of the other fields within the extracted entry.

Figure 24 Screenshot of Test1.txt entry in SystemIndex_0A table

Page 71 of 151

Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144

9 10 11 12 13 14 15 & T _ > ) Z T E i T E S 1 . T X R` T _ i

00 00 00 26 00 7F DF 0C 00 54 00 09 31 00 2E 00 00 00 00 00 00 04 7F 80 FF 0C 5F 0E 00 00 00 FF 80 3E D5 DE B1 9D 01 00 12 C9 01 FF FF FF FF 29 FF FF FF 00 00 00 00 00 5A 8E AA 7F 13 C9 01 00 00 00 00 00 00 00 00 00 53 00 54 00 31 00 2E 00

FF 69 7F 54 00 45 00 53 54 00 58 00 09 54 00 00 00 00 0E 12 80 5F 00 69 FF FF FF 07 00 00 00 00 00 00 00 04 52 60 B7 B9 00 00 00 00 00 00 00 FF D3 CC C3 B9 12 C9 01 00 00 02 00 00 00 00 00 09 00 FC 14 00 54 00 45 00 54 00 58 00 54

S T 1 . T X T

Further examination of the extracted record compared against the SystemIndex_0A file when viewed with the Microsoft Database Viewer revealed that there were entries that held identical values. Those were found to be: Offset 47 50 holds the value of 0x 69 FF 0C 5F when converted to little endian 0x 5F 0C FF 69 translates to decimal 1594687337. This is the value recorded in the field of PathID of the Windows.edb file when viewed with the Microsoft Database Viewer. It can be seen that offset 51 holds the value of 0x 0E, which decodes to the decimal 14. This is the Document ID. Offset 59 holds the value 0x 07 that is the same value as held in the as CrawlNumber Crawled field of the SystemIndex_0A table. Offset 87 holds the value 0x 29 which translates to decimal 41 that is the same value as held in the as transaction flags field of the SystemIndex_0A table. Offset 121 holds the value 0x 02 that is the same as the access count field in the SystemIndex_0A table. It can be seen that with the aid of the Microsoft Database Viewer various fields within the SystemIndex_0A table entry may be decoded.

Page 72 of 151

Figure 25 Possible values within the SystemIndex_0A table

It was essential if the extracted record was to be deconstructed and the hypothesis of the above entries, together with the FILETIME stamp entries validated then further testing had to be carried out. This would establish whether findings held true that entries around the keyword hot consisted of the various fields in the SystemIndex_0A table or were merely spurious coincidences.

5.5 Experiment 1 Phase 2

The purpose of the second phase of Experiment 1 was to corroborate the findings of the first phase in respect of the transaction log file and Windows.edb file. In respect of the transaction log file the following artefacts will be reviewed: the apparent sequence counter for the file within the transaction log. The file length byte, the Document ID value preceded by the marker 0x EC F8 42 7E in the first entry (0x FF FF FF FF in the second entry). The Windows.edb file fields will also be corroborated in respect of

Page 73 of 151

The methodology employed used a test bed image which had one file haggistest.txt: already in the My Documents Directory. An additional four text files were added to the directory and the indexer allowed to run. Prior to the start of the experiment it was decided to reduce the size of the index in order to assist with viewing and searching the Windows.edb file. In order to achieve this, the indexer was paused and then the Advanced Options were selected. The index settings were then set to only index the My Documents folder by de-selecting the other options. The file types were then reduced to only index the properties and file contents of text files. The indexer then was invoked to rebuild the index. The files added were titled Killiecrankie.txt, Bannockburn.txt, Castle Gordon.txt, and Ye Jacobites by name.txt. As each file was added the indexing status window was viewed and it was seen that the status revealed that as each document was added it reported that two items were left to be scanned. The index now button was selected and the items indexed so far count was incremented by one and the items left to scan returned to zero. This behaviour was observed on each occasion that a test document was added to the index. One possibility would be that the indexing status window shows when the file is initially added to the gather queue and when the file is added to the index the number of items index is incremented by one. The system was then imaged and the image examined using Encase. The $MFT file was examined and the entries relating to the files that were added to the index examined. This revealed the following created dates as recorded in the $MFT for the various files.
File Name Killiecrankie Bannockburn Castle Gordon Ye Jacobites by name Created Time in $MFT file 12th October 2008 18:04:55 12th October 2008 18:05:23 12th October 2008 18:05:39 12th October 2008 18:05:57

Page 74 of 151

Table 7 Created time in $MFT for test files.

A text string search for the various file names was carried out within the indexing files. This resulted in hits within the SystemIndex.ntfy.4.gthr file and Windows.edb.

5.6 Examination of the Indexer Transaction Log file

The first file viewed was the Systemindex.ntfy.4.gthr file. It was seen that at file offset 67 we could see the start of a 202 byte entry for the text file containing the poem Killiecrankie. This entry was extracted and saved as entry1.bin.
Offset 00000000 00000010 00000020 00000030 00000040 00000050 00000060 00000070 00000080 00000090 000000A0 000000B0 000000C0 0 4D 78 02 63 20 73 4B 74 7F C9 00 63 00 1 44 71 00 3A 53 74 69 00 A6 01 00 A8 00 2 4D 0E 00 5C 65 5C 6C 00 8C EC 00 8C 00 3 44 A7 00 44 74 4D 6C 00 2C F8 00 2C 00 4 0D 8C 00 6F 74 79 69 00 C9 42 00 C9 00 5 01 2C 00 63 69 20 65 00 01 7E 00 01 00 6 00 C9 00 75 6E 44 63 00 FF 05 BE 00 00 7 8 9 A 00 AB 00 74 57 6D 6B FF BE 00 8C 01 B 00 AD 00 73 44 65 69 FF 61 00 2C 00 C 6B 8C 42 20 53 6E 65 FF 63 00 C9 00 D 01 2C 00 61 20 74 2E FF A8 00 01 00 E 80 C9 00 6E 54 73 74 60 8C 00 BE 02 F 00 01 00 64 65 5C 78 64 2C 00 61 00 MDMD xq , k 7-, B c:\Documents and Settings\WDS Te st\My Documents\ Killiecrankie.tx t `d , ac, B~ ac, a c,

00 00 00 01 14 37 00 00 00 6D 65 6E 67 73 5C 6F 63 75 72 61 6E 00 00 00 FF FF FF 00 00 00 61 63 A8 00 00 00 00 00 00

At file offset 269 was a second entry relating to this file. This entry was extracted to a separate file named entry2.bin.
Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144 00000160 00000176 00000192 0 4D 78 02 63 20 73 4B 74 7F 9D 00 CC 00 1 44 71 00 3A 53 74 69 00 A6 01 00 AD 00 2 4D 0E 00 5C 65 5C 6C 00 8C FF 00 8C 00 3 44 A7 00 44 74 4D 6C 00 2C FF 00 2C 00 4 D7 8C 03 6F 74 79 69 00 C9 FF 00 C9 00 5 01 2C 12 63 69 20 65 00 01 FF 00 01 00 6 00 C9 04 75 6E 44 63 00 FF 05 00 00 00 7 00 01 00 6D 67 6F 72 00 FF 00 98 00 00 8 00 00 02 65 73 63 61 00 FF 00 CC 00 00 9 10 11 12 13 14 15 00 98 00 6E 5C 75 6E 00 FF 00 AD 00 00 00 CC 00 74 57 6D 6B FF 00 00 8C 01 00 AD 00 73 44 65 69 FF 80 00 2C 00 69 8C 42 20 53 6E 65 FF 3E 00 C9 00 01 2C 00 61 20 74 2E FF D5 00 01 00 80 C9 00 6E 54 73 74 60 DE 00 00 02 02 01 00 64 65 5C 78 64 B1 00 98 00 MDMD xq , i -, B c:\Documents and Settings\WDS Te st\My Documents\ Killiecrankie.tx t `d , > -, -,

Page 75 of 151

When the file compare function within Winhex was invoked to compare both entries it is apparent that the following 29 bytes are different.
Offset Entry 1 Entry 2 4 0D D7 12 6B 69 15 00 02 24 14 00 25 37 98 26 AB CC 36 00 03 37 00 12

Offset Entry 1 Entry 2

38 00 04

40 00 02

138 BE 00

139 61 80

140 63 3E

141 A8 D5

142 8C DE

143 2C B1

Offset Entry 1 Entry 2

144 C9 9D

146 EC FF

147 F8 FF

148 42 FF

149 7E FF

166 BE 00

167 61 98

168 63 CC

Offset Entry 1 Entry 2

169 A8 AD

174 BE 00

175 61 98

176 63 CC

177 A8 AD

Table 8 - File compare results for Killiecrankie.txt Transaction log entries

Byte 5 on both transaction log entries held the value of 1. The significance of this byte as highlighted in phase one of the experiments is that it was the first file to be added to the index and so appears to hold the value of the entry within the transaction log. For this to be held true, then this byte should incrementally increase as the further transaction log entries for separate files are examined. Byte 44 was found to hold the value 0x 42 when converted to its decimal value is found to be 66. This was seen to be the entry length for the File path and file name + 1 in the first phase of the experiments. For this to hold true then again the entry length for the File path and file name + 1 should be 66 bytes. Examination of the transaction log shows that this is in fact correct. It was also seen that bytes 146 149 in the first entry held the value EC F8 42 7E (this is the same 4 bytes as in the first phase of the experiment) followed by the value 05 in byte 150. In phase one this was the Document ID number as identified in the

Page 76 of 151

Windows.edb file. The second transactions log entry for the killiecrankie.txt file bytes 146 149 were found to have changed to 0x FF FF FF FF. This is consistent with the first phase experiment. In respect of FILETIMES it could be seen that there were differences between the extracted files, entry1.bin and entry2.bin. The six FILETIMES highlighted by Stewart [19] were seen in the first entry. When the file compare command was run against both files it highlighted that the first FILETIME entry was identical in both extracted files as was the third FILETIME entry. It was observed that the second, fourth, fifth and sixth FILETIMES had changed. Just as in the first phase of the experiment it was noted that the fourth FILETIME in entry2.bin (the second transaction log entry in the file in respect of the added text file) was decoded to 1st January 1970 at 00:00:00 hrs. The $MFT record for the file Killiecrankie.txt revealed a created time of 12th October 2008 18:04:55 hrs. This was identical to the time (UTC) for the third FILETIME. On continuing to browse the file it was seen that at file offset 471 was the first entry relating to the text file named Bannockburn. This entry was extracted to a separate file named entry3.bin.

Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144 00000160 00000176 00000192

0 4D FA 02 63 20 73 42 00 8C EC 00 8C 00

1 44 87 00 3A 53 74 61 00 2C F8 00 2C 00

2 4D 7E 00 5C 65 5C 6E 00 C9 42 00 C9 00

3 44 B7 00 44 74 4D 6E 00 01 7E 00 01 00

4 9F 8C 00 6F 74 79 6F 00 FF 06 08 00 00

5 02 2C 00 63 69 20 63 00 FF 00 AF 00 00

6 00 C9 00 75 6E 44 6B 00 FF 00 85 00 00

7 00 01 00 6D 67 6F 62 00 FF 00 B7 00 00

8 00 32 00 65 73 63 75 FF 08 00 8C 01

9 10 11 12 13 14 15 00 7E 00 6E 5C 75 72 FF AF 00 2C 00 00 FD 00 74 57 6D 6E FF 85 00 C9 00 00 B9 00 73 44 65 2E FF B7 00 01 00 6B 8C 40 20 53 6E 74 96 8C 00 08 02 01 2C 00 61 20 74 78 3F 2C 00 AF 00 80 C9 00 6E 54 73 74 F4 C9 00 85 00 00 01 00 64 65 5C 00 B6 01 00 B7 00 MDMD k ~, 2~, @ c:\Documents and Settings\WDS Te st\My Documents\ Bannockburn.txt ? , , B~ , ,

On browsing further the second entry relating to this file was found at file offset 671. This entry was extracted entry4.bin and viewed as a separate file in Winhex.

Page 77 of 151

Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144 00000160 00000176 00000192

0 4D FA 02 63 20 73 42 00 8C FF 00 8C 00

1 44 87 00 3A 53 74 61 00 2C FF 00 2C 00

2 4D 7E 00 5C 65 5C 6E 00 C9 FF 00 C9 00

3 44 B7 00 44 74 4D 6E 00 01 FF 00 01 00

4 67 8C 03 6F 74 79 6F 00 FF 06 8C 00 00

5 03 2C 12 63 69 20 63 00 FF 00 E0 00 00

6 00 C9 04 75 6E 44 6B 00 FF 00 FF 00 00

7 00 01 00 6D 67 6F 62 00 FF 00 B9 00 00

8 00 8C 02 65 73 63 75 FF 00 00 8C 01

9 10 11 12 13 14 15 00 E0 00 6E 5C 75 72 FF 80 00 2C 00 00 FF 00 74 57 6D 6E FF 3E 00 C9 00 00 B9 00 73 44 65 2E FF D5 00 01 00 69 8C 40 20 53 6E 74 96 DE 00 8C 02 01 2C 00 61 20 74 78 3F B1 00 E0 00 80 C9 00 6E 54 73 74 F4 9D 00 FF 00 02 01 00 64 65 5C 00 B6 01 00 B9 00 MDMDg i ~, , @ c:\Documents and Settings\WDS Te st\My Documents\ Bannockburn.txt ? , > , ,

When the file compare function within Winhex was invoked to compare both entries it is clear that the following 30 bytes are different.
Offset Entry 1 Entry 2 4 9F 67 5 02 03 12 6B 69 15 00 02 24 32 8C 25 7E E0 26 FD FF 36 00 03

Offset Entry 1 Entry 2

37 00 12

38 00 04

40 00 02

136 08 00

137 AF 80

138 85 3E

139 B7 D5

140 8C DE

Offset Entry 1 Entry 2

141 2C B1

142 C9 9D

144 EC FF

145 F8 FF

146 42 FF

147 7E FF

164 08 8C

165 AF E0

Offset Entry 1 Entry 2

166 85 FF

167 B7 B9

172 08 8C

173 AF E0

174 85 FF

175 B7 B9

Table 9 File compare results for Bannockburn.txt Transaction log entries

Comparison between both extracted file entries starts to reveal consistencies with previous findings. Byte 5 of both files incremented by a value of one. This is consistent with it being some form of incremental counter. Byte 44 held a value of 0x

Page 78 of 151

40 when converted to decimal is 64. This is again found to be the entry length for the file path and file name + 1. It was again noted that bytes 144 147 in the first entry held the value EC F8 42 7E. Bytes 144 -147 were again found to have been changed to 0x FF FF FF FF in the second entry for the file in the transaction log. Byte 150 held the value 06 in byte 158. Examination of the Windows.edb file will confirm whether this is the Document ID number for the file. In respect of FILETIMES it again could be seen that there were differences between the extracted files, entry3.bin and entry4.bin. When the file compare command was run against both files it highlighted that the first FILETIME entry was identical in both extracted files as was the third FILETIME entry. It was observed that the second, fourth, fifth and sixth FILETIMES had changed in the second entry in the log for the text file. The fourth FILETIME entry was again noted to decode to 1st January 1970 at 00:00:00 hrs. The $MFT record for the file Bannockburn.txt revealed a created time of 12th October 2008 18:05:23 hrs. This was identical to the time (UTC) for the third FILETIME. The first entry in respect of the file Castle Gordon.txt was found at file offset 871. This entry was extracted entry5.bin and viewed in Winhex.

Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144 00000160 00000176 00000192

0 4D 8C 02 63 20 73 63 74 9F C9 00 2E 00

1 44 EE 00 3A 53 74 61 00 C0 01 00 C1 00

2 4D 26 00 5C 65 5C 73 00 8C EC 00 8C 00

3 44 C1 00 44 74 4D 74 00 2C F8 00 2C 00

4 31 8C 00 6F 74 79 6C 00 C9 42 00 C9 00

5 04 2C 00 63 69 20 65 00 01 7E 00 01 00

6 00 C9 00 75 6E 44 20 00 FF 07 9A 00 00

7 00 01 00 6D 67 6F 67 00 FF 00 15 00 00

8 00 70 00 65 73 63 6F 00 FF 00 2E 00 00

9 10 11 12 13 14 15 00 54 00 6E 5C 75 72 00 FF 00 C1 00 00 00 DD 00 74 57 6D 64 FF 9A 00 8C 01 00 C5 00 73 44 65 6F FF 15 00 2C 00 6B 8C 42 20 53 6E 6E FF 2E 00 C9 00 01 2C 00 61 20 74 2E FF C1 00 01 00 80 C9 00 6E 54 73 74 82 8C 00 9A 02 00 01 00 64 65 5C 78 08 2C 00 15 00 MDMD1 k &, pT, B c:\Documents and Settings\WDS Te st\My Documents\ castle gordon.tx t , ., B~ ., .,

At file offset 1073 the second entry in relation to the Castle Gordon.txt was found. This entry was extracted entry6.bin and viewed in Winhex.

Page 79 of 151

Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144 00000160 00000176 00000192

0 4D 02 02 63 20 73 63 74 9F C9 00 E6 00

1 44 9F 00 3A 53 74 61 00 C0 01 00 C5 00

2 4D 37 00 5C 65 5C 73 00 8C EC 00 8C 00

3 44 C1 00 44 74 4D 74 00 2C F8 00 2C 00

4 FB 8C 03 6F 74 79 6C 00 C9 42 00 C9 00

5 04 2C 12 63 69 20 65 00 01 7E 00 01 00

6 00 C9 04 75 6E 44 20 00 FF 07 00 00 00

7 00 01 00 6D 67 6F 67 00 FF 00 4A 00 00

8 00 D8 02 65 73 63 6F 00 FF 00 E4 00 00

9 10 11 12 13 14 15 00 DD 00 6E 5C 75 72 00 FF 00 C0 00 00 00 E6 00 74 57 6D 64 FF 00 00 8C 02 00 C5 00 73 44 65 6F FF 4A 00 2C 00 69 8C 42 20 53 6E 6E FF E4 00 C9 00 01 2C 00 61 20 74 2E FF C0 00 01 00 80 C9 00 6E 54 73 74 82 8C 00 D8 02 02 01 00 64 65 5C 78 08 2C 00 DD 00 MDMD i 7, , B c:\Documents and Settings\WDS Te st\My Documents\ castle gordon.tx t , J, B~ J, ,

When the file compare function within Winhex was invoked to compare both entries it is evident that the following 26 bytes are different.
Offset Entry 1 Entry 2 4 31 FB 12 6B 69 15 00 02 16 8C 02 17 EE 9F 18 26 37 24 70 D8 25 54 DD

Offset Entry 1 Entry 2

26 DD E6

36 00 03

37 00 12

38 00 04

40 00 02

138 9A 00

139 15 4A

140 2E E4

Offset Entry 1 Entry 2

141 C1 C0

166 9A 00

167 15 4A

168 2E E4

169 C1 C0

174 9A D8

175 15 DD

176 2E E6

Offset Entry 1 Entry 2

177 C1 01

186 01 02

Table 10 - File compare results for castle gordon.txt Transaction log entries

Comparison between both extracted file entries revealed some areas of inconsistency with previous findings. Byte 5 of both files held a value of 04. Previous entries had

Page 80 of 151

incremented by one. Byte 66 held a value of 0x 42 when converted to decimal is 66. This is again found to be the entry length for the file path and file name + 1. It was again noted that bytes 146 149 in the first entry held the value 0x EC F8 42 7E. When the second entry was examined it was also found to hold the same values. Examination of the Windows.edb file confirmed that byte 150, which held the value 07, was the value of the Document ID number for the file. No simple explanation could be found for the apparent inconsistencies in the entries for this particular file. The file compare revealed that there were 26 bytes that were different in both entries. However the fact that byte 5 had not incremented and the string 0x EC F8 42 7E had not changed therefore to the expected 0x FF FF FF FF. In respect of FILETIMES it again could be seen that there were differences between the extracted files, entry5.bin and entry4.bin. When the file compare command was run against both files it highlighted that although he the first FILETIME in both entries were different they decoded to the same time. The most likely explanation for this is that the decoder only decodes the time to the nearest minute. The third FILETIME was identical in both extracted files. It was observed that the second, fourth, fifth and sixth FILETIMES had changed. The fourth FILETIME entry was again noted to decode to was decoded to 1st January 1970 at 00:00:00 hrs. The $MFT record for the file Castle Gordon.txt revealed a created time of 12th October 2008 18:05:39 hrs. This was identical to the time (UTC) for the third FILETIME. The first entry in respect of the file Ye Jacobites by name.txt was found at file offset 1275. This entry was extracted entry7.bin and viewed in Winhex.

Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112

0 4D 34 02 63 20 73 59 6E

1 44 58 00 3A 53 74 65 61

2 4D 37 00 5C 65 5C 20 6D

3 44 CC 00 44 74 4D 4A 65

4 CC 8C 00 6F 74 79 61 2E

5 05 2C 00 63 69 20 63 74

6 00 C9 00 75 6E 44 6F 78

7 00 01 00 6D 67 6F 62 74

8 00 40 00 65 73 63 69 00

9 10 11 12 13 14 15 00 29 00 6E 5C 75 74 00 00 DC 00 74 57 6D 65 00 00 D1 00 73 44 65 73 00 6B 8C 49 20 53 6E 20 00 01 2C 00 61 20 74 62 00 80 C9 00 6E 54 73 79 00 00 01 00 64 65 5C 20 00 MDMD k 4X7, @), I c:\Documents and Settings\WDS Te st\My Documents\ Ye Jacobites by name.txt

Page 81 of 151

00000128 00000144 00000160 00000176 00000192 00000208

00 FF 00 CC 00 00

FF 8E 00 8C 01

FF BA 00 2C 00

FF 39 00 C9 00

FF CC 00 01 00

B4 8C 00 8E 02

C1 2C 00 BA 00

9E C9 00 39 00

CB 01 00 CC 00

8C EC 00 8C 00

2C F8 00 2C 00

C9 42 00 C9 00

01 7E 00 01 00

FF 08 8E 00 00

FF 00 BA 00 00

FF 00 39 00 00

, 9, B~ 9 , 9,

At file offset 1484 the second entry in relation to the Ye Jacobites by name.txt was found. This entry was extracted entry8.bin and viewed in Winhex.
Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144 00000160 00000176 00000192 00000208 0 4D 34 02 63 20 73 59 6E 00 FF 00 D1 00 00 1 44 58 00 3A 53 74 65 61 FF 00 00 8C 01 2 4D 37 00 5C 65 5C 20 6D FF 80 00 2C 00 3 44 CC 00 44 74 4D 4A 65 FF 3E 00 C9 00 4 9D 8C 03 6F 74 79 61 2E FF D5 00 01 00 5 06 2C 12 63 69 20 63 74 B4 DE 00 9A 02 6 00 C9 04 75 6E 44 6F 78 C1 B1 00 8B 00 7 00 01 00 6D 67 6F 62 74 9E 9D 00 DE 00 8 00 9A 02 65 73 63 69 00 CB 01 00 D1 00 9 10 11 12 13 14 15 00 8B 00 6E 5C 75 74 00 8C FF 00 8C 00 00 DE 00 74 57 6D 65 00 2C FF 00 2C 00 00 D1 00 73 44 65 73 00 C9 FF 00 C9 00 69 8C 49 20 53 6E 20 00 01 FF 00 01 00 01 2C 00 61 20 74 62 00 FF 08 9A 00 00 80 C9 00 6E 54 73 79 00 FF 00 8B 00 00 02 01 00 64 65 5C 20 00 FF 00 DE 00 00 MDMD i 4X7, , I c:\Documents and Settings\WDS Te st\My Documents\ Ye Jacobites by name.txt , > , ,

When the file compare function within Winhex was invoked to compare both entries it is evident that the following 30 bytes are different.

Offset Entry 1 Entry 2

4 CC 9D

5 05 06

12 6B 69

15 00 02

24 40 9A

25 29 8B

26 DC DE

36 00 03

Offset Entry 1 Entry 2

37 00 12

38 00 04

40 00 02

145 8E 00

146 BA 80

147 39 3E

148 CC D5

149 8C DF

Offset Entry 1 Entry 2

150 2C B1

151 C9 9D

153 EC FF

154 F8 FF

155 42 FF

156 7E FF

173 8E 9A

174 BA 8B

Page 82 of 151

Offset Entry 1 Entry 2

175 39 DE

176 CC D1

181 8E 9A

182 BA 8B

183 39 DE

184 CC D1

Table 11 - File compare results for ye jacobites by name.txt Transaction log entries

Comparison between both extracted file entries reveals consistencies with previous findings, notwithstanding the Castle Gordon.txt file. Byte 5 of both files incremented by a value of one from 0x 05 to 0x 06. This is consistent with it being some form of incremental counter as previously thought. Byte 44 held a value of 0x 49 when converted to decimal is 73. This is again found to be the entry length for the file path and file name + 1. It was again noted that bytes 144 147 in the first entry held the value 0x EC F8 42 7E. Bytes 153 -156 were again found to have been changed to 0x FF FF FF FF in the second entry for the file in the transaction log. Examination of the Windows.edb file will confirm whether Byte 157, which held the value 08, was the value of the Document ID number for the file. In respect of FILETIMES it again could be seen that there were differences between the extracted files, entry7.bin and entry8.bin. When the file compare command was run against both files it highlighted yet again that the first FILETIME entry was identical in both extracted files as was the third FILETIME entry. It was observed that the second, fourth, fifth and sixth FILETIMES had changed. The fourth FILETIME entry was again noted to decode to was decoded to 1st January 1970 at 00:00:00 hrs. The $MFT record for the file Ye Jacobites by name.txt revealed a created time of 12th October 2008 18:05:57 hrs. This was identical to the time (UTC) for the third FILETIME. Repeating the experiment and viewing the changes in the Transaction Log file have added greater value to the information that Stewart [19] had previously highlighted. It can be seen that on the file being added to the index that two separate entries are created for the file within the transaction log file, whereas Stewart had only deconstructed one entry. Stewarts observation that six FILETIME entries are created is confirmed.

Page 83 of 151

However this series of experiments has shown that the first and third FILETIME fields are the same in both entries. The third FILETIME field which is immediately after the file name field is identical to the file created date value held in the $MFT date. The second entry for each added file has the fourth FILETIME field changed to The fourth FILETIME entry was again noted to decode to was decoded to 1st January 1970 at 00:00:00 hrs. This is most likely to be some form of nil entry marker used by the programmers.

5.7 Windows.edb file entry

With the test files added the Windows.edb file was extracted and viewed using both Winhex and the Microsoft Database Viewer. The purpose of using both tools was to corroborate the findings and in particular the use of Winhex would allow analyst to be able to view the raw data. This is particularly useful when deleted artefacts are recovered from unallocated clusters. A text string search for the various file names resulted in findings entries in the file at the following locations:
File Offset 12599897 12600073 12600264 12600442 12600633 Entry haggistest.txt Killiecrankie.txt Bannockburn.txt Castle Gordon.txt Ye Jacobites By Name.txt

Table 12 Windows.edb file entry for Experiment 1 Phase 2.

When viewing the Windows.edb file in Winhex it was difficult to fully appreciate the structure and various entries for the file, however when using the Microsoft Database Viewer we can start to see further detail. When the SystemIndex_Gthr table was viewed with the Microsoft Database Viewer it revealed that the documents have the following Documents ID.

Page 84 of 151

Document ID

FileName1 (decoded from Binary to ASCII)

4 5 6 7 8

Haggistest.txt Killiecrankie.txt Bannockburn.txt Castle Gordon.txt Ye Jacobites By Name

Table 13 Document ID from SystemIndex.Gthr Table

Armed with the above data we can now see that the Document ID number was the same value as held in the Transaction Log entries for the various files when preceded with 0x EC F8 42 7E in the first entry and 0x FF FF FF FF in the second entry for the file. Having established the Document ID for the various files we can now use the Microsoft Database Viewer to reveal the contents of the SystemIndex_0A table in respect of the files added to the index: We can see that the table has several fields of interest to the examiner.
DocID 4 5 6 7 8 5 System Date Created
th th

System Date Modified 5


th th

SystemSize 184 586 715 910 865

October 2008 20:58:17 October 2008 17:04:55

October 2008 20:58:17 October 2008 17:04:55

12

12

12th October 2008 17:05:23 12 12


th th

12th October 2008 17:05:23 12 12


th th

October 2008 17:05:39 October 2008 17:05:57

October 2008 17:05:39 October 2008 17:05:57

Table 14- SystemIndex_0A table entries

It can be seen that the table records the FILETIME in respect of created and modified dates of the files. When the various files were examined in Winhex the value recorded in the

Page 85 of 151

SystemSize field size value was found to be identical to the actual size in bytes of the file contents. There were other fields populated with data in respect of the documents however these fields appear to be obfuscated. These fields included: System_File Extension, which was populated with 0x 17 2e 76 7e 66 for each file. System_FileAttributes, which was populated with the value 32 for each file. System_FileName, System_ItemFolderPathDisplay, System_ItemName, System_ItemTypeText, System_Search_AutoSummary. The System_Search_AutoSummary field will be discussed in detail in section 5.13.

5.7.1 SystemIndex_Gthr entries

Having viewed the contents of the SystemIndex_0A table ; the SystemIndex_Gthr table was then opened with the Microsoft Database Viewer . The various Document ID numbers identified the files.

Figure 26 Experiment 1 Phase 2 SystemIndex_Gthr table entries It can be seen that the various files have the same PathId value of decimal 203891110 which is 0x A6 21 27 0C.

Page 86 of 151

The area around the text string hit for the file haggistest.txt was extracted and viewed in Winhex in order to establish whether the hypothesis raised in section 5.4 of this chapter in respect of the decoding of the fields can be confirmed.
Offset 12599888 12599904 12599920 12599936 12599952 12599968 12599984 12600000 12600016 12600032 12600048 12600064 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 '! H A G G I S T E T B~ X T _ !' S T . 3I-' _ I-' 8 3I-' 3

00 7F 8C 27 21 A6 00 09 49 00 53 00 54 00 00 54 00 09 58 00 54 00 00 04 12 80 5F 00 A6 21 42 7E 06 00 00 00 00 33 74 24 5E B2 68 17 2D 27 00 00 00 00 00 00 FD FF AF 49 2D 27 C9 01 00 33 01 00 00 00 00 00 06 00 FC 1E 00 48 00 41 00 47 00 45 00 53 00 54 00 2E 00 38

7F 48 00 41 00 47 00 47 45 00 09 53 00 54 00 2E 00 00 00 00 06 7F 80 00 27 0C 04 00 00 00 EC F8 AF 49 2D 27 C9 01 5F 95 C9 01 FF FF FF FF 2B 02 FF FF 02 00 00 00 00 33 AF 49 2D 27 C9 01 00 00 00 00 00 00 00 00 00 00 00 47 00 49 00 53 00 54 00 54 00 58 00 54 00 00

t$^h -' +

H A G G I S T E S T . T X T

The highlighted values have been extracted and the values entered into the table below.
Data 0x A6 21 27 0C 0x 04 0x 00 33 AF 49 2D 27 C9 01 0x 5E B2 68 17 2D 27 C9 01 0x 2B 02 00 00 0x 00 33 AF 49 2D 27 C9 01 0x 00 33 AF 49 2D 27 C9 01 Suggested Field PathID DocumentID Time MD5 Changed Last Modified TransactionFlags First Accessed Last Accessed

Table 15 Extracted values from Windows.edb file Haggistest.txt file

It can be seen that there are four FILETIMES within the extracted entry. When these were compared with the values recorded in the SystemIndex_gthr table when viewed with the Microsoft Database Viewer then can be attributed to their respective fields. Particularly

Page 87 of 151

interesting is the fact that the file first and last accessed times are recorded together with the Last Modified time. Having examined the entries above for the first file, the remaining files were also extracted and a similar process of cross checking the recorded details in the Microsoft Database Viewer and the raw data when viewed in Winhex undertaken. The area around the first of the added files killiecrankie.txt was extracted and the raw data compared to the values in the Microsoft Database Viewer.
Offset 12600064 12600080 12600096 12600112 12600128 12600144 12600160 12600176 12600192 12600208 12600224 12600240 12600256 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 '! K I L L I E C R I !' , , + , $ K I L L I E C R A N K I E . T X T / , E . T X A N K T _ y$`d

00 7F 8C 27 21 A6 00 09 49 00 45 00 43 00 00 49 00 09 45 00 2E 00 00 00 00 00 00 04 7F 80 21 27 0C 05 00 00 00 EC 99 DB A7 8C 2C C9 01 1D 2C C9 01 FF FF FF FF 2B FF FF FF 02 00 00 00 00 99 DB A7 8C 2C C9 01 00 00 00 00 00 00 00 00 00 4C 00 4C 00 49 00 45 00 4B 00 49 00 45 00 2E 00 2F

7F 4B 00 49 00 4C 00 4C 52 00 09 41 00 4E 00 4B 54 00 58 00 09 54 00 00 00 00 05 12 80 5F 00 A6 F8 42 7E FF FF FF FF 00 17 79 24 60 64 7F A6 8C 00 00 00 00 00 00 00 FF 99 DB A7 8C 2C C9 01 00 00 01 00 00 00 00 00 07 00 FC 24 00 4B 00 49 00 43 00 52 00 41 00 4E 00 54 00 58 00 54 00 00 00

B~

The values have been compared and extracted into the table below.
Data 0x A6 21 27 0C 0x 05 0x 00 99 DB A7 8C 2C C9 01 0x 60 64 7F A6 8C 2C C9 01 0x 2B 00 00 00 0x 00 99 DB A7 8C 2C C9 01 0x 00 99 DB A7 8C 2C C9 01 Suggested Field PathID DocumentID Time MD5 Changed Last Modified TransactionFlags First Accessed Last Accessed

Table 16 - Extracted values from Windows.edb file Killiecrankie.txt file

Page 88 of 151

The values were compared and again it was seen that the fields within the systemIndex_Gthr table could be decoded. The Bannockburn.txt file text string hit within the Windows.edb file was extracted and again compared against the values recorded when the file entry in the Microsoft Database Viewer
Offset 12600256 12600272 12600288 12600304 12600320 12600336 12600352 12600368 12600384 12600400 12600416 12600432 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 '! B A N N O C K B . T X T _ !' U R N B

00 7F 8C 27 21 A6 7F 09 4F 00 43 00 4B 00 42 2E 00 09 54 00 58 00 54 06 12 80 5F 00 A6 21 27 7E FF FF FF FF 00 E2 5A 24 96 3F F4 B6 8C 2C C9 00 00 00 00 00 FF FF FF B7 8C 2C C9 01 00 E2 5A 00 00 00 00 00 07 00 00 20 00 42 00 41 00 4E 00 42 00 55 00 52 00 4E 00 00 00 38

42 00 41 00 4E 00 4E 00 00 09 55 00 52 00 4E 00 00 00 00 08 7F 80 00 00 0C 06 00 00 00 EC F8 42 B7 8C 2C C9 01 2A 17 79 01 FF FF FF FF 2B 00 00 FF 02 00 00 00 00 E2 5A B7 8C 2C C9 01 00 00 01 00 00 00 00 00 00 00 FC 4E 00 4F 00 43 00 4B 00 2E 00 54 00 58 00 54 00

~ Z, * y $?, + , Z, B A N N O C K B U R N . T X T 8 Z

The values have been extracted into the table below.

Data 0x A6 21 27 0C 0x 06 0x 00 E2 5A B7 8C 2C C9 01 0x 96 3F F4 B6 8C 2C C9 01 0x 2B 00 00 00 0x 00 E2 5A B7 8C 2C C9 01 0x 00 E2 5A B7 8C 2C C9 01

Suggested Field PathID DocumentID Time MD5 Changed Last Modified TransactionFlags First Accessed Last Accessed

Table 17 - Extracted values from Windows.edb file Bannockburn.txt file

Page 89 of 151

As in the previous examples the values were compared and again it was seen that the fields within the systemIndex_Gthr table could be decoded. The Castle Gordon.txt file text string hit within the Windows.edb file was extracted and again compared against the values recorded when the file entry in the Microsoft Database Viewer.

Offset 12600432 12600448 12600464 12600480 12600496 12600512 12600528 12600544 12600560 12600576 12600592 12600608 12600624

9 10 11 12 13 14 15 '! C A S T D O !' L E G O R T _ N . T X

00 7F 8C 27 21 54 00 09 4C 00 45 00 20 44 00 4F 00 09 4E 00 2E 00 00 00 00 00 00 04 7F A6 21 27 0C 07 00 00 00 00 4A E4 C0 8C 2C C9 01 8C 2C C9 01 FF FF FF FF FF FF FF FF 02 00 00 00 00 4A E4 C0 8C 2C C9 01 07 00 00 00 00 00 00 00 00 53 00 54 00 4C 00 45 00 44 00 4F 00 4E 00 2E 00 4A

A6 7F 43 00 41 00 53 00 00 47 00 09 4F 00 52 00 00 54 00 58 00 09 54 00 80 00 00 07 12 80 5F 00 EC F8 42 7E FF FF FF FF 32 17 79 24 82 08 9F C0 2B 00 00 02 00 00 00 00 00 4A E4 C0 8C 2C C9 01 00 00 01 00 00 00 00 00 00 00 FC 24 00 43 00 41 00 20 00 47 00 4F 00 52 00 54 00 58 00 54 00 00

B~

J, 2 y$ , + J, $ C A S T L E J G O R D O N . T X T J,

The values have been extracted into the table below.


Data 0x A6 21 27 0C 0x 07 0x 00 4A E4 C0 8C 2C C9 01 0x 82 08 9F C0 8C 2C C9 01 0x 2B 00 00 02 0x 00 4A E4 C0 8C 2C C9 01 0x 00 4A E4 C0 8C 2C C9 01 Suggested Field PathID DocumentID Time MD5 Changed Last Modified TransactionFlags First Accessed Last Accessed

Table 18 - Extracted values from Windows.edb file Castle Gordon.txt file

Page 90 of 151

As in the previous examples the values were compared and again it was seen that the fields within the systemIndex_Gthr table could be decoded.

The Ye Jacobites by name.txt file text string hit within the Windows.edb file was extracted and again compared against the values recorded when the file entry in the Microsoft Database Viewer

Offset 12600624 12600640 12600656 12600672 12600688 12600704 12600720 12600736 12600752 12600768 12600784 12600800 12600816 12600832

9 10 11 12 13 14 15 '! Y E A C O B S M E !' B Y . T X T _ B~ J N A

00 7F 8C 27 21 A6 00 09 41 00 43 00 4F 00 00 53 00 09 20 00 42 00 00 4D 00 45 00 09 2E 00 00 00 00 00 00 00 00 02 00 A6 21 27 0C 08 00 00 FF 00 DF 9E CB 8C 2C C9 CB 8C 2C C9 01 FF FF FF 00 FF FF FF FF 02 00 00 01 00 DF 9E CB 8C 2C C9 00 07 00 00 00 00 00 00 45 00 20 00 4A 00 41 00 54 00 45 00 53 00 20 00 41 00 4D 00 45 00 2E 00

7F 59 00 45 00 20 00 4A 42 00 09 49 00 54 00 45 59 00 20 00 09 4E 00 41 54 00 58 00 54 00 09 00 7F 80 00 00 08 12 80 5F 00 EC F8 42 7E FF FF FF 01 3B 17 79 24 B4 C1 9E FF 2B 00 00 00 00 00 00 00 00 DF 9E CB 8C 2C C9 01 00 00 01 00 00 00 00 00 00 00 FC 32 00 59 00 43 00 4F 00 42 00 49 00 42 00 59 00 20 00 4E 00 54 00 58 00 54 E

I T E

, ; y$ , + , 2 Y J A C O B I B Y N T E S ,

A M E . T X T

The values have been extracted into the table below.

Data 0x A6 21 27 0C 0x 08 0x 00 DF 9E CB 8C 2C C9 01 0x B4 C1 9E CB 8C 2C C9 01 0x 2B 00 00 00 0x 00 DF 9E CB 8C 2C C9 01 0x 00 DF 9E CB 8C 2C C9 01

Suggested Field PathID DocumentID Time MD5 Changed Last Modified TransactionFlags First Accessed Last Accessed

Page 91 of 151

Table 19 - Extracted values from Windows.edb file Ye Jacobites by Name.txt file

As in the previous examples the values were compared and again it was seen that the fields within the systemIndex_Gthr table could be decoded.

5.8 Data Added Conclusions

We have seen through experimentation that we can add value to many of the findings of Stewarts examination of the transaction log file. He had identified the Header ID and various FILETIME fields within the log file. We have empirically been able to add to that understanding by confirming artefacts such as the transaction log incremental counter byte. The fact that the length of the entry length for the file path and file name + 1 is recorded in the file. The most likely explanation for this value being held in the log file is that it is a variable field and so the application requires the string length. It has been shown that the first transaction log entry for a file held the value 0x EC F8 42 7E and was immediately followed by the Document ID number for the file. It has also been shown that the value 0x EC F8 42 7E is changed in the second entry to 0x FF FF FF FF. In addition to the Transaction log entries, we have seen that the file properties are recorded in two tables within the Windows.edb file, the SystemIndex_Gthr and the SystemIndex_0A. The schema of the SystemIndex_0A table (Appendix A) reveals many of the properties that the indexer records. Comparing the entries in Microsoft database Viewer and comparing it against the raw data extracted and viewed with Winhex reveals many of the properties that are extracted from the documents. Forensic Analysts regularly recover fragments of files in unallocated clusters, file slack, Pagefil.sys or Hiberfil.sys to name but a few. The particular benefit to the forensic community that this exercise demonstrates is that when such fragments of the index are recovered much valuable data can be deduced in respect of the parent files. This is even after the parent files have been deleted.

Page 92 of 151

5.9

Experiment 2 - Modifying Data

The purpose of the second experiment was to establish what changes are made to the indexing files when a test document was modified. First of all it was necessary to establish a baseline for the experiment. In order to do this file activity was monitored with ProcMon. A file haggis.txt was added to the filesystem. The index was updated and a snapshot taken of the file system. This snapshot was mounted using the vmwaremount program and FTK imager was used to create an image file that was named test2a.E01. The image file was added to Encase and allowed to verify.

Figure 27: Encase screenshot prior to modification

The $MFT entry for the file was extracted as MFT_entry_test2a.bin. Although the entries are 1024 bytes in length only the first 383 bytes of the MFT record for the file are reproduced below to the end of file marker. Within the entry itself there are several dates and times that are found within the Standard Information Attribute. Examination of the extracted data in Winhex revealed that the Standard Information Attribute starts at offset 56 and runs to offset 111.

Page 93 of 151

Offset 0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368

9 10 11 12 13 14 15 FILE0 8 ) ` H q ) 3!2 3!2 83 8# % q ) q ) h a g g i s . t x t @ ( )} 0 V q ) q ) p h

46 49 4C 45 30 00 03 00 09 00 01 00 38 00 01 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8F 71 E3 81 29 C9 01 BA 33 21 97 F7 32 C9 01 20 00 00 00 00 00 00 00 00 00 00 00 82 01 00 00 38 23 10 00 00 00 00 00 00 00 00 00 00 00 04 00 BA 25 00 00 00 00 01 00 00 8F 71 E3 81 29 C9 01 00 8F 71 E3 81 29 C9 01 EF 05 00 00 00 00 00 00 0A 03 68 00 61 00 67 00 74 00 78 00 74 00 00 00 00 00 00 00 00 00 05 00 74 3F D7 40 E8 9E DD 11 80 00 00 00 48 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 2B 05 00 00 00 00 00 00 21 01 72 32 00 00 01 00

08 68 BF 03 00 00 00 00 80 01 00 00 00 04 00 00 06 00 00 00 87 29 00 00 10 00 00 00 60 00 00 00 48 00 00 00 18 00 00 00 BA 33 21 97 F7 32 C9 01 38 BC D7 F4 AE 33 C9 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 70 00 00 00 56 00 00 00 18 00 01 00 00 8F 71 E3 81 29 C9 01 00 8F 71 E3 81 29 C9 01 00 10 00 00 00 00 00 00 20 00 00 00 00 00 00 00 67 00 69 00 73 00 2E 00 40 00 00 00 28 00 00 00 10 00 00 00 18 00 00 00 99 B0 00 0C 29 7D CE A7 01 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 2B 05 00 00 00 00 00 00 FF FF FF FF 82 79 47 11

t?@ @ + ! r2 + H

yG

Using the function built into Winhex the dates that are found between file offsets and can be decoded:
Creation FILETIME Last Modified FILETIME Last MFT Record FILETIME Last Accessed FILETIME 0x 00 8F 71 E3 81 29 C9 01 0x BA 33 21 97 F7 32 C9 01 0x BA 33 21 97 F7 32 C9 01 0x 38 BC D7 F4 AE 33 C9 01 8th October 2008 20:10:20 hrs 20th October 2008 21:05:33 hrs 20th October 2008 21:05:33 hrs 21st October 2008 18:58:08 hrs

Table 20 Extracted $MFT Record properties for haggis.txt file

Page 94 of 151

The Windows.edb file was viewed with the Microsoft Database Viewer and it was seen that haggis.txt was recorded within the Systemindex_ghtr table with the following information:
Document ID FileName1 First Access Last Access Last Modified Time MD5 Changed 4 HAGGIS.TXT 00 1e 6f e3 81 29 c9 01 00 bd 12 9a f7 32 c9 01 ba 33 21 97 f7 32 c9 01 00 1e 6f e3 81 29 c9 01

Table 21 Extracted systemindex_ghtr table entries

The entry in the Windows.edb file was extracted and viewed in Winhex.
Offset 12599872 12599888 12599904 12599920 12599936 12599952 12599968 12599984 12600000 12600016 12600032 00 26 00 7F 8C 27 21 A6 00 09 49 00 53 00 2E 00 00 00 00 06 7F 80 00 00 0C 04 00 00 00 EC F8 42 E3 81 29 C9 01 D6 89 76 01 FF FF FF FF 29 00 00 FF 02 00 00 00 00 1E 6F 9A F7 32 C9 01 00 00 04 00 00 00 00 00 00 00 FC 47 00 49 00 53 00 2E 00 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 00 00 7F 48 00 41 00 47 00 47 54 00 09 58 00 54 00 00 04 12 80 5F 00 A6 21 27 7E FF FF FF FF 00 1E 6F 24 BA 33 21 97 F7 32 C9 00 00 00 00 00 FF FF FF E3 81 29 C9 01 00 BD 12 00 00 00 00 00 07 00 00 16 00 48 00 41 00 47 00 54 00 58 00 54 2 H A G G I S . T X T & '! H A G G I S . T X T _ !' o o )

B~ )

) v$3!2

Using the facility built into Winhex the values of the bytes recorded in the four FILETIME fields in the database entry equate to:
Field First Access Last Access Last Modified Time MD5 Changed Hexidecimal 0x 00 1e 6f e3 81 29 c9 01 0x 00 bd 12 9a f7 32 c9 01 0x ba 33 21 97 f7 32 c9 01 0x 00 1e 6f e3 81 29 c9 01 Decoded value Wed, 08 October 2008 20:10:20 Mon, 20 October 2008 21:05:38 Mon, 20 October 2008 21:05:33 Wed, 08 October 2008 20:10:20

Table 22 Decoded values for Windows.edb file

Page 95 of 151

Procmon was again used to monitor file activity. The file haggis.txt was then opened and all but the first verse deleted, after which the file was saved. The index was updated and a snapshot taken of the file system. This snapshot was mounted using the vmwaremount program and FTK imager was used to create an image file that was named test2b.E01. The image file was also added to Encase and allowed to verify.

Figure 28: Encase screenshot after to modification

As can be seen from the screenshot above the last written FILETIME has changed to 22nd October 2008 at 15:02:13 hrs. The MFT record for the file was extracted and saved as MFT_entry_test2b.bin.

Offset 0 16 32 48 64 80

9 10 11 12 13 14 15 FILE0 8 ni ) ` H q ) *N4

46 49 4C 45 30 00 03 00 09 00 01 00 38 00 01 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8F 71 E3 81 29 C9 01

6E 69 BF 03 00 00 00 00 80 01 00 00 00 04 00 00 06 00 00 00 87 29 00 00 10 00 00 00 60 00 00 00 48 00 00 00 18 00 00 00 2A F1 9B C8 4E 34 C9 01

Page 96 of 151

96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368

2A F1 9B C8 4E 34 C9 01 20 00 00 00 00 00 00 00 00 00 00 00 82 01 00 00 68 3B 10 00 00 00 00 00 00 00 00 00 00 00 04 00 BA 25 00 00 00 00 01 00 00 8F 71 E3 81 29 C9 01 00 8F 71 E3 81 29 C9 01 EF 05 00 00 00 00 00 00 0A 03 68 00 61 00 67 00 74 00 78 00 74 00 00 00 00 00 00 00 00 00 05 00 74 3F D7 40 E8 9E DD 11 80 00 00 00 48 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 BE 00 00 00 00 00 00 00 21 01 72 32 00 00 01 00

2A F1 9B C8 4E 34 C9 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 70 00 00 00 56 00 00 00 18 00 01 00 00 8F 71 E3 81 29 C9 01 00 8F 71 E3 81 29 C9 01 00 10 00 00 00 00 00 00 20 00 00 00 00 00 00 00 67 00 69 00 73 00 2E 00 40 00 00 00 28 00 00 00 10 00 00 00 18 00 00 00 99 B0 00 0C 29 7D CE A7 01 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 BE 00 00 00 00 00 00 00 FF FF FF FF 82 79 47 11

*N4 *N4 h; % q ) q ) h a g g i s . t x t @ ( )} 0 V q ) q ) p

t?@ @ ! r2 H

yG

We can again extract the data from the Standard Information Attribute and decode it with the facility within Winhex program.
Creation FILETIME Last Modified FILETIME Last MFT Record Change FILETIME Last Accessed FILETIME 0x 00 8F 71 E3 81 29 C9 01 0x 2A F1 9B C8 4E 34 C9 01 0x 2A F1 9B C8 4E 34 C9 01 0x 2A F1 9B C8 4E 34 C9 01 8th October 2008 20:10:20 hrs 22nd October 2008 14:02:13 hrs 22nd October 2008 14:02:13 hrs 22nd October 2008 14:02:13 hrs

Table 23 - Extracted $MFT Record properties for haggis.txt file after modification

These date and times corroborate the findings when viewing the file properties in EnCase.

Page 97 of 151

The Windows.edb file was extracted and viewed in Windows Database Viewer. It could be seen that the Document ID remained the same however the Last Accessed and Modified FILETIME have changed.
Document ID FileName1 First Access Last Access Last Modified Time MD5 Changed
4 HAGGIS.TXT 00 1e 6f e3 81 29 c9 01 00 58 e5 ce 4e 34 c9 01 2a f1 9b c8 4e 34 c9 01 00 1e 6f e3 81 29 c9 01

Table 24 - Extracted systemindex_ghtr table entries after modification

The entry for the haggis.txt document was extracted from the edb file.
Offset 12599872 12599888 12599904 12599920 12599936 12599952 12599968 12599984 12600000 12600016 12600032 00 26 00 7F 8C 27 21 A6 00 09 49 00 53 00 2E 00 00 00 00 06 7F 80 00 00 0C 04 00 00 00 EC F8 42 E3 81 29 C9 01 D6 89 76 01 FF FF FF FF 29 00 00 FF 02 00 00 00 00 1E 6F CE 4E 34 C9 01 00 00 06 00 00 00 00 00 00 00 FC 47 00 49 00 53 00 2E 00 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 00 00 7F 48 00 41 00 47 00 47 54 00 09 58 00 54 00 00 04 12 80 5F 00 A6 21 27 7E FF FF FF FF 00 1E 6F 24 2A F1 9B C8 4E 34 C9 00 00 00 00 00 FF FF FF E3 81 29 C9 01 00 58 E5 00 00 00 00 00 07 00 00 16 00 48 00 41 00 47 00 54 00 58 00 54 N4 H A G G I S . T X T & '! H A G G I S . T X T _ !' o o ) X

B~ )

) v$*N4

Field First Access Last Access Last Modified Time MD5 Changed

Hexidecimal 0x 00 1e 6f e3 81 29 c9 01 0x 00 58 e5 ce 4e 34 c9 01 0x 2a f1 9b c8 4e 34 c9 01 0x 00 1e 6f e3 81 29 c9 01

Decoded Value Wed, 08 October 2008 20:10:20 Wed, 22 October 2008 14:02:24 Wed, 22 October 2008 14:02:13 Wed, 08 October 2008 20:10:20

Table 25 - Decoded values for Windows.edb file after modification

Page 98 of 151

Both of the extracted Windows.edb file entries were compared and it was noted that the following 12 bytes were different.

Offset Entry 1 Entry 2

75 BA 2A

76 33 F1

77 21 9B

78 97 C8

79 F7 4E

80 32 34

Offset Entry 1 Entry 2

112 BD 58

113 12 E5

114 9A CE

115 F7 4E

116 32 34

121 04 06

Table 26 - File compare results for $MFT entries after modification

Examination of the above table confirms that the modifications to the Last Modified time field and the Last Accessed time field.

5.10 Data Modification Conclusions For the forensic analyst, this section has probably the least amount of information of value. This is due to the fact that if I file is modified it will remain in the active file set and therefore, entries within the $MFT, directories and the file itself will be available for examination. It can however be seen that the indexer records the change by updating the Last Accessed and Last Modified FILETIME stamp.

Page 99 of 151

5.11 Experiment 3 - Deleting Data

The purpose of the third experiment was to establish what changes were made to the indexing files when a file was deleted from the index. This was potentially for the forensic analyst the most interesting experiment, as frequently computer forensic investigations are conducted on computers where suspects have deleted data in a crude attempt to hide their actions. The VMWare snapshot was used to return the system to a point at the conclusion of a modification test where the test2.txt document was in the My Documents directory. Examination of the Windows.edb file with the Microsoft Database Viewer revealed that the test2.txt document had a DocumentID number of 22.

Figure 29 Screenshot of SystemIndex_Gthr table showing test2.txt entry before deletion test

The method used involved starting Procmon and the system monitored for activity. The file test2.txt was then deleted and the indexer allowed to re-index the content. The Procmon output was then saved to a csv file named experiment3_phase1.csv. A snapshot was taken of the system after which the system was shut down. The vmware_mount utility was used to mount the snapshot file after which it was imaged using FTK imager. The image file was examined using EnCase. A text string search for the file test2.txt resulted

Page 100 of 151

in a hit being recorded in the SystemIndex.Ntfy3.gthr file. It has already been seen that when a file is indexed it is recorded in the SystemIndex.Ntfy3.gthr file on two separate occasions. It was noted that an additional entry had been appended to the file in relation to the deleted file.
Offset 00000000 00000016 00000032 00000048 00000064 00000080 00000096 00000112 00000128 00000144 00000160 00000176 00000192 0 4D 94 02 63 20 73 74 00 FF 00 00 00 00 1 44 75 00 3A 53 74 65 00 FF 00 00 00 00 2 4D 47 00 5C 65 5C 73 FF 00 00 00 00 3 44 A5 00 44 74 4D 74 FF 00 00 00 00 4 5A BD 00 6F 74 79 32 FF 00 00 00 00 5 12 12 00 63 69 20 2E FF 00 00 00 00 6 00 C9 00 75 6E 44 74 01 00 00 00 00 7 00 01 00 6D 67 6F 78 00 00 00 00 00 8 00 7E 01 65 73 63 74 00 00 00 00 00 9 10 11 12 13 14 15 00 80 00 6E 5C 75 00 00 00 00 00 00 00 06 00 74 4D 6D 00 00 EC 00 00 00 00 AB 00 73 53 65 00 00 F8 00 00 00 69 BD 3A 20 63 6E 00 00 42 00 00 00 00 12 00 61 20 74 00 00 7E 00 00 00 80 C9 00 6E 54 73 00 FF 16 00 00 00 00 01 00 64 65 5C 00 FF 00 00 00 00 MDMDZ i uG ~ : c:\Documents and Settings\MSc Te st\My Documents\ test2.txt B~

Examination of the entry reveals that bytes 16 23 is a windows FILETIME that decoded to 09th September 2008 20:50:08 hrs. Bytes 24 31 were a further FILETIME 09th September 2008 20:50:18 hrs. Bytes 118 held a value of 0x 01 the remainder of the field was padded was zeros. Bytes 130 137 was zeroed. Bytes 138 -142 held the values EC F8 42 7E 16. Bytes 158 165 were zeroed, as were bytes 166 173. It was noted that Byte 178 held the value 0x 02 compared to 0x 01 for the first entry for this file. It was noted that this particular entry for the file had only two FILETIME stamps, whereas previous entries had 6 FILETIME stamps recorded.

Page 101 of 151

5.11.1 Examination of the Windows.edb file

The Windows.edb file was extracted from the disk image and the contents viewed using the Microsoft Database Viewer. Examination of the SystemIndex_gthr table revealed that the entry relating to the test document had been deleted from the table. The SystemIndex_DeletedDocIds table was examined and it was noted that it recorded an entry for the DocumentID 22. Notwithstanding a checkpoint version value no further detail in respect of the deleted file, such as time deleted was recorded.

Figure 30 SystemIndex_DeletedDocIds entry for Document 22

5.11.2 Examination of the INFO2 file entry

Test 3\Test 3\RECYCLER\S-1-5-21-2000478354-1078081533-839522115-1003\INFO2 Info2 record for deleted file Index Deleted 1 09/Sep/2008 20:50:07 Documents\test2.txt Path C:\Documents and Settings\MSc Test\My

Figure 31 INFO2 file details for deleted file

Page 102 of 151

As can be seen from the above screenshot the recycler recorded the time of deletion at 20:50:07 hrs. This was one second prior to the first record in the SystemIndex.Ntfy3.gthr file above. This would suggest that once the file itself is deleted the indexer was updated almost immediately. The initial deletion test highlighted the fact that an entry appeared to be created in the SystemIndex.Ntfy3.gthr file with two FILETIME stamps, the first of which was immediately after the deletion of the file. The record for the document in the SystemIndex_Gthr table of the Windows.edb file was removed and an entry created in the SystemIndex_DeletedDocIds table. This latter entry had no corresponding time stamp. This operation appears to have been carried out within seconds of the document being deleted from the file system. In order to test some of the observations in the first phase of the experiment, a further phase was conducted where numerous files were deleted. Additionally it was decided to expand the experiment to include traces of the file within the Windows.edb.

5.12 Experiment 3 Phase 2

The VMWare system was started and the system restored to the same point as Experiment One Phase 2. This point was after an additional four files were added to the index. This meant that a total of 8 items were in the index, consisting of 3 directories and the five documents. Procmon was started in order to capture file activity and then in turn each of the 5 text files were deleted by selecting the Del key. This would ensure that the deleted file would be placed into the Recycler folder and create an entry in the INFO2 file. Similarly to the first phase of the test it was intended to use the INFO2 file as a reference during the subsequent examination.

Page 103 of 151

The indexing status dialogue box was viewed and it initially displayed Items Indexed so far = 8 and Items left to be scanned = 0. The file haggis.txt was deleted and it was observed that immediately the Items left to be scanned displayed 1. The index then updated the display and the Items Indexed so far decremented by one digit to 7 and the Items left to scan was reset to zero. Each of the text files were similarly deleted at the conclusion of which the Items indexed so far counter was set at 3 and the Items left to be scanned counter was set to zero. At the conclusion the Procmon log file was saved in the root directory. A snapshot was taken of the system after which it was shut down. The vmare_mount utility was used to mount the snapshot file that was then imaged using FTK imager. The disk image was then added to Encase and allowed to verify, which it did. The SystemIndex.NTFY4.gthr file was extracted and viewed in Winhex. The original SystemIndex.NTFY.gthr file was compared against this latest version of the file. It was seen that during the original experiment that as each file was added to the index two separate entries were added to the file. However when each file was subsequently deleted an additional entry was appended to the transaction log. This was the same behaviour as observed during the first phase of this experiment. The additional entries were extracted as separate files: entry1_gthr.bin
Offset 0 16 32 48 64 80 96 112 128 144 160 176 0 4D C8 02 63 20 73 68 00 00 F8 00 00 1 44 1E 00 3A 53 74 61 00 00 42 00 00 2 4D 17 00 5C 65 5C 67 00 00 7E 00 00 3 44 31 00 44 74 4D 67 00 FF 04 00 00 4 64 FE 00 6F 74 79 69 00 FF 00 00 00 5 07 39 00 63 69 20 73 00 FF 00 00 00 6 00 C9 00 75 6E 44 74 00 FF 00 00 00 7 00 01 00 6D 67 6F 65 FF 00 00 00 00 8 00 54 01 65 73 63 73 FF 00 00 00 00 9 10 11 12 13 14 15 00 D2 00 6E 5C 75 74 FF 00 00 00 00 00 8F 00 74 57 6D 2E FF 00 00 00 00 00 32 00 73 44 65 74 01 00 00 00 02 69 FE 3F 20 53 6E 78 00 00 00 00 00 02 39 00 61 20 74 74 00 00 00 00 00 80 C9 00 6E 54 73 00 00 00 00 00 00 00 01 00 64 65 5C 00 00 EC 00 00 00 MDMDd i 19 T 29 ? c:\Documents and Settings\WDS Te st\My Documents\ haggistest.txt B~

Page 104 of 151

192

00 00 00 00 00 00 00

entry2_gthr.bin
Offset 0 16 32 48 64 80 96 112 128 144 160 176 192 0 4D 56 02 63 20 73 42 00 00 EC 00 00 00 1 44 9E 00 3A 53 74 61 00 00 F8 00 00 00 2 4D A2 00 5C 65 5C 6E 00 00 42 00 00 00 3 44 3D 00 44 74 4D 6E 00 00 7E 00 00 00 4 2C FE 00 6F 74 79 6F 00 FF 06 00 00 00 5 08 39 00 63 69 20 63 00 FF 00 00 00 00 6 00 C9 00 75 6E 44 6B 00 FF 00 00 00 00 7 00 01 00 6D 67 6F 62 00 FF 00 00 00 00 8 00 EC 01 65 73 63 75 FF 00 00 00 00 9 10 11 12 13 14 15 00 0A 00 6E 5C 75 72 FF 00 00 00 00 00 72 00 74 57 6D 6E FF 00 00 00 00 00 3E 00 73 44 65 2E FF 00 00 00 00 69 FE 40 20 53 6E 74 01 00 00 00 02 00 39 00 61 20 74 78 00 00 00 00 00 80 C9 00 6E 54 73 74 00 00 00 00 00 00 01 00 64 65 5C 00 00 00 00 00 00 MDMD, i V=9 r>9 @ c:\Documents and Settings\WDS Te st\My Documents\ Bannockburn.txt B~

entry3_gthr.bin
Offset 0 16 32 48 64 80 96 112 128 144 160 176 192 0 4D F2 02 63 20 73 63 74 00 00 00 00 00 1 44 36 00 3A 53 74 61 00 00 00 00 00 00 2 4D 0E 00 5C 65 5C 73 00 00 EC 00 00 00 3 44 43 00 44 74 4D 74 00 00 F8 00 00 00 4 F6 FE 00 6F 74 79 6C 00 00 42 00 00 00 5 08 39 00 63 69 20 65 00 00 7E 00 00 00 6 00 C9 00 75 6E 44 20 00 FF 07 00 00 00 7 00 01 00 6D 67 6F 67 00 FF 00 00 00 00 8 00 70 01 65 73 63 6F 00 FF 00 00 00 00 9 10 11 12 13 14 15 00 C3 00 6E 5C 75 72 00 FF 00 00 00 00 00 7F 00 74 57 6D 64 FF 00 00 00 00 00 44 00 73 44 65 6F FF 00 00 00 00 69 FE 42 20 53 6E 6E FF 00 00 00 00 00 39 00 61 20 74 2E FF 00 00 00 00 80 C9 00 6E 54 73 74 01 00 00 00 02 00 01 00 64 65 5C 78 00 00 00 00 00 MDMD i 6 C9 p D9 B c:\Documents and Settings\WDS Te st\My Documents\ castle gordon.tx t B~

gthr4_ghtr.bin
Offset 0 16 32 48 64 80 96 112 128 0 4D 16 02 63 20 73 4B 74 00 1 44 42 00 3A 53 74 69 00 00 2 4D 73 00 5C 65 5C 6C 00 00 3 44 4A 00 44 74 4D 6C 00 00 4 C0 FE 00 6F 74 79 69 00 00 5 09 39 00 63 69 20 65 00 00 6 00 C9 00 75 6E 44 63 00 FF 7 00 01 00 6D 67 6F 72 00 FF 8 00 A0 01 65 73 63 61 00 FF 9 10 11 12 13 14 15 00 72 00 6E 5C 75 6E 00 FF 00 58 00 74 57 6D 6B FF 00 00 50 00 73 44 65 69 FF 00 69 FE 42 20 53 6E 65 FF 00 00 39 00 61 20 74 2E FF 00 80 C9 00 6E 54 73 74 01 00 00 01 00 64 65 5C 78 00 00 MDMD BsJ9 i rXP9 B c:\Documents and Settings\WDS Te st\My Documents\ Killiecrankie.tx t

Page 105 of 151

144 160 176 192

00 00 00 00

00 00 00 00

EC 00 00 00

F8 00 00 00

42 00 00 00

7E 00 00 00

05 00 00 00

00 00 00 00

00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00

B~

gthr5_gthr.bin
Offset 0 16 32 48 64 80 96 112 128 144 160 176 192 208 0 4D D6 02 63 20 73 59 6E 00 FF 00 00 00 00 1 44 7A 00 3A 53 74 65 61 FF 00 00 00 00 2 4D FE 00 5C 65 5C 20 6D FF 00 00 00 00 3 44 61 00 44 74 4D 4A 65 FF 00 00 00 00 4 91 FE 00 6F 74 79 61 2E FF 00 00 00 00 5 0A 39 00 63 69 20 63 74 01 00 00 00 02 6 00 C9 00 75 6E 44 6F 78 00 00 00 00 00 7 00 01 00 6D 67 6F 62 74 00 00 00 00 00 8 00 D0 01 65 73 63 69 00 00 00 00 00 00 9 10 11 12 13 14 15 00 02 00 6E 5C 75 74 00 00 EC 00 00 00 00 27 00 74 57 6D 65 00 00 F8 00 00 00 00 62 00 73 44 65 73 00 00 42 00 00 00 69 FE 49 20 53 6E 20 00 00 7E 00 00 00 00 39 00 61 20 74 62 00 FF 08 00 00 00 80 C9 00 6E 54 73 79 00 FF 00 00 00 00 00 01 00 64 65 5C 20 00 FF 00 00 00 00 MDMD i za9 'b9 I c:\Documents and Settings\WDS Te st\My Documents\ Ye Jacobites by name.txt B~

It was observed that each of the entries contained only two FILETIMEs; this was identical to the behaviour observed during the first phase of the experiment. The relevant details have been extracted to the table below.

File Name Haggis Bannockburn Castle Gordon Killiecrankie Ye Jacobites by name

Filetime 1 29/10/2008 29/10/2008 29/10/2008 29/10/2008 29/10/2008

19:40:26 19:40:47 19:40:56 19:41:09 19:41:48

Filetime 2 29/10/2008 29/10/2008 29/10/2008 29/10/2008 29/10/2008

19:40:28 19:40:48 19:40:59 19:41:18 19:41:48

Table 27 File Deletion FILETIME Stamps

It can be seen that these FILETIMEs relate to time during the experiment when the files were deleted. The most likely explanation is that the first field is when the file is listed as Items left to be scanned and the second when the Items Indexed so far counter is updated. The INFO2 file was examined and the dates and times of the file deletion recorded.

Page 106 of 151

Figure 32: Screenshot of recycle bin

File Deletion Test\test3b\RECYCLER\S-1-5-21-2052111302-179605362-7253455431003\INFO2 INFO2 record for deleted files Index Deleted Path 4 29/Oct/2008 19:40:25 C:\Documents and Settings\WDS Test\My Documents\haggistest.txt 5 29/Oct/2008 19:40:46 C:\Documents and Settings\WDS Test\My Documents\Bannockburn.txt 6 29/Oct/2008 19:40:55 C:\Documents and Settings\WDS Test\My Documents\castle gordon.txt 7 29/Oct/2008 19:41:08 C:\Documents and Settings\WDS Test\My Documents\Killiecrankie.txt 8 29/Oct/2008 19:41:47 C:\Documents and Settings\WDS Test\My Documents\Ye Jacobites by name.txt Table 28: Decoded INFO2 File

Identical behaviour to that observed in the first phase of the test was seen where the record in the INFO2 file is timed immediately prior to the first entry in the transaction log file.

Page 107 of 151

An example the two previous entries for the text file Bannockburn.txt have been compared to the additional entry created on deletion: First entry:
Offset 0 16 32 48 64 80 96 112 128 144 160 176 192 0 4D FA 02 63 20 73 42 00 8C EC 00 8C 00 1 44 87 00 3A 53 74 61 00 2C F8 00 2C 00 2 4D 7E 00 5C 65 5C 6E 00 C9 42 00 C9 00 3 44 B7 00 44 74 4D 6E 00 01 7E 00 01 00 4 9F 8C 00 6F 74 79 6F 00 FF 06 08 00 00 5 02 2C 00 63 69 20 63 00 FF 00 AF 00 00 6 00 C9 00 75 6E 44 6B 00 FF 00 85 00 00 7 00 01 00 6D 67 6F 62 00 FF 00 B7 00 00 8 00 32 00 65 73 63 75 FF 08 00 8C 01 9 10 11 12 13 14 15 00 7E 00 6E 5C 75 72 FF AF 00 2C 00 00 FD 00 74 57 6D 6E FF 85 00 C9 00 00 B9 00 73 44 65 2E FF B7 00 01 00 6B 8C 40 20 53 6E 74 96 8C 00 08 02 01 2C 00 61 20 74 78 3F 2C 00 AF 00 80 C9 00 6E 54 73 74 F4 C9 00 85 00 00 01 00 64 65 5C 00 B6 01 00 B7 00 MDMD k ~, 2~, @ c:\Documents and Settings\WDS Te st\My Documents\ Bannockburn.txt ? , , B~ , ,

Second entry:
Offset 0 16 32 48 64 80 96 112 128 144 160 176 192 0 4D FA 02 63 20 73 42 00 8C FF 00 8C 00 1 44 87 00 3A 53 74 61 00 2C FF 00 2C 00 2 4D 7E 00 5C 65 5C 6E 00 C9 FF 00 C9 00 3 44 B7 00 44 74 4D 6E 00 01 FF 00 01 00 4 67 8C 03 6F 74 79 6F 00 FF 06 8C 00 00 5 03 2C 12 63 69 20 63 00 FF 00 E0 00 00 6 00 C9 04 75 6E 44 6B 00 FF 00 FF 00 00 7 00 01 00 6D 67 6F 62 00 FF 00 B9 00 00 8 00 8C 02 65 73 63 75 FF 00 00 8C 01 9 10 11 12 13 14 15 00 E0 00 6E 5C 75 72 FF 80 00 2C 00 00 FF 00 74 57 6D 6E FF 3E 00 C9 00 00 B9 00 73 44 65 2E FF D5 00 01 00 69 8C 40 20 53 6E 74 96 DE 00 8C 02 01 2C 00 61 20 74 78 3F B1 00 E0 00 80 C9 00 6E 54 73 74 F4 9D 00 FF 00 02 01 00 64 65 5C 00 B6 01 00 B9 00 MDMDg i ~, , @ c:\Documents and Settings\WDS Te st\My Documents\ Bannockburn.txt ? , > , ,

Third entry:
Offset 0 16 32 48 64 80 96 112 128 144 160 176 0 4D 56 02 63 20 73 42 00 00 EC 00 00 1 44 9E 00 3A 53 74 61 00 00 F8 00 00 2 4D A2 00 5C 65 5C 6E 00 00 42 00 00 3 44 3D 00 44 74 4D 6E 00 00 7E 00 00 4 2C FE 00 6F 74 79 6F 00 FF 06 00 00 5 08 39 00 63 69 20 63 00 FF 00 00 00 6 00 C9 00 75 6E 44 6B 00 FF 00 00 00 7 00 01 00 6D 67 6F 62 00 FF 00 00 00 8 00 EC 01 65 73 63 75 FF 00 00 00 00 9 10 11 12 13 14 15 00 0A 00 6E 5C 75 72 FF 00 00 00 00 00 72 00 74 57 6D 6E FF 00 00 00 00 00 3E 00 73 44 65 2E FF 00 00 00 00 69 FE 40 20 53 6E 74 01 00 00 00 02 00 39 00 61 20 74 78 00 00 00 00 00 80 C9 00 6E 54 73 74 00 00 00 00 00 00 01 00 64 65 5C 00 00 00 00 00 00 MDMD, i V=9 r>9 @ c:\Documents and Settings\WDS Te st\My Documents\ Bannockburn.txt B~

Page 108 of 151

192

00 00 00 00 00 00 00 00

The various entries have been extracted to the table below for ease of comparision.

Filetime Field 1 2 3 4 5 6

12 12 12 12 12 12

Entry 1 October 2008 17:05:24 October 2008 17:05:28 October 2008 17:05:23 October 2008 17:05:24 October 2008 17:05:24 October 2008 17:05:24

12 12 12 01 12 12

Entry 2 October 2008 17:05:24 October 2008 17:05:28 October 2008 17:05:23 January 1970 00:00:00 October 2008 17:05:28 October 2008 17:05:28

Entry 3 29 October 2008 19:40:47 29 October 2008 19:40:48

Table 29 File deletion comparison table

It can clearly be seen that the third entry only has two FILETIMEs and that those are timed when the actual files were deleted from the file system. With the files deleted the Windows.edb file was extracted and opened with the Microsoft database viewer. The SystemInex_gthr table was viewed and it was seen that there were three records displayed. These records related to the directories, none of the documents that had been deleted from the index were recorded in the table.

Figure 33 - Screenshot of SystemInex_gthr table after multiple file deletion test.

The SystemIndex_DeletedDocsIds table was viewed and it was seen that the document Id of the deleted documents was recorded but no further details were found.

Page 109 of 151

Figure 34 - SystemIndex_DeletedDocIds entry for multiple file deletion

The Windows.edb file was then examined using Winhex and a text string search of the names of the files that had been deleted resulted in hits from file offset 12599889.
Offset 12599888 12599904 12599920 12599936 12599952 12599968 12599984 12600000 12600016 12600032 12600048 12600064 12600080 12600096 12600112 12600128 12600144 12600160 12600176 12600192 12600208 12600224 12600240 12600256 12600272 12600288 12600304 12600320 12600336 12600352 12600368 12600384 12600400 12600416 12600432 0 00 00 00 42 74 00 AF 01 FC 00 00 00 00 00 21 99 2C FF 99 00 4C 4B 2F 09 2E 06 7E 24 00 B7 00 20 42 00 1 2F 09 54 04 7E 24 00 49 00 1E 45 38 09 49 00 27 DB C9 FF DB 00 00 00 00 4F 00 12 FF 96 00 8C 00 00 00 00 2 00 49 00 12 06 5E 00 2D 00 00 00 00 49 00 00 0C A7 01 FF A7 00 4C 49 7F 00 09 80 FF 3F 00 2C 00 42 55 38 3 7F 00 09 80 00 B2 00 27 00 48 53 7F 00 09 00 05 8C FF 02 8C 00 00 00 8C 43 54 5F FF F4 00 C9 00 00 00 00 4 8C 53 58 5F 00 68 00 C9 00 00 00 8C 45 45 00 00 2C FF 00 2C 00 49 45 27 00 00 00 FF B6 00 01 00 41 52 7F 5 27 00 00 00 00 17 00 01 00 41 54 27 00 00 04 00 C9 FF 00 C9 00 00 00 21 4B 58 A6 00 8C FF 00 07 00 00 8C 6 21 54 54 A6 00 2D FD 00 06 00 00 21 43 2E 7F 00 01 FF 00 01 00 45 2E A6 00 00 21 E2 2C FF E2 00 4E 4E 27 7 A6 00 00 21 33 27 FF 33 00 47 2E A6 00 00 80 EC 1D 2B 00 00 00 00 00 7F 42 54 27 5A C9 FF 5A 00 00 00 21 8 7F 45 00 27 AF C9 FF AF 00 00 00 7F 52 54 00 F8 17 00 99 00 00 43 54 42 00 00 0C B7 01 FF B7 00 4E 2E A6 9 10 11 12 13 14 15 48 00 00 0C 49 01 FF 49 00 47 54 4B 00 00 00 42 79 00 DB 01 FC 00 00 00 09 00 06 8C FF 02 8C 00 00 00 7F 00 09 00 04 2D FF 02 2D 00 00 00 00 09 58 05 7E 24 00 A7 00 24 52 58 41 55 00 00 2C FF 00 2C 00 4F 54 43 41 53 00 00 27 FF 00 27 00 49 58 49 41 00 12 FF 60 00 8C 00 00 00 00 00 00 08 00 C9 FF 00 C9 00 00 00 00 00 00 06 00 C9 FF 00 C9 00 00 00 00 00 09 80 FF 64 00 2C 00 4B 41 54 4E 52 7F 00 01 FF 00 01 00 43 58 41 47 54 7F 00 01 FF 00 01 00 53 54 4C 4E 54 5F FF 7F 00 C9 00 00 00 00 00 00 80 EC 2A 2B 00 00 00 00 00 00 00 00 80 EC 5F 2B 00 00 00 00 00 00 00 00 00 FF A6 00 01 00 49 4E 00 4E 4E 00 F8 17 00 E2 00 00 4B 54 53 47 2E 00 F8 95 02 33 00 00 54 00 4C 4B 00 A6 00 8C FF 00 07 00 00 00 00 00 00 42 79 00 5A 01 FC 00 00 00 '! H A G G I S T E S T . T X T _ !' B~ 3I-' _ t$^h -' + 3 I-' 3I-' H A G G I S T E S T . T X T 8 '! K I L L I E C R A N K I E . T X T _ !' B~ , y$`d , + , , $ K I L L I E C R A N K I E . T X T / '! B A N N O C K B U R N . T X T _ !' B ~ Z, * y $?, + Z , Z, B A N N O C K B U R N . T X T 8 '! C A S /

Page 110 of 151

12600448 12600464 12600480 12600496 12600512 12600528 12600544 12600560 12600576 12600592 12600608 12600624 12600640 12600656 12600672 12600688 12600704 12600720 12600736 12600752 12600768 12600784 12600800 12600816 12600832

54 44 00 A6 00 8C FF 00 07 00 00 00 00 00 00 00 00 FF CB 00 01 00 45 54 41

00 00 00 21 4A 2C FF 4A 00 53 44 4A 09 53 4D 00 A6 00 8C FF 00 07 00 00 00

09 4F 00 27 E4 C9 FF E4 00 00 00 00 41 00 00 00 21 DF 2C FF DF 00 20 45 4D

4C 00 00 0C C0 01 FF C0 00 54 4F 7F 00 09 45 00 27 9E C9 FF 9E 00 00 00 00

00 09 00 07 8C FF 02 8C 00 00 00 8C 43 20 00 00 0C CB 01 FF CB 00 4A 53 45

45 4E 00 00 2C FF 00 2C 00 4C 4E 27 00 00 09 00 08 8C FF 02 8C 00 00 00 00

00 00 04 00 C9 FF 00 C9 00 00 00 21 4F 42 2E 00 00 2C FF 00 2C 00 41 20 2E

20 2E 7F 00 01 FF 00 01 00 45 2E A6 00 00 00 02 00 C9 FF 00 C9 00 00 00 00

00 00 80 EC 32 2B 00 00 00 00 00 7F 42 59 54 7F 00 01 FF 00 01 00 43 42 54

47 54 00 F8 17 00 4A 00 00 20 54 59 00 00 00 80 EC 3B 2B 00 00 00 00 00 00

00 00 00 42 79 00 E4 01 FC 00 00 00 09 20 58 00 F8 17 00 DF 00 00 4F 59 58

09 58 07 7E 24 02 C0 00 24 47 58 45 49 00 00 00 42 79 00 9E 01 FC 00 00 00

4F 00 12 FF 82 00 8C 00 00 00 00 00 00 09 54 08 7E 24 00 CB 00 32 42 20 54

00 09 80 FF 08 00 2C 00 43 4F 54 20 54 4E 00 12 FF B4 00 8C 00 00 00 00

52 54 5F FF 9F 00 C9 00 00 00 00 00 00 00 09 80 FF C1 00 2C 00 59 49 4E

00 00 00 FF C0 00 01 00 41 52 00 4A 45 41 00 5F FF 9E 00 C9 00 00 00 00

T L E G O R D O N . T X T _ !' B~ J, 2 y$ , + J, J, $ C A S T L E G O R D O N . T X T J '! Y E J A C O B I T E S B Y N A M E . T X T _ !' B~ , ; y$ , + , , 2 Y E J A C O B I T E S B Y N A M E . T X T

It could be seen that hits were found when the file was viewed in Winhex but, not found when the Windows.edb file was viewed in the Microsoft Database Viewer. The likely explanation for this is the fact that the Microsoft Database Viewer is using the Windows API to display the contents of the database. The use of Winhex revealed the raw data and not what the API was passing to the program. The same sectors from the extracted Windows.edb file from test1b were compared with the extracted file after the deletion test. The purpose of this was to ascertain whether any bytes of data had been changed. The test1b.bin was hashed using MD5 and the resultant output was recorded as 2795D8958FED9FBF4058E6DA8F055DF9. After the deletion test had been carried out the same sectors from the Windows.edb file was extracted and also hashed. The resultant MD5 was also seen to be 2795D8958FED9FBF4058E6DA8F055DF9.

5.13 File Content

The research chapter of this report revealed (Section 4.5) that a number of files indexed the content in addition to the properties of the parent file. For these experiments text files were

Page 111 of 151

chosen as the As will be seen in the experiment that follows in respect of the preview of documents, the content is recorded within the Windows.edb file itself. The significance of this clearly being that if details of the file itself survive the index being updated as shown above then potentially a copy of the original file may also survive. The problem to be overcome is the fact that as has been shown the Microsoft Database Viewer does not reveal the details that have been deleted from the index, even though viewing the raw data with Winhex reveals that it survives. As can be seen from section below the obfuscated content of a file is held in the System Search AutoSummary field of the SystemIndex_0A table of the database. The Windows.edb file was searched for details of the System Search AutoSummary for the file Ye Jacobites by name.txt. It was found at file offset 5036176. This experiment shows that in addition to the meta data about a file such as FILETIMEs surviving a deletion of the parent file, but so does the content. This finding is highly significant, although as could be seen when the Windows.edb file was viewed afterwards it could be seen that the Microsoft Database Viewer did not reveal the file contents

5.14 Deletion Test Conclusions

It can be seen that experimentation has empirically revealed that when files are deleted from the file system, within the briefest of periods the indexer records the fact in the transaction log file. Unlike such entries when a file is added to the index, it was observed that two FILETIME stamps were recorded with the most likely explanation being that the first records when the indexer adds the file to the gather queue and the second when the index is updated. This finding is potentially significant should a computer forensic analyst recover fragments of the transaction log during an examination. This experiment has enabled the forensic community to be able to make a distinction between a file being added to the index or being modified and a file being deleted together with a very accurate time stamp for such activity (depending on the system clock setting at the time of the activity).

Page 112 of 151

This experiment has also highlighted the fact that the Windows.edb file retains details of a file after it has been deleted from a file system. This is significant for the forensic computing community.

Page 113 of 151

5.15 Experiment 4 - Preview Exercise One of the features of Windows Desktop Search is the facility to preview any document that is searched for. The purpose of this experiment was to confirm where the data that populates the preview pane is obtained. There were essentially two possibilities either the document itself or from the obfuscated data in the Windows.edb file. The Windows Desktop Search website reported that the actual content is protected for privacy by using the NTFS permissions to only allow users to access files that they have permission to do so. Should the permissions on a file change, then the change is notified to the index and only those with sufficient privileges can search for the file. As an additional security measure the file content is protected by obfuscation [42]. The test document haggis.txt was 1,519 bytes in size and was located in the My Documents directory. ProcMon was launched and the monitoring of file and Registry activity commenced. The Windows Desktop Search user interface was then launched and a search was conducted for the term haggis. It was seen that the haggis.txt document was previewed in the right hand pane of the user interface. 676

Figure 35 - Screenshot of System Search AutoSummary field

Page 114 of 151

The interface was then closed and ProcMon stopped and the logfile saved as haggis_preview.xls. On examination it was seen that at 20:57:55 hrs the searchindexer process accessed the C:\Documents and Settings\All Users\Application Data\ Microsoft \Search \Data \Applications \Windows \Windows.edb file and read the file from offset 155,648 for a total of 8,192 bytes. At 20:57:55 hrs the searchindexer process accessed the C:\Documents and Settings\All Users\Application Data\ Microsoft \Search \Data \Applications \Windows \Windows.edb file and then read the file from offset 2007040 for a total of 8,192 bytes. Finally at 20:57:55 hrs it was then seen that the Windows.edb file was accessed with the QueryDirectory process. This would suggest that the preview pane on the Windows Desktop Search user interface is populated by the obfuscated data from the Windows.edb file Auto Search Summary column.

Operation ReadFile

Path C:\Documents and Settings\All Users\Application Data\Microsoft\Search\Data\Applicatio ns\Windows\Windows.edb

Detail Offset: 155,648, Length: 8,192, I/O Flags: Non-cached

ReadFile

C:\Documents and Settings\All Users\Application Data\Microsoft\Search\Data\Applicatio ns\Windows\Windows.edb

Offset: 2,007,040, Length: 8,192, I/O Flags: Non-cached

QueryDirectory

C:\Documents and Settings\All Users\Application Data\Microsoft\Search\Data\Applicatio ns\Windows\Windows.edb

Filter: Windows.edb, 1: Windows.edb

Table 30 Procmon Log

Page 115 of 151

On viewing the file within the Windows.edb file using the Microsoft Database Viewer it could be seen that the haggis.txt was identified as Document Number 4. contents of the file are obfuscated in some manner. The System Search AutoSummary Column was selected and viewed. It was seen that the

Figure 36 Screenshot of obfuscated data in the System Search AutoSummary field

This is consistent with the postings on the Microsoft developers Network board postings that had indicated that the content was obfuscated for security reasons [39].

Page 116 of 151

The Procmon Log file revealed that the Windows.edb file was read initially from 155,648 for a total of 8,192 bytes. When viewed in Winhex it was noted that this page of the database held all of the fields within the SystemIndex_0A table. The next read operation reported by Procmon was from offset 2007040 for a total of 8,192 bytes. On examination it was seen that this page of the database held the obfuscated contents of the file.

Page 117 of 151

Figure 37 View of Windows.edb showing obfuscated data.

This would tend to support the fact that the auto search summary field does hold the obfuscated version of the actual document and is used when previewing files.

Experiment 4 Phase 2

In order to ensure that the result of phase one of this experiment was verified it was decided to devise a further experiment that would validate the previous findings. To test whether the auto search summary column contained the obfuscated data WinHex was used to change the data within the obfuscated data section of the Windows.edb file and an attempt was made to preview the document.

Page 118 of 151

VMWare was configured with five test documents added to the My Documents directory. The snapshot used was the one saved from the modification test where the document Haggistest.txt had been modified. Additionally the four other documents Killiecrankie, Bannockburn, Castle Gordon, Ye Jacobites by name, were added to the directory. In order to carry out the experiment it was necessary to establish the contents of the auto search summary column. This was completed by viewing the edb file with the Microsoft Database Viewer and selecting the Auto Search Summary column. The contents of the column were viewed in Hexadecimal view and copied to a separate file. The first experiment was conducted on the haggistest.txt document identified as DocID number 4.

Figure 38 Microsoft Database Viewer Screenshot

For the next stage of the experiment it was necessary to stop the Windows Desktop Search service in order to be able to access the Windows.edb file and change some of the data. This was done by selecting Control Panel, System and Maintenance,

Page 119 of 151

Administrative tools and selecting the Services Applet. It was then necessary to locate the Windows Search service and select stop. The Windows.edb file was then opened in WinHex. The contents of the Auto Search Summary column was searched for and found at File Offset 05031632.

Figure 39 Obfuscated data in Windows.edb file prior to experiment

The first byte of data was changed from AB to AC.

Figure 40 - Obfuscated data in Windows.edb file after experiment

Page 120 of 151

The changes were saved and the Windows Search service was restarted. The user interface was then used to search for the document. The interface revealed that the document was not found. When the Windows Desktop Search Indexing Status was viewed it showed that the Items indexed so far value was set at nil, as was the Items left to scan value. The Windows.edb file was opened in the Microsoft Database Viewer where it was discovered that the SystemIndex_0A table recorded nil records, however the SystemIndex_Gthr table still recorded the fact that 8 records were held.

Figure 41 Windows.edb file after experiment.

This would appear to show that the index had been corrupted during the experiment and that the indexing status is dependent on the SystemIndex_0A table. This experiment was repeated for the Killiecrankie.txt file.

Page 121 of 151

Figure 42 Screenshot of auto search summary field for

Figure 43 Killiecrankie.txt file prior to change

In order to rule out the fact that the first byte was causing the problem, in the remaining experiments random bytes within the field were selected and changed. The same results were experienced on each occasion.

Page 122 of 151

Figure 44 Killiecrankie.txt file after change

This would indicate that the database had become corrupted by the changing of one single byte of data within it. This opens up the possibility that there is some form of CRC or hash check on the database that reveals when it has become corrupted.

Experiment 4 Phase 3

One of the features of the user interface when previewing files is the Deskbar history section. It was noted that during the preview experiment that previous searches were displayed in the deskbar. See Figure 44 below. It was found that the terms were added to the deskbar history, only after the document had been previewed, i.e. when the term was entered into the search box and the return key selected in order to display the document in the preview pane. The two most obvious hypotheses were that the details were retained in the system Random Access Memory [RAM] or within the System Registry.

Page 123 of 151

Figure 45 Deskbar History

5.15.1 System Registry

The first simple experiment was to reboot the test machine to see whether the details survived a re-boot. After the machine powered up it was seen that the search terms survived the operation. The fact that they did indicated that the data was stored in the System Registry; as the expected result for the details to be held in RAM was for them no longer to be present. The users NTUSER.dat file was extracted from the machine and examined using the Access Data Registry Viewer. It was observed that in the Software\Microsoft\Windows Desktop Search\DB key were the terms inputted into the user interface to search for the documents.

Page 124 of 151

Figure 46 System Registry Search terms

As can be seen from the screenshot above the terms that had been entered into the Deskbar and the documents previewed were in the SearchStrings key. It could also be seen that EnableHistory key was set at 0x00000001 (1).

5.15.2 Enable History Key

As a further experiment the key was edited to change the value from at 0x00000001 (1) to at 0x00000000 (0).

Page 125 of 151

Figure 47 System Registry after Experiment 4 Phase 3

It was noted that immediately the search terms were removed from the Deskbar and examination of the registry revealed that the details in the SearchStrings key had also been removed.

5.16 Preview Experiment Conclusions

Examination of the Procmon log file reveals that when a search was conducted for a test document the Windows.edb file was read and not the actual document itself, prior to the preview pane showing the test document. The further test produced unhelpful results to a certain extent in that when the auto search summary content was changed, it appears to have corrupted the index. The System Registry examination revealed that the history of documents that were searched for was recorded in the users Software\Microsoft\Windows Desktop Search\DB key. This artefact was potentially the most useful fact gleaned during this experiment.

Page 126 of 151

CHAPTER 6 - Critical Project Analysis and Review

6.1 Introduction

This chapter looks at the project and highlights both the successes together with areas where improvement could have been made. It is intended that this part of the final document acts as a guide to other students embarking on similar research and will hopefully provide them with sufficient information to assist in avoiding the errors made and allow them to build upon the successes of this project.

6.2 The Project Plan

The project started off with the submission and acceptance of a defined project plan. The various milestones of the project such as interim report submission and mid term presentation assisted with focusing the author on crucial deadlines to be met during the project lifetime. The timeline was more or less followed, although work and family commitments did impact during the course of the project year. On reflection the author feels that more time should have been allocated to the experimentation and analysis phase of the project, which was found to be more time consuming than initially anticipated. An issue that in hindsight should have been anticipated was the fact that some experiments gave spurious findings and so were repeated several times until the author was satisfied that the findings were consistent enough to be included in the summary of major findings. One area of the project that proved invaluable and yet was not considered in the project plan was the backing up of test data. A risk assessment was not considered or included in the original project plan, which was an error. The author realised relatively early during the experimentation phase of the project that it was essential to have a verifiable

Page 127 of 151

backup of all of test data in case of a disaster befalling the laptop that contained the original copies of such data. Had a disaster befallen the laptop and the data been lost the project would almost certainly be fatally flawed and considerable time and effort would have to be expended in re-running tests in order to obtain the data again. Saving copies of the project document including online material became more important as the project developed and the risk of losing the data increased. Several copies of the test data were saved on two separate computers in addition to a backup on removable media. During the experimental phase it became apparent that the property store used by Windows Desktop Search was a Jet Blue database. It was only then that research was conducted in order to find a software program that would allow the database to be viewed. The authors lack of knowledge in this area could have been fundamentally improved if this had been identified during the planning stage and time allowed becoming conversant with such databases. Some considerable time was lost whilst the author attempted to find a program that would allow the database to be read. In the end no such program was available. As it turned out a major break through in the project was when Microsoft supplied a viewer for the database through the Law Enforcement portal. Without this, and coupled with the inability of the author to program to sufficiently high standard to be able to write his own application, serious impact on the project overall would have occurred and the valuable artefacts discovered may have not been identified. The literature review part of the project plan was carried out at the initial stage of the project and was allocated a very short period of time. In practice the review actually carried on throughout the project lifetime. A particular example of this was the fact that it was only during December 2008 that the Search Index Examiner by Passware was identified through continuing literature review of the forensic focus web site. The program itself was released on 12th November 2008.

Page 128 of 151

6.3 The Focal Point of the Project

The regular meetings with the project supervisor assisted with maintaining focus during the project year. As the project developed there were several occasions when opportunities arose to be side tracked such as exploring IFilters or the Inverted Index files to name but two. Although these are covered briefly during the project, the major focus was the property store (Windows.edb file) and the Transaction Log file. The author remained largely dedicated to identifying the main features of these files during the project lifetime. In the end focus was mainly maintained through the system of regular contact with the tutor.

6.4 Choice of Tools

As highlighted earlier, the lack of programming ability of the author meant that third party tools had to be relied upon. The ideal solution would have been for a bespoke tool to be written for the task of extracting the data from the Windows.edb file. On reflection had the issue not been resolved with supply of the Microsoft Database Viewer then the value of this project would have been severely undermined. The initial idea to use a hard disc drive to conduct experiments was quickly dropped in favour of using VMware workstation. This proved to be very successful and led to greater flexibility when it came to repeating experiments. The author was able to take snapshots that could at a later date be returned to in order to repeat or amend experiments. Winhex was used as the primary tool for examining the results in detail. This was preferred over normal forensic tools such as Encase due to the greater granularity offered by viewing the data at such a low level as offered by the hex editor.

Page 129 of 151

6.5 Meetings with the Tutor

Meetings with the tutor proved increasingly important during the lifecycle of the project, where refinement and essential attention to detail were required to produce the final report. The meetings helped by not only ensuring that focus was maintained on the core area of the project but also maintaining morale and providing re-assurance. This regular contact with the tutor was welcomed and the author would encourage any students to ensure that they follow suit. One area that could have been improved upon was that the author never maintained any formal notes of the points discussed during the meetings. These could have formed for want of a better description a performance development tool. The report of the points discussed and tasks to be preformed prior to the next meeting may have acted as project development report for future meetings. The tutor did in fact annotate the updated dissertation at each meeting noting development points on it so they form a basis of noting progress against expectations.

6.6 Management of the Project

Notwithstanding the meetings with the tutor, the task of ensuring that the project was delivered lay entirely with the author. At the conclusion it is clear that the greatest resource in terms of completion of the project was time itself. The employer gave support in terms of time to travel to meetings with the project supervisor; however no time was allowed to carry out any of the tasks other than in the authors own time. As has previously been highlighted balancing home and work time together with finding time to complete the project was at times very difficult with each having to take a back seat at various times during the project year. It was felt that had the employer appreciated the significance of the project in terms of the personal and professional development of the author then greater support in terms of time may have been realised.

Page 130 of 151

Time management became particularly stressful in the final few weeks of the project when much refining of the report was being undertaken. Circumstances beyond the control of the author meant that as a result of a murder and robbery enquiry the author was unable to work on the project for a two-week period. Even at such a late stage this caused the author to consider whether the report could be completed and submitted on time.

6.7 The Learning Experience

Despite some low points during the project year, overall it has been a positive experience. Unfamiliarity with the internal structure of databases has been highlighted and with hindsight a greater understanding of this would have resulted in a better result. This was compounded by a lack of programming ability to write an application to parse the various tables that make up the Jet Blue database. These areas of development shouldnt however overshadow the positive aspects of the project. These include the fact that the author thoroughly enjoyed carrying out analysis of the internal structure at disk level. Confidence in the use of Winhex greatly improved and has been used in day-to-day work, as has the use of the VMWare disk mount utility.

6.8 Conclusions

Overall, the project can be considered a success with some caveats needing to be applied. Previously unknown artefacts about the Windows Desktop Search are now available for forensic examiners to use during their investigation. Additional benefits derived from the project for the author included the achievement of several personal goals. One area that the author enjoyed was the fact that confidence in the area of reverse engineering of an application. This was mainly due to the fact that examination of the Windows.edb file was largely conducted in Winhex. Although only vaguely

Page 131 of 151

familiar with the tool at the commencement of the project, by the conclusion the tool was being used routinely in everyday laboratory work.

Page 132 of 151

CHAPTER 7 - Results and Discussion


7.1 Introduction

This chapter shall summarise the results and major conclusions of the project.

7.2 System Architecture

The key research objectives of the project were to establish: 1. What files are created by the application upon installation. 2. What changes to the system Registry are created by the application upon installation. 3. What data is indexed by the application. 4. What traces are there when new content is added to a drive. 5. What traces would be left of indexed contents once the parent material had been deleted. It is felt that those objectives have largely been reached, although there is room for further work. The use Intrl5 during the foundation experiment established which directories and files were created by the installation of the Windows Desktop Search application. Not only were the changes to the system registry monitored but the foundation experiment also identified the registry key where the details of files that had been searched for were saved. The Preview Exercise later corroborated this. The default settings of the indexer were established in addition to the default locations that are indexed.

Page 133 of 151

For the forensic analyst one of the more useful pieces of information that was gleaned during this project were the artefacts identified in respect of the Transaction Log file. Whereas Stewart [19] had identified the file as part of the search indexer, this project put much meat onto the bones of his work. He had left many bytes of the file as unknown. Through experimentation, light has been shed of much of the file. Nonetheless there is still further work to be completed in respect of identify every part of it. Programs such as the Microsoft Database Viewer together with the Passware Search Index Examiner tool have been identified as resources for the forensic examiner. A caveat must be placed on these however, in that it has been empirically proven that file content survives the parent file being deleted and the index updated. The Microsoft tool together with Passwares Search Examiner will produce results for files that are currently indexed. What this research has proven is that pointers to file records are removed incredibly quickly after the indexer is notified of the deletion of the parent file. Therefore if either tool provides details of a file then the file will be in the active file set and should be easily discoverable. The forensic examiner must not totally rely on these tools when examining the Windows.edb file. The most significant discovery was the fact that entries, including file content survived a reindexing of the property store after deletion of a file. Some aspects of the authors original ideas were not met. This was due to the sheer complexity of the structure of the indexer and the time scale of submission of the project. It would have been nice to produce a guide to be made available to the forensic community of the artefacts identified during the project. That may be an assignment to occupy the author now that the project report has been delivered.

Page 134 of 151

7.3 Methodology

The methodology used during the various experimental phases has proven to produce forensically sound results. The use of VMWare together with the snapshot mount utility was another area that the author enjoyed learning about and using during the project and is certainly a very useful tool to have in the tool box for day-to-day forensic analysis work.

The Future

Far from concluding the research of the Windows Desktop Search is only the start. This project has identified a number of further areas of future research the most critical being a solution to being able to extract the content of deleted files that remain in the index. The research at present would indicate that the pointers to a file are deleted, but the file meta data and content are not. Further experimentation is required to establish the longevity of such data and whether the index uses the space previously occupied by the deleted files immediately. The possibility of examining the property store of the Windows Desktop Search is becoming more relevant with the proliferation of wiping tools whereby original files are being securely deleted and unallocated clusters wiped.

7.4 Conclusions

Just as computing technology, such as desktop search indexers are constantly evolving, so must the forensic analysis of artefacts produced by such applications be kept up to date. Research has shown that such indexers cached copies of files independent of the operating system

Page 135 of 151

The project has clearly demonstrated that there are potentially numerous indexed artefacts to be recovered by a forensic analyst. The possibility offered by applications such as Passwares Search Indexer tool or fellow Cranfield Student, John Douglass WDS Analyser should lead to further research in this area. Passware have clearly been able to circumvent the obfuscation used by the application; however the tool as it currently stands does not recover deleted entries or content. Although not covered in this project the Microsoft Vista operating system Volume Shadow Copy provides the forensic community with the potential to recover previous Windows.edb files. Any of the above tools could therefore be used to view he contents of the file and provide a timeline in respect of the index content. One final observation that is worthy of note is that this project has highlighted that reliance on automated tools may result in vital evidence being missed. A salutary lesson for those who practice Nintendo forensics.

Page 136 of 151

References
[1] IDC, The Hiddencosts on Information Work, [Online], 2007, Available at http://factiva.com/collateral/files/whitepaper _IDC_hiddencosts_0405.pdf [2] EMC, 2007, Expanding Digital Universe, [Online] Available at http://uk.emc.com/leadership/digital-universe/expanding-digitaluniverse.htm?CMP=ILC-carHP&panel=our+digital+universe [3] Google Desktop Search, Information when you want it, right on your desktop 2007, [Online] Available at http://desktop.google.com [4] Filehawk, The File Organiser, [Online] Available at http://www.filehawk.com/ [5] Copernic Search Engine, The Desktop Search Solution youve been looking for, [Online] Available http://www.copernic.com/ [6] Webster's New Collegiate Dictionary, Definition of Science, [Online] Available from http://www.merriam-webster.com/dictionary/science [7] Encarta Online Dictionary, Definition of Science, [Online] Available from http://encarta.msn.com/encyclopedia_761557105/Science.html [8] Casey, E. (2004). Digital Evidence and Computer Crime. San Diego: Academic Press [9] Digital Forensic Research Workshop, A Road Map for Digital Forensic Research, Available at http://www.dfrws.org/2001/dfrws-rm-final.pdf [10] TheJo/Blog, Desktop Search comparison [Online] http://thejo.in/2005/01/desktopsearch-comparison/

Page 137 of 151

[11] MSDN Search Forum , Windows Desktop Search Development,[Online] http://forums.microsoft.com/msdn/showforum.aspx?forumid=127&siteid=1 [12] Brandon Paddocks Online Journal, Brandon Live, [Online], http://brandonlive.com/ [13] Turnbull, Slay and Blundell, Googling Forensics, School of Computer and Information Science, Edith Cowan University. Available at www.scissec.scis.ecu.edu.au/conference_proceedings/ 2005/forensics/turnbull.pdf [14] B. Turnbull, B. Blundell, and J. Slay, Google desktop as a source of digital evidence, International Journal of Digital Evidence, vol. 5, no. 1, pp. 1-12, 2006 [15] File Monitor, http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx [16] Registry Monitor, http://technet.microsoft.com /en-us/sysinternals/bb896642.aspx [17] T Pavlic, J Slay, B Turnbull, Developing a Process Model for the Forensic Extraction of Information from Desktop Search Applications, Journal of Digital Forensics, Security and Law, Volume 3 [18] Pavlic, T, Slay, J, Turnbull, B, 2008, Google Desktop Search Evidence Collector: The development of a proof-of-concept application for the forensically sound extraction of electronic evidence from Google Desktop Search , 4th Annual IFIP Working Group 11.9 International Conference on Digital Forensics, January 27-30, 2008, Kyoto, Japan, [19] Stewart B. Forensic implications of Windows vista, MSc thesis, University of Strathclyde; 2007 [20] Microsoft Developer Network, FILETIME structure, http://msdn.microsoft.com/en-us/library/ms724284(VS.85).aspx [21] Guidance Software Support Portal Forum, EnCase Users Group, [Online] https://support.guidancesoftware.com/forum/forumdisplay.php?f=8

Page 138 of 151

[22] Digital Detective Bulletin Board, Computer and Digital Forensics, [Online] http://www.digital-detective.co.uk/cgi-bin/digitalboard/YaBB.pl [23] Access Data Bulletin Board, [Online] http://forums.accessdata.com/ [24] Spotlight Desktop search for Macs, [Online] http://www.apple.com/macosx/features/300.html#spotlight [25] Saunders, M., Lewis, P., Thornhill, A. (2000). Research Methods for Business Students.Prentice Hall: FT. [26] Defence Computer Forensic Laboratory dd, dcfldd, Available at http://dcfldd.sourceforge.net/ [27] e-fense, Helix Incident Response and Computer Forensic Bootdisk, Available at http://www.e-fense.com/helix/ [28] Inctrl5, Available at home.planet.nl/~pa0joz/pc_util.html [29] Process Monitor, Available at http://technet.microsoft.com/enus/sysinternals/bb896645.aspx [30] Guidance Software, EnCase Forensic Edition, Available at http://www.digitalintelligence.com/software/guidancesoftware/encase/ [31] Access Data, Access Data Registry Viewer, Available at http://www.accessdata.com/media/en_us/print/techdocs/Registry%20Viewer.pdf [32] VMWare Workstation, Available at http://www.vmware.com/

Page 139 of 151

[33] Digital Detective, Decode Software, Available at http://www.digitaldetective.co.uk/freetools/decode.asp [34] Microsoft Developers Network, Extensible Storage Engine, Available at http://msdn.microsoft.com/en-us/library/ms684493.aspx [35] Oakleaf Blog, Red vs. Blue JET Database API Confusion, Available at http://oakleafblog.blogspot.com/2006/07/red-vs-blue-jet-database-api-confusion.html [34] VMWare, VMWare Disk Mount Users Guide, Available at www.vmware.com/pdf/VMwareDiskMount.pdf [35] Smith, D 2008, email, 4th Sep, diasmith@microsoft.com [36] Microsoft Technet, The Exchange Database Utilities, available at http://technet.microsoft.com/en-us/library/aa998249.aspx [37] Microsoft Developers Network, Enterprise Search Protocol Handlers, Available at http://msdn.microsoft.com/en-us/library/aa981260.aspx [38] Microsoft Download Centre, Good Citizenship when developing background services for Windows Vista. Available at http://www.microsoft.com/downloads/details.aspx?FamilyID=F8E87C7D-9404-491492AE-DDE09389A64E&displaylang=en [39] Microsoft Developers Network, iFilters, Available at http://msdn.microsoft.com/en-us/library/ms691105.aspx [40] Microsoft Developers Network, Developing Filters for Windows Search, [Online] Available at http://msdn.microsoft.com/en-us/library/bb266533(VS.85,printer).aspx

Page 140 of 151

[41] Microsoft Developers Network, Change Journal Changes, Available at http://msdn.microsoft.com/en-us/library/aa363803.aspx [42] Microsoft Search, Frequently Asked Questions, [Online] Available at http://www.microsoft.com/windows/products/winfamily/desktopsearch/technicalresourc es/techfaq.mspx

Page 141 of 151

Bibliography
Posey, B., 2005, The Security Risks of Desktop Searches, Windows Security. Com, available online at www.windowssecurity.com

Page 142 of 151

Appendices
Appendix A File Dump Output
Microsoft(R) Windows(TM) Database UtilitiesVersion 5.1Copyright (C) Microsoft Corporation. All Rights Reserved.Initiating FILE DUMP mode... Database: G:\WDS Test1\Test Data\windows.edb ******************************* META-DATA DUMP ******************************* Name Type ObjidFDP PgnoFDP ============================================================================== G:\WDS Test1\Test Data\windows.edb Db 1 1 MSysObjects Name RootObjects MSysObjectsShadow SystemIndex_0A ISystem_ApplicationName ISystem_Audio_ChannelCount ISystem_Audio_EncodingBitrate ISystem_Author ISystem_Calendar_Duration ISystem_Calendar_IsRecurring ISystem_Calendar_Location ISystem_Calendar_ReminderTime ISystem_Calendar_Resources ISystem_Calendar_ShowTimeAs ISystem_Calendar_ShowTimeAsText ISystem_Communication_AccountName ISystem_Communication_TaskStatus ISystem_Communication_TaskStatusText ISystem_ComputerName ISystem_Contact_Anniversary ISystem_Contact_AssistantName ISystem_Contact_AssistantTelephone ISystem_Contact_Birthday ISystem_Contact_BusinessAddressCity ISystem_Contact_BusinessAddressCountry ISystem_Contact_BusinessAddressPostalCode ISystem_Contact_BusinessAddressPostOfficeBox ISystem_Contact_BusinessAddressState ISystem_Contact_CompanyMainTelephone ISystem_Contact_EmailAddress ISystem_Contact_EmailAddress2 ISystem_Contact_EmailAddress3 ISystem_Contact_EmailAddresses ISystem_Contact_EmailName ISystem_Contact_FirstName ISystem_Contact_FullName ISystem_Contact_Gender ISystem_Contact_Hobbies ISystem_Contact_HomeAddressCity ISystem_Contact_HomeAddressCountry ISystem_Contact_HomeAddressPostalCode ISystem_Contact_HomeAddressPostOfficeBox ISystem_Contact_HomeAddressState ISystem_Contact_HomeFaxNumber ISystem_Contact_HomeTelephone ISystem_Contact_IMAddress ISystem_Contact_JobTitle ISystem_Contact_Label ISystem_Contact_LastName ISystem_Contact_MiddleName ISystem_Contact_MobileTelephone ISystem_Contact_NickName ISystem_Contact_OfficeLocation ISystem_Contact_PagerTelephone Tbl Idx Idx Tbl Tbl Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx 2 4 5 3 16 210 202 180 112 47 176 33 127 71 131 70 63 96 116 160 61 91 69 206 32 164 43 80 189 42 150 188 41 149 84 68 67 79 158 115 126 184 163 106 60 40 78 141 170 217 157 125 175 148 156 4 7 10 24 869 749 741 719 962 900 715 886 250 921 254 920 913 946 966 499 911 941 919 745 885 503 896 930 728 895 473 727 894 472 934 918 917 929 481 965 249 723 502 956 910 893 928 464 509 756 480 248 714 471 479

Page 143 of 151

ISystem_Contact_PersonalTitle ISystem_Contact_PrimaryAddressCity ISystem_Contact_PrimaryAddressCountry ISystem_Contact_PrimaryAddressPostalCode ISystem_Contact_PrimaryAddressPostOfficeBox ISystem_Contact_PrimaryAddressState ISystem_Contact_PrimaryEmailAddress ISystem_Contact_PrimaryTelephone ISystem_Contact_Profession ISystem_Contact_SpouseName ISystem_Contact_Suffix ISystem_Contact_WebPage ISystem_ContentStatus ISystem_DateAccessed ISystem_DateAcquired ISystem_DateArchived ISystem_DateCompleted ISystem_DateCreated ISystem_DateImported ISystem_DateModified ISystem_Document_ClientID ISystem_Document_Contributor ISystem_Document_DateCreated ISystem_Document_DatePrinted ISystem_Document_DateSaved ISystem_Document_Division ISystem_Document_LastAuthor ISystem_Document_Manager ISystem_Document_RevisionNumber ISystem_Document_WordCount ISystem_DueDate ISystem_EndDate ISystem_FileAttributes ISystem_FileExtension ISystem_FileName ISystem_FileOwner ISystem_FlagColor ISystem_FlagColorText ISystem_FlagStatus ISystem_FlagStatusText ISystem_Image_BitDepth ISystem_Image_CompressionText ISystem_Image_Dimensions ISystem_Importance ISystem_ImportanceText ISystem_IsDeleted ISystem_IsRead ISystem_IsShared ISystem_ItemAuthors ISystem_ItemDate ISystem_ItemFolderNameDisplay ISystem_ItemFolderPathDisplay ISystem_ItemFolderPathDisplayNarrow ISystem_ItemName ISystem_ItemNameDisplay ISystem_ItemParticipants ISystem_ItemPathDisplay ISystem_ItemType ISystem_ItemTypeText ISystem_ItemUrl ISystem_Journal_EntryType ISystem_Keywords ISystem_Kind ISystem_KindText ISystem_Language ISystem_Link_TargetParsingPath ISystem_Link_TargetSFGAOFlags ISystem_Media_DateEncoded ISystem_Media_DateReleased ISystem_Media_Duration ISystem_Media_Producer ISystem_Media_Publisher

Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx

147 146 216 99 77 205 215 62 169 59 168 114 159 220 179 153 200 209 178 199 83 203 162 154 167 122 139 75 145 183 134 54 193 192 53 51 219 111 86 26 144 152 182 82 198 110 72 81 177 98 118 50 25 34 172 48 52 197 133 208 76 117 166 207 165 35 64 87 21 173 20 66

470 469 755 949 927 744 754 912 508 909 507 964 498 759 718 476 739 748 717 738 933 742 501 477 506 245 462 925 468 722 457 904 732 731 903 237 758 961 936 879 467 475 721 932 737 960 922 931 716 948 968 236 878 887 511 901 902 736 256 747 926 967 505 746 504 888 914 937 874 512 873 916

Page 144 of 151

ISystem_Media_SubTitle ISystem_Media_Writer ISystem_Media_Year ISystem_Message_AttachmentNames ISystem_Message_BccAddress ISystem_Message_BccName ISystem_Message_CcAddress ISystem_Message_CcName ISystem_Message_ConversationID ISystem_Message_ConversationIndex ISystem_Message_DateReceived ISystem_Message_DateSent ISystem_Message_FromAddress ISystem_Message_FromName ISystem_Message_HasAttachments ISystem_Message_IsFwdOrReply ISystem_Message_SenderAddress ISystem_Message_SenderName ISystem_Message_ToAddress ISystem_Music_AlbumArtist ISystem_Music_AlbumTitle ISystem_Music_Artist ISystem_Music_BeatsPerMinute ISystem_Music_Composer ISystem_Music_Conductor ISystem_Music_Genre ISystem_Music_InitialKey ISystem_Music_Mood ISystem_Music_Period ISystem_Music_TrackNumber ISystem_Note_Color ISystem_Note_ColorText ISystem_ParentalRating ISystem_ParsingName ISystem_Photo_CameraManufacturer ISystem_Photo_CameraModel ISystem_Photo_ContrastText ISystem_Photo_DateTaken ISystem_Photo_Event ISystem_Photo_ExposureProgram ISystem_Photo_ExposureProgramText ISystem_Photo_ExposureTime ISystem_Photo_Flash ISystem_Photo_FlashText ISystem_Photo_FNumber ISystem_Photo_FocalLength ISystem_Photo_GainControlText ISystem_Photo_ISOSpeed ISystem_Photo_MeteringModeText ISystem_Photo_OrientationText ISystem_Photo_PhotometricInterpretationText ISystem_Photo_ProgramModeText ISystem_Photo_SaturationText ISystem_Photo_SharpnessText ISystem_Photo_WhiteBalanceText ISystem_Priority ISystem_PriorityText ISystem_Project ISystem_ProviderItemID ISystem_Rating ISystem_RatingText ISystem_RecordedTV_ChannelNumber ISystem_RecordedTV_DateContentExpires ISystem_RecordedTV_EpisodeName ISystem_RecordedTV_OriginalBroadcastDate ISystem_RecordedTV_RecordingTime ISystem_RecordedTV_StationCallSign ISystem_RecordedTV_StationName ISystem_Search_GatherTime ISystem_Sensitivity ISystem_SensitivityText ISystem_SFGAOFlags

Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx Idx

37 27 19 140 23 31 39 46 105 108 130 124 90 95 155 89 123 104 103 65 212 195 211 194 18 56 201 44 74 36 30 204 218 85 129 138 22 45 107 29 137 88 174 121 102 181 214 58 94 213 38 136 49 57 28 143 128 196 97 132 109 135 187 101 120 93 119 186 73 24 191 92

890 880 872 463 876 884 892 899 955 958 253 247 940 945 478 939 246 954 953 915 751 734 750 733 871 906 740 897 924 889 883 743 757 935 252 461 875 898 957 882 460 938 713 244 952 720 753 908 944 752 891 459 235 907 881 466 251 735 947 255 959 458 726 951 243 943 242 725 923 877 730 942

Page 145 of 151

ISystem_Shell_OmitFromView Idx 161 500 ISystem_Size Idx 185 724 ISystem_SourceItem Idx 171 510 ISystem_StartDate Idx 190 729 ISystem_Status Idx 151 474 ISystem_Task_CompletionStatus Idx 113 963 ISystem_ThumbnailCacheId Idx 142 465 ISystem_Title Idx 100 950 ISystem_Video_FrameRate Idx 55 905 I__SDID Idx 17 870 SystemIndex_0P Tbl 15 769 SystemIndex_DeletedDocIds Tbl 225 1281 SystemIndex_DeletedDocIds_S Tbl 306 2049 docidShadowIdx Idx 307 2050 SystemIndex_Gthr Tbl 11 513 indexDocId Idx 12 514 SystemIndex_GthrPth Tbl 8 257 SystemIndex_GthrPth_S Tbl 300 613 pathShadowIdx Idx 301 614 SystemIndex_Gthr_RecCount Tbl 7 133 SystemIndex_Gthr_S Tbl 302 1125 gatherShadowIdx Idx 303 1126 SystemIndex_MaxDoc Tbl 221 1025 maxdocMainIdx Idx 222 1026 SystemIndex_MaxDoc_S Tbl 304 1381 maxdocShadowIdx Idx 305 1382 __NameTable__ Tbl 6 33 ****************************************************************************** Operation completed successfully in 1.109 seconds.

Page 146 of 151

Appendix B Passware Search Index Examiner

Passware Search Indexer In December 2008, the author became aware that in 13th November 2008 [] the forensic focus web site had posted details of a new tool being launched by Passware, a company best known for cryptographic cracking applications [].

Figure 48 Screenshot from Passware Web Site

Page 147 of 151

Tantalisingly their sales documentation claims to be able to recover files deleted from the file system, but not yet deleted from the index. A demo was downloaded from their web site and tested against some of the Windows.edb files created during the experimental phase of the project. Due to the very late awareness of the tool no in depth experimentation was conducted with it, and so this section shall just be able to provide a very brief overview. Data added to the system. The Windows.edb file created after the 5 text documents were added to the index was opened using the passware search indexer. The *.xls file output option was selected and it was noted that a folder named search auto summary was created in the selected output directory. Examination of this directory revealed that it contained a *.csv file that recorded the details of the files added to the database. In addition to the fields identified during this project the System_ItemTypeText field was populated as was the System_ItemName field revealing that Passware appear to have been able to read the obfuscated data. This was confirmed when the folder search_auto_summary was viewed. The tool had also exported copies of the text documents that had been added to the index. The documents which were named by their respective DocID number were in clear text. It is therefore apparent that Passware have been able to parse the Windows.edb file and un-obfuscate the text files within it.

Page 148 of 151


Figure 49 View of output of Passwares Search Index Examiner

Example Text File The text file 6.txt was opened and it was seen that it contained the following information: DocID = 6 System_FileAttributes = 32 System_FileExtension = .txt System_FileName = Ye Jacobites by name.txt System_DateCreated = 30/11/2008 16:08:27 System_DateModified = 30/11/2008 16:08:27 System_ItemFolderPathDisplay = c:\Documents and Settings\WDS Test\My Documents System_ItemName = Ye Jacobites by name.txt System_ItemTypeText = Text Document System_Size = 865 System_Search_AutoSummary =
Ye Jacobites by name, give an ear, give an ear, Ye Jacobites by name, give an ear, Ye Jacobites by name, Your fautes I will proclaim, Your doctrines I maun blame, you shall hear.

Page 149 of 151

The full text of the document was extracted from the System_Search_AutoSummary Field. In addition it can be seen that many of the fields that appeared obfuscated when viewed by the Microsoft Database Viewer were in plain text. Data Deleted from the Indexer The Windows.edb file that was created during the file deletion experiment was opened with the passware search indexer. The file Bannockburn.txt (DocID 6) had been deleted from the index and yet the index detail of the file including the obfuscated content was still viewable with Winhex. Examination of the output of the Search Index Examiner revealed that it failed to display the deleted file.

Figure 50 File Deletion Test Output Search Index Examiner

The author contacted Passware [] who claimed that if the document is no longer visable via Microsoft API, the full version of our product wont export it either. Our software does not depend on Microsoft Search API, it reads the database directly. However the software will not undelete database records (at least in the current version of the software). The software will display auto summary for documents that were deleted from the file system, but not from the Windows Search database. The interesting point is that experiments carried out during this project have shown that when a file is deleted from the file system, the Search Index is updated almost instantaneously. The point made in Passwares literature is accurate (if the file is still in the index although deleted from the file system) but unlikely.

Page 150 of 151

Conclusions From the brief view Passwares Search Index Examiner tool appears to be able to extract the database entries for files within the Windows.edb file. Interestingly the obfuscation used in amongst others the System_Search_AutoSummary field has been circumvented. It has still to be able to extract the details of files that have been deleted from the index but nonetheless remain present.

Page 151 of 151

You might also like