Difference between pages "Java" and "Linux Unified Key Setup (LUKS)"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
 
(How to detect =)
 
Line 1: Line 1:
{{Expand}}
+
{{expand}}
  
== Java WebStart Cache ==
+
Linux Unified Key Setup (LUKS) is commonly used by Linux to encrypt storage media volumes. LUKS is implemented in the Linux kernel in dm-crypt (dm = Device Mapper) and the user-space component cryptsetup.
As of Java version 6 the Java WebStart Cache can be found in the following locations.
+
  
On Linux
+
LUKS supports various encryption methods, like:
<pre>
+
* [[AES]]
/home/$USER/.java/deployment/cache/
+
* [[Anubis]]
</pre>
+
* [[Blowfish|BlowFish]]
 +
* [[Cast5]]
 +
* [[Cast6]]
 +
* [[Serpent]]
 +
* [[Twofish|TwoFish]]
  
On MacOS-X
+
These encryption methods can be used in various chaining modes and with various initialization vector modes.
<pre>
+
/Users/$USER/Library/Caches/Java/cache/
+
</pre>
+
  
On Windows XP
+
== How to detect ===
<pre>
+
A LUKS encrypted volume starts with the "LUKS\xba\xbe" signature.
C:\Documents and Settings\%USERNAME%\Application Data\Sun\Java\Deployment\cache\
+
</pre>
+
  
On Windows Vista and later
+
A hexdump of the start of the volume should look similar to:
 
<pre>
 
<pre>
C:\Users\%USERNAME%\AppData\LocalLow\Sun\Java\Deployment\cache\
+
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
 +
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 +
00000020  00 00 00 00 00 00 00 00  63 62 63 2d 65 73 73 69  |........cbc-essi|
 +
00000030  76 3a 73 68 61 32 35 36  00 00 00 00 00 00 00 00  |v:sha256........|
 +
00000040  00 00 00 00 00 00 00 00  72 69 70 65 6d 64 31 36  |........ripemd16|
 +
00000050  30 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |0...............|
 
</pre>
 
</pre>
  
== IDX file format ==
+
== External Links ==
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.
+
* [http://clemens.endorphin.org/nmihde/nmihde-A4-ds.pdf New Methods in Hard Disk Encryption], by Clemens Fruhwirth, July 18, 2005
 +
* [http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf LUKS On-Disk Format Specification - Version 1.2.1], by Clemens Fruhwirth, October 16, 2011
 +
* [https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html LUKS Disk Encryption], by [[RedHat]]
 +
* [https://googledrive.com/host/0B3fBvzttpiiSNUVYSFF1TmRONmc/Linux%20Unified%20Key%20Setup%20(LUKS)%20Disk%20Encryption%20format.pdf LUKS Disk Encryption format specification], by the [[libluksde|libluksde project]], July 2013
 +
* [http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ Practical malleability attack against CBC-Encrypted LUKS partitions], by Jakob Lell, December 22, 2013
  
Values are in big-endian.
 
 
<pre>
 
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:
 
{|
 
! align="left"| Offset
 
! Size
 
! Value
 
! Description
 
|-
 
| 0
 
| 4
 
|
 
| Unknown, seen 00 00 00 00 and 01 00 00 00
 
|-
 
| 4
 
| 4
 
| 02 5b 00 00
 
| Signature?
 
|-
 
| 8
 
| 7
 
|
 
| Unknown
 
|-
 
| 15
 
| 6
 
| 01 1f 81 29 fe b8
 
| Unknown timestamp, POSIX timestamp in milli seconds
 
|-
 
| 21
 
| 10
 
|
 
| Unknown, empty values
 
|-
 
| 31
 
| 6
 
| 01 2b 24 4a cb dd
 
| Unknown timestamp, POSIX timestamp in milli seconds
 
|-
 
| 37
 
| 19
 
|
 
| Unknown
 
|-
 
| 56
 
| 6
 
| 01 2b 24 4a a4 cd
 
| Unknown timestamp, POSIX timestamp in milli seconds
 
|-
 
| 62
 
| 2
 
|
 
| Unknown, empty values
 
|-
 
| 64
 
| 6
 
| 01 2e 45 83 f4 18
 
| Unknown timestamp, POSIX timestamp in milli seconds
 
|-
 
| 70
 
| 22
 
|
 
| Unknown
 
|-
 
| 92
 
| 6
 
| 01 2b 24 4a a4 cd
 
| Unknown timestamp, POSIX timestamp in milli seconds
 
|-
 
| 98
 
| 30
 
|
 
| Unknown, empty values
 
|}
 
 
To convert a timestamp in e.g. Python
 
<pre>
 
print datetime.datetime(1970, 1, 1) + datetime.timedelta(milliseconds=0x011f8129feb8)
 
2009-02-16 22:17:07
 
</pre>
 
 
<pre>
 
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 00 00 00  |estApplet.jar...|
 
000000c0  0c 36 36 2e 33 37 2e 32  31 30 2e 38 36 00 00 00  |.66.37.210.86...|
 
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.........|
 
000001d0  00 b4 bd 49 77 e2 5a 96  36 3c af b5 ea 3f e4 20  |...Iw.Z.6<...?. |
 
...
 
</pre>
 
 
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]]
+
[[Category:Disk encryption]]
 +
[[Category:Linux]]

Revision as of 12:18, 23 December 2013

Information icon.png

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

Linux Unified Key Setup (LUKS) is commonly used by Linux to encrypt storage media volumes. LUKS is implemented in the Linux kernel in dm-crypt (dm = Device Mapper) and the user-space component cryptsetup.

LUKS supports various encryption methods, like:

These encryption methods can be used in various chaining modes and with various initialization vector modes.

How to detect =

A LUKS encrypted volume starts with the "LUKS\xba\xbe" signature.

A hexdump of the start of the volume should look similar to:

00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  63 62 63 2d 65 73 73 69  |........cbc-essi|
00000030  76 3a 73 68 61 32 35 36  00 00 00 00 00 00 00 00  |v:sha256........|
00000040  00 00 00 00 00 00 00 00  72 69 70 65 6d 64 31 36  |........ripemd16|
00000050  30 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |0...............|

External Links