Why would anyone use linen?
Just curious.
Does it write a raw image file, or a proprietary EnCase evidence file format?
If it only writes an EnCase proprietary image file, why would you want that? IE, what is/are the benefit/s for using that proprietary format?
Cheers!
farmerdude
Greetings,
Are you trolling or honestly curious?
Linen creates EnCase evidence files, which are fairly useful if you're using EnCase, which a huge number of people are.
Here's the wikipedia article on the format
http//
_David
Well, the question was asked, so it was sincere.
I am asking because for the life of me I cannot figure out why anyone would write a proprietary E01 file, and I didn't know if linen provided the option to write a raw image file.
The question still lingers … why would you write a proprietary image file instead of an open one?
Anyone? Bueller?
Cheers!
farmerdude
Greetings,
Did you read the Forensics wiki (correction from first response where I stated "wikipedia) article describing the file format? It explains some of the benefits. A brief clip from the article
"The evidence files, or E01 files, contain a physical bitstream of an acquired disk, prefixed with a '"Case Info" header, interlaced with CRCs for every block of 64 x 512 byte sectors (32 KiB), and followed by a footer containing an MD5 hash for the entire bitstream. Contained in the header are the date and time of acquisition, an examiner's name, notes on the acquisition, and an optional password; the header concludes with its own CRC. "
Having the case information in the header and CRCs for each block is rather useful. (And these are features that, I believe, Simon has put into afflib?)
EnCase has a major share of the market. Writing a file format that EnCase can read is pretty useful. And Linen exists, I suspect, mostly for EnCase users.
-David
I'm aware of the format for the proprietary image file, David. Thank you.
I've just always wondered why anyone would write a proprietary image file format, that is all. For a few reasons. Namely
1) Forensic practitioners don't tend to appreciate analyzing files that are in a proprietary format so why would they knowingly create another one?
2) The E01 proprietary image format offers nothing in the way of efficiency or accuracy in analyzing the data within. The only selling point that Guidance Software markets is that _if_ data is changed you will know where. However, as many practitioners already know the data can be changed and the CRC also changed so that everything appears as it should.
You stated that "Having the case information in the header and CRCs for each block is rather useful." Can you elaborate on this? Why is it useful? Have you ever had the data change and the CRC alerted you to this fact? If so, how many times in how many image files?
Have you ever had the underlying file system your E01 files stored within corrupt and have to recover your image file(s)? If so, how easy was it to recover that compressed data within the container on the corrupt file system? Recovering data from a MBOX is easy compared to a PST. Likewise, recovering data from a raw image is easy compared to an E01.
I support an open, raw image, nothing more. Locking yourself into a proprietary format that offers nothing but confinement and monetary reward seems absurd. Hanging your hat on the what-if-my-image-file-is-changed scenario-then-this-proprietary-image-format-will-save-me is like waiting for lightning to strike on a cold Winter's day when the sun is shining. Could it happen? Yes. Has it happened? Yes. Frequently? No. Should you purchase lightning strike on Winter's day sun shining insurance, just in case? No.
Most acquisition engines, both free and commercial, offer the option of writing a raw image output file. That raw file format is the easiest to analyze across operating system environments with both forensic and non-forensic applications, and it is backward and forward compatible.
Cheers!
farmerdude
Good morning,
This discussion is devolving into something resembling Linux vs Windows/OS X. I use Linux, FreeBSD, Windows, Solaris, and OS X. I also use raw, EnCase, dmg, and FTK file formats. I've not had a need to use the afflib format yet, but I am looking forward to doing so. I use EnCase. I also use the Backtrack 3, Helix, perl, awk, sed, dcfldd, OS X, and a host of other tools as needed.
I'll use the tools that get the job done, and "job done" includes many factors including meeting the client's wishes, support, feature sets, and reliability. Like it or not, EnCase is a very feature rich tool with a lot of support by the vendor and community.
If you choose to avoid all tools that use proprietary formats, you're severely limiting your range of options, and limiting the work you can take on. That may or may not be a problem for you. Personally, I wish to keep my options open.
Yes, I've used CRC on individual files. Last month, I spent several days sorting through a large collection of drives sent to me by a client, each containing a number of EnCase images. About 20% of these images were bad in some manner, probably due to the way they were copied from the original drives to the drives shipped to me. The CRC value on the files allowed me to determine which one of the files making up the whole image was bad. I could then request just that file rather than the entire image.
If you need to move an image across multiple systems and multiple tools and you feel a raw image works best for you, have at it. However, there are a lot of environments where EnCase or FTK is the standard tool and will handle the vast majority of the analysis work. In those environments, using the native, and proprietary, file format makes the most sense.
When necessary, I can use the EnCase image with other tools in a variety of ways
1) Mount it with Mount Image Pro.
2) Export one or more files out of it.
3) Convert the image to another format.
-David
Hi David,
Thank you for your detailed reply. I wish you would have answered each of my questions, though. They were asked for specific reasons. Like the ratio of times the CRC has been an issue for you. Or if you've had to attempt to recover data from an E01 residing on a corrupt file system.
Note that I don't feel this discussion is devolving into one operating system vs. another operating system. You did go off the path a bit with the tools and and operating systems stuff, but my question was simple and on the path I'm simply asking why anyone, yourself included, would write a proprietary image file format. That is all. And my interest is simply because I see _no_ advantage in performance or reliability to the E01 file format. For seven years no one has answered this other than "I write it because that is what the application writes".
So again, if there is an advantage to that proprietary format, let's hear it. The CRC slant is a not an advantage as we know that data can be changed and the CRC along with it so no warning will be given. The examiner information embedded slant is not an advantage because forensic practitioners are intelligent humans who must maintain a chain of custody and log records for image files, so one should never wonder which case an image belongs to.
If you have some other reason for writing an E01 file other than it's the only format that application allows you to write I am interested in hearing it. Sincerely )
Cheers!
farmerdude
Is it still a proprietary format? I believe the file format is quite well documented by A. Rosen and by the libewf project. I think that you have to deal with the file format and have to admit that crc's are used as well as casedata within the file instead of nothing or a md5 or whatever checksum file.
RJM
Good afternoon,
The fact that the E01 file format includes individual CRC values that helped me out significantly at least once is useful information for me. I'm not going to sit down with you and work out how to determine a formula to determine an accurate ratio to answer your question beyond that.
I gave you an example of a file system that corrupted portions of an EnCase image which the CRC check found and helped us isolate the problem. If you don't like that particular answer, I'm sorry.
I gave you several advantages of the EnCase file format, but you seem to be choosing to ignore them. Here they are again, plus some others.
1) Case information is in the header. It stays with the image files.
2) CRC value for individual files.
3) Can be created by tools running on Linux and Windows.
4) Is the native file format for a tool I use often.
5) The tool I use often has significant market share and I am often asked to provide images in that format.
If you don't find any value in these features, that is your opinion, but it may not be a universal opinion, and it certainly isn't grounds for continuing to insist that the EnCase file format has no value unless you qualify that statement by adding "to me."
-David
What would you need to use another option for other than dd?