Large hard drive imaging

That doc is 7 years old. Time to generate a new comparison including NVMe, USB 3.1 und Core i7/9 CPU… - today we simply have a new generation of tools and hardware available. No, sorry, I do not have that time available -/

Sure, but even then X-Ways was on the fastish side, if you prefer, I was surprised at the surprise 😯 expressed by armresl about your report of using X-Ways for imaging ) .

jaclaz

I'm honestly shocked that people still use FTK or Encase for imaging.
Or Encase for anything actually

I'm honestly shocked that people still use FTK or Encase for imaging.
Or Encase for anything actually

Just read this https://www.reddit.com/r/computerforensics/comments/e7rblh/is_encase_worth_buying_any_more/

It is certainly true that imaging time will increase with disk size. However, the discussion so far didn't mention that the imaging time will also depend on the amount/type of data and level of compression. For instance, it is quite common for 1-2TB drives in "consumer" equipment to be >50% empty and there is an inevitable trade-off between speed and compression.

Wouldn't that only matter if you're reading the contents or doing logical extractions? If you're simply running a stream acquisition (physical disk/sectors), the content shouldn't matter no?

I'm by no means a hardware imaging expert so I could be wrong but that was always my assumption.

Jamie

Correct, a physical drive image is a bit for bit copy, data content does not matter on the read, an empty drive would take the same time as a full drive. However if your are making a compressed image copy, the compression time will be effected by the data content which will in turn effect the write time.

All things being optimum, the source image read time is the speed limiting factor and that is unchanged by data content.

I'm honestly shocked that people still use FTK or Encase for imaging.
Or Encase for anything actually

Just read this https://www.reddit.com/r/computerforensics/comments/e7rblh/is_encase_worth_buying_any_more/

Yeah that's been my impression, over the past 4 years a lot of forces/companies have moved to X-Ways/Axiom combination.

I also use X-Ways for all my imaging, in standard scenarios, but I'm curious as to your experiences with highest compression versus the fast-adaptive method. ….
Are your observations purely-imaging related or both for imaging and processing?

Hmm. It might be, that the adaptive compression is a bit faster then using full compression. This might depend on the hardware you are using, especially the number and type of CPU. Perhaps we are only talking here about a few minutes?! I am always using the max compression, because a lot of the images I am creating will be uploaded to a SFTP server, so we can split the analysis work across the team. The Incident Response Team I am working for is distributed across the globe and we are working from home, if we are not onsite for an emergency response

Some of our customers are in countries with bandwidth limitations, therefore we always try to make the file size as small as possible. If possible, we ask our customers to use other tools like Cylr to generate a zip file with the necessary evidence. This is what saves most of the time, bandwidth and file size.

regards, Robin

Just read this https://www.reddit.com/r/computerforensics/comments/e7rblh/is_encase_worth_buying_any_more/

Yep, and also the results of the NIST testing of carving apps
https://www.forensicfocus.com/Forums/viewtopic/p=6601012/#6601012

jaclaz

Back on this subject, having to do sporadic lockdown imaging, it's made me think about times more, and X-Ways seems to be topping out at around 5.5GB/min.
I say X-Ways but I wonder if the write-blocker is actually the limit as that's not much over 90MB/sec on drives I'd expect to see at nearer 130MB-150MB/sec.
For SATA drives I'm using the t35es-r2 over esata (and the esata port can, and does, copy much faster than that - with a dock plugged in for example).
Whilst a direct SATA connection might be a way round this, using a linux-based forensics distro, I just wondered if the rest of you X-Ways users noticed from memory the 5.5GB/min mark to be a limitation? And if so, were you using the T35es-R2?
I have a feeling I may have seen faster imaging speeds in X-Ways and therefore not be a limitation of the software/CPU - perhaps via the tableau PCIe write-blocker /adapter for solid state drives - rather than the T35es-r2 - hence the question.
(not currently in the office so can't have a play and try to determine if this is correct)

We have definitely had faster speeds than that through X-Ways imager. We use WinFE to live boot some devices which have soldered on SSD's and then image using X-Ways imager, think we have close to double that speed before.

You may have a limitation with your writeblocker, you could try booting a device to WinFE and see if that is quicker.

We have definitely had faster speeds than that through X-Ways imager. We use WinFE to live boot some devices which have soldered on SSD's and then image using X-Ways imager, think we have close to double that speed before.

You may have a limitation with your writeblocker, you could try booting a device to WinFE and see if that is quicker.

Thanks - sounds like my memory of seeing faster speeds was probably right then.
It's been less of an issue in the past overnighting stuff (and the faster stuff were probably fast drives/chips anyway) so didn't pay too much attention.
So I guess the next logical question is then does anyone use other brands of hardware write-blocker that are exceeding this kind of speed on eSata or USB3? (eSata preferably as I've found that most reliable - but doesn't have to be)