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
Breaking, Misc

Vulnerabilities in Sitefinity WCMS – A Success Story of a Responsible Disclosure Process


For those who never heard of Sitefinity before, it is an ASP.NET-based Web Content Management System (WCMS), which is used to deploy and manage applications as other CMS‘s do. A bitter quick glance at Sitefinity and its advantages can be found in this overview.

Delving into the core of this blog post, recently I had the opportunity to look at Sitefinity WCMS in which I found two reflected Cross Site Scripting (XSS) (CVE-2018-17053 and CVE-2018-17056), a stored XSS (CVE-2018-17054) and an arbitrary file upload (CVE-2018-17055) vulnerabilities.

I admit that the vulnerabilities mentioned in here are classical ones, but because of the huge spectrum of the platform versions affected, I thought it would be helpful to send a loud signal to whomever are using Sitefinity, so they can apply fixes and be safe 😉

Continue reading “Vulnerabilities in Sitefinity WCMS – A Success Story of a Responsible Disclosure Process”

Continue reading

A little KeePass Mea Culpa…

Some weeks ago, I tweeted about grabbing clipboard content from KeePass with some PowerShell. From some reactions to this tweet, and after reading it a couple of times again, I realize it was sending the wrong message, and I would like to take a bit more than 280 chars to clarify what I meant when I posted that tweet…

TLDR: Password managers are a must, not using one exposes you to far more risks than using one. Do it.  Continue reading “A little KeePass Mea Culpa…”

Continue reading

Security Advisory for VMware vRealize Automation Center

During a recent customer project we identified several vulnerabilities in the VMware vRealize Automation Center such as a DOM-based cross-site scripting and a missing renewal of session tokens during the login. The vulnerabilities have been disclosed to VMware on November 20th, 2017. A security advisory for the vulnerabilities has been made available here on April 12th, 2018. Continue reading “Security Advisory for VMware vRealize Automation Center”

Continue reading

White Paper on Incident Analysis and Forensics in Docker Environments

In this article, we describe the impact of the increased use of Docker in corporate environments on forensic investigations and incident analysis. Even though Docker is being used more and more (Portworx, Inc., 2017), the implications of the changed runtime environment for forensic processes and tools have barely been considered. We describe the technological basics of Docker and, based on them, outline the differences that occur with respect to digital evidence and previously used methods for evidence acquisition. Specifically, we look at digital evidence within a Docker container which are lost or need to be acquired in different ways compared to a classical virtual machine, and what new traces and opportunities arise from Docker itself.

Continue reading “White Paper on Incident Analysis and Forensics in Docker Environments”

Continue reading

An Update of PenTesting Tools that (do not) Support IPv6

As you may remember, back in 2014 we published a whitepaper (compiled by Antonis Atlasis) on the support of IPv6 in different pentesting tools. This is almost three years ago and we thought it is time for an update. In short not much has changed. Most of the tools which didn’t support IPv6 are still not supporting it or haven’t got any update since then.
This post will  cover the tools where we could identify some progress on supporting IPv6.

Continue reading “An Update of PenTesting Tools that (do not) Support IPv6”

Continue reading