Back to basics - Create Your Own Evidence

One of the most important skills one can have in forensics is to be able to create a controlled evidence where all aspects of the evidence is known in order to test the reliability of tools and methodologies.  In this case, I wanted to explore a few options in enCase and create a test image that can help test the keyword search capabilities.

You can watch my video on the details and you can also request the final evidence file.  http://youtu.be/iP9UzHG19Gw
If you need to request the evidence file than I failed to get my point across that you need to be able to create a baseline evidence in order to test any tool that you might come across.

The evidence is based on Central Daylight Savings time and NTFS file system.

D:\>dir /t:c                                                                    creation times
 Volume in drive D is NTFS_1024
 Volume Serial Number is F807-E907

09/21/2014  03:06 AM            10,241 file_c.txt
09/21/2014  03:08 AM             2,049 file_d.txt
09/21/2014  03:06 AM             2,049 file_e.txt
09/21/2014  03:06 AM             2,049 file_f.txt
               4 File(s)         16,388 bytes
               0 Dir(s)      53,191,680 bytes free

D:\>dir /t:a                                                                  last access times
09/21/2014  03:06 AM            10,241 file_c.txt
09/21/2014  03:08 AM             2,049 file_d.txt
09/21/2014  03:06 AM             2,049 file_e.txt
09/21/2014  03:06 AM             2,049 file_f.txt

D:\>dir /t:w                                                                last written times
09/21/2014  03:04 AM            10,241 file_c.txt
09/21/2014  03:05 AM             2,049 file_d.txt
09/21/2014  03:05 AM             2,049 file_e.txt
09/21/2014  03:05 AM             2,049 file_f.txt

MFT record location in sector and the two data run sector locations for the file called file_a.txt where a keyword "keyword2" is spanned between two data run locations and the file is deleted.  enCase allows for the file to be un-deleted before searched for keywords, so this file will be crucial to test that capability.
42722   -   MFT record
280     -   file_a.txt
41230 ( custer 20615)

The VBR will need to be corrupted in order to write directly to the raw device, so the first 7 bytes will be zeroed out and restored after we are done with the evidence drive creation. ( Thanks to Chuck Black for researching and finding this simple trick )
EB 52 90 4E 54 46 53  - VBR

Details of keyword locations and offset values.
....akeyword2a....  file_a.txt 230b3
^keyword1-1^              23123
....keyword2....          1424042   second data run RAM slack
....keyword2....          1424305   second data run drive slack
...keyword1-1...          1424372   UNICODE  second data run drive slack
....keyword2zzzz          14243FD   split between last cluster and next unused cluster
...aaaakey                   25bfd   first half or split keyword datarun 1
word2aaaaa...             1421C00  second half of split keyword datarun 2

keyword2ccc...      file_c.txt 25c00
^keyword1-1^   25c91
^keyword1-1^ UNICODE 25D14
...keyword2...  RAM slack  28473
...keyword2...  Drive slack 28724

dddkeyword2ddd...      file_d.txt 28AC5
^keyword1-1^   28fb3
..keyword1-1.. UNICODE RAM slack 29063
...keyword2...  RAM slack  290D5
...keyword2...  Drive slack 292B4

bbbkeyword2bbb...      file_b.txt deleted 294c5
...keyword2...  RAM slack  2B0A3
...keyword2...  Drive slack 2B2C4

split between file_b.txt and file_f.txt
....keyword2fffff            2B3FD
ffffkeyword2ffff             2B454

...eeekeyword2eee...      file_e.txt 14D20F3
...keyword2...  RAM slack  14d28a4
...keyword2...  Drive slack 14d2ac4
...a2V5d29yZDI=...     drive slack Base64 encoded 14D2B34

...keyword2... File_f.txt MFT record  14DCA43

....keyword2... unused MFT record 14DDB04

...zzzzkeyword2zzzz...  unallocated space 3692683