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

From Forensics Wiki
(Difference between pages)
Jump to: navigation, search
(IDX file format)
 
(Header)
 
Line 1: Line 1:
{{Expand}}
+
A Windows Prefetch file consists of one file header and multiple file sections with different content. Not all content has an obvious forensic value.
  
== Java WebStart Cache ==
+
As far as have been possible to ascertain, there is no public description of the format. The description below has been synthesised from examination
As of Java version 6 the Java WebStart Cache can be found in the following locations.
+
of multiple prefetch files.
  
On Linux
+
== Characteristics ==
<pre>
+
Integer values are stored in little-endian.
/home/$USER/.java/deployment/cache/
+
</pre>
+
  
On MacOS-X
+
Strings are stored as UTF-16 little-endian without a byte-order-mark (BOM).
<pre>
+
/Users/$USER/Library/Caches/Java/cache/
+
</pre>
+
  
On Windows XP
+
Timestamps are stored as Windows Filetime in UTC.
<pre>
+
C:\Documents and Settings\%USERNAME%\Application Data\Sun\Java\Deployment\cache\
+
</pre>
+
  
On Windows Vista and later
+
== Header ==
<pre>
+
C:\Users\%USERNAME%\AppData\LocalLow\Sun\Java\Deployment\cache\
+
</pre>
+
  
== IDX file format ==
+
This format has been observed on Windows XP, ..will need to be modified for Vista/Win7 format
Caveat: The following information is based on analysis of several dozen *.idx files from different Windows 7 systemsAs such, the following information should not be considered to have been exhaustively researched.
+
  
Values are in big-endian.
+
{| class="wikitable"
 +
|-
 +
! Field
 +
! Offset
 +
! Length
 +
! Type
 +
! Notes
 +
|-
 +
| H1
 +
| 0x0000
 +
| 4
 +
| DWORD
 +
| Format version (see format version section below)
 +
|-
 +
| 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)
 +
|-
 +
|}
  
<pre>
+
Likely to be format version dependent structure for format version 0x11.
00000000  01 00 00 00 02 5b 00 00  00 00 1d c7 b4 00 00 01  |.....[..........|
+
00000010  1f 81 29 fe b8 00 00 00  00 00 00 00 00 00 00 01  |..).............|
+
00000020  2b 24 4a cb dd 01 00 00  00 00 00 00 00 00 00 00  |+$J.............|
+
00000030  00 00 00 00 00 00 00 00  01 2b 24 4a a4 cd 00 00  |.........+$J....|
+
00000040  01 2e 45 83 f4 18 00 00  00 00 00 00 00 00 00 01  |..E.............|
+
00000050  01 00 00 00 00 00 00 00  00 00 00 00 01 2b 24 4a  |.............+$J|
+
00000060  a4 cd 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
+
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
+
</pre>
+
  
The header is 128 bytes in size and contains:
+
{| class="wikitable"
{|
+
|-
! align="left"| Offset
+
! Field
! Size
+
! Offset
! Value
+
! Length
! Description
+
! Type
 +
! Notes
 
|-
 
|-
| 0
+
| H8
 +
| 0x0054
 
| 4
 
| 4
|
+
| DWORD
| Unknown, seen 00 00 00 00 and 01 00 00 00
+
| Offset to section A
 
|-
 
|-
 +
| H9
 +
| 0x0058
 
| 4
 
| 4
 +
| DWORD
 +
| ? Nr of entries in section A
 +
|-
 +
| H10
 +
| 0x005C
 
| 4
 
| 4
| 02 5b 00 00
+
| DWORD
| Signature?
+
| Offset to section B
 
|-
 
|-
| 8
+
| H11
| 7
+
| 0x0060
|
+
| 4
| Unknown
+
| DWORD
 +
| Nr of entries in section B
 
|-
 
|-
| 15
+
| H12
| 6
+
| 0x0064
| 01 1f 81 29 fe b8
+
| 4
| Unknown timestamp, POSIX timestamp in milli seconds
+
| DWORD
 +
| Offset to section C
 
|-
 
|-
| 21
+
| H13
| 10
+
| 0x0068
|
+
| 4
| Unknown, empty values
+
| DWORD
 +
| Length of section C
 
|-
 
|-
| 31
+
| H14
| 6
+
| 0x006C
| 01 2b 24 4a cb dd
+
| 4
| Unknown timestamp, POSIX timestamp in milli seconds
+
| DWORD
 +
| Offset to section D
 
|-
 
|-
| 37
+
| H15
| 19
+
| 0x0070
|
+
| 4
| Unknown
+
| DWORD
 +
| ? Probably the number of entries in the D section header
 
|-
 
|-
| 56
+
| H16
| 6
+
| 0x0074
| 01 2b 24 4a a4 cd
+
| 4
| Unknown timestamp, POSIX timestamp in milli seconds
+
| DWORD
 +
| Length of section D
 
|-
 
|-
| 62
+
| H17
| 2
+
| 0x0078
|
+
| 8
| Unknown, empty values
+
| FTIME
 +
| Latest execution time of executable (FILETIME)
 
|-
 
|-
| 64
+
| H18
| 6
+
| 0x0080
| 01 2e 45 83 f4 18
+
| 16
| Unknown timestamp, POSIX timestamp in milli seconds
+
| ?
 +
| ? Possibly structured as 4 DWORD. Observed values: /0x00000000 0x00000000 0x00000000 0x00000000/, /0x47868c00 0x00000000 0x47860c00 0x00000000/
 
|-
 
|-
| 70
+
| H19
| 22
+
| 0x0090
|
+
| 4
| Unknown
+
| DWORD
 +
| Execution counter
 
|-
 
|-
| 92
+
| H20
| 6
+
| 0x0094
| 01 2b 24 4a a4 cd
+
| 4
| Unknown timestamp, POSIX timestamp in milli seconds
+
| DWORD?
 +
| ? Observed values: 1, 2, 3, 4, 5, 6 (XP)
 
|-
 
|-
| 98
 
| 30
 
|
 
| Unknown, empty values
 
 
|}
 
|}
  
