Comparison of our tool afro (APFS file recovery) with Blackbag Blacklight and Sleuthkit

At this years ARES conference, Jonas Plum (Siemens) and me (Andreas Dewald, ERNW Research GmbH) published a paper about the forensic analysis of APFS, file system internals and presented different methodologies for file recovery. We also publicly released a tool implementing our presented approaches, called afro (APFS file recovery).

APFS is the file system for Apple devices that is used by default on all current iOS mobile devices, as well as macOS since High Sierra, and is thus currently rolled out on a large number of devices. By using afro, we evaluated and compared the different approaches amongst each other and identified the method that so far delivers the best results and compared it to photorec. This showed that AFRO outperforms photorec on the evaluated APFS dataset. In the presentations of this research we were often asked if other tools like Blackbags Blacklight do not already support this recovery process. So, we decided to compare the file recovery capabilities of BlackLight and afro. We wanted to compare afro to the sleuth kit as well, as at the DFRWS conference it was discussed about adding APFS Support to The Sleuthkit Framework, but no implementations are public yet.

We present the results of this comparison in in remainder of this blogpost.

Stages of file deletion


In APFS different stages of deleted files exist. Some deleted files are still be referenced from versioning structures in the file system. These can be recovered just by parsing the file system. Partially unreferenced files are not referenced from the root file system hierarchy any more. Parsing cannot restore those files and the goal of afro was to restore partially unreferenced files as well. Completely unreferenced files and file fragments can only be recovered by file carving.

APFS Parsing
APFS is structured in a single container that can contain multiple APFS volumes. The container superblock is the entry point to the file system and is located in the first block of the file system. The container superblock contains references to the volume superblocks, which in turn point to their own root node and so to all file nodes. These nodes can be parsed to obtain file name, file metadata and file contents.


By design, APFS offers the ability to recover certain states of the file system including old or deleted versions of files. The container superblock contains a reference to the checkpoint structure. The checkpoint references the preceding container superblock, which contains information in an older state of the file system. In this way multiple older states can be recovered by parsing this chain of container superblocks.

Recovery Methodologies
APFS is a copy-on-write file system and thus each block is copied before changes are applied. Therefore, a history of all files which were not overwritten and according file system structures exist. This results in a high number of artifacts that can be utilized in forensic file recovery.

From those artifacts, we identified three different approaches for file recovery that rely on different artifacts as entry points, which we present in this section: The signature-based file system metadata carving methods “NXSB carving” and “APSB carving”, as well as the heuristic file system metadata carving method “node carving”. All methods iterate the file system in blocks of 4096bytes, which is the smallest block size observed in APFS. Those blocks are checked for metadata structures which in turn are parsed and used to extract files.

NXSB carving APSB carving Node carving
  1. Iterate file system in blocks of 4096 byte1
  2. Check whether bytes 32 to 36 equal ‘NXSB’
  3. Verify checksum to eliminates false positives
  4. Parse identified container superblock & descent into all structures inside this container
  1. Iterate file system in blocks of 4096 byte1
  2. Check whether bytes 32 to 36 equal ‘APSB’
  3. Verify checksum to eliminates false positives
  4. Parse identified volume superblock & descent into all structures inside this volume
  1. Iterate file system in blocks of 4096 byte1
  2. Check whether bytes 24 to 26 (object type) equal ‘0x2’ or ‘0x3’
  3. Check if bytes 28 to 30 (subtype) equal ‘0xe’ (file subtype)
  4. Verify checksum to eliminates false positives
  5. Parse file node


Image Generation
For the ARES conferences we created a 100MB APFS image “wsdf.dmg”. We added a hierarchy of files of different types and folders to this image. Afterwards the “document” folder, which contains a pdf, txt, docx, pptx, and a xslx file was deleted. The image can be downloaded here. We use that simple image as a testcase for both tools.

Blacklight parses the filesystem and lists all non-deleted files. The extracted metadata is correct. It does not parse any of the deleted documents in the “document” folder. Even the carving process on unallocated space was not able to recover well-known file formats like pdf, docx, xslx and pptx. A screenshot of the recognized files can be seen below.


With afro we used the carving of volume superblocks to recover the data from the image.

afro -e bodyfile -e files -o 40 carve apsb wsdf.dmg

afro recovers all documents which existed in the “document” folder. They are even recovered twice: from the .Trash folder as well as the original location.


APFS support is still a developing topic and even blacklight’s advertised “leading APFS support” lacks recovery capabilities. afro does not handle some APFS features like snapshots, encryption or compression but is still the only tool we are aware of to recover all files from the image. We hope recovery from APFS will improve in the future and commercial tools like blacklight as well as open source solutions like the sleuth kit will add or enhance APFS support, as APFS is already rolled out widely.


P.S.: See also Jonas’ blogpost.

Continue reading

Reading the BlueCoat FileSystem

You may remember our last post regarding the SGOS system and the proprietary file system. Since then, we got access to a newer version of the system ( Still not the most current one (which seems to be nor of the 6.6.x branch (which seems to be though. As this system version also used the same proprietary filesystem (although it initially booted from a FAT32 partition), I decided to take a deeper look into this.

Continue reading “Reading the BlueCoat FileSystem”

Continue reading