The Answer

Forensics, Security, Law

Evidence Verification

Mar 05

2010

Manipulating encase E01 files, Myth or Reality?

Posted by Yogesh Khatri in Password Cracking, imaging, Hacking, Forensics, Evidence Verification, E01 password, acquisition

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.

UPDATE: The file download error has now been fixed. If you cannot download files, let us know by posting a message on the forum. Thanks.

Apr 05

2009

The Enscript Command line, New Possibilities

Posted by Yogesh Khatri in Forensics, Evidence Verification, Enscript, CommandLine, COM

As encase and E01 files have become the standard in digital forensics, I have been using the Enscript language built within encase to automate my tasks. It has become the language of choice for many reasons, it has a rich library of functions that can create dialogs for UIs, perform direct registry access without mounting (except user hives), read/write files and automate manual encase tasks like searching, filtering, etc. But the most compelling reason to use enscript is that I don't have to copy/unerase files from encase before working on them.

However, there are certain drawbacks. I wish to automate my tasks to a level where I shouldn't have to see encase at all. :) This is supported half way right now, an enscript can be launched from the command line with the -r switch to encase. But unlike regular programs, no parameters for the script can be specified on the command line, as the script cannot access Encase's command line. And that's a big show stopper. :(

The solution I came up with was to create a COM DLL that an enscript could load and one of the functions exposed in the DLL's interface would be the command line. Because the DLL is loaded from the Encase process (by the script), it can access Encase's command line. The DLL, enscript and batch file (for registering it with windows) can be downloaded below. Scroll to the end of article for link.

Usage:
1. The DLL must be registered with windows. To register the DLL, place it somewhere where it won't get moved or deleted like the windows folder.
2. Copy the batch file provided to the same location and execute it, this will register the DLL. Now it's ready for use.
3. Run the enscript in encase.

This now opens up a world of possibilities. We can now have encase launch, start an enscript, load an evidence file, process it, dump out results and quit all from a single command line statement. I can now create a batch file or even an item on the explorer right-click menu which processes my evidence files! The only thing missing is the ability to write back out to StdOut (Console). Because encase is a windows application, it does not attach to a console. :(

As a demo, I created a couple of scripts and integrated them into shell right-click menu items.
Script 1: Get Profile Info.Enscript
This can be run on a single E01 or L01 file.
This performs the following actions:
1. Load the specified E01/L01 file into encase.
2. Recurse through the entries in this file and find all windows profile names.
3. Create output file in the same folder as evidence file.
4. Write all profile information to this output file.
5. Close encase when done. (" -x" command line switch)

Script 2: Verify Evidence File.Enscript
This can be run on a single file or folder containing E01 files and can be either recursive or non-recursive. You can point it to the root of a drive and have it verify all files on that drive and get a single report for it. Similar to the "Get Profile Info" script, the output is stored into a file in the same folder as E01 file (if file is selected) or in the root folder selected.

Registering the Shell Handlers:
This is done by inserting a few keys into the registry. The zip files provided have registry scripts to do this automatically. Before running it, you will have to edit it with notepad to change the path of the script as well as the encase path to wherever they exist on your system. (You need double backslashes (\\) in the path in the .reg file only, not if you edit the registry directly. The same goes for the encase path. Also double-quotes have backslash pre-fixed to them. )

Download files here:

Command Line DLL.zip
Get Profile Info.zip
Verify Evidence File.zip

42 LLC

The Answer

Forensics, Security, Law

Manipulating encase E01 files, Myth or Reality?

The Enscript Command line, New Possibilities