I had the opportunity recently to borrow a MacQuisition licence from our imaging lab for a few days. It isn’t a tool which I’ve had much reason to use before. Given the limited support for Apple’s APFS file system among forensic tools (X-Ways and EnCase have some support now; I don’t have access to BlackLight but I expect it is pretty good.), an alternative available to digital forensic analysts is to simply copy files and directories from the source device. I was curious about the changes that might be introduced during such a logical collection from macOS to a Windows environment.
During my investigation I discovered that some metadata is lost (perhaps inevitably) and that others are transmuted to fit the destination file system. This is certainly noteworthy in the context of a forensic acquisition from macOS. But under other circumstances the same changes could prove to be the source of evidence. Since these artefacts are created when files are moved from one file system to another, they could demonstrate such movement and be clues to the provenance of the files.
This is not a review of MacQuisition, and I do not recommend using logical file collection to FAT or NTFS as your main method to acquire data from macOS for forensic analysis. For many reasons I think that the easiest option available to examine a macOS exhibit is to do so on another Mac. Not least among those is to avoid the transformations I describe in this article.
Timestamps
On Unix like operating systems, one might use a tool such as cp or rsync to copy files from one location to another. MacQuisition uses the latter in its Data Collection mode (more on that later). Regardless of the program used, the atime (data last accessed) and ctime (status last changed) attributes will be updated on the destination. The other two timestamps, mtime (data last modified) and birthtime (file creation), are preserved.
There doesn’t seem to be a way around this. MacQuisition does however collect metadata (using stat) from the source files beforehand.
Extended File Attributes
Extended file attributes can be an important source of evidence on macOS. These tend to contain extra metadata fields such as more timestamps than the previously mentioned four attributes (there are a couple of examples in the screenshot below). In recent versions of macOS, even the contents of a resource fork are stored in an extended attribute (com.apple.ResourceFork).
In the screenshot shown above, there are six extended attributes listed which are associated with a picture file (a screenshot in fact). What happens to these when the file is copied to a FAT-formatted drive? The Apple Double format is used to create two files on the destination for each file copied to a FAT volume. The first has the same name as the source file and will contain the contents of the data fork. The second has the name of the source file prepended with “._” and shall contain extended attributes and the resource fork.
The situation illustrated in the screenshot above will be familiar to many people. These are some files I’ve copied from macOS to Windows on a USB flash drive. Notice how most (but not all) of the files have hidden “._” counterparts. In the following example, I use PowerShell to view the contents of a file called “._BaseSystem.dmg“. (I wonder why rsync is in there at offset 0x83…)
How about on NTFS? Here the NTFS driver creates alternate data streams to store the extended attributes. In the following example, I enumerate the streams associated with a screenshot captured on macOS. A couple of those weren’t present as extended attributes on the source. Can you tell which ones they are?
On macOS a resource fork can be accessed in a couple of ways typically. One is through the extended attribute com.apple.ResourceFork. The other is as a regular file by appending “..namedfork/rsrc” to the end of the file’s path. On NTFS, the resource fork gets stored in a data stream named AFP_Resource.
Another interesting alternate data stream is AFP_AfpInfo. The value of the extended attribute com.apple.FinderInfo ends up in here; a separate com.apple.FinderInfo data stream is not created. The NTFS data stream named AFP_AfpInfo could also contain information relating to backups and ProDOS. The following example shows the extended attribute relating to an alias file and the corresponding alternate data stream.
That rsync extended attribute (rsync.%stat) has popped up a few times now. What’s that all about? MacQuisition makes use of rsync, which is a very popular file transfer tool, and one of the options passed to that program (--fake-super I believe) results in this new alternate data stream being added to every file that is copied. This new stream is used by rsync to store additional metadata which are not supported by NTFS. Let’s look at an example.
Taking a look at the rsync source code, it becomes apparent that these numbers represent the following metadata: mode rdev_major,rdev_minor uid:gid (an explanation of the mode field’s format can be found in the XNU source code).
What would happen if the source file already had an attribute with the same name? I thought it would be fun to try to find out. The following image shows an extended attribute being created on macOS, with a distinctly invalid value.
Then I tried to perform an extraction with MacQuistion, just as I had done previously, but it wouldn’t extract the file. In fact, it would extract nothing at all if that file was part of the list of items to acquire. At least there was a log file though.
Evidently rsync did not like that. Imagine the mischief one could make by adding that attribute to all the files on a drive!
Symbolic Links
FAT file systems do not support either symlinks or hard links. So Apple made their own implementation of symbolic links using ordinary text files. These files contain four newline separated fields: the string XSym, the length of the symbolic link in decimal (four digits), the MD5 hash of the symlink and the symlink itself. The symlink is padded with spaces to make up 1024 bytes. As a result, these files are always 1067 bytes long.
NTFS does have native support for symlinks. But when I copied some using MacQuisition I got IntxLNK files. This seems to be a consequence of the NTFS driver that MacQuisition uses, and there’s some information online which indicates that the file format is related to Interix, Microsoft’s implementation of Unix.
Conclusion
Here I’ve considered some examples of metadata that can be lost or transformed during a data collection process. There are also circumstances when the data we collect is itself transformed, sometimes by the source device itself. Android and iTunes backups are two notable examples that come to mind. Exporting emails from a mail server is another.
Digital forensic analysts will want to be very clear about the source and representation of the data they examine. It is important to understand the limitations of the methods and tools which they use. Changes, such as the ones described here, and other caveats could have an impact on their analysis. It is just as important that these limitations are documented properly, so that any subsequent analysis, or indeed the customer, can be well informed.
Arun Prasannan
Principal Analyst (Research & Development)
The post Messing about with Windows metadata when analysing a Mac appeared first on CCL Group.
Article Link: https://cclgroupltd.com/messing-about-with-windows-metadata-when-analysing-a-mac/