Presentation is loading. Please wait.

Presentation is loading. Please wait.

Lecture 4: Evaluating Tools 6/5/2003 CSCE 590 Summer 2003.

Similar presentations


Presentation on theme: "Lecture 4: Evaluating Tools 6/5/2003 CSCE 590 Summer 2003."— Presentation transcript:

1 Lecture 4: Evaluating Tools 6/5/2003 CSCE 590 Summer 2003

2 Tools vs. Knowledge and Methodologies Knowledge of underlying technology and sound methodologies win Technology continues to evolve Tools become outdated and change too If a person could not explain something without the use of a specific tool, testimony would be severely compromised in a court –I don’t need Encase. I can recover that file with just a hex editor and a toothpick!

3 Structure of a Forensic Investigation Evidence preservation Lead formulation Focused searches Temporal analysis Evidence recovery

4 Collection and Preservation Must preserve integrity All conclusion based on integrity of copy process First time evidence comes into logical danger is at this stage, even –when memory resident software based Interrupt 13 hard drive blockers are installed –when mounting evidence drive under non-DOS operating system

5 Testing Initial Tools First tool touching an evidence drive –Must not change it and –Must preserve the evidence If an evidence drive is to be mounted under a non-DOS operating system: –Boot and initialization procedures must be reviewed to insure the drive is not written to –Even if it is to be mounted read-only

6 Testing an Imaging Tool Materials: –Several blank hard drives –A hexadecimal editor –The tool you are testing Wipe hard drives Mark drives with a specific recognizable pattern Take hashes of the drives

7 Testing an Imaging Tool Image them with the tool Take hashes again and check for differences Compare original and restored image to make sure all data is there and identical For specialized device drivers, perform the tests with and without them Check the ability to image ‘nothing’ –Image one completely wiped drive onto another completely wiped drive

8 Testing an Imaging Tool For gaps between and around partition tables: –Use a hex editor to compare –Logical hashes won’t include these and you can’t do physical hashes (bad blocks, clusters) Document BIOS access modes, supported buses Document all drive and partition specifications –Sizes, hardware, allocation, architectural data –Use two different operating systems’ partitioning and diagnostic utilities to collect this data

9 Testing an Imaging Tool Computer Forensics Tool Testing Don’t forget, as technologies change and tools are updated, frequent re-validation and re-testing is necessary

10 A Note on Hex Editors Even baseline tools used to test other tools need testing Example: Norton’s Diskedit –Can no longer access a drive location by cylinder, head, sector –Can’t handle extended partitions on large drives –Targeted at single partition, LBA mode, Windows only environment and customers who did not want to use a hex editor Most hex editors do not understand specific drive architectural structures like partition tables and boot records Use several tools to validate one another’s results

11 Formulating Leads Two requirements –Acceptable level of ‘hits’ both true and false generated False positives (not really a lead) can be expensive and time consuming False negatives (missed leads) can halt an investigation –Output must be meaningful and useful to all parties, including non-technical Lawyers may want it in an Access database

