Difference between pages "Windows Prefetch File Format" and "GRR"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
 
(Publications)
 
Line 1: Line 1:
A Windows Prefetch file consists of one file header and multiple file sections with different content. Not all content has an obvious forensic value.
+
{{Infobox_Software |
 +
  name = Rekall |
 +
  maintainer = [[Darren Bilby]] and others |
 +
  os = {{Cross-platform}} |
 +
  genre = {{Incident response}} |
 +
  license = {{APL}} |
 +
  website = [https://code.google.com/p/grr/ code.google.com/p/grr/] |
 +
}}
  
As far as have been possible to ascertain, there is no public description of the format. The description below has been synthesised from examination
+
GRR is an Incident Response Framework focused on Remote Live Forensics.
of multiple prefetch files.
+
  
== Characteristics ==
+
= See also =
Integer values are stored in little-endian.
+
* [[rekall]]
Strings are stored as UTF-16 little-endian without a byte-order-mark (BOM).
+
Timestamps are stored as Windows Filetime.
+
  
== Header ==
+
= External Links =
 +
* [https://code.google.com/p/grr/ Project site]
 +
* [https://code.google.com/p/grr/wiki/ProjectFAQ Project FAQ]
 +
* [http://grr.googlecode.com/git/docs/index.html Documentation]
  
This format has been observed on Windows XP, ... will need to be modified for Vista/Win7 format
+
== Publications ==
 +
* [http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/37237.pdf Distributed forensics and incident response in the enterprise], by [[Michael Cohen]], [[Darren Bilby]], G. Caronni. Digital Investigation, 2011.
 +
* [https://googledrive.com/host/0B9hc84IflFGbN2IwMTUyYTUtMTU0Mi00ZWQ3LWFhNDktM2IyMTg5MmY3OWI0/Hunting%20in%20the%20Enterprise:%20Forensic%20Triage%20and%20Incident%20Response Hunting in the enterprise: Forensic triage and incident response], by [[Andreas Moser], [[Michael Cohen]], Digital Investigation, 2013.
  
{| class="wikitable"
+
== Presentations ==
|-
+
* [https://googledrive.com/host/0B1wsLqFoT7i2N3hveC1lSEpHUnM/Docs/GRR%20Rapid%20Response%20-%20OSFC%202012.pdf OSDFC 2012 GRR Overview], by [[Darren Bilby]]
! Field
+
! Offset
+
! Length
+
! Type
+
! Notes
+
|-
+
| H1
+
| 0x0000
+
| 4
+
| DWORD
+
| ? Probably a version number, identifying the file structure. Observed values: 0x11 - Windows XP; 0x17 - Vista, Windows 7
+
|-
+
| H2
+
| 0x0004
+
| 4
+
| DWORD
+
| ? Probably a file magic number. Only observed value: 0x41434353 ('SCCA')
+
|-
+
| H3
+
| 0x0008
+
| 4
+
| DWORD?
+
| ? Observed values: 0x0F - Windows XP, 0x11 - Windows 7
+
|-
+
| H4
+
| 0x000C
+
| 4
+
| DWORD
+
| Prefetch file length.
+
|-
+
| H5
+
|0x0010
+
| 60
+
| USTR
+
| Name of executable as Unicode string, truncated after 29 code units, if necessary, and terminated by U+0000. As it appears in the prefetch file file name.
+
|-
+
| H6
+
|0x004C
+
|4
+
|DWORD
+
|The prefetch hash, as it appears in the pf file name.
+
|-
+
| H7
+
|0x0050
+
|4
+
|?
+
|? Observed values: 0 for almost all prefetch files (XP); 1 for NTOSBOOT-B00DFAAD.pf (XP)
+
|-
+
| H8
+
| 0x0054
+
| 4
+
| DWORD
+
| Offset to section A
+
|-
+
| H9
+
| 0x0058
+
| 4
+
| DWORD
+
| ? Nr of entries in section A
+
|-
+
| H10
+
| 0x005C
+
| 4
+
| DWORD
+
| Offset to section B
+
|-
+
| H11
+
| 0x0060
+
| 4
+
| DWORD
+
| Nr of entries in section B
+
|-
+
| H12
+
| 0x0064
+
| 4
+
| DWORD
+
| Offset to section C
+
|-
+
| H13
+
| 0x0068
+
| 4
+
| DWORD
+
| Length of section C
+
|-
+
| H14
+
| 0x006C
+
| 4
+
| DWORD
+
| Offset to section D
+
|-
+
| H15
+
| 0x0070
+
| 4
+
| DWORD
+
| ? Probably the number of entries in the D section header
+
|-
+
| H16
+
| 0x0074
+
| 4
+
| DWORD
+
| Length of section D
+
|-
+
| H17
+
| 0x0078
+
| 8
+
| FTIME
+
| Latest execution time of executable (FILETIME)
+
|-
+
| H18
+
| 0x0080
+
| 16
+
| ?
+
| ? Possibly structured as 4 DWORD. Observed values: /0x00000000 0x00000000 0x00000000 0x00000000/, /0x47868c00 0x00000000 0x47860c00 0x00000000/
+
|-
+
| H19
+
| 0x0090
+
| 4
+
| DWORD
+
| Execution counter
+
|-
+
| H20
+
| 0x0094
+
| 4
+
| DWORD?
+
| ? Observed values: 1, 2, 3, 4, 5, 6 (XP)
+
|-
+
|}
+
  
It's worth noting that the name of a carved prefetch file can be restored using the information in field H5 and H6, and its size can be determined by field H4.
+
== Workshops ==
 
+
* [https://drive.google.com/?usp=chrome_app#folders/0B1wsLqFoT7i2eU1jU0JldW9JUU0 OSDFC workshop 2013] , by [[Darren Bilby]]
== Section A and B ==
+
 
+
The content of these two sections is unknown.
+
 
+
== Section C ==
+
 
+
== Section D ==
+
 
+
Section D contains one or more subsections. The number is (most likely) determined by the DWORD at file offset 0x0070. Each subsection refers to directories on an identified volume.
+
 
+
In this section, all offsets are assumed to be counted from the start of the D section.
+
 
+
{| class="wikitable"
+
|-
+
! Field
+
! Offset
+
! Length
+
! Type
+
! Notes
+
|-
+
| DH1
+
| +0x0000
+
| 4
+
| DWORD
+
| Offset to volume string (Unicode, terminated by U+0000)
+
|-
+
| DH2
+
| +0x0004
+
| 4
+
| DWORD
+
| Length of volume string (nr of characters, including terminating U+0000)
+
|-
+
| DH3
+
| +0x0008
+
| 8
+
| FTIME
+
| (File time)
+
|-
+
| DH4
+
| +0x0010
+
| 4
+
| DWORD
+
| Volume serial number of volume indicated by volume string
+
|-
+
| DH5
+
| +0x0014
+
| 4
+
| DWORD
+
| ? Offset to section DHS1
+
|-
+
| DH6
+
| +0x0018
+
| 4
+
| DWORD
+
| ? Length of section DHS1 (in bytes)
+
|-
+
| DH7
+
| +0x001C
+
| 4
+
| DWORD
+
| ? Offset to section DHS2
+
|-
+
| DH8
+
| +0x0020
+
| 4
+
| DWORD
+
| ? Nr of strings in section DHS2
+
|-
+
| ?
+
| +0x0024
+
| ?
+
| ?
+
| ? additional 28 bytes (includes one timestamp?)
+
|}
+
 
+
 
+
 
+
If all the executables and libraries referenced in the C section are from one single disk volume, there will be only one section in the D section. If multiple volumes are referenced by section C, section D will contain multiple sections.  (A simple way to force this situation is to copy, say, NOTEPAD.EXE to a USB drive, and start it from that volume. The corresponding prefetch file will have one D header referring to, e.g. \DEVICE\HARDDISK1\DP(1)0-0+4 (the USB drive), and one to, e.g. \DEVICE\HARDDISKVOLUME1\ (where the .DLLs and other support files were found).
+

Revision as of 14:20, 12 January 2014

Rekall
Maintainer: Darren Bilby and others
OS: Cross-platform
Genre: Incident Response
License: APL
Website: code.google.com/p/grr/

GRR is an Incident Response Framework focused on Remote Live Forensics.

See also

External Links

Publications

Presentations

Workshops