exFAT File System Time Zone Concerns

exFAT Time Zone Concerns

The exFAT file system tracks the time zone offset of all MAC time's stored for the respective file. The file system uses 32-bit time stamps (and another byte tracking 10ms increments). Additionally, all time stamps are recorded to the file system as local machine time while applying a time zone offset that is also stored when a file is changed/modified/accessed. The implications of this include being able to track removable media across several time zones without the need for the system they were used in. (For a more detailed look at the exFAT file system, see Robert Shullich's paper on SANS Computer Forensics Resources).

exFAT stores time zone offsets in a one byte value. Vista SP1 (the first desktop release of exFAT) did NOT utilize the time zone byte. In this case, the time zone bytes will be 0x00. Since the OS needs to know whether or not to read the time zone offset, the first bit (the high bit) will be a 0 to indicate time zone offset should not be applied or a 1 to indicate that the time zone offset is to be applied. The low seven bits can then be signed to ascertain a 15 minute interval time zone offset. Examples follow below.

To illustrate the time zone offset and to demonstrate differences in how a file will be displayed to a user between Windows and EnCase, I started with a thumb drive formatted in exFAT. The drive did have data on it prior to my test that I simply deleted. You'll see remnants of this in the screen captures from EnCase. It does not affect this test, however. The formatting setup sized sectors at 512 bytes and clusters at 64 sectors per cluster. The cluster heap starts at sector 384 (cluster 2), and the root directory is in physical sector 512 (cluster 4).

No logical files were on the volume when I started. As I said, some data was deleted so EnCase does pick it up.

My machine was already set to EDT (UTC -4 hours). I created an empty text file on the device by right clicking and choosing, "New Text Document". All files were created this way, and nothing was added to the content — this was just a test of the time zones after all. I then reset my time zone to UTC and created the next file.

This file was created the same way and was saved as UTC.txt. A windows refresh was not performed. All of the times from earlier files will be displayed with the previous time zone. When I was done adding files, I did a screen refresh. You'll see that Windows converted all dates and times using the time zone offset.

A file was added with a positive offset — UTC +1 hour — to illustrate how the signed integer works. It's named "Berlin Time".

Kathmandu was selected because the time zone is in a 15 minute increment — and this is and example of why the time zone byte in exFAT must accommodate 15 minute intervals.

I changed my machine back to EDT and refreshed the window. All times line up to when the files were created and applied the proper time zone offset.

In this shot, a few things are going on. Let's start with the time zone stuff first. Windows displays all the times as UTC with the exFAT stored time zone applied. The EnCase shot shows all times by applying ONLY the local machine time.

• Example 1: Berlin Time : Modified Date : 10:06 AM Windows : 16:06 PM EnCase
• Example 2: EDT (UTC -4hrs) : Modified Date : 10:04 AM Windows : 10:04 AM EnCase
• Example 3: Kathmandu : Modified Date : 10:07 AM Windows : 19:51 PM EnCase
• Example 4: UTC : Modified Date : 10:05 AM Windows : 14:05 PM EnCase

Looking at the time zone offset value stored, it is 0x88. Break this into it's binary value:

1 0 0 0 : 1 0 0 0

Time zone is turned on. Bit 1 = 1. Sign the additional 7 bits:

x -64 32 16 : 8 4 2 1

So the value is 8. Since these are 15 minute increments, multiply 8 x 15 to get 120. 120 is equal to 2 hours. The time zone offset is therefore UTC+2 hrs. (I left day light time turned on — that accounts for the additional hour (UTC+2 instead of the expected UTC+1)

Looking at the time zone offset value stored, it is 0xF0. Break this into it's binary value:

1 1 1 1 : 0 0 0 0

Time zone is turned on. Bit 1 = 1. Sign the additional 7 bits:

x -64 32 16 : 8 4 2 1

So the value is -16 (-64 + 32 + 16). Since these are 15 minute increments, multiply -16 x 15 to get -240. Negative 240 is equal to -4 hours. The time zone offset is therefore UTC-4 hrs.

Looking at the time zone offset value stored, it is 0x97. Break this into it's binary value:

1 0 0 1 : 0 1 1 1

Time zone is turned on. Bit 1 = 1. Sign the additional 7 bits:

x -64 32 16 : 8 4 2 1

So the value is -23 (16 + 4 + 2 +1). Since these are 15 minute increments, multiply 23 x 15 to get 345. 345 is equal to 5.75 hours. The time zone offset is therefore UTC+5:45 hrs.

Looking at the time zone offset value stored, it is 0x80. Break this into it's binary value:

1 0 0 0 : 0 0 0 0

Time zone is turned on. Bit 1 = 1. Sign the additional 7 bits:

x -64 32 16 : 8 4 2 1

So the value is 0. Since these are 15 minute increments, multiply 0 x 15 to get 0. 0 is equal to 0 hours. The time zone offset is therefore UTC hrs.

Finally, to illustrate that the time zone codes are relative to both the machine time zone offset and the action taken, I added text to the Berlin file while my machine remained in EDT.

The time zone offset switched to 0xF0 for the modified time zone offset and last accessed time zone offset. The created time zone offset did not change (it remains 0x88). And, from example 2 above, we know that 0xF0 is EDT (UTC-4hrs).

EnCase still uses the local machine offset while Windows uses appropriate TZ offset as stored in the directory entry record for the file.

Additional Considerations 

I want to throw another concern while we're at it. I eluded to this earlier and I'll return to the screenshot which I mentioned had additional issues.

Disregard the Windows portion and look at the top where EnCase displays several file names. Many of the files are marked as deleted by the red circle with a slash through it. It should be pointed out that when a directory entry record is marked as AVAILABLE FOR USE (by setting the most significant bit in the first byte of the entry to 0 from 1), this does NOT EXCLUSIVELY mean the file associated with the record has been deleted. It simply means that the directory record is available for use — that could be because the file was deleted.

Look again at the entries — focus on the New Text Document.txt files. These files were created with the right click. They took up a lot of space in the directory entries with their long file name. When I renamed them to UTC.txt, EDT (UTC -4hrs).txt, etcetra, the entries for New Text Documents.txt was marked as available for use. This can — and does happen — when files are manually renamed as well. The old names might point to the same data — or not.

To quickly sum up: to say that all the files marked with the circle and slash by EnCase are deleted would not be true in the case of exFAT.

Jeff Hamm is a Senior Forensic Computer Analyst for Paradigm Solutions and was formerly a Sergeant with the Oakland County Sheriff's Office in Michigan. He is now a full time contractor for a federal digital forensic laboratory where he carries a case load and manages a forensic team including cell phone and media analysts. He has been working media forensics and conducting computer crime investigations since 2001 and he holds the CFCE, EnCE, and ACE.