12 Focused Searches Searching medium for specific information instead of general leads –Child pornography General requirements for focused searching: –Ability to delimit searches ` Ex. we want Micros, not Microsoft –Scalable Don’t want limitations on the number of search terms

13 Focused Searching Requirements Shell pattern searches Regular expression searches Hexadecimal searches Unicode searches –Common Windows character representation Unattended batched or scripted mode

14 Shell Pattern Matching * - match 0 or more instances of any character ? – match single instance of any character [abcde] – match a single instance of any character in the brackets [0-9] – match a single instance of any character in the range 0-9 –[a-zA-Z] not [a-Z] [^0-9] – match a single instance of any character except those in the brackets {pattern1,pattern2,…} – match any pattern in the list # ls h*# ls h?# ls *[ej]* hello.txt hhhello.txt hh

15 Regular Expression Pattern Matching [1234], [0-9], [^0-9] – same as shell patterns. – (period) matches a single character pattern1|pattern2|… - match listed pattern ^ - match from beginning of line $ - match end of line * - match 0 or more repetitions of previous regular expression + - match 1 or more repetitions of previous regular expression ? - match 0 or 1 repetitions of previous regular expression \ - remove special meaning of following character

16 Temporal Analysis Date and time info on files, data chunks, etc MAC times: File Modification, Access, and Creation times Some tools do UTC conversion on NTFS partitions – watch out

17 Deleted File Times Hard to conclusively prove deletion times on a file or directory in MS file systems Unix, easier as long as inodes, blocks, etc have not already been overwritten Journaling filesystems provide a wealth of data –If journal entries have not been overwritten or replaced FAT and VFAT undelete tools need to be thoroughly tested: –Sometimes tools pick out newly re-allocated subdirectories in a deleted directory in place of the deleted subdirectories

18 Recovery Tools Recovering files on media and deleted files on media Recovering file slack space File slack space example: –Have a file 2200 bytes long –Operating system allocates disk space in 1024 byte blocks only –It take 3 blocks (3072 bytes) to store our file –There is 872 bytes of slack left over

19 File Slack Space Have been entire shadow file systems built in slack Is hard to do, because slack must stay stable. Deleting regular files returns the file’s space (including slack) to be reused Slack can contain info from a background program running when file was created

20 Deleted File Recovery Tools Some tools include slack space when recovering files Some stop at proper offset = real length of file Must know how your tool works If a tool recovers slack too, sometimes have to trick applications by modifying file’s size to get the file to open properly without the slack

21 Evaluating Performance dd and netcat –http://users.erols.com/gmgarner/forensics/ With standard dd, netcat, and md5sum on Linux 40GB drive > 6 hours imaging If you use gzip to compress stream before netcat, even longer I/O intensive Need to maximize performance

22 Buffers Most time spent copying between buffers When imaging a logical volume, data is copied between: –Drive’s internal buffers -> file system’s in-memory cache –File system’s in-memory cache -> application’s read buffer –Application’s read buffer -> application’s write buffer –Application’s write buffer -> system output buffer (or write cache depending on hardware) –System output buffer -> output device’s internal buffer –Output device’s internal buffer -> output device

23 More Buffers Add on compression (gzip/zlib) –Copy to zlib input buffer –Copy from zlib output buffer Piping to md5sum –Also two more copies –md5sum must also be run on source side and destination side Piping to netcat –Two more copies

24 Other Factors Increase in time is linear (constant rate) with each copy No multi-threading in forensic imaging tools I/O threads spend a lot of time blocked – waiting for slower I/O operations to complete

25 Improvements? Incorporate cryptographic checksumming (md5) into the imaging application, dd –Both recorded in MD5 log file (MD5 digest) –Input path of original data in [..] –Output path of image listed second –Recorded checksum is actually computed against the input to dd –Example output \f6d426a3a8fcf8e365606b6eec5f2c40 [\\\\.\\A:] *d:\\floppy.img checksum input path output path

26 More Improvements netcat (nc) also modified to do MD5 checksums like dd md5sum modified to verify against dd’s MD5 output log Which file does the md5sum verify against: file listed in the input path to dd or the output path? –By default, verifies against output path

27 Example – dd with MD5

28 Output File floppy.md5 Contains: \f6d426a3a8fcf8e365606b6eec5f2c40 [\\\\.\\A:] *d:\\floppy.img Also modified md5sum to work with the modified dd’s MD5 output files: Check output image against floppy.md5: –md5sum –c floppy.md5 Recompute MD5 checksum: –md5sum –o floppy.md5 \\.\A:

29 Windows Device Names For the purpose of dd: –\\.\PhysicalDrive0 The physical device –\\?\Volume{87c34910-d826-11d4-987c-00a0b } The volume name –\\.\C: The mount point of the volume in Windows –\\.\PhysicalMemory Contents of memory Use volume_dump to get all this info + ugly volume names

30 Example – volume_dump


Download ppt "Lecture 4: Evaluating Tools 6/5/2003 CSCE 590 Summer 2003."

Similar presentations


Ads by Google