What Is an E01 File? The EnCase Disk Image, and How to Open and Check One

7 How Do You Open E01 Files? Free tools, Windows programs and viewers

FileInfo's program list names six Windows programs, and the list has no Mac or Linux program. Filext names EnCase Forensic, OSForensics and EMBIRD. We tested on Linux, so the table marks what we tested and what we did not.

Open the first file and let your tool find the rest. If you name only E01, libewf tools look for E02, E03 and the others by name in one folder.

Open E01 files on Linux

Sleuth Kit lists the files in an image. The next listing shows our first set.

$ fls -i ewf -r good/evidence.E01
d/d 11:  lost+found
d/d 12:  docs
+ r/r 13:  report.txt
r/r 14:  hello.txt
r/r 15:  notes.txt
r/r 16:  photo.bin
V/V 6145:  $OrphanFiles

The numbers before the file names are inodes. icat -i ewf evidence.E01 16 writes photo.bin to the screen, so send it to a file with >. The mmls command lists the partitions when the disk has a partition table.

ewfmount shows the disk as one raw file named ewf1. The hash of that file matched the source disk in all 15 of our sets. We did not mount the file system on top of it.

mkdir /mnt/ewf
ewfmount evidence.E01 /mnt/ewf
ls -l /mnt/ewf
sha256sum /mnt/ewf/ewf1

Open E01 files on Windows

1. 1 Copy all the segment files into one folder. Keep their names.
2. 2 Choose a program that lists E01 files. the FileInfo page names EnCase Forensic, OSForensics, Mount Image Pro and SmartMount.
3. 3 Add the first file, E01. The program finds the other files by name.
4. 4 Check the hash first, as the check steps shows.
5. 5 If you need a viewer for the email inside, use one from the viewer part.

We did not test any Windows program. Free viewers and trials limit what they show, and the vendors state their own limits.

Open E01 files on a Mac

FileInfo lists no Mac program for E01 files. We did not test a Mac. If you have E01 files and no program, the safe route is a Linux or Windows machine with a tool from the table above.

View email in E01 files without EnCase

Viewers help when you need the email or files inside an E01 file and you do not own EnCase. Two Windows viewers come from the sites that this guide belongs to.

SysTools says its viewer opens E01 files, reads PST, OST and EDB files inside them and makes CSV and TXT reports. Freeviewer says its viewer opens E01 files without EnCase and previews the same three mail types. Both pages also say there is no limit on file size. The two pages disagree with themselves on free versions, because one line says a free version is not available and another says free. Check the price on the vendor page before you download. We did not test either viewer, so treat every line as the vendor's own claim.

8 How Do You Check an E01 File? Compare the hash, with a tool or a script

A hash check takes one command. Put all E01 files in one folder, then use ewfverify. It reads the entire image, hashes it again and prints both hashes.

$ ewfverify -q good/evidence.E01
MD5 hash stored in file:  a53b724acd8d3924e2868473e6ca39c3
MD5 hash calculated over data:  a53b724acd8d3924e2868473e6ca39c3
ewfverify: SUCCESS

A good set ends with SUCCESS and two equal hashes. A damaged one ends with FAILURE. The next listing shows our copy with one flipped bit in photo.bin.

$ ewfverify -q bad/evidence.E0*
ewfverify 20140814
Sector validation errors:
  total number: 1
  at sector(s): 46208 - 46271 (number: 64) in segment file(s): bad/evidence.E03
MD5 hash stored in file:  ef2aa4dd960c705ff1c0e85dfb1cc025
MD5 hash calculated over data:  b9736cbbb5bc17f000529d59a748b571
ewfverify: FAILURE

The sector range shows you where to look. The 64 sectors from 46,208 to 46,271 are one chunk, and ewfverify names its segment. The two hashes differ, so this copy is not the copy that was made.

Check E01 files with Python

