Is there a way to turn off segments for E01 files in guymager? I tried setting libewf segment size to 0 in the Guymager configuration but it throws an error in the config file. Removing that line and it defaults to around 640 MB per segment.
Anyone have any ideas on this? Thank you in advance.
I was under the impression that any E01 image larger than 2GB has to be split into segments.
This is not the case when imaging with FTK Imager. I always do compressed, one file with FTK Imager. It might not be possible with guymager, but I thought I'd ask if someone knew how to accomplish this.
Is there a way to turn off segments for E01 files in guymager?
No, segment files are part of the EWF design.
Although you could make the segment file very large, e.g. 100 TiB, which will have a similar result; a single segment file.
libewf (EWF) has the following restrictions
Roughly all EWF formats other than encase6 allow for a maximum of 2 GiB segment files. Due to the limitation of 2^31 file offsets within the format.
Encase6 uses a base offset to expand beyond the 2 GiB limitation.
Although this might not be compatible with all tools that handle EWF, but the most common ones do.
For more information about the file format see the working document on http//
BTW The same information was already available on
http//
I'm not entirely sure if guymager enforces additional limits, but I think you should as the author.
I haven't had much luck with the Encase6 format in the past, but I'll look into it and do some testing.
I don't often need to use guymager / libewf, but it works great for imaging laptops live with zif connectors or drives in hard to reach places D
I haven't had much luck with the Encase6 format in the past, but I'll look into it and do some testing.
If I'm not mistaken the encase6 format (for a lack of better name) was introduced around EnCase 6.7.1. Because the EnCase additions are not open, it took a while for other tools to integrate the changes.
Let me put it like this there are some interesting aspects to the EWF format in contrast to RAW, but it also has its limitations.
Personally I like the idea of an open standard like AFF1/AFF4. This format also provides a fresh look on what an evidence container format actually should be. What functionality it should provide, besides being a container for the data and some metadata. But alas most commercial products do not provide support for that format.
I don't often need to use guymager / libewf, but it works great for imaging laptops live with zif connectors or drives in hard to reach places D
I'm not entirely sure what the hardware interface got to do with the tool, but I assume you probably use an alternative solution when imaging PATA/SATA disks.
IMHO guymager is a great tool. The author, Guy was one of the first to realize the power of multi-threaded (MT) imaging. Although nowadays there are several MT imaging tools.
My experiments with MT imaging conclude me that, on average, it can image disks faster using fast compression than with-out. It boils down to this often the write speed of harddisks is slower than the read speed. Writing less data means speeding up the imaging pipeline. For some additional read, Tableau has an interesting whitepaper on speeds of harddisks, titled "Benchmarking Hard Disk Duplication Performance in Forensic Applications".
Regarding libewf I've put some features in the ewftools I personally missed in other imaging tools and some are still work in progress. Some simple ideas that can speed up the imaging process, i.e. empty-block compression and resume write.
Although I've noticed that because the ewftools are command line and do not come (except by 3rd parties) with pre-build binaries it can be quite challenging for some users to build and use them.
Yes, I typically use Tableau with FTK Imager for PATA/SATA.
Thanks for the helpful information, I will do some testing with Encase6 utilizing libewf and the higher limit, and see if FTK will play nicely with those images.
Yes, I typically use Tableau with FTK Imager for PATA/SATA.
Thanks for the helpful information, I will do some testing with Encase6 utilizing libewf and the higher limit, and see if FTK will play nicely with those images.
Note that in the past I heard some people mentioning performance impact with different segment sizes; although that was mainly regarding FTK 1.x.
If you hit a snag just let me know, the most easy way is through the libewf project site tracker(s) or my sourceforge user account.