• All lab media should maintain a unique volume label and a unique directory to receive the evidence file(s).
• All lab media should be forensically sterile – wiped of all data, verified to be absent of any data, freshly partitioned, and formatted.
• Upon starting a new case – default Export and Temp directories should be defined.
• These folders will provide a default location for exported data as well as a specific folder to contain files that are created through the use of external viewers.
• Both of these folders are case specific and can be modified as to location at any time.
• When an examiner double-clicks on a file, the data is copied to the defined temp directory, and the associated viewer is then called to display the file data.
• When EnCase is properly shut down, EnCase will delete the files from the temp folder.
• Bit stream image of the source media written to a file(s).
• Contains case information as first block, validated by attached CRC.
• No alteration to case information block can be made.
• There is no limit to the EnCase® evidence file segment size.
• Content of the evidence file cannot be changed – data cannot be “added” to an existing evidence file.
• Contains your “work” – search results, bookmarks, and report.
• It is simply a text file containing information specific to a single case/investigation.
• There is no limit to the number of evidence files that can be added to a single case – 8 hdds, 200 diskettes, 24 CDRs – as example.
• Case file is updated by utilizing the SAVE button or selecting SAVE from the
• Evidence file verification results are stored within the .case file. Backup File (.CBAK)
• Is created at preset intervals
• Captures current state of .case file.
EnCase® Configuration Files
• Contain global changes to the EnCase environment – external viewers, hash sets/libraries, signature table.
• This global environment dictates information/tools available for all cases – not case specific.
• Example EnCase configuration .ini files:
o FileSignatures.ini – File Signature Table
o FileTypes.ini – organizes files into groups by extension; determines which viewer to use
o Keywords.ini – global keywords list o Filters – available filters
o Viewers.ini – installed external viewers
• File Types table dictates the action that will occur if a user double-clicks on a specific file.
• External viewers are associated with file extensions through the File Types.
Verification of E01
• CRC (32 bit) every 64 sectors.
• MD5 (128 bit) computed during acquisition and placed at the end of the evidence file.
• To fully verify all CRCs as well as MD5 must validate and verify.
• If any changes occur to an evidence file, the CRC for the affected block(s) will no longer verify, and EnCase will display an error when any data within the block is accessed.
• EnCase will also indicate an error if the evidence file is verified again.
• Three (3) aspects of an existent evidence file can be changed/altered –
o Password +/-, compression, and evidence file segment size.
o The applied filename of the evidence file can be changed, and/or the evidence file(s) can be moved to another location; however EnCase will prompt you to locate the renamed evidence file if it is changed after it is added to a case.
o Individual segments of an evidence file can be verified under Tools -> Verify Single Evidence File.
• Compression does not have an impact on the verification of an evidence file; hash value will remain constant.
Searches - General Information
• Searches within the Windows® environment are both physical and logical.
• Within the EnCase® Windows environment, keywords that span noncontiguous clusters will still be located within logical files. No searching tool will find keywords spanning noncontiguous clusters in unallocated space.
• Searches in unallocated space are physical only as no logical definitions exist in this area.
Searches - GREP – Most Commonly Used Symbols
• [ ] Square brackets form a set, and the included values within the set have to match a single character. [1-9] will match any single numeric value from 1 to 9.
• - Denotes a range – such as above.
• ^ States “not” – [^a-z] = NO alpha characters from a to z.
• + States to repeat the preceding character or set any number of times, but at least once.
• * States to repeat the preceding character or set any number of times, including zero times.
• \x Indicates that the following value is to be treated as a hexadecimal value - \xFF\xD8\xFF…
• ? Means “or not” – joh?n will yield both JOHN and JON
• You must indicate via the check box that the created expression is a GREP term.
Searches - Unicode
• Selecting Unicode will cause EnCase to search for the keyword in both ASCII and Unicode.
• Unicode uses two bytes for each character allowing the representation of 65,536 characters.
• Simply compares the displayed extension with the file’s header/signature. Four possible results will be obtained:
o !Bad Signature - The extension is in the File Signature table but the header is incorrect, and the header is not in the File Signature table.
o * [Alias] - The header is in the table and the extension is incorrect. This indicates a file with a renamed extension.
o MATCH - The header matches the extension. If the extension has no header in the File Signature table, then EnCase will return a Match as long as the header of the file does not match any header in the File Signature table.
o UNKNOWN - indicates that neither the header/signature nor the extension is listed in the table. If either the header/signature or the extension is listed in the table, you will NOT obtain a value of UNKNOWN.
• To examine the results of the File Signature effort, sort on the File Signature column.
• Remember that the gallery view will not display supported image files that maintain extensions inconsistent with image files until and unless the Signature Analysis has been run.
• The Signature Table can be edited and/or added to by accessing the table, and choosing right-click New.
• Hash sets can be created from selected files, and the set(s) can then be added to the library.
• The hash value computed for a given file is based upon the logical file content only – not the slack area of the file.
• File names are maintained within the folder/directory and have no bearing on the computed hash value of a given file.
• EnCase will compute a hash value of each file in the case and then compare these computed values to the values present in the library.
• Hash analysis allows the examiner to identify files that are known – either as innocuous files that can be ignored or as files that are evidentiary in content.
• Hash sets contain only the computed hash values of the files – not the file content. A file cannot be created from the computed hash value. ASCII and Binary
• ASCII table is a 7-bit table, and the acronym stands for the American Standard Code for Information Interchange.
• The resultant 128 values represent alpha/numeric values, common punctuation and other values.
• Hexadecimal notation employs two characters to represent one byte.
• A single byte (8 bits) can represent one of 256 possible values; a nibble (4 bits) can represent one of 16 possible values.
• The “LE” indicator within EnCase indicates the number of bytes that have been selected/swept/highlighted.
• Nibble = 4 bits
• Byte = 8 bits
• Word = 2 bytes = 16 Bits
• Dword = 4 bytes = 32 Bits