You are here: 42 Resources Blog tags acquisition

42 LLC

SANS

The Answer

Forensics, Security, Law

Tag >> acquisition
Mar 05
2010

Manipulating encase E01 files, Myth or Reality?

Posted by Yogesh Khatri in Password CrackingimagingHackingForensicsEvidence VerificationE01 passwordacquisition

Yogesh Khatri
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. 
Jul 07
2009

Using robocopy for network collections

Posted by Chris Pavan in robocopyForensicsediscoverycollectionacquisition

Chris Pavan

Too often we come across systems that the traditional tools just can’t handle. For example, if you have ever had to deal with a NetApp you know that you can’t just pull out the disks, image them, and then try to rebuild the RAID later. One option when you can’t remove drives is to try and get a shell on the appliance, but many times that is not an option either. When the only documented access to data is through a Microsoft network share, one of the best options is to use Microsoft’s robocopy utility. robocopy allows you to copy files across the network via mapped shares making it a great solution to this ever-growing problem of proprietary network storage systems. And it allows you to maintain time stamps and does its own limited data verification.

Download the Windows Server 2003 resource kit from the following location:

http://www.microsoft.com/Downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

 When you install the resource kit, be sure to read the End User License Agreement (EULA) and ensure that your use will not violate the agreement.

 Because we are going to write out files directly to another disk and not into a forensic image file format you will need to ensure that you have properly prepared a target drive to store the files on. Prepare your target hard drive by wiping it with the hex pattern \x00 and verifying that the data has been successfully wiped. Once the process of wiping and verification has completed, format the drive with the NTFS file system.

 The next step is to turn off or disable all applications that might scan or affect the data that is being written to your target drive. In particular you will want to turn off active scanning of files by your anti-virus software and disable any power saving features, such as allowing the system to turn off hard disks or putting the computer to sleep. The ultimate goal here is to make sure that the process is not interrupted and that the data is transferred in as pristine a state as possible.

The easiest way to copy files from a network drive using robocopy is to first map the drive on the local system. Be sure to keep good notes on how you mapped the drive such as server name, share name, IP address, user name, etc. It is not necessary to record the password to the share, and if you do, it should be changed so it does not pose a security risk to your organization or client.

On your target drive, create a folder named after the server that you are copying the data from. Inside that folder create another folder with the share name. This structure allows you to copy files from multiple shares on the same server preserving relationships and structure.

For this scenario we have mapped the source \\co_fileserver\profiles to drive letter s:\. Our target drive was connected via USB and was automatically assigned drive letter t:\. On our target drive we created the folder structure t:\co_fileserver\profiles for us to point robocopy to.

The following command will copy everything from the source drive s:\ to the target drive path t:\co_fileserver\profiles:

robocopy s:\ t:\co_fileserver\profiles /E /COPY:DAT /R:3 /W:3 /V /TS /FP /NP /LOG+:t:\co_fileserver\profiles.log /TEE

Here is the breakdown of the options that were used

/E Copy everything including empty directories.

/COPY:DAT Copy the Data, Attributes, and Timestamps of the files and folders.

/R:3 If a file is locked retry copying a total of three times.

/W:3 Wait three seconds between each retry when retrying to copy a file.

/V Provide verbose logging.

/TS Include the timestamps of the files in the log.

/FP Provide the full path of the files in the log.

/NP Do not display progress. This will fill up your log if left out.

/LOG+:t:\co_fileserver\profiles.log Create a log of the activity in the path t:\co_fileserver\profiles.log. The + tells robocopy to append the log. If you leave this out robocopy will overwrite the log if it already exists. By leaving it in you don’t accidentally overwrite any of your previous work.

/TEE Output the progress to the screen as well as the log. This is a good option so you can see that the application is making progress.

