🦉 Thanatology part 2: Multiple disk images formats handling using the Exhume ToolKit
This blogpost is part of the Thanatology blogpost series. If you haven’t check it out, I recommend reading the following first:
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.
Disk images in digital forensics
A disk image is a complete copy of the contents of a digital storage device, such as a hard drive, solid-state drive (SSD), USB stick, CD/DVD, Virtual Machine, etc. It captures every bit of data stored on the device, including user files, system files, and even hidden or deleted information. In digital forensics, disk images are crucial because they allow investigators to preserve and analyze data without altering the original evidence. By working from an image rather than the actual device, forensic analysts ensure the integrity of the evidence is maintained, which is essential for legal proceedings and maintaining a chain of custody.
Logical Vs Physical Acquisitions
There are two primary types of acquisitions in digital forensics: physical acquisition and logical acquisition.
Physical acquisition involves creating a bit-for-bit copy of the entire storage device, including slack space, unallocated space, and hidden partitions. This type of acquisition is more comprehensive and enables deeper forensic analysis, such as recovering deleted files or analyzing remnants of previously stored data.
Logical acquisition, on the other hand, captures only the files and directories visible to the operating system. While faster and less storage-intensive, logical acquisition may miss important data that resides outside the active file system, making it less thorough for forensic purposes.
Choosing between logical and physical acquisition depends mostly on the context of the digital forensic investigation case. However a chain of custody must be respected in each case, documenting the actions taken before, during and after the acquisition.
The disk image formats ecosystem
When performing a full acquisition of a disk (whether it is a physical disk or an existing disk image from a Virtual Environnement for example without compression) you will always need to store the forensic copy on a storage device that possess at least the same storage capacity as the source disk copy you have to make. The storage capacity is increasing with the years which means the need to find ways to compress those images to be able to store more data was growing. That’s where some new disk image formats come into play.
Several disk image formats can be used digital forensic investigations, each with specific features and use cases. The most common formats include raw (dd), Expert Witness Format (EWF or. E01), and Advanced Forensic Format (AFF). The raw format is a simple sector-by-sector copy of the drive and is widely supported due to its simplicity and universality. However, it does not include metadata or compression which can be a bummer when facing situations with terabytes of data. EWF, developed by Guidance Software, is widely used in professional forensic environments because it supports metadata storage (like case number, examiner notes), compression, and integrity checks. If you are interested in EWF, we made a blogpost about it. AFF is an open-source format designed to be flexible and extensible while also supporting compression and metadata. The choice of format often depends on the tools available, the complexity of the case, and the need for efficient storage and documentation.
Last but not least: the Virtual Disk Image formats like qcow, qcow2, vmdk , vdi, vhd or vhdx are used primarily for virtualization and emulation. Not all these formats come with compressions, but the layout is different for each and require parsing operations to obtain raw data sectors. Digital forensics examiner can also encounter such disk image format when seizing a virtual machine for example that is stored within the building of a cloud provider service. The difference (and sometimes advantage) when stepping upon such cases is that the disk image relevant for the case is already there, it functions just like a physical disk image would in a traditional forensic context. This allows to directly parse the file system, recover deleted files, analyze partition structures, and perform low-level searches without the physical disk extraction and digital copy phase. Virtual disk image also often has the capability of storing snapshots which can be very valuable for the investigator to be able to retrieve data that changed in time. If you are interested about those disk image formats, we made a blogpost about VMDK.
What are we left with?
When investigators deal with disk images in multiple formats, the main problem faced is compatibility and interoperability across forensic tools and workflows. Each image format has its own structure, metadata handling, compression method, and supported features, which can create significant challenges during analysis, validation, and evidence handling. The usual methodology to maximize compatibility is often to use tools and operations to convert those specific disk images into raw disk images that can later be ingested into forensics toolkits, but it can be time consuming and even generate data-loss.
Exhume Body: Disk Image data abstraction
Exhume Body is one of the core components of the Exhume Tool Suite. It is one of the foundation modules which is trying to provide an agnostic disk image data abstraction layer for file system forensics. It is providing a way to read and seek through multiple disk image formats like if it was contiguous sectors of data like a raw image. Exhume body is designed to understand these multiple disk image formats and to perform the parsing and potential decompression operations on the fly when requesting data.
Exhume Body is enabling the user to read and seek through data. Like most of the Exhume modules, the user can use either the command line interface or as a library. Let us now show some practical examples.
Using Exhume Body with the CLI
After installing exhume, we can provide the tool with the location of the target disk image, the number of bytes to read and an offset. Optionally, we can precise the format of the disk image. If no format is specified, the tool will try to discover the format automatically.
In the following output, we are reading the first sector (512 bytes) of an EWF Linux disk image we would like to investigate. We will pipe the result inside xxd.
[2025-06-15T09:32:08Z INFO exhume_body] Processing the file 'disk.E01' in 'auto' format...
[2025-06-15T09:32:08Z INFO exhume_body] Detected an EWF disk image.
[2025-06-15T09:32:08Z INFO exhume_body] Evidence : disk.E01
[2025-06-15T09:32:08Z INFO exhume_body::ewf] EWF File Information:
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Number of Segments: 1
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Acquisition Metadata:
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Case Number: OSDFCon Workshop VM1
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Evidence Number: 001
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Description: Compromised Webserver
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Examiner: Ali Hadi
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Notes:
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Application Version: ADI3.4.2.2
[2025-06-15T09:32:08Z INFO exhume_body::ewf] OS Version: Win 201x
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Acquisition Date: 2019 10 6 17 58 15
[2025-06-15T09:32:08Z INFO exhume_body::ewf] System Date: 2019 10 6 17 58 15
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Password Hash: 0
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Reserved: f
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Volume Information:
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Chunk Count: 1032260
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Sectors Per Chunk: 64 (32768 bytes)
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Bytes Per Sector: 512
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Total Sector Count: 66064608
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Chunk Information:
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Segment Number: 1
[2025-06-15T09:32:08Z INFO exhume_body::ewf] Number of Chunks: 1032260
00000000: efbf bd63 efbf bd10 efbf bdd0 bc00 efbf ...c............
00000010: bdef bfbd 0000 efbf bdd8 8eef bfbd efbf ................
00000020: bdef bfbd 007c efbf bd00 06ef bfbd 0002 .....|..........
00000030: efbf bdef bfbd 2106 0000 efbf bdef bfbd ......!.........
00000040: 0738 0475 0bef bfbd efbf bd10 efbf bdef .8.u............
00000050: bfbd efbf bd07 75ef bfbd efbf bd16 efbf ......u.........
00000060: bd02 efbf bd01 efbf bd00 7cef bfbd efbf ..........|.....
00000070: bdef bfbd 7401 efbf bd4c 02ef bfbd 13ef ....t....L......
00000080: bfbd 007c 0000 efbf bdef bfbd 0000 0000 ...|............
00000090: 0000 0000 0000 0000 0000 0000 efbf bd01 ................
000000a0: 0000 0000 0000 00ef bfbd efbf bdef bfbd ................
000000b0: efbf bdef bfbd c280 7405 efbf bdef bfbd ........t.......
000000c0: 7074 02ef bfbd efbf bdef bfbd 797c 0000 pt..........y|..
000000d0: 31ef bfbd efbf bdd8 8ed0 bc00 20ef bfbd 1........... ...
000000e0: efbf bd64 7c3c efbf bd74 02ef bfbd efbf ...d|<...t......
000000f0: bd52 efbf bd17 04ef bfbd 0703 7406 efbf .R..........t...
00000100: bdef bfbd 7def bfbd 1701 efbf bd05 7cef ....}.........|.
00000110: bfbd 41ef bfbd efbf bd55 efbf bd13 5a52 ..A......U....ZR
00000120: 723d efbf bdef bfbd 55ef bfbd 7537 efbf r=......U...u7..
00000130: bdef bfbd 0174 3231 efbf bdef bfbd 4404 .....t21......D.
00000140: 40ef bfbd 44ef bfbd efbf bd44 02ef bfbd @...D......D....
00000150: 0410 0066 efbf bd1e 5c7c 66ef bfbd 5c08 ...f....\|f...\.
00000160: 66ef bfbd 1e60 7c66 efbf bd5c 0cef bfbd f....`|f...\....
00000170: 4406 0070 efbf bd42 efbf bd13 7205 efbf D..p...B....r...
00000180: bd00 70ef bfbd 76ef bfbd 08ef bfbd 1373 ..p...v........s
00000190: 0d5a efbf bdef bfbd 0fef bfbd efbf bd00 .Z..............
000001a0: efbf bdef bfbd 7def bfbd 0066 0fef bfbd ......}....f....
000001b0: c688 64ef bfbd 4066 efbf bd44 040f efbf ..d...@f...D....
000001c0: bdef bfbd efbf bdef bfbd 02ef bfbd efbf ................
000001d0: bdef bfbd 40ef bfbd 4408 0fef bfbd efbf ....@...D.......
000001e0: bdef bfbd efbf bd02 66ef bfbd 0466 efbf ........f....f..
000001f0: bd60 7c66 09ef bfbd 754e 66ef bfbd 5c7c .`|f....uNf...\|
00000200: 6631 efbf bd66 efbf bd34 efbf bdef bfbd f1...f...4......
00000210: 31ef bfbd 66ef bfbd 7404 3b44 087d 37ef 1...f...t.;D.}7.
00000220: bfbd efbf bdef bfbd efbf bd30 efbf bdef ...........0....
00000230: bfbd efbf bd02 08ef bfbd efbf bdef bfbd ................
00000240: 5aef bfbd c6bb 0070 efbf bdef bfbd 31db Z......p......1.
00000250: b801 02ef bfbd 1372 1eef bfbd efbf bd60 .......r.......`
00000260: 1eef bfbd 0001 efbf bdef bfbd 31ef bfbd ............1...
00000270: efbf bd00 efbf bdef bfbd efbf bdef bfbd ................
00000280: efbf bd1f 61ef bfbd 265a 7cef bfbd efbf ....a...&Z|.....
00000290: bd7d efbf bd03 efbf bdef bfbd 7def bfbd .}..........}...
000002a0: 3400 efbf bdef bfbd 7def bfbd 2e00 efbf 4.......}.......
000002b0: bd18 efbf bdef bfbd 4752 5542 2000 4765 ........GRUB .Ge
000002c0: 6f6d 0048 6172 6420 4469 736b 0052 6561 om.Hard Disk.Rea
000002d0: 6400 2045 7272 6f72 0d0a 00ef bfbd 0100 d. Error........
000002e0: efbf bd0e efbf bd10 efbf bd3c 0075 efbf ...........<.u..
000002f0: bdef bfbd 40ef bfbd 0200 0000 efbf bd20 ....@..........
00000300: 2100 efbf bd1a 3b1f 0008 0000 00ef bfbd !.....;.........
00000310: 0700 003b 1b1f 05ef bfbd efbf bdef bfbd ...;............
00000320: efbf bdef bfbd 0700 0268 efbf bd03 0000 .........h......
00000330: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000340: 0000 0000 0000 0000 0000 0000 0000 55ef ..............U.
00000350: bfbd 0a ...
We can witness in the logs that exhume_body successfully retrieved the metadata about the EWF disk image and gave us the bytes we have requested. That is good if you want to dump some specific data from a specific offset to later analyse it in an other tool for example.
Using Exhume Body as a Library
One use-case you might have the need to automate a specific parsing task from a disk image. If you are willing to program in rust (you should), you can use exhume_body as a library to perform the task you want. Here is an example.
use exhume_body::Body;
use std::io::{Read, Seek, SeekFrom};
fn main() {
// Enable log output (optional)
env_logger::Builder::new()
.filter_level(log::LevelFilter::Info)
.init();
// Open the evidence file — let Exhume auto-detect the image format
let mut body = Body::new("/path/to/evidence.E01".to_string(), "auto");
// Dump some high-level metadata to the log
body.print_info();
// Seek to byte offset 0x200
body.seek(SeekFrom::Start(0x200)).expect("seek failed");
// Read the next 0x400 bytes (1 KiB)
let mut buffer = vec![0u8; 0x400];
body.read_exact(&mut buffer).expect("read failed");
println!("Read {} bytes; first 16 bytes: {:02x?}", buffer.len(), &buffer[..16]);
}
Conclusion
Exhume body is a powerfull module of the Exhume toolkit and is one of the core libary used for many other modules and part of the Thanatology project. In the next blogpost we will cover MBR and GPT partition analysis using Exhume Partitions ! Join us on Discord if you want to participate to the project.