Difference between pages "User:Helixgroup" and "Prefetch"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
(Suggestion of outline :)
 
(Volume)
 
Line 1: Line 1:
''The danger in using a wiki as a collaboration tool is that other people will edit it.  
+
{{Expand}}
 +
Windows Prefetch files, introduced in [[Windows|Windows XP]], are designed to speed up the application startup process. Prefetch files contain the name of the executable, a Unicode list of DLLs used by that executable, a count of how many times the executable has been run, and a timestamp indicating the last time the program was run. Although Prefetch is present in Windows 2003, by default it is only enabled for boot prefetching. The feature is also found in [[Windows Vista]], where it has been augmented with [[SuperFetch]], [[ReadyBoot]], and [[ReadyBoost]].
  
Information on cryptographic file system was moved to [[File Systems#Cryptographic File Systems]]
+
Up to 128 Prefetch files are stored in the <tt>%SystemRoot%\Prefetch</tt> directory [http://blogs.msdn.com/ryanmy/archive/2005/05/25/421882.aspx]. Each file in that directory should contain the name of the application (up to eight (?) characters), a dash, and then an eight character hash of the location from which that application was run, and a <tt>.pf</tt> extension. The filenames should be all uppercase except for the extension. The format of hashes is not known. A sample filename for [[md5deep]] would look like: <tt>MD5DEEP.EXE-4F89AB0C.pf</tt>. If an application is run from two different locations on the drive (i.e. the user runs <tt>C:\md5deep.exe</tt> and then <tt>C:\Apps\Hashing\md5deep.exe</tt>), there will be two different prefetch files in the Prefetch folder.
  
  
 +
== Signature ==
 +
Each Prefetch file has a signature in the first 8 bytes of the file. Windows XP and Windows Vista will generate Prefetch files with the signature \x11\x00\x00\x00\x53\x43\x43\x41 (0x41434353 0x00000011). Windows 7 Prefetch file's signature is \x17\x00\x00\x00\x53\x43\x43\x41 (0x41434353 0x00000017). The [http://en.wikipedia.org/wiki/ASCII ASCII] representation of these bytes will display "....SCCA".
  
=== Vendor's product overview: ===
+
== Timestamps ==
Seagate FDE: http://www.seagate.com/docs/pdf/marketing/PO-Momentus-FDE.pdf
+
  
Network Appliance: http://www.netapp.com/ftp/decru-fileshredding.pdf
+
Both the [[NTFS]] timestamps for a Prefetch file and the timestamp embedded in each Prefetch file contain valuable information. The timestamp embedded within the Prefetch file is a 64-bit (QWORD) [http://msdn2.microsoft.com/en-us/library/ms724284.aspx FILETIME] object The creation date of the file indicates the first time the application was executed. Both the modification date of the file and the embedded timestamp indicate the last time the application was executed.
  
NetApps DataFort: http://www.decru.com/products/pdf/dsEseries.pdf
+
Windows will store timestamps according to Windows [http://msdn.microsoft.com/en-us/library/ms724290%28VS.85%29.aspx epoch].
  
Decru Lifetime Key Management: http://www.decru.com/products/ltkm.htm
+
==== Creation Time ====
 +
The creation time does not have a static offset on any Windows platform. The location of the creation time can be found using the offset 0x8 + length of Volume path offset.
  
Decru Whitepaper: http://www.forensicswiki.org/images/6/6f/Securing_Storage_White_Paper.pdf
+
==== Last Run Time ====
 +
A timestamp of when the application was last ran is embedded into the Prefetch file. The offset to the "Last Run Time" is located at offset 0x78 from the beginning of the file on [[Windows]] XP. The offset for Windows Vista and Windows 7 is at 0x80.  
  
Price for Decru DataFort E510 1.6 for NAS: http://infosecuritymag.techtarget.com/ss/0,295796,sid6_iss346_art680,00.html
+
== MetaData ==
 +
==== Header ====
 +
In each Prefetch file, the size of the header is stored and can be found at offset 0x54 on Windows XP, Windows Vista, and Windows 7. The header size for Windows XP is 0x98 (152) and 0xf0 (240) on Windows Vista and Windows 7.
  
DecruDataFort E440: http://www.computerworld.com/hardwaretopics/storage/story/0,10801,78766,00.html
+
The Prefetch file will embed the application's name into the header at offset 0x10.
  
[[User:Lenageraghty|Lenageraghty]] 22:08, 7 November 2005 (EST)
+
==== Run Count ====
 +
The run count, or number of times the application has been run, is a 4-byte (DWORD) value located at offset 0x90 from the beginning of the file on [[Windows]] XP. On Windows Vista and Windows 7, the run time can be found at 0x98.
  
=== SAM Useful TCFS site: ===
+
==== Volume ====
 +
Volume related information, volume path and volume serial number, are embedded into the Prefetch file. The precise offset for this information varies for each application ran. In the header at offset 0x6c, the location of the volume path is stored. The location is a 4-bytes (DWORD) value. The offset 0x6c is consistent for Windows XP and Windows 7.
  
Transparent CryptoGraphical file system: http://www.tcfs.it/index.php?pc=2
+
At the location given from 0ffst 0x6c, a 4 byte value is stored which is the number of bytes from current offset (location from offset 0x6c) to the beginning of the volume path. The location from offset 0x6c, for ease, will be called the "volume path offset." The volume path is embedded as a NULL-terminating string.
  
TCFS intro: http://www.linuxjournal.com/article/2174
+
The length of the volume path is a 4-byte value is located at volume path offset + 0x4.
  
--[[User:Samlam|Samlam]] 19:56, 13 November 2005 (EST)
+
The volume [http://en.wikipedia.org/wiki/Volume_serial_number serial number] is a 4-byte value that identifies a media storage. A serial number does not have a consistent offset within a Prefetch between Windows operating systems. The 4-byte value can be found eight (8) bytes from the creation time location.
  
=== ERIC Seagate new offerings: ===
+
== Issues ==
Full Disk Encryption: http://www.eweek.com/article2/0,1759,1825740,00.asp
+
==== End of File ====
 +
Prefetch files generated by the Windows operating system does not have any signature or sequences of bytes to indicate when the end of the Prefetch file has been reached.
  
Seagate product specification: http://www.seagate.com/content/docs/pdf/marketing/PO-Momentus-FDE.pdf
+
== See Also ==
 +
* [[SuperFetch]]
 +
* [[Prefetch XML]]
  
 
+
== External Links ==
[[User:Samlam|Samlam]] 12:10, 13 November 2005 (EST)
+
* [http://milo2012.wordpress.com/2009/10/19/windows-prefetch-folder-tool/ Prefetch-Tool Script] - Python looks Prefetch files up on a web server.
 
+
* [http://www.mitec.cz/wfa.html Windows File Analyzer] - Parses Prefetch files, thumbnail databases, shortcuts, index.dat files, and the recycle bin
=== Cryptographcial File Systems: ===
+
* [http://www.microsoft.com/whdc/driver/kernel/XP_kernel.mspx#ECLAC Microsoft's description of Prefetch when Windows XP was introduced]
[[File Systems#Cryptographic File Systems]] Readings on crytographical file systems.
+
* [http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/default.aspx More detail from Microsoft]
=== Some Questions / Notes from BJ===
+
* [http://www.tzworks.net/prototype_page.php?proto_id=1 Windows Prefetch parser] Free tool that can be run on Windows, Linux or Mac OS-X.
I added to the existing outline below. We only get 15 pages max, so we might have to limit ourselves to 2 pages (3 tops) per EFS, so there might be too many items for each EFS listed, but I think it would be good for us to be consistent and have the same items in each EFS.
+
 
+
I think we should start filling out what we can in the outline during this week, so that we can "refine as we go". 
+
 
+
Please make sure and add your citations, also.  Do not worry about format; we will do that later; but make sure all the information is there.
+
 
+
=== Suggestion of outline : ===
+
*Introduction (BJ)
+
**Definition of an Encrypting File System
+
**Purpose/Goal of an EFS
+
***Purpose: to add an additional layer of security, controlled by the user, over that user's data
+
***Goal: to allow users to feel confident the data placed in the EFS cannot be compromised.
+
**Overview of General Workings
+
***(description of common functionality and common processes to all or most EFS)
+
***You have data in memory, you want to save it to disk, you only want "authorized" people to see it; not even system administrators and/or backup operators
+
***You control access by "owning" the key
+
***Key is generated (somehow)
+
***There is overhead in the process of encrypting/decrypting (unavoidable)
+
**Overview of Common Usage
+
***Maybe some categories of users and what they are looking for:
+
***"business critical applications" like databases, etc. where business relies on data being available and secure
+
***"business users" like managers who want to secure employee reviews, HR people wanting to secure salary information, etc.
+
***"casual users" people who just want to make sure their data is secure.
+
**The currently available systems (market share?)
+
**Why we choose CFS TCFS and Network Applicances
+
*Study of 4 systems in depth, including why this system is selected for study.
+
**CFS (LENA)
+
***Overview
+
****When Developed
+
****Platform(s)
+
****Current Version
+
***Key Management
+
***Ease of Use for End Users
+
***Legal Issues
+
***Failure Modes
+
***Challenges in Installation/Use by System Administrator
+
***Performance
+
***Cost
+
***Conclusion (?? what would that be??)
+
**TCFS (SAM)
+
***Overview
+
****When Developed
+
****Platform(s)
+
****Current Version
+
***Key Management
+
***Ease of Use for End Users
+
***Legal Issues
+
***Failure Modes
+
***Challenges in Installation/Use by System Administrator
+
***Performance
+
***Cost
+
***Conclusion (?? what would that be??)
+
**Network Appliance DataForte and Seagate (ERIC)
+
***Overview
+
****When Developed
+
****Platform(s)
+
****Current Version
+
***Key Management
+
***Ease of Use for End Users
+
***Legal Issues
+
***Failure Modes
+
***Challenges in Installation/Use by System Administrator
+
***Performance
+
***Cost
+
***Conclusion (?? what would that be??)
+
**Windows EFS (BJ)
+
***Overview
+
****When Developed
+
****Platform(s)
+
****Current Version
+
***Key Management
+
***Ease of Use for End Users
+
***Legal Issues
+
***Failure Modes
+
***Challenges in Installation/Use by System Administrator
+
***Performance
+
***Cost
+
***Conclusion (?? what would that be??)
+
*Common Issues/Problems (ALL)
+
**Impact on computer forensics
+
**Impact on end-users (i.e. what if you are away on a business trip and you have to go to the hospital and all of your files are encrypted on your laptop?) (or even worse, what if you die and all your financial information is encrypted?)
+
**Impact on business owners (e.g. what if an employee quits and all that person's data files, contact info, etc. are encrypted)
+
*Future (ALL)
+
**What would be useful to add or remove
+
**How we would accomplish the changes we suggest
+
*Conclusion. (ALL)
+
 
+
[[User:Bjl170|Bjl170]] 20:23, 14 November 2005 (EST)
+
 
+
[[User:Lenageraghty|Lenageraghty]] 08:36, 11 November 2005 (EST)
+
 
+
=== Questions : ===
+
* What systems are currently available ?
+
 
+
[[User:Lenageraghty|Lenageraghty]] 08:48, 11 November 2005 (EST)
+
 
+
=== Suggestions/Questions/Outline ?: ===
+
* Solutions from other storage vendors.
+
* Desirable features for a cryptographical file system.
+
* cost
+
** performance
+
** total solution for end-users
+
** Key management for cryptographical file system
+
** Ease of use by end-users
+
** Failure modes
+
** Challenges in using/installing
+
 
+
[[User:Lenageraghty|Lenageraghty]] 22:48, 7 November 2005 (EST)
+
 
+
===== comment from TA (Joe)  =====
+
That looks like some of the right inroads.  Remember that the paper is
+
not very long, so you may want to focus on the three systems and do a
+
deep analysis.  Certainly some things to think about:
+
      Simson's lecture where he talked about it
+
      Failure modes of such systems
+
      Challenges in using/installing
+
 
+
''comment from teacher:'' Please remember that this Wiki is publically accessible on the Internet. It's great if you can improve the resource for everbody. But do try to do that, rather than just creating your own space...
+

Revision as of 18:52, 2 July 2011

Information icon.png

Please help to improve this article by expanding it.
Further information might be found on the discussion page.

Windows Prefetch files, introduced in Windows XP, are designed to speed up the application startup process. Prefetch files contain the name of the executable, a Unicode list of DLLs used by that executable, a count of how many times the executable has been run, and a timestamp indicating the last time the program was run. Although Prefetch is present in Windows 2003, by default it is only enabled for boot prefetching. The feature is also found in Windows Vista, where it has been augmented with SuperFetch, ReadyBoot, and ReadyBoost.

Up to 128 Prefetch files are stored in the %SystemRoot%\Prefetch directory [1]. Each file in that directory should contain the name of the application (up to eight (?) characters), a dash, and then an eight character hash of the location from which that application was run, and a .pf extension. The filenames should be all uppercase except for the extension. The format of hashes is not known. A sample filename for md5deep would look like: MD5DEEP.EXE-4F89AB0C.pf. If an application is run from two different locations on the drive (i.e. the user runs C:\md5deep.exe and then C:\Apps\Hashing\md5deep.exe), there will be two different prefetch files in the Prefetch folder.


Signature

Each Prefetch file has a signature in the first 8 bytes of the file. Windows XP and Windows Vista will generate Prefetch files with the signature \x11\x00\x00\x00\x53\x43\x43\x41 (0x41434353 0x00000011). Windows 7 Prefetch file's signature is \x17\x00\x00\x00\x53\x43\x43\x41 (0x41434353 0x00000017). The ASCII representation of these bytes will display "....SCCA".

Timestamps

Both the NTFS timestamps for a Prefetch file and the timestamp embedded in each Prefetch file contain valuable information. The timestamp embedded within the Prefetch file is a 64-bit (QWORD) FILETIME object The creation date of the file indicates the first time the application was executed. Both the modification date of the file and the embedded timestamp indicate the last time the application was executed.

Windows will store timestamps according to Windows epoch.

Creation Time

The creation time does not have a static offset on any Windows platform. The location of the creation time can be found using the offset 0x8 + length of Volume path offset.

Last Run Time

A timestamp of when the application was last ran is embedded into the Prefetch file. The offset to the "Last Run Time" is located at offset 0x78 from the beginning of the file on Windows XP. The offset for Windows Vista and Windows 7 is at 0x80.

MetaData

Header

In each Prefetch file, the size of the header is stored and can be found at offset 0x54 on Windows XP, Windows Vista, and Windows 7. The header size for Windows XP is 0x98 (152) and 0xf0 (240) on Windows Vista and Windows 7.

The Prefetch file will embed the application's name into the header at offset 0x10.

Run Count

The run count, or number of times the application has been run, is a 4-byte (DWORD) value located at offset 0x90 from the beginning of the file on Windows XP. On Windows Vista and Windows 7, the run time can be found at 0x98.

Volume

Volume related information, volume path and volume serial number, are embedded into the Prefetch file. The precise offset for this information varies for each application ran. In the header at offset 0x6c, the location of the volume path is stored. The location is a 4-bytes (DWORD) value. The offset 0x6c is consistent for Windows XP and Windows 7.

At the location given from 0ffst 0x6c, a 4 byte value is stored which is the number of bytes from current offset (location from offset 0x6c) to the beginning of the volume path. The location from offset 0x6c, for ease, will be called the "volume path offset." The volume path is embedded as a NULL-terminating string.

The length of the volume path is a 4-byte value is located at volume path offset + 0x4.

The volume serial number is a 4-byte value that identifies a media storage. A serial number does not have a consistent offset within a Prefetch between Windows operating systems. The 4-byte value can be found eight (8) bytes from the creation time location.

Issues

End of File

Prefetch files generated by the Windows operating system does not have any signature or sequences of bytes to indicate when the end of the Prefetch file has been reached.

See Also

External Links