A very useful tool is the ability to search the complete disk for a possible string(s). This option is only enabled with the forensic package. The search can be set up to work with multiple strings, and mixed types of string. ie a string may be either straight characters, uni-code, or both searched for.
The disk will searched at the same time as data carving takes place, if required, just a simple search and no saving of data.
Every sector / cluster is searched for the string, which can be any combination of characters, not just printing characters.
When a match is found, the sector number is added to the log. If the Stop on each match is enabled, a dialog box will be displayed with the sector number. The log can be viewed at any time, and sorted on the status column to see if any matches have been found. A search cluster can be viewed by clicking on the entry in the log.
A possibly unique feature of the CnW Recovery search is the ability to search both standard and compressed NTFS clusters. To enable this mode it is necessary to set the following flags on the Image Option display
Read in cluster mode
Test for NTFS compressed clusters
It is also necessary to set the start cluster sector number, and the cluster size (typically 8).
As each cluster is read it will be tested to see if compressed. If compressed, it will be expanded and searched
Uni-code and straight searching
The option for uni-code search can be used on it's own, or with the standard search. Both little end and big endian strings are searched for
Limitations with raw disk searching
At first glance, searching sectors or clusters seems a fool proof way to find a string, but there are limitations that must be understood before using the results as forensic evidence. The two areas are fragmentations and logical file structure
If a string being searched for is at the end of a cluster, it is possible that the file is fragmented, and so the end of the string may be on a different cluster, not adjacent to the first. In this case, the string will not be found. Fortunately this is a fairly rare event. If the search string is 24 characters, and the cluster is 4K, then the chance of missing a string is about 0.5% (1 in 200). For a shorter string, the chance is misising it decreases, but then the chance of finding a string that is not relevant increases.
The second case where a disk search may fail is due to the data in a file not being as expected. It will be clear that if a string is contained within a Zip file, it may not be found as the file will not be opened. The latest Microsoft Office files are infact all compressed, and so strings will not be detected by a raw image search. Slightly less obvious is that some programs will in effect save every version of a file, (making Undos possible) and so the original string will be saved, but any edited version will be done with pointers. A raw search may find the original, but not a small edit of it. The edit could be a correction in spelling or a few words that are part of the search string. These may not be detected.
Optimising multiple search strings
It is extremely useful to beable to search for multiple strings in a single pass. Searching does have a computing overhead so it is useful to know that the length of the shortest string will affect the overall search speed. This means if you want to search for 'zz' it will be slower than a string which is longer.
The raw search function will normally find a string if it exists, but one has to aware of limitations. To help reduce these limitations it will be best to run multiple searches.