2018-06-30

exFAT Timestamp Behavior Associated with Different Operating Systems

Much like my recent post on ‘Using Extended MAPI Properties to determine email sent time’ this post is a response to David Cowen’s ‘Sunday Funday' challenge as detailed over at ‘Hacking Exposed - Computer Forensics Blog’.

The question posed by David was as follows:

ExFAT is documented to have a timezone field to document which timezone a timestamp was populated with. However most tools just see it as FAT and ignore it. For this challenge document for the following operating systems how they populate ExFAT timestamps and which utility will properly show the correct values.
  • Operating systems:
  • Windows 7
  • Windows 10
  • OSX High Sierra
  • Ubuntu Linux 16.04

This sort of question/ challenge is exactly the sort of thing I enjoy. I’m always keen to learn something new and find it interesting to test how artefacts behave under various circumstances and determine the implication(s) as they relate to forensic analysis.

With that said, I went decidedly off-piste and ended up down a whole range of rabbit holes exploring odd observations and working to better my understanding of exFAT. To that end, I will be following up with a much longer, possibly even a series of posts detailing my observations and methodology.

For the moment I wanted just to share a few of the high level observations.

In preparation I undertook a significant number of tests, performing different file operations using different Operating Systems, I also expanded the tests to include Windows 8.1 and Ubuntu 18.04. The results of all test were written to a spreadsheet where the date/time as recorded in my notes could be compared to the relevant fields as they appear on disk. I then furnished the same spreadsheet with details as to how each tool I analysed displayed the timestamps, and as I am sure any reader will agree nothing makes for quick and easy conclusions like a 1332 cell Excel monstrosity. 

Unsurprisingly this took a significant amount of time to review and in all honesty it has not yet been fully mined for its potential value, hence why a more detailed post will follow. On the basis of these tests the following observations are made as it relates to each OS’s handling of the exFAT file system:

How different operating systems use the three available Date/Time fields

The first observations relate to how the operating systems employ the different time fields, different Operating Systems implement and maintain different timestamps for files depending on a number of factors and as such they employ different terminology. For the purpose of this exercise we assume the knowledge that exFAT supports the recording of 3 distinct timestamps, refereed to in this post as Created, Accessed and Last Modified. We then examine the timestamps presented within the various operating systems and correlate them to the exFAT field they draw the data from.


Operating SystemOS NameexFAT Field
OSX 10.13.3CreatedCreated
OSX 10.13.3AccessedAccessed
OSX 10.13.3ModifiedModified
OSX 10.13.3ChangedModified
Windows 7/8/10Date CreatedCreated
Windows 7/8/10Date ModifiedModified
Windows 7/8/10Date AccessedAccessed
Ubuntu 16/18.04BirthN/A
Ubuntu 16/18.04AccessedAccessed
Ubuntu 16/18.04ModifiedModified
Ubuntu 16/18.04ChangedModified

A summary of how each of the tested operating systems utilitises the various timestamp, adjustment and timezone fields is outlined below. I hasten to add that these were the results from my initial testing, most will be repeated in preparation for the detailed posts so as to confirm the more notable findings.


Windows 10

Creation Time – Recorded with centisecond granularity, the default 2 second granularity associated with the MSDOS 32bit Timestamp is complemented with an additional field which permits addition of up to 199 centiseconds.

Last Modified Time – Recorded with 2 second granularity as the additional field appears to go unused and is consistently populated with a value of 0.

Accessed Time – Recorded with 2 second granularity due to lack of support in exFAT for greater granularity.

Timezone Fields – All timestamps are recorded as a direct representation of the local time of the system, the UTC offset (as configured on the system) is recorded in the associated timezone fields.



Windows 8 and Windows 7

Creation Time – Recorded with centisecond granularity.

Last Modified Time – Recorded with centisecond granularity when this timestamp is populated as a result of a new file being created (e.g. echo data into a file or right click, new file) however when the file is created as a result of a copy or move action then the centisecond granularity is dropped. The offset is consistently set at 0 and at this stage I have to assume that the timestamp is rounded down to the nearest even second.

Accessed Time – Recorded with 2 second granularity due to lack of support in exFAT for greater granularity.

Timezone Fields – All timestamps are recorded as a direct representation of the local time of the system, the UTC offset (as configured on the system) is recorded in the associated timezone fields.



Ubuntu 16.04 and Ubuntu 18.04

Creation Time – Recorded with nearest second granularity, while exFAT supports the recording of centisecond offsets the only observed offsets used are 0 and 1.

