±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 36618
New Yesterday: 10 Visitors: 177

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

Imaging software

Discussion of computer forensics employment and career issues.
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page Previous  1, 2, 3, 4, 5  Next 
  

gmarshall139
Senior Member
 

Re: Imaging software

Post Posted: Feb 14, 06 20:40

I don't agree that the .e01 file format is proprietary. It's widely used by several applications. As for what the future may hold how are we to know?

That said, it is certainly possible with user specified block size and granularity settings in Encase ver. 5 to limit the compatibility with other forensic applications.

Many of the acquisitions I do are off site and under time constraints. I like Encase in that I can do an acquisition without compression in the fastest manner possible. I can then add it to encase and reaquire the image with maximum compression overnight, in order to free up space and speed up archival. The original image can be dd or .e01, it matters not, but the second will be .e01.
_________________
Greg Marshall, EnCE 
 
  

farmerdude
Senior Member
 

Post Posted: Feb 15, 06 00:31

ANDY,

Okay, thank you. I *thought* you could write a RAW image file using EnCase. Can you do it in acquisition engine, or do you have to write the E01 first and then carve the raw out?


GREG,

Are you indicating that because the E01 file is used by "several applications" you believe that it is not a proprietary file format?

The fact that SMART, FTK, etc. all can interpret the data structures doesn't mean that E01 isn't proprietary. Many of the forensic analysis programs can interpret Microsoft PST files, but that doesn't preclude the PST from being a proprietary file format either.


As for the future ... the past sometimes is a good indicator as to what the future might hold. And in the past EnCase has changed in that depending upon which version of it was used to produce the E01 other versions are not able to view the file. Again, I don't use EnCase, but I believe version 3 or 4 isn't backware compatible with previous versions. Verification from a licensed EnCase user?


Can you please explain your second paragraph? I don't understand the "user specified block size" etc. etc. etc.?


You are incorrect if you believe you can write a pure non-compressed E01 file, Greg. EnCase always compresses, even when you tell it not to (unless they've changed this in version 5).

Are you indicating in your tests EnCase is faster than other acquisition engines using the same variables? Myself, I have found using an acqusition engine, crossover cable, and gig ether cards to be the fastest, averaging 1.5-1.7 gig a minute. Oh, and of course this isn't the EnCase engine. Just 'dd', 'SMART for Linux', or similar.

BTW, my discussion isn't centering around *which* tool to acquire with, but the image file *format* that should be written. No one has yet to provide a legitimate reason why they select E01 when they use EnCase to acquire. Legitimate to me indicating why the proprietary format is superior to the open format (speed, extra features and blessings, etc.).

regards,

farmerdude  
 
  

gmarshall139
Senior Member
 

Post Posted: Feb 15, 06 02:00

- farmerdude
Are you indicating that because the E01 file is used by "several applications" you believe that it is not a proprietary file format?

The fact that SMART, FTK, etc. all can interpret the data structures doesn't mean that E01 isn't proprietary. Many of the forensic analysis programs can interpret Microsoft PST files, but that doesn't preclude the PST from being a proprietary file format either.


That's exactly what I'm saying. "Proprietary" suggests private ownership such as with a patent or a trademark. I don't think you can compare it to a .pst file format. Not only can other applications interpret it, some of them (at least FTK that I'm aware of) acquire to .e01 files as well. There is standardization, but such standardization is voluntary, I suppose out of the desire on the part of the vendors for the evidence files to be cross compatible.


- farmerdude
As for the future ... the past sometimes is a good indicator as to what the future might hold. And in the past EnCase has changed in that depending upon which version of it was used to produce the E01 other versions are not able to view the file. Again, I don't use EnCase, but I believe version 3 or 4 isn't backware compatible with previous versions. Verification from a licensed EnCase user?


The .e01 file format is compatible with all versions of Encase from 1 through 5. I can add an .e01 file acquired under version 1 and examine it in version 5 and vice-versa. I see no reason why they would change this.

You may be confusing the compatibility of the case files across versions. They are indeed incompatible in most cases due to additional features being added to successive versions. Of course the case file would hold your bookmarks, reports, search hits, etc. I can open the evidence file in any version, I may just have to replicate work. Many examiners archive a copy of the Encase version used in the analysis along with their case file and evidence files.


- farmerdude
Can you please explain your second paragraph? I don't understand the "user specified block size" etc. etc. etc.?


Encase version 5 offers the user the option of changing block size and error granularity in the evidence files. By changing the block size the user can increase the size of the block used to calculate the CRC. I suppose the theory being it will speed up the acquisition.

Error granularity settings change how many sectors are zero'd out when Encase encounters a read error. It can be reduced down to one sector, so that the data from the other 63 sectors is not thrown out if there's only an error in one of them. The default for each has always been 64 sectors.

I have not tested either, but I would presume that changing them may have consequences on compatibility with other applications or other versions. That said, I think choice is a good thing, it lends itself to flexibility.

- farmerdude

