BFIP4Griffeye V4.2 A Big Update! – APFS Support

After some long hours coding, testing, and squashing bugs, I feel like the next big release of BFIP is ready for primetime! There’s still so much more I want to do with the tool. However, I felt the features introduced in this update were worth prioritizing and getting pushed out. There are tons of little tweaks throughout the update, and probably even more changes I’ve forgotten about in the process. The biggest update is the addition of support for APFS formatted forensic images into the Breakpoint Processing Engine!

This involved numerous enhancements to the disk analysis module, with lots of additional logic and checks to identify pool Volumes any APFS containers they might hold.

Here’s a run-down on the general flow of BFIP when using the updated Breakpoint Processing Engine to handle APFS images:

APFS Workflow

• Conducts a search in the configured forensic Images folder looking for supported forensic Image types, then adds them to a processing queue.
• Iterates over the queue of forensic images and sends them off to their own Breakpoint Processing Engine subprocess in an orderly manner.
• Each forensic image is evaluated using a series of checks to see if it is a properly formatted disk, gather partition-table information, file-system identifiers, etc. If during this check, indicators of an APFS pool are identified, another series of checks will be initiated to inspect the suspected APFS pool further.
• If a valid APFS pool is found, a series of information will be gathered for each container in the pool to include its ‘Role’, Encryption Status, physical-locations, and more.
• Next, the information identified about APFS containers, partition formats, etc, will be passed through a series of checks that will conduct unallocated carves in Partitions that contain traditional formatting schema’s and have a possibly of storing unallocated data. Any partitions/volumes that were previously identified as holding valid APFS containers will be sent off to a series of new APFS processing modules.
  • The APFS modules will evaluate the container for its encryption status flag. If it’s encrypted, any further APFS processing is terminated. If the container is decrypted, a series of process will attempt to parse and extract the file-structure and it’s metadata.
  • Based on this extracted file-system information, a series of file extractions processes will be initiated recovering specific filetypes based on what was selected in the ‘Breakpoint Carving Options’ menu. This can include common filetypes for images, video, office-docs, PDFs, and archives.
    • During this file recovery process, the files will be simultaneously hashed, and then be saved to the standard BPE Carved Files folder in the generated case folder.
      • The exact recovery process speed can vary greatly depending on the number of CPU cores available on the processing machine. The Breakpoint Processing Engine as configured to use a minimum of (3) file extraction sub-threads at one time; but will intelligently scale up to using more on systems with more additional CPU cores available.
• After the APFS modules complete the extraction of all [configured] located files, a VICS JSON will then be generated based on a combination of any files recovered during an [applicable] PhotoRec carving, plus those recovered from located APFS containers.
• Finally, after all forensic images have been processed, any generated JSONs and associated forensics images will then be sent to Griffeye for automated import and processing. Or…, if ‘Carve Only‘ [for DI Core users] was selected, the recovery process will terminate, and the examiner can manually handle any further processing of the JSONs and data generated from the selected forensic images.

Additional Notes:

Please understand that APFS support is still in active development and all features are not fully implemented.

Some of the bigger items that are not yet implemented include:

• *FileVault encryption is not yet supported in this initial release. *
  • If File Vault encryption is detected by BFIP during import, the processing of that specific image will be skipped, and BFIP will move onto the next available forensic image in the processing queue.

• *APFS Snapshots are not yet supported in this Initial Release. * APFS Snapshots now supported as of version 5.0!
• APFS processing speed: APFS requires additional interpretation to conduct extraction of each file and its associated metadata from its respective containers. This has an inherent impact on the speed at which APFS containers are processed, versus the comparatively much faster speed of a simple carve of unallocated space. In order to speed up this process the Breakpoint Processing Engine is employing a multithreaded approach to allow for simultaneous extraction of multiple files from a single container. The rate at which this occurs and the number of threads dedicated per process is still being optimized. As further testing and feedback comes in, there will likely be room for further speed gains as the threading process is optimized to scale with a wide range of CPU cores users may have available.
• In addition, testing has shown a considerable speed decline when reading from a forensic image located on a SMB network drive/share. Even with high bandwidth 10Gb network connections, and fast network storage, this is not recommended. Processing APFS image from a local drive is highly recommended.
• All the other changes and updates included can be found in the changelog

Download:

BFIP 5.31

MD5:943925f200ac50765311b039078c654e

BFIP V5 - User Manual