Difference between revisions of "Java"

From ForensicsWiki
Jump to: navigation, search
(Java WebStart Cache)
(Java WebStart Cache)
Line 26: Line 26:
 
Caveat: The following information is based on analysis of several dozen *.idx files from different Windows 7 systems.  As such, the following information should not be considered to have been exhaustively researched.
 
Caveat: The following information is based on analysis of several dozen *.idx files from different Windows 7 systems.  As such, the following information should not be considered to have been exhaustively researched.
  
Analyzing several of the *.idx files (from Sun\Java\Deployment\cache\6.0\) in a hex editor indicates that information regarding the downloaded content starts at offset 0x80 in the *.idx filesThe 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 longAt the end of that string, the next DWORD is the length of the second string, also in big endian format.
+
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 fileFor 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".   
  
Following the end of the second string, there is a DWORD value which can be interpreted as a <i>type</i> value, of sorts, as for values of 2, 6, or 7, the remaining data appears to follow a fairly regular patternFor a value of 2, there appear to be 4 strings, for 6, there appear to be 12 strings, and for a value of 7, there appear to be 14 strings.  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.
+
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 longAt the end of that string, the next DWORD is the length of the second string, also in big endian format.
  
In many cases, the <i>type</i> values of 2 include an HTTP Response code of 302; the values of  6 and 7 include a response of 200, and the *.idx files themselves appear to contain certificate (and perhaps other) information.
+
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 ==
 
== External Links ==

Revision as of 11:40, 17 January 2013

Information icon.png

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

Java WebStart Cache

As of Java version 6 the Java WebStart Cache can be found in the following locations.

On Linux

/home/$USER/.java/deployment/cache/

On MacOS-X

/Users/$USER/Library/Caches/Java/cache/

On Windows XP

C:\Documents and Settings\%USERNAME%\Application Data\Sun\Java\Deployment\cache\

On Windows Vista and later

C:\Users\%USERNAME%\AppData\LocalLow\Sun\Java\Deployment\cache\

Caveat: The following information is based on analysis of several dozen *.idx files from different Windows 7 systems. As such, the following information should not be considered to have been exhaustively researched.

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 unpack("N",$data)). Beginning at offset 0x84, the string is length 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 type value, of sorts, and the remaining data (i.e., strings following the apparent type value) appears to follow a fairly regular pattern. The type 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 type 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