The dissection of the header of PR_CONVERSATION_INDEX (22 bytes) is as follows:
* One reserved byte. Its value is 1.
* Five bytes for the current system time converted to the FILETIME structure format.
* Sixteen bytes holding a GUID, or globally unique identifier.
The correct parsing for FILETIME is carried out on 8-bytes.
The current way FILETIME is converted to a time is that it takes the 5-bytes, with pre-padding of 1 byte (00), and post-padding of 2 bytes (0000). The full 8-bytes are then converted to a readable time (the converted value represents 100-nanosecond units since start of 1/1/1601).
Example:
> Real data from an email/conversation received on 12 July, 2015 2:52PM (UTC+3) - the header value is: 01D0BC97E1676C1F56A7FE154FA7B1E19C86BBABE4EE
```
Current FILETIME: (Low = 0xE1670000, High = 0x00D0BC97) = 11:52:46.352 AM 09-Mar-1787
```
Note that the high byte starts with 00 (arbitrary padding)
The correct way of evaluating FILETIME is to not pre-pad the FILETIME (5-bytes) but rather take the first 6-bytes, and only add post-padding of 2-bytes (0000)
As such, the FILETIME should be evaluated as:
```
0x01D0BC97:E1670000 - this would result in the correct timestamp: 11:42:50 AM 12-Jul-2015
```
which is the correct timestamp for the email
This would eventually need to be corrected in upcoming versions, to correctly reflect the FILETIME included in the Conversation Index
References:
http://www.meridiandiscovery.com/how-to/e-mail-conversation-index-metadata-computer-forensics/
https://msdn.microsoft.com/en-us/library/office/cc765583.aspx
http://www.silisoftware.com/tools/date.php?inputdate=0x01D0BC97E1670000&inputformat=filetime
http://www.silisoftware.com/tools/date.php?inputdate=0x00D0BC97E1670000&inputformat=filetime
Comments: ** Comment from web user: sgriffin **
* One reserved byte. Its value is 1.
* Five bytes for the current system time converted to the FILETIME structure format.
* Sixteen bytes holding a GUID, or globally unique identifier.
The correct parsing for FILETIME is carried out on 8-bytes.
The current way FILETIME is converted to a time is that it takes the 5-bytes, with pre-padding of 1 byte (00), and post-padding of 2 bytes (0000). The full 8-bytes are then converted to a readable time (the converted value represents 100-nanosecond units since start of 1/1/1601).
Example:
> Real data from an email/conversation received on 12 July, 2015 2:52PM (UTC+3) - the header value is: 01D0BC97E1676C1F56A7FE154FA7B1E19C86BBABE4EE
```
Current FILETIME: (Low = 0xE1670000, High = 0x00D0BC97) = 11:52:46.352 AM 09-Mar-1787
```
Note that the high byte starts with 00 (arbitrary padding)
The correct way of evaluating FILETIME is to not pre-pad the FILETIME (5-bytes) but rather take the first 6-bytes, and only add post-padding of 2-bytes (0000)
As such, the FILETIME should be evaluated as:
```
0x01D0BC97:E1670000 - this would result in the correct timestamp: 11:42:50 AM 12-Jul-2015
```
which is the correct timestamp for the email
This would eventually need to be corrected in upcoming versions, to correctly reflect the FILETIME included in the Conversation Index
References:
http://www.meridiandiscovery.com/how-to/e-mail-conversation-index-metadata-computer-forensics/
https://msdn.microsoft.com/en-us/library/office/cc765583.aspx
http://www.silisoftware.com/tools/date.php?inputdate=0x01D0BC97E1670000&inputformat=filetime
http://www.silisoftware.com/tools/date.php?inputdate=0x00D0BC97E1670000&inputformat=filetime
Comments: ** Comment from web user: sgriffin **
The analysis in that article is wrong. The first byte is hard coded as 1 and the most significant byte of the dwHighDateTime is not encoded. Now - the byte that gets dropped is always 1 (unless we time travel), so it's OK to assume it.