We continue to see more and more Apple devices come through our doors here at Digital Discovery. As such I do what I can to increase my knowledge in this area on a regular basis. I often rely on Sarah Edwards for assistance. She truly is a genius, not like the so-called geniuses at the Apple store, a REAL genius. Anyways…
The type of work we tend to investigate the most is intellectual property theft. More often than not, these cases center on a former employee’s use of external USB devices to transfer data from their work computer. Whether the data belongs to the company or an individual is up to the court to decide, my focus is on what the data says.
I’ve been doing some testing to attempt to show how file movements on MacOS systems affect the metadata on the destination. I thought I’d share my findings. This is a work in progress as there appears to be some inconsistencies that I’ve not yet figured out.
HFS+ has five distinct date and time stamps. These are as follows:
- Created
- Modified (last written)
- Accessed
- Record Change
- Added Date
Created, modified and accessed are all pretty straight forward. Record change is when the file’s metadata is changed in the catalog (similar to the $MFT in NTFS).
“Added Date” is a relatively new discovery. This is when a file was copied or moved to its current location. If a file exists on a HFS+ volume and it is moved to another folder on that same volume then this metadata value is updated to reflect that move. If you’re using X-Ways Forensic, this value is populated under the “Created²” field.
File Creation on HFS+
When a new file is created on a HFS+ volume the dates and times are as follows:
- Created -Â Time of creation
- Modified -Â Time of creation
- Accessed -Â Time of creation
- Record Changed – Time of creation
- Added Date – Not populated
Duplication of files on HFS+
When a file is duplicated (right click on a file and select “Duplicate” from the context menu) on a HFS+ volume the dates and times are impacted in the following way:
- Created -Â Inherited from the original
- Modified -Â Inherited from the original
- Accessed -Â Time of duplication
- Record Changed -Â Time of duplication
- Added Date -Â Time of duplication
Modifying of files on HFS+
When a file is modified (edited) on a HFS+ volume the dates and times are impacted in the following way:
- Created -Â Unchanged
- Modified -Â Time of modification
- Accessed -Â Time of modification
- Record Changed -Â Time of modification
- Added Date -Â No change
Something to point out here is the “Added Date” value. If I duplicate a file and then edit the contents of that duplicated file, the “Added Date” field will still show the date and time of the creation of the duplicate. So here you’d have the creation time of the original, the creation time of the duplicate, and the modification time all for the same file.
HFS+ to HFS+
If a user copies or moves files from one HFS+ volume to another the dates and times are impacted, on the destination, in the following ways:
- Created – Inherited from the original
- Modified – Inherited from the original
- Accessed – Updated to time of copy
- Record Changed – Updated to time of copy
- Added Date – Updated to time of copy
All other metadata attributed to the files is stored in the stored in the HFS+ file system.
HFS+ to ExFAT
ExFAT only has 3 timestamps. If a user copies or moves files from a HFS+ volume to ExFAT the dates and times are impacted, on the destination, in the following ways:
- Created – Inherited from the original
- Modified – Inherited from the original
- Accessed -Â Updated to time of copy
There is more activity than simply updating timestamps for files. This is discussed in the metadata section later.
HFS+ to FAT32
Like ExFAT there’s 3 timestamps, but the Accessed time is only attributable to a day. If a user copies or moves files from a HFS+ volume to FAT32 the dates and times are impacted, on the destination, in the following ways:
- Created – Inherited from the original
- Modified – Inherited from the original
- Accessed -Â Updated to date of copy
There is more activity than simply updating timestamps for files. This is discussed in the metadata section later.
ExFAT or FAT32 to HFS+
If a user copies or moves files from either a ExFAT or FAT32 volume to HFS+ the dates and times are impacted, on the destination, in the following ways:
- Created – Inherited from the original
- Modified – Inherited from the original
- Accessed – Updated to time of copy
- Record Changed – Updated to time of copy
- Added Date – Updated to time of copy
Metadata and “._” files
Because files stored in HFS+ volumes typically hold a great deal more metadata than exists in other volumes (extended attributes, etc.), any file being copied from a HFS+ volume to a ExFAT or FAT32 volume will also have a matching hidden file created by MacOS. For example, if I copied a file named “me.jpg” from a HFS+ volume to an ExFAT or FAT32 volume, a hidden file would also be created. This hidden meta-file would be named “._me.jpg”. The timestamps for such a file would be as follows:
- Created -Â Time of creation
- Modified -Â Time of creation
- Accessed -Â Time of creation
This means that, even if the other timestamp metadata fields are changed through editing or accessing the file, we can still know the exact date and time that the file was copied to an ExFAT or FAT32 volume from looking at the creation date of the associated meta-file.
A note on Access times on MacOS
Access times are a little odd on HFS+ volumes. Apparently the access time field is updated if you select a file and click on “Get Info” from the context menu. However the access times are NOT updated when a file is opened and not saved(?).
If, however, you either use “Get Info” or open a file (and not save it) on either ExFAT or FAT, the Accessed metadata field is updated. The related meta-files also have their Accessed dates and times updated.
2 responses to “MacOS File Movements”
[…] Thanks to Lee Withfield for his research. You will find the article here. […]
[WORDPRESS HASHCASH] The comment’s server IP (80.74.146.170) doesn’t match the comment’s URL host IP (80.74.146.167) and so is spam.
Hey Lee,
Could the inconsistencies be attributed to different versions of OS X/MacOS? Did you perform these tests only in the latest MacOS version?
File movement operations are implemented in the OS, not in the File System structures. That’s why we have different behaviors for each of XP/Vista/7/etc.
Great start on documentation!