What would you need to use another option for other than dd?
I'm not sure what the question is there.. but if you are asking "Why would you use another option other then DD?" I could ask the same.." Why would you use DD?" Is it because your tools do no support E01? In doing this stuff for the past 10 years I have never needed DD except to play around with VM Ware stuff.. and even that you can Mount an E01 with other tools and go from there.. E01 works with both EnCase and FTK.. is created by both FTK Imager and EnCase… and gets the job done..
So just because it's not "OPEN" or "FREE" doesn't make it not a good option.
Does linen do anything better than say FTK in creating E01 because it is the native program?
I can quite honestly say that I've never had an EnCase image file lose integrity by itself.
The EWF format is not proprietary, it may have been at one point but it is no longer the case. FTK, EnCase, numerous open source tools, all use this file format if you want to use it. As long as you vrify what you have acquired you hould never have a real problem.
DD is a powerful tool, I now use it primarily for imaging Vista restore points, but DD has limitations. My largest conceern is compression. If I imaged a 1TB drive using DD I would be left with an image 1TB in size. If I did the same in EWF format it is probable that the image would be considerably smaller.
It boils down to personal preference. I prefer using EWF files as that is what I use on a daily basis.
If you need to image something quickly in EWF format I recommend 'ewfacquire' part of libewf. This is also found on the Helix CD. It can be compiled for Windows, OSX, BSD, and Linux.
Unfortunately people become so entrenched with what tools they use that this issue just becomes one large argument.
Does linen do anything better than say FTK in creating E01 because it is the native program?
They should creat the same file. If anything I would choose to use FTK Imager as it lets you the choose from a wider selection of compression schemes. Also EnCase has reported issues with imaging with previous versions whereas no such issue has been found in FTK.
DFICSI - Thanks I have always used FTK Imager (or the Logicube MD5/Talon), just thought I would see if I was missing something by not looking at other imaging programs.
Hi David,
One of my points is that the potential value of the embedded CRC does not outweigh the very real cost of a proprietary format. You don't have to figure out your ratio - I'm certain that for most practitioners they have either never needed the CRC feature _or_ it's play has been less than a double-digit percentage of their total EO1 image files.
A second point is that the data can be changed and the CRC value also changed. You never spoke to this in your replies. So ultimately, what good is it if both items can be changed?
With respect to your "example of a file system that corrupted portions of an EnCase image" I didn't follow this. I read that you have a segmented image file, portions of which the E01s were corrupt, _not_ the underlying file system. There _is_ a difference, David - if the E01 is corrupt versus the underlying file system is corrupt. You stated that the CRCs alerted you to the fact that the E01 was bad. Because the CRCs wouldn't alert you to the file system being corrupt. My question stands have you had to attempt to recover data from within the proprietary, compressed E01 image file residing within a corrupt file system versus an open, raw uncompresssed image residing within a corrupt file system?
I respectfully disagree to your laundry list of why you feel the proprietary E01 format is advantageous over a raw image. Specifically
1) Case information should be well documented already, and responsible practitioners shouldn't have to rely on the information stored within the image file header. Remember, that information can be changed and the CRC value also changed. Relying on self authentication can be a mistake. I would prefer to rely on a physical paper as well as a digital document.
2) CRC value can be changed to match the changed data.
3) N/A
4) N/A
5) N/A
The N/As are not advantages, they are a personal preference. I was (am) looking for a neutral view on why the E01 is preferred, superior, advantageous, etc.
Again, please understand I'm only asking for a real benefit to the proprietary file format, David. Not market share, tool support, etc. It _appears_ that there are no _real_ advantages to the E01 format - it doesn't result in faster searching, better analysis, easier recovery if the underlying file system becomes corrupt, etc. It certainly appears a number of practitioners writing E01 files do so simply because that is all their tool is capable of writing during the acquisition process (EnCase variants). Other tools allow practitioners choice - raw, E01, etc. Still other tools write only the raw format.
I do appreciate you're taking time to reply. I think you have illustrated my points about the E01 having no real advantage nicely. I'm only trying to show those with open minds that perhaps the E01 offers no real value and potentially offers more confinement and may be a detriment in the long run. That is all. My posts have never been a personal attack against you or any of the EnCase variants. You were the lucky one who chose to reply )
Cheers!
farmerdude
Farmerdude,
Again is EWF a proprietary file format? I do not think so. Besides that the crc feature can be useful in some cases. At this moment EWF is the standard just like DOC is for office files and please deal with that fact. I personally find it very useful to add meta data within evidence files than keeping it just in txt files!? Furthermore I find the discussion a bit boring. Of course a lot of us would like to see that an open format like AFF would be supported in EnCase or FTK, but that's not the reality.
Cheers,
RJM
Hi RJM,
I find the discussion a bit boring.
Thank you for writing this! It game me a chuckle! Apparently not boring enough to login and type a post, though.
😉
Cheers!
farmerdude
Hi Farmerdude,
Correct. Because this discussion keeps coming back sometimes. I think that EWF is not a proprietary file format and that's from what I read that's your primary argument. I think this because multiple vendors support the file format, a specification has been published multiple years back by Rosen and the current layout of the format has been documented in the libewf project. But if you want to acquire with dd, please do so.
Shalom,
RJM
Sleuthkit