Recently, we had to process a case where we received many encase images (E01 files) which were password protected. The party that provided the images misplaced the password which meant Encase would not load them. We do a lot of our processing in Encase as it can be automated with scripting and it minimizes manual artifact extraction and reporting. Hence we needed to crack/remove the password from these files. 

 

The encase password protection feature is simply an application level protection. It does not protect the data within the E01 file. Utilities that operate with E01 files have the option of honoring or ignoring this “feature”. Hence FTK and tools using libewf load the file just fine, without asking for a password. We could re-image all the files in FTK to remove the passwords, so they can be used by encase, but that would require lots of time copying and verifying the files again, lots of extra disk space and many hours. So we decided to see if it’s possible to manipulate the E01 header to remove/blank out the password. 

 

The E01 format has been pretty well documented by Joachim Metz in his project libewf. What I found was pretty scary. The header fields in an E01 file are completely detached from the image data. There is absolutely nothing that protects that header, not even a checksum! It can be easily altered. The case information is stored in the header section which is a zlib (Deflate) compressed stream. This when decompressed is simply a tab-delimited text file, from which the password hash can easily be deleted and the resulting file recompressed and put back into the E01 file. The whole operating takes no more than a few minutes to perform manually once you figure out the offsets and text file format. Of course you will need a program that decompresses and recompresses a zlib stream. (That I had to create myself)

 

So practically anyone with this knowledge can now change acquisition information, i.e., notes, acquisition date and time, examiner name, case number, evidence type, drive serial number, drive type, etc...

The only catch is that the new compressed data stream (after manipulation) must be equal or smaller in size to fit in the space allotted for the header. If not, then all the data will have to be shifted down and the offsets and CRCs for the remaining sections in the files will have to be adjusted for all the evidence segments (E01, E02, E03...). This is a little more work, but is also easily accomplished.

 

We could easily then create a program to edit this information, but we leave that for another day. We did however create a utility to remove the password from an E01. You can download it here. It’s a command line application which takes only a few seconds to run, as only a few bytes in the first segment (E01) are modified. The other segments (E02, E03…) are not touched. It will create a backup of your original E01 file, just in case. 

 

It uses .NET 2.0, which you should already have unless you are running a really old XP system which never got any updates. If not, download and install it from Microsoft.

 

So in essence what we have proved today is that relying on an encase E01 file’s case information is really no better than the text file that accompanies DD images. There is no reason to believe it is un-alterable or secure by any means.