The script below does the same job without libewf. It reads the segments in the order of their header numbers and checks every section checksum and both chunk tables. It then reads every chunk, hashes the data and compares the MD5. Save it as check_e01.py and give it the segment files.

import sys, struct, zlib, hashlib
SIG = bytes.fromhex('455646090d0aff00')
u32 = lambda b: struct.unpack('<I', b)[0]
files, notes = {}, []
for path in sys.argv[1:]:
    d = open(path, 'rb').read()
    if d[:8] != SIG:
        sys.exit(f'{path} is not an E01 segment: its first 8 bytes are wrong')
    files.setdefault(struct.unpack('<H', d[9:11])[0], []).append((path, d))
for n in range(1, max(files) + 1):
    if len(files.get(n, [])) != 1:
        notes.append(f'segment {n} is missing' if n not in files else f'two files claim to be segment {n}')
md5, bad, found, expect, stored, size = hashlib.md5(), [], 0, 0, None, 64 * 512

def read_table(body, limit, d):
    count, base = struct.unpack('<I4xQ', body[:16])
    if zlib.adler32(body[:20]) != u32(body[20:24]):
        raise ValueError('table header')
    if len(body) == 28 + 4 * count and zlib.adler32(body[24:24 + 4 * count]) != u32(body[-4:]):
        raise ValueError('table entries')
    ent = struct.unpack(f'<{count}I', body[24:24 + 4 * count])
    pos = [(e & 0x7fffffff) + base for e in ent] + [limit]
    return [(e >> 31, d[pos[i]:pos[i + 1]]) for i, e in enumerate(ent)]

for n in sorted(files):
    path, d = files[n][0]
    off, end, tab = 13, 0, None
    try:
        while True:
            kind = d[off:off + 16].rstrip(b'\0').decode()
            nxt, sz = struct.unpack('<QQ', d[off + 16:off + 32])
            if zlib.adler32(d[off:off + 72]) != u32(d[off + 72:off + 76]):
                raise ValueError(f'section {kind} descriptor')
            body = d[off + 76:off + sz]
            if kind in ('header', 'header2'):
                try: zlib.decompress(body)
                except zlib.error: notes.append(f'{path}: damaged {kind} section')
            if kind == 'volume':
                if zlib.adler32(body[:-4]) != u32(body[-4:]): notes.append(f'{path}: damaged volume section')
                expect, size = u32(body[4:8]), u32(body[8:12]) * u32(body[12:16])
            if kind == 'sectors': end = off + sz
            if kind in ('table', 'table2') and (kind == 'table' or tab is None):
                try: tab = read_table(body, end or off + sz, d)
                except Exception: tab = None
            if kind == 'table2' and tab is None: notes.append(f'{path}: both chunk tables are damaged')
            if kind in ('table2', 'next', 'done') and tab:
                for flag, raw in tab:
                    try:
                        if flag: data = zlib.decompress(raw)
                        else:
                            data = raw[:-4]
                            assert zlib.adler32(data) == u32(raw[-4:])
                    except Exception:
                        bad.append(found); data = b'\0' * size
                    md5.update(data); found += 1
                tab = None
            if kind == 'hash': stored = body[:16].hex()
            if kind in ('done', 'next') or nxt <= off: break
            off = nxt
    except (ValueError, struct.error) as e:
        notes.append(f'{path}: stops at byte {off} ({e})')
print('chunks found:', found, 'of', expect)
print('damaged chunks:', bad or 'none')
print('stored MD5:   ', stored or 'missing')
print('computed MD5: ', md5.hexdigest())
for x in notes: print('note:', x)
sys.exit(0 if not (bad or notes) and found == expect and stored == md5.hexdigest() else 1)

Here is what it printed for a good file, for the damaged copy and for a set that lost its last segment.

$ python3 check_e01.py good/evidence.E01
chunks found: 768 of 768
damaged chunks: none
stored MD5:    a53b724acd8d3924e2868473e6ca39c3
computed MD5:  a53b724acd8d3924e2868473e6ca39c3