To convert a timestamp in e.g. Python
+
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.
<pre>
+
print datetime.datetime(1970, 1, 1) + datetime.timedelta(milliseconds=0x011f8129feb8)
+
2009-02-16 22:17:07
+
</pre>
+
  
<pre>
+
=== Format version ===
00000080  00 00 00 39 68 74 74 70  3a 2f 2f 77 77 77 2e 74  |...9http://www.t|
+
00000090  6f 70 63 6f 64 65 72 2e  63 6f 6d 2f 63 6f 6e 74  |opcoder.com/cont|
+
000000a0  65 73 74 2f 63 6c 61 73  73 65 73 2f 43 6f 6e 74  |est/classes/Cont|
+
000000b0  65 73 74 41 70 70 6c 65  74 2e 6a 61 72          |estApplet.jar  |
+
</pre>
+
  
{|
+
{| class="wikitable"
! align="left"| Offset
+
|-
! Size
+
 
! Value
 
! Value
! Description
+
! Windows version
 
|-
 
|-
| 128
+
| 0x11
| 4
+
| Windows XP, Windows 2003
|
+
|-
| Original URL string size
+
| 0x17
 +
| Windows Vista, Windows 7
 +
|-
 +
| 0x1a
 +
| Windows 8.1
 
|-
 
|-
| 132
 
| ...
 
|
 
| Original URL string (UTF-8 without an end-of-string character?)
 
 
|}
 
|}
  
<pre>
+
== Section A and B ==
000000b0                                          00 00 00  |            ...|
+
000000c0  0c 36 36 2e 33 37 2e 32  31 30 2e 38 36 00 00 00  |.66.37.210.86  |
+
</pre>
+
  
{|
+
The content of these two sections is unknown.
! align="left"| Offset
+
 
! Size
+
== Section C ==
! Value
+
 
! Description
+
== 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
 
| 4
|
+
| DWORD
| IP string size
+
| Offset to volume string (Unicode, terminated by U+0000)
 
|-
 
|-
| ...
+
| DH2
| ...
+
| +0x0004
|
+
| 4
| IP string (UTF-8 without an end-of-string character?)
+
| DWORD
|}
+
| Length of volume string (nr of characters, including terminating U+0000)
 
+
<pre>
+
000000c0                                          00 00 00  |            ...|
+
000000d0  07 00 06 3c 6e 75 6c 6c  3e 00 0f 48 54 54 50 2f  |...<null>..HTTP/|
+
000000e0  31 2e 31 20 32 30 30 20  4f 4b 00 0e 63 6f 6e 74  |1.1 200 OK..cont|
+
000000f0  65 6e 74 2d 6c 65 6e 67  74 68 00 07 31 39 35 31  |ent-length..1951|
+
00000100  36 36 38 00 0d 6c 61 73  74 2d 6d 6f 64 69 66 69  |668..last-modifi|
+
00000110  65 64 00 1d 4d 6f 6e 2c  20 31 36 20 46 65 62 20  |ed..Mon, 16 Feb |
+
00000120  32 30 30 39 20 32 32 3a  31 37 3a 30 37 20 47 4d  |2009 22:17:07 GM|
+
00000130  54 00 0c 63 6f 6e 74 65  6e 74 2d 74 79 70 65 00  |T..content-type.|
+
00000140  18 61 70 70 6c 69 63 61  74 69 6f 6e 2f 6a 61 76  |.application/jav|
+
00000150  61 2d 61 72 63 68 69 76  65 00 04 64 61 74 65 00  |a-archive..date.|
+
00000160  1d 53 61 74 2c 20 31 38  20 53 65 70 20 32 30 31  |.Sat, 18 Sep 201|
+
00000170  30 20 31 30 3a 30 31 3a  30 36 20 47 4d 54 00 06  |0 10:01:06 GMT..|
+
00000180  73 65 72 76 65 72 00 06  41 70 61 63 68 65 00 1b  |server..Apache..|
+
00000190  64 65 70 6c 6f 79 2d 72  65 71 75 65 73 74 2d 63  |deploy-request-c|
+
000001a0  6f 6e 74 65 6e 74 2d 74  79 70 65 00 1a 61 70 70  |ontent-type..app|
+
000001b0  6c 69 63 61 74 69 6f 6e  2f 78 2d 6a 61 76 61 2d  |lication/x-java-|
+
000001c0  61 72 63 68 69 76 65 1f  8b 08 00 00 00 00 00 00  |archive.........|
+
...
+
</pre>
+
 
