Besides dd, which other means of acquisition would be best to become familiar with? I would like to start building my resume aiming to gain an entry level job. Since making forensically sound images is very important, I want to take a very good look at all of the options available to me. This question is aimed at imaging a dead system.
Does anyone use ghost to make images? Are there any other windows apps used for acquisition?
Is helix the best for imaging memory contents of a live system?
Sorry if my post isnt the most cohesive. Just looking for some feedback in the middle of studying.
There are various ways to acquire a forensically sound image.
*Windows app Attach the suspect drive to a write blocker (IDE, SATA, SCSI etc.) and mount it via usb/firewire on your acquisition workstation. You can then use FTK imager installed on your acquisition workstation to obtain an forensic image (dd, Safeback, Encase) of the mounted suspect drive.
*DOS app Ghost can be used but I would recommend against it unless you have no other choice left. There is a switch in Ghost that you can specify to get a sector by sector copy. I assume you have a bootable floppy disk. Make sure the Ghost command in autoexec.bat has the switch included for sector by sector copy.
*Windows App WinHex is another option.
*DOS app I have used X-Ways Replica from the makers of WinHex. Works well. I prefer this over Ghost boot disk.
*Paraben's Forensic Replicator is good as well.
It varies case by case and depends upon the the situation. I have used all
of the above.
There are other products but the ones I mention are most widely used.
The method I prefer for dead (turned off) systems is Write Blocker and FTK imager combination.
IMHO Prodiscover is the best product to acquire a live system.
Thanks for the quick reply. Although dd works fine, I figured it would be best to also look at a few other commonly used alternatives. I am going to check out a few that you mentioned.
Can I also suggest you take a look at the free windows tool FTK Imager. You can download from www.accessdata.com/ftkuser.
It's a really useful tool, easy to use and can convert between formats. You can also take a look at the drive pre-aquisition.
FTK Imager was one that I looked at first. I used it to make an image of a flash drive. Seemed to be cake.
Im going to play around the the FTK demo a bit as well.
Whichever tool(s) you use to acquire and/or clone drives, make certain you write your image files in a raw format (such as that of 'dd'). A raw image file can be interpreted and accessed by every program, now and conceivably always in the future. A proprietary image file format cannot be read by every program and may not always be read in the future by the same software (backward compatibility is not a guarantee, a popular Win32 forensic program is guilty of this). You gain maximum advantage using a raw format.
Check out SMART for Linux - you can acquire and clone simultaneously. It's very slick. Additionally, error handling ensures you don't "throw the baby out with the bath water".
I can't agree more with farmerdude. I supervised a section at a very large government lab where we imaged many many terabytes last year and our first choice is always a dd image using dcfldd. This tool generates an MD5 while you image and the newest version available on sourceforge can do several other hash algorithms. The sheer portability of the raw image is invaluable because all the big forensic software tools all have their advantages/disadvantages so I may use multiple tools on one exam.
I agree with Thomas…in fact, I've used FTK Imager to convert EnCase evidence files to dd format recently for this very reason.
> …a popular Win32 forensic program…
Thomas, which one?
Also, could you provide some insight regarding your post about memdump in another thread? The original poster was asking about dumping the contents of RAM on Windows…there doesn't seem to be a version of memdump for Windows, unless you know of one (link, please??).
I've used FTK imager, Encase's built in imager, their netowrk boot disk imager via a network and ILook's IXimager. I tend to stick with the E01 format due to the CRC and MD5 checks built in. I suppose it's a matter of personal preference however…
Win32 program …. EnCase
Also, someone provided one link for memdump for Windows back on that thread, sorry for late reply.
The CRC checks every 32KB for E01 files …. if you feel you need that then that's the tool for you. Or Safeback, as they have CRC checking as well IIRC. However, if you've done dozens, hundreds, or thousands of E01 files, have you ever needed the CRC check? You can always play the what if game. However, that proprietary format comes with a big drawback if you have never needed to play the what if game. Is it nice? Maybe. Is it a necessity? No. Does the E01 proprietary format have drawbacks/limitations? Absolutely. Like a PST instead of a mbox.
> Does the E01 proprietary format have drawbacks/limitations? Absolutely. Like a PST instead of a mbox.
I'm not sure I follow. I've pulled PST files out of EnCase and dd images and worked with them. I've done the same w/ mbox/inbox files.
What am I missing here?
I could be completely wrong so Iâ€™ll apologise in advance. I donâ€™t think farmerdude is saying there are problems with .pst or mbox files in the E01 format. I think heâ€™s drawing a comparison between a proprietary format (.pst) and a format thatâ€™s slightly easier to access (mbox)?
Hhhmmm…okay, from that perspective, it makes sense. Sorry, I didn't see that outright.
Well, given that, I'd like to hear Thomas's insights into proprietary formats. I'm sure that the most prominent issue is going to be that proprietary formats are…well…proprietary, and aren't read by all tools. But aside from that, are there any particular issues?
A proprietary file format is restrictive, potentially limiting (crippling), and potentially most costly (financially).
Restrictive in that some developers do not allow others to interpret their file structure. They hide beneath the DMCA umbrella and threaten if support for their file format is included a lawsuit will result. Case in point, no Safeback v3 support in AccessData's FTK.
Potentially limiting (crippling) in that you may not be able to validate your work using other tools as a direct result of the above point. You may find the court directing you to do the work again, to an open file format, so that opposing experts may see what you see and analyze what you analyzed. You may find that your tool with the proprietary format support doesn't find what you're looking for or doesn't do what you want it to do. You hear of another tool that does, but unfortunately it doesn't read that proprietary image file format. You may find yourself having to revisit a case. Unfortunately that image file is using an older version of the proprietary format. Where or where is your old installation media for that older version of that program? Because a year or two have passed, and you're using the new and improved version - which happens to not support the older proprietary image file formats, by the way.
Potentially more costly in that you may be stuck with the program that legally interprets that file structure forever. You may have to upgrade to the next version or you'll receive no official company support. The newer version may not be backware compatible so that if you want to use the new (bug fixes and enhancements) version you'll have to restore the image back out and reacquire using the new version (A lot of time involved here. All of which could have been saved had you acquired to an open, raw image in the first place.).
At this point the light should be shining bright so bright in your eyes that acquiring to a raw image will be what you do from here on out.
BTW, can anyone argue *why* a proprietary image file format is superior, or should be preferred and used over the raw format?
The EnCase acquisition engine is capable of writing a raw image file format (very much like 'dd' does). I understand the default is E01, but you can elect a raw format. I do not own EnCase so I am unaware of how you select the raw image option, but I can't imagine it's buried too deep?
So, if the program you choose to analyze image files with is EnCase, that is fine, but that doesn't substantiate choosing the proprietary E01 format over the raw format EnCase is capable of producing. Simply select the raw image format.
With regards to compression, the capability for compressing on the fly is there for the raw image format as well, be it 'dd' syntax piped to compression program, dcfldd variant, or SMART for Linux. I'll presume Guidance Software would include the capability to compress their raw image format in their acquisition engine as well. Verified?
You don't have to use Linux, nor a 'dd' command or equivalent. Use EnCase and dump to the raw format. Which version of EnCase are you using? Does yours not support writing to the raw format?
From Guidance's site
"EnCase Linen Utility The Linen utility is a Linux version of the industry standard DOS-based EnCase acquisition tool. While it performs the same basic function as the DOS version, it overcomes a number of limitations, such as non-Windows operating systems, extremely large hard drives and speed of acquiring data."
Their words, not mine. I hope your agency is aware of these and have protocols in place.
I am not arguing, but your last line "and for the above reasons this proprietary image fiile format (EnCase) is better for me" I don't feel answers my question, nor does it substantiate writing an E01 versus a raw image.
What you've mentioned is invested money in a product and company, not an image file format. You've made mention of prevelance of Win32 over Linux in your area and others. But again, that has nothing to do with image file formats. What I'm asking for is WHY write an E01 and not a raw image, using that same tool? Additionally, what benefits does the proprietary E01 provide to you?