Technical Hints
Supported file and disk size: at least 120 TB
Maximum file size in volume snapshots: 120 TB - 1 byte
Maximum number of sectors generally: 240-1
Maximum number of clusters generally: 232-1
Maximum number of hash values per hash database: 231-1
File system support for volumes with more than 232 sectors: NTFS, Ext*, XFS, Reiser*
File system support for volumes with more than 232 clusters: NTFS, Ext4, XFS
Maximum number of simultaneously open interpreted disk images: 100
Maximum number of simultaneously open partitions and interpreted volume images: 256
Maximum number of search terms in a case: 8191
Maximum number of data windows: 1000
Max. no. of program instances: 99
Max. reversible keyboard inputs: 65535
Encryption depth: 128-256 bit
Offset presentation: hexadecimal/decimal
In most cases, the progress display shows the completed percentage of an operation. However, during search and replace operations it indicates the relative position in the current file or disk.
Search and replace operations generally run fastest with case sensitivity switched on and without wildcards enabled.
Here are some pieces of information concerning the Master Boot Record of a hard disk, that is editable using the Disk Editor.
When searching with the option "count occurrences" activated or when replacing without prompting, for a search algorithm there are generally two ways to behave when an occurrence has been found, which in some cases may have different results. This is explained by the following example:
The letters "ana" are searched in the word "banana". The first occurrence has already been found at the second character.
1st alternative: The algorithm continues the search at the third character. So "ana" is found again at the fourth character.
2nd alternative: The three letters found in the word "banana" are skipped. The remaining letters "na" do not contain "ana" any more.
WinHex is programmed in the second manner, since this delivers the more reasonable results when counting or replacing occurrences. (If you continue a search using the F3 key or you choose the replace option "prompt when found", the algorithm follows the first alternative.)
Special Performance Enhancements
File header signature searches, block-wise hash matching, FILE record searches, searches for lost partitions, and physical simultaneous searches are sparse-aware operations when dealing with certain compressed and sparse .e01 evidence files. That means that areas that on the original hard disk were never written and thus still zeroed out or areas that had been wiped on the original hard disk or consciously omitted areas in cleansed images are skipped and almost require no time, because their data neither has to be read nor decompressed nor further processed (searched/hashed/matched against the block hash database).
Sparse-awareness is active for .e01 evidence files that were created by X-Ways Forensics and X-Ways Imager with a chunk size of 32 KB, 128 KB or 512 KB. Also possibly for images created by 3rd party software, depending on the settings and the internal layout. Operations are not sparse-aware on images of Windows dynamic disks, images of LVM2 disks, and on reconstructed RAIDs based on .e01 evidence files.
Logical searches and indexing in files stored in an NTFS file system are also sparse-aware at the .e01 evidence file level, and generally logical searches in virtual "Free space" files.
Logical searches and indexing in NTFS, Ext*, XFS and UFS file systems are sparse-aware at the file system level. That means no time is wasted on large sparse areas within sparse files. Those areas are ignored, regardless of whether the evidence object is an .e01 evidence file, raw image, RAID, or actual disk.