After years of speculation, Apple finally announced that they were developing a new file system at the Apple Worldwide Developers Conference (WWDC) last year. Aptly named the Apple File System (APFS), the latest development from Apple is continuing to raise heads and is being watched with interest by technology lovers, everyday iPhone users and forensic professionals alike.
The new system is being developed to replace Apple’s now-ageing Hierarchical File System Plus (HFS+) file system that was developed in 1998 (note: HFS+ is an improved version of HFS, released in 1985!). Since then, the technology market has evolved to a place that the features of this file system were not designed to handle. Despite coping remarkably well with these changes, HFS+ is finally beginning to give Apple a big enough headache to make it worth a total re-write.
Apple has aimed this new file system at almost all of their devices, from Apple TV and Watch, to iOS and desktop MacOS. This means there will be sweeping changes across the board to the way the disk and files will be accessed by programs, applications and the operating system itself.
There are many features of this file system, but to keep this article brief, I will only be discussing the features that will be of key note to forensic practitioners.
So what is this new file system that is sure to cause revolution in the technology sector whilst simultaneously causing upheaval in the forensics industry?
With solid-state drives and flash memory giving speeds that were not dreamed possible in 1998, the APFS is being designed from the ground upwards with speed in mind, the key to this coming from the copy-on-write design.
Copy-On-Write is not a new technique and has been in use in the software engineering world since the late 90s. However, more recently, this technology has moved across to the world of file systems. The idea behind the technology is simple: If a user makes an exact copy of a file, there is no need to make two copies. Instead, just have one file that is linked from two different locations – the result is that only one copy is made on the actual hard drive and less time is spent writing data that is exactly the same, bit-for-bit.
To illustrate this, the below example shows an image of a dog being saved on the hard drive using a single sector.
Copy-On-Write achieves its superior disk-space usage and speed by pointing the user towards the same file on the hard drive sector, whilst appearing to the user as two separate image files altogether.
If the user then deleted the first file, the reference to the file is deleted, with the second image still pointing to the same place and appearing as the only image.
From a forensic investigation standpoint, this fact is both a positive and negative. File carving tools used on this file system should be far quicker performing their tasks – searching for a file’s signature will only pull back one file and not every single copy that is found on the device. This will make life easier by effectively performing a deduplication prior to the utilisation of forensics tools as opposed to afterwards as is usually standard.
That being said, it still remains to be seen if this will cause issues on questions such as ‘how many instances of this image were stored on the machine?’, where the currently available tools will have to be reworked to accommodate this problem.
With Apple often leading the way in securing their user’s data, they have ensured that the file system has built-in support for encryption at a disk level. This results in a robust physical security strategy that will ensure a stolen laptop or hard drive could not be read without the necessary encryption keys.
For any forensic practitioners reading this article; I don’t need to tell you the issues that encryption can cause.
Checksums, or unique fingerprints of data, can be used for ensuring data remains unchanged or damaged. The APFS promises to produce checksums of the metadata surrounding the files which is definitely a step in the right direction. This results in a file system that is unlikely to corrupt, or should at least make it easy to determine the location of any corruption should it occur.
A further step that would have been useful, especially from a forensic viewpoint, is the checksum creation for user data, such as word files or images. APFS does not do this which is a shame as the positive implications this could have had for forensics would have sped up investigations significantly.
The creation of checksums, particularly MD5 and SHA, takes a considerable amount of time for each item of evidence that arrives at a forensics company, even with a large amount of processing power. To have this facility built into the file system, it may be possible to extract the checksums from the file system, which would render the current time-consuming process of checksum generation obsolete. Although, an investigation would need to be carried out on the trustworthiness of these checksums; particularly the ability of the user to alter them.
A feature that has been introduced in the file system, and one that has gone without much mention in the surrounding media attention, is the introduction of Space Sharing. This feature allows different file systems to share the same free space on a hard drive. This means that, in theory, the hard drive could have several operating systems running that do not need to have a fixed, pre-allocated size built in, as traditional file systems do when using the Master Boot Record or Volume Boot Records.
This has implications in parsing software that is designed to allow the file system to be mounted and read in a read-only forensic manner, such as leading software EnCase. These systems rely on an understanding of how the underlying file system organises and displays the data stored on the hard drive. By writing a brand new method of space allocation, new challenges on how to ‘recreate’ the file system in a virtual environment will have to be addressed.