Last Modified Time – Recorded with nearest second granularity, while exFAT supports the recording of centisecond offsets the only observed offsets used are 0 and 1.

Accessed Time – Recorded with 2 second granularity due to lack of support in exFAT for greater granularity.

Timezone Fields – All timezones are recorded in UTCThe Timezone fields are consistently set to 00, indicating that they are not in use. A



OSX 10.13.3

Creation Time – Recorded with centisecond granularity.

Last Modified Time – Recorded with centisecond granularity

Accessed Time – Recorded with 2 second granularity due to lack of support in exFAT for greater granularity.

Timezone Fields – Consistently set to “FC” which is UTC-1 and I have no idea why...



Tool Interpretation of Timestamp date


For this half of the question David left it up to us to choose which tools/utilities to test to determine “which utility will properly show the correct values”. I felt it would be most useful to provide an overview of how the major forensics suites (or at least those I have access to) display the data and how they refer to the different timestamps. To that end I set out to test how different tools presented the timestamp information associated with the same filesystem I generated in Part 1, by creating files on a single USB device. 

The following tools have been tested so far:
  • EnCase 7.12.1
  • X-Ways Forensics 19.6
  • FTK 6.2
  • TSK Autopsy 4.7.0
  • Windows 10 Native
  • Ubuntu 18.04 Native

I intend to expand on this list and provide a detailed review of the performance limitations associated with each. But for the moment the summary result is that no tool will reliably display the exFAT timestamps associated with the various tested operating systems. The tools all failed to accurately display the date an action was performed in one way or another for at least one of the operating systems. Importantly this isn't always a failure of the tool, as above the the differences in implementation of exFAT cause inconsistencies which no tool could account for.

The tools which failed the worst are those which asked the examiner to specify the source timezone, commonly these ignored the provided timezone data altogether and then adjusted all the decoded MSDOS timestamps at the whim of the user. This scenario is most challenging when an item of removable storage media has been written to by multiple different operating systems or multiple instances of the same OS but with different timezone settings configured.

One key point to mention is that one type of tool will correctly inform the examiner of the timestamp data written to disk, that is to say that tools which do not attempt to perform any interpretation can't misinterpret that data. 

One example which worked flawlessly during this analysis was to use the third party WinHex exFAT Template by Scott Pancoast (https://www.x-ways.net/winhex/templates/index.html) to display the values of the Directory Records. Another interesting point to note here is that manual review of the timezone and timestamp data associated with files on an exFAT can provide additional forensic value, for instance the inconsistencies in how the filesystem is handled and what data gets written to different fields (as detailed above) can help you suppose what OS (and maybe version) was used to write the files to disk.

Thanks to David for inspiring some research that I thoroughly enjoyed, and watch this space for the fuller analysis and findings.

7 comments:

  1. FTK 6.4 corrected an issue with displaying exFAT times (reportedly). You may want to see if it makes a difference after upgrading FTK.

    ReplyDelete
    Replies
    1. Hi Mike, do you have a source on this or any additional info? Cheers.

      Delete
  2. The FTK 6.4 release notes don't mention exFAT, be nice to get some verification of this. https://ad-pdf.s3.amazonaws.com/ftk/6.4.x/FTK_6_4_RN.pdf

    ReplyDelete
    Replies
    1. Interestingly, I have just found mention of resolving this issue in the release notes for 6.2... "Improved handling of exFAT timestamps reading the Timezone marker. (42459, 1123)" https://ad-pdf.s3.amazonaws.com/ftk/FTK%206.1/FTK_6_1_RN.pdf

      I've done some more testing and there must have been an issue with my test system because 6.2 is rendering them differently to my notes while 6.1 is consistent with my previous observations. I will update the post to reflect that.

      Delete
  3. If you use a program like VoidTools Everything, it's very easy to see the time difference between file systems. I find that there usually is a 1-2 second difference between FAT32/exFAT and NTFS of the same exact file.

    example:
    https://i.imgur.com/kYo2Qin.png

    ReplyDelete
  4. Very good article! We will be linking to this particularly great post on our website. Keep up the good writing.
    4k Stogram Crack
    CloudMounter Crack
    WinHex Crack

    ReplyDelete

  5. Scientific bookkeeping isn't just about doing the math; it additionally requires solid correspondence and analytical abilities. These experts should have the option to pass complex monetary ideas on to assorted crowds, including judges and juries.

    ReplyDelete