+
{|
+
! align="left"| Offset
+
! Size
+
! Value
+
! Description
+
 
|-
 
|-
| ...
+
| DH3
 +
| +0x0008
 +
| 8
 +
| FTIME
 +
| (File time)
 +
|-
 +
| DH4
 +
| +0x0010
 
| 4
 
| 4
|
+
| DWORD
| Number of value pairs
+
| Volume serial number of volume indicated by volume string
 
|-
 
|-
| ...
+
| DH5
| ...
+
| +0x0014
|
+
| 4
| Array of value pairs
+
| DWORD
|}
+
| ? Offset to section DHS1
 
+
A value pair is variable of size and consists of:
+
{|
+
! align="left"| Offset
+
! Size
+
! Value
+
! Description
+
 
|-
 
|-
| 0
+
| DH6
| 2
+
| +0x0018
|
+
| 4
| Value description string size
+
| DWORD
 +
| ? Length of section DHS1 (in bytes)
 
|-
 
|-
| 2
+
| DH7
| size
+
| +0x001C
|
+
| 4
| Value description string
+
| DWORD
 +
| ? Offset to section DHS2
 
|-
 
|-
| ...
+
| DH8
| 2
+
| +0x0020
|
+
| 4
| Value string size
+
| DWORD
 +
| ? Nr of strings in section DHS2
 
|-
 
|-
| ...
+
| ?
| size
+
| +0x0024
|
+
| ?
| Value string
+
| ?
 +
| ? additional 28 bytes (includes one timestamp?)
 
|}
 
|}
  
Analysis of *.idx files have revealed a number of interesting findings.  One is that specific offsets appear to be based on the version or "magic number" of the *.idx file.  For example, for files with the second DWORD of the binary contents of the file (thought to be the "magic number") of 0x5a02, the URL from which the data was retrieved starts at offset 0x20, and is an ASCII string terminated by "\x00\x00". 
 
 
For a magic number of 0x5d02, the size of the URL string can be found at offset 0x80. The first two string values to extract from this data are prefaced with their lengths in 4-byte DWORDs, stored in big endian order.  To get the first string, read the DWORD at offset 0x80, and translate it as a big endian value (in Perl, use <i>unpack("N",$data)</i>).  Beginning at offset 0x84, the string is <i>length</i> characters long.  At the end of that string, the next DWORD is the length of the second string, also in big endian format.
 
 
Once you've completed reading the initial strings, there is a DWORD value which can be interpreted as a <i>type</i> value, of sorts, and the remaining data (i.e., strings following the apparent <i>type</i> value) appears to follow a fairly regular pattern.  The <i>type</i> value appears to represent the number of string pairs in the remaining data.  Each string is prefaced by a WORD (2-byte) value, in big endian format, which tells us how long each string is...using this information, it is a fairly straightforward process to parse through the information and collect the strings, and pair them up.
 
 
In many cases, the <i>type</i> values of 2 include an HTTP Response code of 302; the values of  6, 7, and 8 (values that have been observed so far) include a response of 200, as well as additional data (including time stamps), and the *.idx files themselves appear to contain certificate (and perhaps other) information.
 
  
== External Links ==
 
* [http://sploited.blogspot.ch/2012/08/java-forensics-using-tln-timelines.html Java Forensics using TLN Timelines]
 
* [http://journeyintoir.blogspot.com/2011/02/almost-cooked-up-some-java.html Almost Cooked UP Some Java]
 
* [http://journeyintoir.blogspot.com/2011/11/finding-initial-infection-vector.html Finding Initial Infection Vector]
 
  
[[Category:Analysis]]
+
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 05:18, 20 October 2013

A Windows Prefetch file consists of one file header and multiple file sections with different content. Not all content has an obvious forensic value.

As far as have been possible to ascertain, there is no public description of the format. The description below has been synthesised from examination of multiple prefetch files.

Contents

Characteristics

Integer values are stored in little-endian.

Strings are stored as UTF-16 little-endian without a byte-order-mark (BOM).

Timestamps are stored as Windows Filetime in UTC.

Header

This format has been observed on Windows XP, ... will need to be modified for Vista/Win7 format

Field Offset Length Type Notes
H1 0x0000 4 DWORD Format version (see format version section below)
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)

Likely to be format version dependent structure for format version 0x11.

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

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.

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).