FTK reporting invalid E01 file

An update…

I was able to use FTK Imager and convert the E01 into a DD image (single DD file).

Adding it as Evidence in and FTK 1.71 case worked fine. Am trying to process it now.

Still wondering what happened and how I can possibly mitigate it in the future.

Any suggestions welcome. Will be testing some stuff…

Guidance Software occasionally updates the E01 file format which makes it so that certain versions of EnCase cannot read E01 files created by certain versions of FTK.

Moreover, Guidance Software makes it clear that they do not "support" the use of evidence files created by other applications (why should they), so creating an E01 with FTK for use with EnCase can create issues (if someone wanted to challenge it).

Although FTK does not compress DD images, their use is the safest best in terms of portability of the evidence.

I can answer the why should they part. You ever hear any press is good press. You have someone using FTK to create an E01 file IMHO the ultimate compliment. Every time someone is asked about the image it's an Encase image regardless of the platform they use to investigate it on.

Guidance needs to loosen up.

They have, likely, decided that it isn't worth the liability. You figure that if they did do this, then every time that they upgraded EnCase, and every time that there was a change to FTK, libewf, etc., they'd have to test it for compatibility.

It is far less expensive for them to make the claim of compatibility the burden of the vendor claiming it.

Thanx. However, the E01 was created using FTKImager, and I tried to read it using FTK.

I recreated the DD using FTKImager also and it loaded into FTK and the processing did start without any errors.

In essence, it is FTK creating the E01, DD and doing the processing. No Encase involvement (other than its an E01 file), which is why I was curious.

I do like E01s - they are easier on the storage space 😉

Moreover, Guidance Software makes it clear that they do not "support" the use of evidence files created by other applications (why should they), so creating an E01 with FTK for use with EnCase can create issues (if someone wanted to challenge it).

How are E01s easier on storage space? I used zip'n'split DD/raw files for archiving cases for years and I doubt that any compression scheme in E01 is better.

Hopefully not too far off topic, but…
When asked by a client to make an "Encase Image", I always clarify that they what they are asking me to do is make a "Forensic Image", a bit stream backup copy of all data on the media. In court as well, I make it clear to define a forensic image, not by way of calling it an Encase Image. The "Encase Image" may be more accurately called an Expert Witness Format image, or even just a forensic image in a proprietary format. Years of Guidance marketing forensics in that the most acceptable (or only) format is an "Encase Image" does a disservice to all other (and more flexible) formats.

I have only had problems loading "EWF" images into forensic applications due to the tool or version of the tool that made them or the tool or the version of the tool being used to read them. The solution has been to convert the famed "Encase Image" to dd. I've not had issues surrounding the dd format in any tool that can create or read this file format.

The more any image type gets further restricted by the tools to create or read them, the more that type becomes practically irrelevant. Take the Safeback image as an example…as soon as FTK and Encase were unable to read the last Safeback version, it was quickly dismissed as a common forensic image format and gone. The "Encase" image format…if it becomes more common for problems of reading it by other non-Encase tools, how long will that continue before the same thing happens?

Greetings,

One advantage of the E01 format is that you can use a compressed E01 directly, without decompressing it. You need to unzip the dd images before using them, consuming CPU cycles and disk space.

No great advantage either way as long as your processes are set up to support your choice.

-David

Greetings,

One advantage of the E01 format is that you can use a compressed E01 directly, without decompressing it. You need to unzip the dd images before using them, consuming CPU cycles and disk space.

No great advantage either way as long as your processes are set up to support your choice.

-David

I'll posit that you're wrong in part, and correct in part. Which is to say that you may save space by not having to create a decompressed image file to work with, however you'll still be using CPU cycles. In fact, if you are working off a compressed image, you'll be using more CPU cycles than if you only decompressed once and worked from a flat DD. Why? Because every time you touch your image, you'll have to decompress that part, and so you'll potentially be decompressing the same data multiple times.

Therefore I'd suggest that the advantage of compressed E01 would be a reduction in space required to contain your image during the processing phase (since both compressed DD and E01 can provide a reduction in space during capture) whilst the disadvantage would be an increased processing overhead. Personally I'd prefer to avoid a lag during the viewing phase of the examination caused by inline decompression. I also can't see a scenario where I'd need more than the 16TB I could set up on my RAID for viewing a single item, at least not before my capacity increases again. (No, I'm not about to make a Bill Gates 512k memory comment mistake here.)

I've always been a raw/DD image guy though, since very early on I decided that I didn't care what supposed features EWF added, with a flat file you always knew exactly what you had. And it's trivial to mount a DD under Linux and view the files via SAMBA, try doing that with an E01 reliably without a paid tool.