Quantcast
Channel: MFCMAPI
Viewing all articles
Browse latest Browse all 1090

Commented Task: FILETIME is not parsed correctly in PR_CONVERSATION_INDEX [17485]

0
0
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 **

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.


Viewing all articles
Browse latest Browse all 1090

Latest Images

Trending Articles





Latest Images