Quote:
WinHex will also show the MD5 HASH after making the image which can also be compressed at the same time.
I've read that using NTFS compression or NTFS sparse feature on large files could cause issues. Indeed I've had issues trying to compress large files (more than 20-30GB approximately) from Windows Explorer, or create large volume images with WinHex using the NTFS compression or sparse feature. But I've created huge sparse images with ddrescue (-S switch) on NTFS partitions with no problem (neither during the creation nor afterwards when accessing such images). It seems to negatively affect the performance though : recently for instance, when creating a sparse image from a healthy 4TB HDD, containing about 500GB worth of data (for
this recovery case), to a NTFS partition on a 2TB HDD, the average rate went from 60-90MB/s at the begining down to about 30MB/s when actually copying data, and then up to about 120MB/s when reading empty areas.
I had asked about this on SuperUser, but didn't get much conclusive insight.
What is your experience on that matter ?
Quote:
The challenge with software is the handling of bad sectors and write blocking of the source drive.
Quote:
In order to use winhex or any windows based tool , hardware write blocker is a must so winhex will be of no use. If source hdd is directly connected to windows pc then some write operation will be performed and access date /stamps will be altered.
It must be a linux based live boot tool.
As some have mentioned in former threads on this forum, deactivating the MBR by replacing the last two bytes by whatever value, like “FF FF” instead of “55 AA”, effectively prevents the system from attempting to mount the partition(s) and potentially alter them. But if done from Windows it might be too late, as it mounts whatever is mountable right away, so indeed it should be done from a Linux system. But, although it should work, it might not be safe enough for a real “forensic” job – especially if the very reason why you need to go to that remote location is because the case is particularly sensitive.
Also worth noting : WinHex 19+ has a “OS-wide write protection” feature, which I haven't tested yet ; it should prevent from tinkering with the MBR, but likewise, it only works after the drive has been analyzed by Windows, which kinda defeats the purpose. From the integrated help :
Quote:
Allows to write-protect locally attached physical storage devices (including removable media, except optical media) with all their volumes everywhere in the operating system, in all applications, even at the sector level in WinHex itself, no matter which edit mode is active. This can be useful to protect original disks that need to be acquired or analyzed (but only after Windows has detected and accessed them) and your own disks that contain images, from accidental alteration, deletion, or data corruption. The effect will last until you remove the write protection again or unplug the devices or reboot your computer. To keep Windows from touching newly attached physical storage devices before you can write-protect them (i.e. to keep them in "offline" mode first), you would need to disable automatic mounting in Windows (and verify that this works). Turning on write-protection for an offline disk will automatically bring the disk online, at the same time while rendering it read-only. Careful, do not write-protect disks that your Windows system needs to write to for proper functioning!
FAQ
Search
Login
Register
HDDGURU FILES
