k1nd0ne

In the objective of implementing the modern Apple File System (APFS) module of the exhume toolkit, a test disk image from a recent macOS system was required. In practice, acquiring physical data from modern Apple hardware (especially with T2 / security constraints) quickly narrows the tooling landscape, and Cellebrite BlackLight / MacQuisition seems to be the default choice.

After acquiring disk image of a modern Apple computer, the output format was AFF4 (Advanced Forensics File Format v4). After not being able to convert this image to a raw disk image on my operating system and, in a quest to make the digital forensics investigation platform agnostic, the next step was obvious: add AFF4 support to exhume_body and make it reliable enough to feed an APFS parser.

In this blog post, I describe that journey and the key findings along the way. The important part is this: MacQuisition produces an AFF4 that strongly diverges from what most public AFF4 descriptions (and many OSS parsers) that I have found assume, which makes existing implementations fail or perform poorly.

Let’s solve this properly.

Happy New Year! A quick update on the current state and features of the Thanatology project, as well as its goals for 2026. If you want to learn more about this project, there is a blog post series about it starting here

Discover the current features of the Thanatology Project by watching the following video.

This blog post is part of the Thanatology blog post series. If you haven’t checked it out, I recommend reading the following first:

• Thanatology part 1: Introduction to the Thanatology project
• Thanatology part 2: Multiple disk images formats handling using the Exhume ToolKit
• Thanatology part 3: MBR and GPT forensics with the Exhume ToolKit.

In the previous part, we discovered how to perform partition discovery for the MBR and GPT layouts. The next step in our digital forensics examination process of a disk image is to identify the type of Filesystem present on a given partition and extract relevant data. In this blog post, we will first dive into the concept of file systems in general. Next, we will explore how the Exhume toolkit is designed to propose a way to understand multiple kinds of file systems and introduce an abstraction module. Finally, some updates on the Thanatology project will be proposed.

Following the parity release of the Volatility3 v2.26 framwework, we updated VolWeb to add the latest plugins, fix some issues and add some new features ! Learn more about the news in this blogpost.

This blogpost is part of the Thanatology blogpost series. If you haven’t check it out, I recommend reading the following first:

• Thanatology part 1: Introduction to the Thanatology project
• Thanatology part 2: Multiple disk images formats handling using the Exhume ToolKit

In this blogpost, we will dive into the concepts of GPT and MBR partition schemes and explore them using Exhume Partitions.

This blogpost is part of the Thanatology blogpost series. If you haven’t check it out, I recommend reading the following first:

• Thanatology part 1: Introduction to the Thanatology project

In this blogpost, we will dive into the concepts of disk images and how digital forensics examiners can use the Exhume toolkit to read data transparently from different formats. First, we will give an overview of what is a disk image and describe some of the existing formats one may encounter during a digital investigation. Next, we will explore how Exhume Body is providing an abstraction layer to those formats to read data agnostically.

In digital forensics, tools are only as valuable as the investigator’s ability to understand and explain their output, especially when presenting evidence in court. Beyond simply extracting data, the methodology behind how artifacts are collected and interpreted plays a critical role in admissibility, reliability and credibility.

This blog post series introduces the Thanatology Project, an open-source, cross-platform digital forensics framework currently under development. Built on top of the Exhume ToolKit (a modular set of Rust-based forensic tools), Thanatology combines performance, transparency, and modern design via a Tauri-based desktop interface. Designed for law enforcement and digital forensic professionals, the project emphasizes not only artifact collection and presentation but will also try to provide help for interpretation.

For example, when analyzing EXTFS file systems, Thanatology will try to offers guidance on timestamp meanings and includes complete extraction details suitable for annexing to formal reports.

The blog series will cover:

• An overview of the Thanatology project and its goals.
• A high-level introduction to the Exhume tool suite.
• Deep dives into each Exhume module and its specific forensic use case.
• Updates on the project development.
• Interesting research techniques we found during our journey.

While Thanatology is not intended to replace established tools, it will attempt to offers a modular and modern alternative ideal for cross-verifying findings or integrating into custom workflows. This blogpost series is mainly here to provide the community with updates, technical knowledge and any interesting subjects we found along the way.

Windows executable analysis is a key aspect of Digital Forensics and Reverse Malware Engineering. Identifying the capabilities of a program can help to target potential malicious code and orient the later reverse code analysis phase. In this blogpost, we will dive into the structure of the Windows Portable Executable (PE) and how we can extract the imported functions in the context of memory analysis.

Windows executable analysis is a key aspect of Digital Forensics and Reverse Malware Engineering. Identifying the capabilities of a program can help to target potential malicious code and orient the later reverse code analysis phase. In this blogpost, we will dive into the structure of the Windows Portable Executable (PE) and how we can extract the imported functions in the context of memory analysis.

In the Digital Forensics ecosystem, the field of memory forensics can help uncover artifacts that can’t be found anywhere else. That can include deleted files, network connections, running processes, rootkits, code injection, fileless malware and many more.

Microsoft introduced the hibernation feature in Windows 2000, allowing systems to be powered down while preserving their volatile state. This is achieved by saving RAM contents and processor context to a file called hiberfil.sys before shutting down inside the root folder of the filesystem drive. When the computer is turned on again, the system restores the volatile state from the saved file. Hibernation files are valuable for digital forensic professionals as they store temporary data from RAM to non-volatile storage, eliminating the requirement for specialized tools on the target device.

The Hibernation file structure has evolved in time. In this blog post, we will dive into the structure of the modern Windows hibernation file and propose a new translation layer for the volatility3 framework to create a raw memory image from a hibernation file.