You MUST review the log before leaving the site. If there was a file locked open by another user during the copy process, robocopy will fail to copy that file and will log the result. You will have to get the user to release control of the file and rerun robocopy again, this time specifying the file that you want to copy. An example of when you will most likely run into this is with PST files. If a user has Microsoft Outlook open the PST file will be locked because it is being edited. Have the user close the application and retry copying the file again using the same syntax as before, only this time add in the full path to the file. It may require some investigation to determine who has the file open if it is not within a specific users file share.

Search through the log for the following entry: ERROR: RETRY LIMIT EXCEEDED.

Just above this entry you will see what caused the failure. You may also want to search through the log for the word ERROR in general just to be sure there were no other issues.

2009/06/30 17:51:47 ERROR 33 (0x00000021) Copying File s:\suzie\Email\archive.pst

The process cannot access the file because another process has locked a portion of the file.

ERROR: RETRY LIMIT EXCEEDED

Rerun robocopy once you have taken steps to unlock the file, this time you only need to grab the file archive.pst. You can simply do this by putting the filename in after the destination, but this will cause robocopy to rescan the entire drive looking for files named archive.pst that haven’t been copied yet which, depending on the size of the drive you are scanning, could take a while..

robocopy s:\ t:\co_fileserver\profiles archive.pst /E /COPY:DAT /R:3 /W:3 /V /TS /FP /NP /LOG+:t:\co_fileserver\profiles.log /TEE

robocopy will not recopy a file that already exists, so you don’t have to worry about collisions. The recommended way is to be more specific and put in the full path information for source and destination.

robocopy s:\suzie\Email t:\co_fileserver\profiles\suzie\Email archive.pst /E /COPY:DAT /R:3 /W:3 /V /TS /FP /NP /LOG+:t:\co_fileserver\profiles.log /TEE

Once you have gone through your log and ensured that you have successfully copied all of the failed files then your collection is complete.

The final step

As soon as the copy is complete disconnect the target drive from the computer and reconnect it to your examination workstation via some means of write protection. Fire up EnCase, FTK or your preferred imaging application and preview the drive. Create a logical evidence file of the contents of the drive if possible. Both EnCase and FTK have given us issues when there are large numbers of files, so you may want to create multiple logical evidence files, one for each share. Additionally, you can also create a full disk image such as an EnCase evidence file (E01) for the entire drive and use that for preservation / analysis. This is one of the more critical steps in the process as this becomes the baseline of your collection. Provided you properly wiped the drive before hand, there should not be any data on the drive other than what was copied by robocopy.

Jun 18
2009

Forensic Imaging of RAM on live Linux systems

Posted by Chris Pavan in RAMlinuximagingForensicsacquisition

Chris Pavan

During CEIC this year I had a couple people come up to me and ask how to create an image of RAM on a Linux computer. Recently there have been a lot of tools created that gets the job done in Windows, but there is nothing really out there for Linux.

 I created a knowledgebase article that goes into detail on how to handle imaging RAM on a Linux system. I also cover how to use netcat to send the image across the network to a remote computer. The article can be found HERE.

 The basic command you are going to run is:

dd if=/dev/mem bs=4096 conv=noerror,sync | tee >evidence.dd | md5sum >evidence.hash

By using tee the data is written out to a file as well as passed down the pipeline so it can be hashed. Once your image completes, run md5sum against the output file and compare that to the hash originally created. If they match you are good to go.

If you want to send the data across the network get netcat listening on your target computer:

nc -l -p 5000 >evidence.dd

On the source computer use the following command:

dd if=/dev/mem bs=4096 conv=noerror,sync | tee >(nc -w 5 target_ipaddress 5000) | md5sum

Make sure you record the MD5 hash value when the process completes and then hash the output on the target computer and compare the two.

 There are also some issues with block sizes that you may run across that I cover in the knowledgebase article.

Incidentally, you can do the same thing with disks, just change the device (e.g. /dev/sda) and now you are taking an image of the serial attached hard drive sda. I am working on another KB article that will cover imaging hard drives on live systems with dd.

42 LLC | 2596 Mission St, Suite 203, San Marino, CA 91108 | info@42llc.net | +1 626.698.1189