Forensic Image Formats: RAW, E01, AFF4, and L01

Forensic image formats answer different evidence questions

A RAW image is the simplest choice when you need a sector-for-sector copy and broad tool compatibility. E01, part of the Expert Witness Compression Format family, wraps media data with case metadata and can split and compress the image. AFF4 is a more flexible container built around addressable streams, but support varies by tool. A logical image contains selected files rather than every addressable sector, so it is not a smaller synonym for a full-disk image.

The right format is the one that preserves the data your authorized scope requires and opens reliably in the tools that will examine, review, and archive it. File extensions do not perform magic evidence rituals. Documentation, verification, and tested compatibility still have to show up for work.

This guide is defensive and educational. Do not acquire or examine a device you do not own or lack explicit written authority to investigate. Legal duties and evidence rules vary; case-specific decisions belong with qualified counsel and a certified examiner.

First decide: physical or logical acquisition

Before comparing containers, decide what needs collecting.

A full-media or physical image aims to represent the source's addressable storage. It may preserve allocated files, deleted-file remnants, filesystem metadata, partition structures, and unallocated space. That breadth makes it useful when the question is not yet narrow or when deleted activity matters.

A logical acquisition collects named files, folders, or other selected objects through a filesystem or application view. It can be appropriate when authority is tightly scoped, time or storage is constrained, or a cloud service exposes records rather than physical media. It generally does not preserve every sector, slack area, or deleted artifact from the source device.

Neither label guarantees completeness. Encryption, damaged media, device firmware, acquisition permissions, live-system changes, and tool limitations can all restrict what was actually captured. Record the method and its limits rather than letting the filename write a heroic story on your behalf.

RAW or DD images: plain and widely readable

A RAW image is an uninterpreted byte stream copied from the source range. You may see extensions such as .dd, .raw, or .img, but the bytes do not become more forensic because somebody chose the sternest-looking suffix.

Advantages

• broad support across commercial and open-source analysis tools;
• simple structure, which makes independent parsing and export straightforward;
• no container-specific metadata is required to reconstruct the media byte stream;
• easy comparison of a hash calculated over the acquired data.

Tradeoffs

The format itself does not provide a standard case-information wrapper. Examiner notes, device identifiers, acquisition times, tool versions, and source details therefore need a separate log. A plain RAW file is normally about the size of the acquired address space unless the filesystem storing it performs compression or the acquisition tool adds an external scheme.

Large RAW images may be split into numbered segments for storage or transfer. If that happens, preserve the complete set, its naming order, and the acquisition log. One missing segment turns a neat evidence package into an extremely expensive jigsaw puzzle.

E01 and EWF: a practical evidence container

E01 is a common extension for the EWF-E01 form of the Expert Witness Compression Format. The current libewf documentation describes EWF as a format for disk and partition images that may be compressed or uncompressed and stored across one or more segment files. Its headers can carry fields such as case and evidence identifiers, examiner name, notes, media model, serial number, and acquisition time, depending on the creating implementation.

That combination explains its popularity: an examiner can package media data, descriptive metadata, integrity information, and manageable segments together. Compression may reduce storage when source blocks are compressible; already compressed or encrypted content will be less cooperative, because mathematics also has boundaries.

E01 is not one perfectly uniform implementation. Tool versions and EWF variants differ. Before selecting it, confirm that every required acquisition, analysis, review, and archival tool can read the exact variant and compression method you plan to create. The libewf project, for example, lists different read/write support for E01, Ex01, L01, and Lx01 features.

AFF4: flexible streams with a compatibility question

The Advanced Forensic Format 4 specification models forensic data as addressable objects and streams inside a container. Implementations can store image streams using compression, and the design can represent more complex collections than one flat disk stream.

That flexibility can be valuable for modern acquisition workflows, especially when a toolchain already uses AFF4. It does not automatically make AFF4 the best archival choice. Ask a blunt question first: can the receiving examiner, validation lab, opposing expert, or future migration tool open and verify this exact AFF4 output?

Format elegance is lovely. A review team staring at an unsupported container on deadline will remain strangely unmoved by it.

Logical evidence files: useful, but narrower

Logical evidence containers such as EWF-L01 collect selected files and related metadata rather than representing a whole physical medium. They can make review smaller and more focused, and they may fit an authorization that permits collection of specified business records but not indiscriminate acquisition of an entire device.

The tradeoff is evidentiary scope. A logical collection may omit deleted content, unallocated space, filesystem structures, or artifacts outside the selected paths. Describe it as a logical acquisition in notes and reports. Never imply that it was a complete physical image simply because the output came from a forensic tool.

Comparison at a glance

A seven-check format decision

1. Define authority and scope. State whose device it is, who authorized acquisition, what data may be collected, and any date or account limits.
2. Name the evidence question. Deleted-file recovery points toward full-media imaging; a narrow production request may justify logical collection.
3. List every consuming tool. Include acquisition, analysis, independent review, export, and long-term archive systems.
4. Plan destination storage. Check capacity, filesystem file-size limits, encryption requirements, transfer method, and whether segmentation is necessary.
5. Record acquisition details. NIST guidance calls for documenting the drive model and serial number, storage capacity, and imaging hardware or software, including its name and version.
6. Calculate and preserve hashes. Record which bytes each digest covers. Verify after acquisition and again after material transfers; a hash without a clearly defined object is just a confident-looking string.
7. Test the evidence package. Open or mount the result read-only, confirm every segment is present, inspect metadata, and if practical validate it with a second compatible tool.

Our chain-of-custody guide covers the handling record around that package. For software options, see the free digital forensics tools guide.

What belongs in the acquisition record

At minimum, record the source identifier and condition, date and time with timezone, examiner, authorization reference, acquisition tool and version, hardware write blocker if used, chosen format and settings, segment size, destination, errors or unreadable sectors, start and finish times, and verification results.

Keep generated logs with the evidence package, but do not assume they explain themselves. A future reviewer should be able to identify what was acquired, how, with which settings, and what the resulting hash actually represents without interviewing Past You through a séance.

Bottom line

Choose RAW when simplicity and broad interoperability dominate. Choose E01 when tested tool support plus embedded metadata, compression, or segmentation improve the workflow. Choose AFF4 when its capabilities solve a real need and every downstream participant can validate it. Choose a logical container only when selected-file acquisition matches the authorized question—and label its narrower scope plainly.

Whatever the format, protect the source, document the method, verify the result, and test the handoff. The evidence is not the extension. The evidence is the data plus the defensible process that got it there.

Sources checked

• NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
• libewf: Expert Witness Compression Format documentation
• libewf: current supported EWF variants and tools
• AFF4 Standard Specification v1.0a