What are people's experience with this suite of tools? I have imaged several devices with the ewfacquirestream tool. Checksums are OK, have managed to get the images to mount with mount-ewf, have opened the images in autopsy/sleuthkit and FTK. However, I can't get them to open properly in Encase V5. Encase sees the image as an unpartitioned physical device. Have tried imaging in encase5 and encase4 format. Anyone else had this problem? Any ideas how to fix it?
Hi, can you send me the details
- version of libewf used
- commands and parameters used dd, netcat and ewfacquirestream I assume
Kind regards,
RJM
Hi rjmm
I am using ewfacquirestream as part of a script. The line that images the hard disk is as follows
ewfacquirestream -c best -C $csname -e my_name -E $evnum -f encase4 -t $evnum < $susdev
Obviously the variable values are defined earlier in the script, the image file is created on my lab machine hard disk.
The script does an md5sum on the physical device, that checksum matches the one produced by ewfacquirestream. I have tried using the encase5 format but get the same results.
Am using version 20080501
In Encase V5.05g I am creating a new case, then using the "Add Device" and "Add Evidence Files" to add the E01 file to the case. When it has been added, I just see the physical disk Icon in the tree pane of Encase with no name associated with it and no data in the view pane. After verification, I click on the entries tab in the tree pane and the Report tab in the lower left hand pane. The Description field reports a Physical Disk with 20015856 Sectors (which is correct). Physical Size of 512, starting extent 0S0 and File Extents 1. It correctly reports the device data, Acquisition and Verification Hash are the same and they match the hash value generated by md5sum on the physical device of the original disk. Total size in bytes as reported here matches the total size as reported by "disktype" command.
There was not DCO or HPA in use on the original disk (according to the tableau-parm command).
As I said previously, Autopsy/TSK and FTK have no problem handling the E01 files.
TIA!
Hi,
Have you imaged a full disk or a partition? I'll get back to you. I'll try to reproduce the error this week.
In the meantime. Have you tried to export the image with 'ewfexport' to a dd image and read it with EnCase.
Kind regards,
RJM
Hi,
How did you image the drive [logical] (partition only) or [physical] (partition table) . EnCase will only look at the info in EWF files, FTK and TSK will read the actual data. This is an EnCase feature P
Hope this helps.
Regards,
RJM
I assume you have the Encase dongle and you are running in "forensic" mode? What you have described is most often seen when the dongle hasn't been captured by the Encase programme.
Thanks for the suggestions guys, I have been imaging the physical disk and have ensured the correct EnCase dongle is connected. Problem still exists!
Further to the last. I have repeated the same process, using the same script and variables on a thumb drive. Encase handles the E01 file created by ewfacquirestream just fine. It may be a problem with the original hard drive. Will have to do some more testing on this.
OK, I think I have got to the bottom of this. I noticed that I originally imaged with 2 GB segment file sizes for my .E0 files (which is my normal practice). I have tried the same suspect hard drive imaged with the default 1.4GB segment size in ewfacquirestream. The E0 files now load into Encase with no problem.
Having read the documentation again, I see that the man pages do indicate a maximum segment size of 1.9GB for encase5 format (my bad!). I am curious where this 1.9GB limitation comes from. I don't know what the maximum segment size in Encase is, off the top of my head, but it is certainly at least 2GB, as I have re-imaged the drive in Encase V5 in 2 GB .E0 files
Hi,
First of all it depends on what the different programs address with the file sizes.
Basically 1 GB should be 1.000.000.000 bytes and 1 GiB 1 x 1024 x 1024 x 1024 bytes. libewf now uses the GiB way of specifying the file size. Basically 2 GB is about 1.9 GiB.
Due the internal sizes of some of the values in the EWF file format it only allows to use 31 bit for file offset values. This allows for a max of 2 GiB. In EnCase 6 a base offset value was introduced to fix this limitation.
I'm not certain why EnCase5 cannot load segment files of a 2 GB ( 2.000.000.000 ) size. The file format allows up to 2 GiB ( 2 x 1024 x 1024 x 1024 ). If EnCase cannot read the evidence files correctly it will not read the evidence files at all.
We still think that the behavior was caused by the physical/logical flag.
Kind regards
RJM
What are people's experience with this suite of tools?
Hi Stumpy,
I've been looking at the ewf suite, but have mainly used ewfacquire for imaging and ewfverify and played about with ewfinfo. I've done some very rough tests and compared ewfacquire against Linen and dcfldd. Its been impressively quicker. I was interested to read that ewfacquirestream can be used to acquire memory '/dev/mem'. However "Currently ewfacquirestream is not error tolerant like dd's with the noerror option". My understanding of the structure of memory is that without the conv=noerror flag you're almost certain to get errors and therefore this tool will not grab Physical Memory.
Is there any particular reason why you've been using ewfacquirestream rather than ewfacquire?
Jim