$ python3 check_e01.py bad/evidence.E0*
chunks found: 768 of 768
damaged chunks: [722]
stored MD5:    ef2aa4dd960c705ff1c0e85dfb1cc025
computed MD5:  e9360814ba841396ddab09b6ee59960f

$ python3 check_e01.py cut/evidence.E0*
chunks found: 765 of 768
damaged chunks: none
stored MD5:    missing
computed MD5:  ac95dceaa5a29bbf20efe5012b24f35b

Chunk 722 is the damaged chunk, and the hashes differ. In the last listing the stored MD5 is missing and the count reads 765 chunks of 768, because E04 is gone. The script also prints a note for a missing segment, a damaged header or volume section and a segment that stops early.

What the script and ewfverify found

The script is a teaching tool and not an evidence tool. It reads EWF version 1 files that libewf wrote, and it fits in one page. It does not read Ex01 files, and we tested it only on our own sets.

Check E01 files again after every copy

Write the hash next to your E01 files in your notes. Check E01 files again after every copy, move or upload. E01 files that pass both times are the copy that was made, and E01 files that fail once need a new copy before anyone trusts them.

What a pass proves

A pass proves that chunks match the hash that the tool stored. It cannot prove that the copy matches the original drive, because only the acquisition tool saw that drive. If a lab log lists the acquisition hash, compare the two hashes. A copy with the same hash as the log is the copy that was made.

Hash a raw copy yourself

You can also make a raw disk with ewfexport and hash it. In all 15 of our sets, raw disks had the same SHA256 as the source disk. The convert section shows the commands.

9 Are E01 Files Safe to Open? The file is data, and the drive inside is the risk

The ending says nothing about safety. An E01 file is a container, and the safety depends on the drive that went into it. The table lists what to check, and every row ends with its source.

Why the password field is not a lock

The header has a password field, and ours said N/A. Forensics Wiki lists encryption for the Ex01 version only. We did not test a file with a password set, so do not count on a password to protect an E01 file. Anyone who has the file can try to read it.

Why the case details matter

The header names the examiner and the notes. Our test header named an examiner and case number that we typed in. Headers from cases can name people and cases. Before you send E01 files outside your company, read the header with ewfinfo and decide if the details can leave.

11 How Do You Convert an E01 File? Raw, virtual disks and single files

There are two kinds of conversion. One makes another kind of disk image. The other pulls files out of the image. Choose by what you need next.

Convert E01 files to a raw DD file

The first command writes disk.raw. The second prints its SHA256. Compare it with the hash of the source if you have one. The next two commands make a VHD file and a VMDK file. We added force_size=on for VHD, because without it the size grows.

ewfexport -u -t disk -f raw evidence.E0*
sha256sum disk.raw
qemu-img convert -f raw -O vpc -o force_size=on disk.raw disk.vhd
qemu-img convert -f raw -O vmdk disk.raw disk.vmdk

A raw disk matches the disk size, 25,165,824 bytes here. That is far larger than E01 files. Virtual disks fall between the two. The table shows sizes for our mostly empty disk.

All five virtual disks read back with the same SHA256 as the raw disk. For the other formats, read the guides to VHD files, VMDK files and VDI files.

Pull files out of E01 files

Sleuth Kit lists the files and extracts them with the inode number. We used this on all 15 E01 file sets and got 4 of 4 test files with the right hash every time.

fls -i ewf -r evidence.E01
icat -i ewf evidence.E01 16 > photo.bin
sha256sum photo.bin

Make a smaller E01 file

Compression is the other direction. Our fast setting made the 24 MiB disk 336,363 bytes, and the best setting made it 251,557. The sizes section has the table. Random data does not shrink, so a drive full of video barely changes.

Convert email inside E01 files

Email needs a viewer, because the mail files live inside the disk. The viewer section names the two Windows viewers. Both vendors state their own limits, and we did not test them.