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.

NIST SP 800-86 distinguishes a logical backup from bit-stream imaging: the former copies directories and files, while the latter creates a bit-for-bit copy that includes free and slack space. That distinction describes the acquisition scope. RAW, E01, and AFF4 describe ways the resulting data may be stored.

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.

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.

Libewf's current project page lists read/write support for EWF-E01 and EWF2-Ex01, while identifying Ex01 bzip2 compression and encryption as unsupported. A statement such as “the tool supports E01” is therefore incomplete unless it names the tool version, exact variant, compression or encryption feature, and operation being tested.

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.

The AFF4 Standard v1.0a describes a ZIP64 file or folder container, RDF metadata in information.turtle, a Map representing a virtual address space, and an Image Stream holding fixed-size data blocks that may be compressed. Its hash properties can describe the linear image stream, and the specification also defines optional block-map hashing. Record which AFF4 object a reported digest covers; a container file, an image stream, and a mapped virtual image are not automatically the same byte object.

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

Treat compatibility as a test result

Do not select a format from a product's generic “supported formats” page alone. Build a small representative image with the planned settings. Open it read-only in the acquisition tool, primary examination tool, independent review tool, and any export or archive workflow. Confirm that each tool sees the same logical size, expected metadata, complete segment set, and verification result.

Repeat the test after a material tool upgrade or setting change. NIST's Computer Forensic Tool Testing program evaluates disk-imaging tools by function, which is the useful model here: compatibility belongs to a particular tool, version, format feature, and operation. It is not a permanent property of a three-character extension.

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 or browse Tools and Software.

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
• NIST Computer Forensic Tool Testing: Disk Imaging
• libewf: Expert Witness Compression Format documentation
• libewf: current supported EWF variants and tools
• AFF4 Standard Specification v1.0a