Even More Thoughts on Forensics

Hi Edward,I've been using dd as my disk image capturing software of choice for many years, usually booting a FreeBSD live CD and using dd to get disk images onto a mounted USB disk.However I wanted to point out that from looking at your loop and the input file argument it passes to dd, I see that you are using dd in a non-forensic manner.The use of dd does not automatically mean that every operation you perform with it will be of a forensic quality. Correct procedure is required to do that.dd can be used with input and output at the file level or raw block level (where you either specify a file from a mounted filesystem or raw block device respectively). To provide a forensic quality read of a disk, the input file must be a raw block device and NOT a file within a mounted filesystem from that block device.Unfortunately this is conceptually blurred in UNIX-like operating systems since a raw block device can be considered a "file" and accessed as such. Meaning that this can be confused when providing the input file (if=) to dd (or output file for that matter). The difference between file level and block level requires knowledge of the operating system you are using, since block devices are not always named in the same manner and thus spotting the distinction can be difficult.One of the first rules to capturing a forensic quality disk image is to NOT mount any filesystem within it, which is a part of why I prefer to use a BSD to capture evidence (it will not just mount a disk it finds without asking me).In your example, you are copying non-forensically at the file level from a mounted filesystem! This means that you are not getting slack space data, deleted data and meta data which relates to (but not contained in) the file, etc and you are also continuing to run the risk of losing that required data as long as that filesystem on the source disk is mounted.

Hello,Re: Using cpActually cp will not do the same job as it does not copy the underlying blocks of the file, but the content of the file. Things are slightly different there. Not if you want true 'duplication' of the underlying blocks. You can use dd to copy files as well as full devices. Unfortunately, until the spec for the VMFS is released, this is the best you can do. dd gives me the opportunity to define the size of the block as well.Re: WorkstationESX uses a Virtual Machine File System to store VMs unlike WorkStation. Since this is unknown to tools like EnCase and FTK, you need to use different mechanisms to get the data off the system.Best regardsEdward L. HaletkyAstroArch Consulting, Inc.

I'm a user of VMWare Workstation, not ESX. However, from the above command line, it appears that ESX uses .vmdk files, so simply documenting and copying the entire .vmdk file off of the system for analysis has worked very well for me during engagements. Both FTK Imager and EnCase will allow you to open the .vmdk file and acquire images, without requiring any further VMWare products.For the contents of memory, pausing a VM will create a .vmem file...this is analogous to a dd dump of RAM, and can be analyzed using the available tools.H. Carveyhttp://windowsir.blogspot.com

Hi,There appear to be a few flaws with your post.For starters, your dd command will overwrite the output file for each of the files in the *.vm* glob, meaning you will only actually end up with the last one that matched. Perhaps you meant to put the $x somewhere in the output path also?Secondly, I've never used ESX, but it appears that you are accessing the files on a mounted filesystem on the host (some embedded linux IIRC). So what exactly is the point of using 'dd' anyway? 'dd' in this context is ultimately reading from a logical file, not a block device. 'cp' will do exactly the same job.Dave