You are incorrect if you believe you can write a pure non-compressed E01 file, Greg. EnCase always compresses, even when you tell it not to (unless they've changed this in version 5).


Maybe you could explain this for me, when I acquire an image with no compression selected the evidence files take up the same space + as the original data did. I realize it is not in a raw format such as dd, but I've examined a drive with .e01 files and the data is clearly there in it's native state, albeit between crc's.

- farmerdude

Are you indicating in your tests EnCase is faster than other acquisition engines using the same variables? Myself, I have found using an acqusition engine, crossover cable, and gig ether cards to be the fastest, averaging 1.5-1.7 gig a minute. Oh, and of course this isn't the EnCase engine. Just 'dd', 'SMART for Linux', or similar.


No, not at all. What I meant was that I was acquiring without compression as the fastest method within Encase. If I want a compressed image, and I usually do, it will take several times as long as an uncompressed one. My practice is to acquire it initially through a write blocker with no compression (I can do right at a gig a minute), then Encase offers the ability to reacquire those evidence files and select full compression in the process if I desire. I do this back at the office and let it run overnight as a 40gb acquisition with full compression may take 5 hours.

This technique limits me to the .e01 file format, as encase is the only application that allows this that I'm aware of, and I don't know how to use Encase to acquire to dd. But then again, I've got no qualms with the .e01 format.

People are seeing similar results as you with Linen. Of course, like you said, if you're going to use Linux, why not just acquire with dd. I suppose it's what you're accustomed to.

Is it faster under Linux to go through the network cable, or to have the drives installed on an IDE channel or a firewire device?

By the way, I am glad to see you here farmerdude. I've been on your website several times and almost met you for some training. I will get around to that as I'm very interested in learning more about Linux, particularly for acquisitions.
_________________
Greg Marshall, EnCE 
 
  

gmarshall139
Senior Member
 

Re: Imaging software

Post Posted: Feb 15, 06 07:24

I did some tests acquiring a small linux volume. I used Encase ver. 5 to acquire it. I changed the block size to 256 sectors and set the error granularity to one sector. As I said before the default is 64 for each of those. I hashed it in version 5. I then added the same image to version 3 and achieved the same hash. That is the earliest version I have, but apparently this feature does not affect backwards compatibility. I also successfully added it to FTK, but as it was a linux volume, FTK couldn't read the file system anyway. Good news for .e01 fans.
_________________
Greg Marshall, EnCE 
 
  

Andy
Senior Member
 

Re: Imaging software

Post Posted: Feb 15, 06 14:03

Just to mention about imaging timings. This is a subject I have done research for my MSc (both locally and across a network), using EnCase and Linux DD.

At the time I used a survey (from this forum, and questionnaires) for the distribution of imaging programs with practitioners. The results as follows: -

EnCase 48.08% (50)
Forensic Toolkit 13.46% (14)
SafeBack 3.85% (4)
dd 14.42% (15)
Ghost 11.54% (12)
Other 8.65% (9)

With imaging there are many different variables to be taken into consideration; however I endevoured to used the same experimental network architecture, hard drives, and file systems, block size, no compression, etc.

EnCase Acquisition Local IDE to IDE.

Drive Time Start Time End Total Bytes/s GB Ave throughput
1 09.41:30 10.01:52 19.58 20485785600 19.08 16.30 MB/sec
2 11.15:40 11.35:11 19.31 20520493056 19.11 16.71 MB/sec
3 07.46:25 08.13:13 26.48 40020664320 37.25 23.73 MB/sec
4 13.52:19 14.22:25 30.06 40024212480 37.27 21.13 MB/sec

Linux DD Acquisition.

Drive Time Start Time End Total Bytes GB Ave throughput
1 10.12:45 10.57:14 44:29 20485785600 19.08 8.04 MB/sec
2 15.18:49 15.53:12 34:23 20520493056 19.11 9.48 MB/sec
3 08.20:13 09.11:14 51:01 40020664320 37.25 12.46 MB/sec
4 10.12:45 10.57:14 44:29 40024212480 37.27 14.30 MB/sec

This is just a small snippet, but the results were that Linux was consistently slower using the same test conditions. This isn't a slight against Linux in any way. I still think its a very good method of creating a forensically sound bit for bit copy of a device, and using something like GRAB in Helix negates the requirement to laboriously type at the command prompt (it has a very nice GUI).

I am also glad to see you here farmerdude, I have a fairly decent understanding of Linux and I am an 'intermediate' user, but would like to learn a lot more. I do think it is overshadowed by the Windows based commercial products and your input, for me is most welcome.

Andy  
 
  

keydet89
Senior Member
 

Re: Imaging software

Post Posted: Feb 15, 06 16:19

Andy,

In your testing of Encase and Linux dd, what were the block sizes you used? What were the command line settings for dd?

Harlan  
 
  

Andy
Senior Member
 

Re: Imaging software

Post Posted: Feb 15, 06 18:23

I don't want to go too far off topic, so in answer to Harlan I'll keep it brief - I used various block sizes for both programs. With EnCase v4 I was stuck with the default block size (32KB or 64 sectors). However with v5 I was able to alter this to whatever I wanted. I found the small block size had less overheads (buffering and caching). I settled for 32KB blocks, and spit the image into 1500MB size chunks. The command lines I used reflected this.

I automated the process using GRAB in the Helix boot CD. I don't have the exact output to hand, but it was something similar to: -

dd if=/dev/hdh skip=0 conv=noerror ibs=32KB(or whatever size) 2 –>> /var/local/grab/logs/grab.image.log | grab-counter
2>> /var/local/grab/logs/grab.buffer.data | tee /var/local/grab/grab-fifo | md5sum > /tmp/hash.log 2>dd if=/var/local/grab/grab-fifo 2>> /var/local/grab/logs/grab.image.log | efense-split -a 3 -n -b 1500m - /home/helix/mnt/MARS/E/DD_Image. >>/var/local/grab/logs/grab.image.log

Andy  
 

Page 4 of 5
Page Previous  1, 2, 3, 4, 5  Next