Difference between pages "Windows Prefetch File Format" and "Talk:Linux Logical Volume Manager (LVM)"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
(Header)
 
(Created page with "Should we change :To make the volume group known to the system :vgexport $VOLUMEGROUP to :To make the volume group known to the system :vgimport $VOLUMEGROUP ? vgexport ma...")
 
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.
+
Should we change
  
As far as have been possible to ascertain, there is no public description of the format. The description below has been synthesised from examination
+
:To make the volume group known to the system
of multiple prefetch files.
+
:vgexport $VOLUMEGROUP
  
== Characteristics ==
+
to
Integer values are stored in little-endian.
+
  
Strings are stored as UTF-16 little-endian without a byte-order-mark (BOM).
+
:To make the volume group known to the system
 +
:vgimport $VOLUMEGROUP
 +
?
  
Timestamps are stored as Windows Filetime in UTC.
+
vgexport makes volume groups ''unknown'' to the system, vgimport makes exported volumes ''known'' to the system. See also [http://www.tldp.org/HOWTO/LVM-HOWTO/recipemovevgtonewsys.html this]. You should also remember, that both vgexport/vgimport alter the data on the physical device. I also added "loop" option to the mount command example, since "-o ro" may alter the data in the file system (replay the journal, etc) [[User:.FUF|.FUF]] ([[User talk:.FUF|talk]]) 10:19, 7 May 2014 (CDT)
 
+
== Header ==
+
 
+
This format has been observed on Windows XP, ...  will need to be modified for Vista/Win7 format
+
 
+
{| class="wikitable"
+
|-
+
! Field
+
! Offset
+
! Length
+
! Type
+
! Notes
+
|-
+
| H1
+
| 0x0000
+
| 4
+
| DWORD
+
| Format version (see format version section below)
+
|-
+
| H2
+
| 0x0004
+
| 4
+
| DWORD
+
| Signature 'SCCA' (or in hexadecimal representation 0x53 0x43 0x43 0x4)
+
|-
+
| 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)
+
|-
+
|}
+
 
+
The following part of the header is likely to be format version dependent structure for format version 0x11.
+
 
+
{| class="wikitable"
+
|-
+
! Field
+
! Offset
+
! Length
+
! Type
+
! Notes
+
|-
+
| 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.
+
 
+
=== Format version ===
+
 
+
{| class="wikitable"
+
|-
+
! Value
+
! Windows version
+
|-
+
| 0x11
+
| Windows XP, Windows 2003
+
|-
+
| 0x17
+
| Windows Vista, Windows 7
+
|-
+
| 0x1a
+
| Windows 8.1
+
|-
+
|}
+
 
+
== 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).
+

Latest revision as of 11:19, 7 May 2014

Should we change

To make the volume group known to the system
vgexport $VOLUMEGROUP

to

To make the volume group known to the system
vgimport $VOLUMEGROUP

?

vgexport makes volume groups unknown to the system, vgimport makes exported volumes known to the system. See also this. You should also remember, that both vgexport/vgimport alter the data on the physical device. I also added "loop" option to the mount command example, since "-o ro" may alter the data in the file system (replay the journal, etc) .FUF (talk) 10:19, 7 May 2014 (CDT)