View source for ExFAT Implementation Notes

= Introduction =

This document contains information on the implementation of the [[exFAT]] file system in [[The Sleuth Kit]] (TSK). Like [[FAT]], exFAT has significant differences with the UNIX file system TSK was originally designed to support, and this document will identify how they were handled. A basic understanding of exFAT is assumed.

= Disk Unit Addressing =

Like [[FAT]], exFAT saves file content in clusters, which are groupings of consecutive sectors (512-bytes each). It has the same problems as FAT in using these clusters as the addressable units, so like FAT the solution is to use sectors as the addressable unit instead. See [[FAT_Implementation_Notes#Disk_Unit_Addressing]] for more information.

= Metadata Addressing =

Again, exFAT shares the same problems discussed in [[FAT_Implementation_Notes#Metadata_Addressing]], and the same solution is used. Note that normal exFAT files have at least three directory entry structures (more the longer the filename is), so the metadata addresses will increase by three or more for files in the same directory.

= mmls and Partition Codes =

ExFAT shares the same partition code as NTFS, so the string displayed by [[mmls]] for type 0x07 is now "NTFS / exFAT (0x07)". See http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

= fsstat and FAT Chains =

Like FAT, exFAT does have FAT chains. However, they are only used to keep track of clusters for fragmented files. Printing a list of FAT Chains in fsstat could give the incorrect impression that those were the only allocated sectors, so it was decided that this part of the output should be hidden for exFAT.

= Time Information =

ExFAT stores the local time in its timestamp fields, so the notes in [[FAT_Implementation_Notes#Notes_on_Timezones]] also apply 

here. However, exFAT does add some additional issues.

== Last Accessed Time ==

In testing, it does not appear that the last accessed time is ever updated from a file being accessed. It does change when a file is modified.

== Timezones ==

Timezone information for the three timestamp fields are also stored along with the DOS-format timestamps. However, these three fields are not found in the original specification, and there seem to be differences in the way the timezone is stored between exFAT implementation (see the next section). The timezone fields are empty in some older versions of Windows, such as Vista SP1. At present, TSK does not store this time zone information.

== Mac OS Differences ==

Through analysis, it was found that exFAT images created on Mac OS store time information differently than the Windows versions.

This is the File Directory Entry from a file created with Windows 7 (UTC-5:00), at 11:27 AM local time on 2013-12-31:

<tt>000230E0 85 02 8B B6 20 00 00 00 '''6E 5B 9F 43''' 73 5B 9F 43<br>
000230F0 73 5B 9F 43 18 00 '''EC''' EC EC 00 00 00 00 00 00 00</tt>

*Create time: 0x5B6E => 11:27:28
*Create time: 0x439F => 2013-12-31
*Create timezone: 0xEC = -20; Timezone is in 15-minute intervals, so this represents UTC-5:00

All that data is correct. Now here is the File Directory Entry from a file created on a Mac (UTC-8:00), at 10:11 local time on 2013-12-31:

<tt>000231E0 85 03 D4 40 30 00 00 00 '''5D 11 21 44''' 5D 11 21 44<br>
000231F0 5D 11 21 44 A9 AD '''A0''' A0 A0 00 00 00 00 00 00 00</tt>

*Create time: 0x115D => 2:10:58
*Create date: 0x4421 => 2014-01-01
*Create timezone: 0xA0

Limited testing suggests that the high order bit of timezone 0xA0 indicates that it is negative, and the rest is used as above, which gives us -(0x20) = -32, which would be UTC-8:00. This is correct, but clearly a different calculation than the Windows version.

Additionally, what should be local time is off by 16 hours. When set to GMT-5, the local time is off by 10 hours. It almost seems like they start with the UTC time and then go the wrong way with the offset. More testing is required.