EVIDENCE IMAGING

CSIS 3160
 ORGANIZE COLLECTED EVIDENCE AND COMMAND OUTPUT
• Naming Conventions for Files and Directories

• A file extension should always indicate the format of the content. For example:
• *.txt can be opened and read using a text editor.
• *.raw is a raw data dump (disk, memory, and so on).
• *.pcap is captured network traffic.
• *.db is a database (possibly a Sleuth Kit file list).
• *.sfs is a SquashFS evidence container.
• *.e01 and *.aff are forensic formats.
 ORGANIZE COLLECTED EVIDENCE AND COMMAND OUTPUT
• Scalable Examination Directory Structure
• Each incident, case, or investigation should have a single unique directory (for example, case42).
• All collected evidence, images, and analysis work should be contained within a hierarchy under
that one root directory. Example:
• OFFICE-US123
• USER-123456
• PC1-HDA
• CD1
• CD2

• USER-98765
• PC1-HDA
• PC1-HDB
• NB1-HDA
• USB1
• USB2
• DVD1

• OFFICE-UK567
• PC1-HDA
 ORGANIZE COLLECTED EVIDENCE AND COMMAND OUTPUT
• Save Command Output with Redirection

• shell command output is redirected into files from stdout as shown here:
• # fls /dev/sda1 > fls-part1.txt
• # fls /dev/sda2 > fls-part2.txt

• To include regular output and error messages, you need to redirect stdout and stderr file
descriptors to the file.
• by adding an ampersand to the redirection (this also applies when piping to another
program):
• # fls /dev/sda &> fls-part1.txt
• When a text file already exists and you need to add additional information to it, you can
use the >> notation to specify an append operation. For example:
• # grep clientnames.xls fls-part1.txt >> notes.txt
 ORGANIZE COLLECTED EVIDENCE AND COMMAND OUTPUT
• Many forensic tasks performed on the command line are time-consuming and may take many hours to
complete (disk imaging, performing operations on very large files, and so on).

• Having a timestamp indicating the duration of the command can be useful.

• The time command provides this functionality.

• There are two common implementations of the time command:

• one is a shell builtin with rudimentary features, The primary advantage of the shell builtin time version is that it will time an
entire pipeline of commands
• the other is a GNU utility with additional features. GNU time will only time the first command in a pipeline.

• Here is an example of using the time command to run a disk-imaging program:

• # time dcfldd if=/dev/sdc of=./ssd-image.raw
• 3907328 blocks (122104Mb) written.
• 3907338+1 records in
• 3907338+1 records out
• real 28m5.176s
• user 0m11.652s
• sys 2m23.652s
 ORGANIZE COLLECTED EVIDENCE AND COMMAND OUTPUT
• Another useful command for some situations is the timestamp output command ts. Any output piped into ts will have
a timestamp appended to each line of output.
• # (ls -l image.raw; cp -v image.raw /exam/image.raw; md5sum /exam/image.raw) |ts
• May 15 07:45:28 -rw-r----- 1 root root 7918845952 May 15 07:40 image.raw
• May 15 07:45:40 'image.raw' -> '/exam/image.raw'
• May 15 07:45:53 4f12fa07601d02e7ae78c2d687403c7c /exam/image.raw
• In this example, three commands were executed (grouped together with parentheses) and the command outputs
were sent to ts, creating a timeline.
 FILE COMPRESSION
• Using compression solves a number of the capacity challenges faced by a forensic examiner.

• You can use a compressed forensic format to store the resulting acquired image, but the effectiveness depends on a
number of factors.

• The compression algorithms you choose will have some effect on the size and time needed to compress a subject
disk. A better compression ratio will take more time to compress (and subsequently uncompress).

• A relatively new PC disk that contains a large number of untouched disk sectors (original manufacturer’s zeroed
contents) will compress better than an older disk containing significant amounts of residual data in the unallocated
sectors.

• Disks that contain large amounts of already compressed files (*.mp3, *.avi, and so on) will not compress much
further, and as a result, forensic imaging tools will benefit less from added compression.

• Encrypted subject disks or disks with large numbers of encrypted files will not compress as well as unencrypted
content due to the data’s higher entropy level.
 SPARSE FILES
• Some filesystems use metadata to represent a sequence of zeros in a file instead of actually writing all the zeros to
the disk.

• Sparse files contain “holes” where a sequence of zeros is known to exist.

• To illustrate, a new drive containing mostly zeroed sectors is acquired with GNU dd ;first as a regular raw file and then
as a sparse file.
• # dd if=/dev/sde of=image.raw
• 15466496+0 records in
• 15466496+0 records out
• 7918845952 bytes (7.9 GB, 7.4 GiB) copied, 112.315 s, 70.5 MB/s
• # dd if=/dev/sde of=sparse-image.raw conv=sparse
• 15466496+0 records in
• 15466496+0 records out
• 7918845952 bytes (7.9 GB, 7.4 GiB) copied, 106.622 s, 74.3 MB/s
 SPARSE FILES
• The GNU dd command provides a conv=sparse flag that creates a sparse destination file.

• the number of blocks transferred is the same for both the normal and sparse files.

• In the following output, the file size and the MD5 hash are also identical. However, notice how the block size used on
the filesystem is very different (7733252 blocks versus 2600 blocks):
• # ls -ls image.raw sparse-image.raw
• 7733252 -rw-r----- 1 root root 7918845952 May 15 08:28 image.raw
• 2600 -rw-r----- 1 root root 7918845952 May 15 08:30 sparse-image.raw
• # md5sum image.raw sparse-image.raw
• 325383b1b51754def26c2c29bcd049ae image.raw
• 325383b1b51754def26c2c29bcd049ae sparse-image.raw
 REPORTED FILE AND IMAGE SIZES
• Many Linux tools support the -h flag to report file sizes in a human-readable form.

• For example, you can use ls -lh, df -h, and du -h to more easily view the size of files and partitions.

• An example ls output with several file sizes is shown here:

• # ls -l
• total 4
• -rw-r----- 1 root root 2621440000 Jan 29 14:44 big.file
• -rw-r----- 1 root root 104857600 Jan 29 14:41 medium.file
• -rw-r----- 1 root root 51200 Jan 29 14:42 small.file
• -rw-r----- 1 root root 56 Jan 29 14:44 tiny.file
• # ls -lh
• total 4.0K
• -rw-r----- 1 root root 2.5G Jan 29 14:44 big.file
• -rw-r----- 1 root root 100M Jan 29 14:41 medium.file
• -rw-r----- 1 root root 50K Jan 29 14:42 small.file
• -rw-r----- 1 root root 56 Jan 29 14:44 tiny.file
 MOVING AND COPYING FORENSIC IMAGES
• Once a copy or move process has been started, disrupting it could leave the data in an incomplete state or require
additional time to revert to the original state.

• A copy or move operation could create temporary files or result in two copies of the images existing temporarily.

• In general, don’t interrupt the process once it has started.

• Consider the following list of typical file and disk image sizes and the average amount of time needed to copy the file
from one disk to another disk:
• • 5KB simple ASCII text email: less than 1 second
• • 5MB typical MP3 music file: less than 1 second
• • 650MB CD ISO image: about 5 seconds
• • 5–6GB typical DVD or iTunes movie download: about 1 minute
• • 64GB common mobile phone image: about 10 minutes
• • 250GB common notebook disk image: 30-40 minutes
• • 1TB typical desktop PC image: more than 2 hours
• • 2TB typical external USB disk image: more than 4 hours
• • 8TB internal disk image: more than 16 hours
 PERFORMANCE AND BOTTLENECKS
• You can assess the performance of various system components by reading the vendor specifications, querying the system
with various tools, or running various benchmarking and measurement tests.
• Useful tools to check the speed of various components include dmidecode, lshw, hdparm, and lsusb.
• To check the CPU family and model, current and maximum speed, number of cores and threads, and other flags
• # dmidecode -t processor
• to view the CPU’s cache (L1, L2, and L3):
• # dmidecode -t cache
• To view the memory, including slots used, size, data width, speed, and other details:
• # dmidecode -t memory
• to view the number of PCI slots, usage, designation, and type:
• # dmidecode -t slot
• to view the storage interfaces, type (SATA, NVME, SCSI, and so on), and speed:
• # lshw -class storage
• To view the speed, interface, cache, rotation, and other information about the attached disks (using device /dev/sda :
• # hdparm -I /dev/sda
• To view the speed of the external USB interfaces (and possibly an attached write blocker), use this command:
• # lsusb -v
 ESTABLISH FORENSIC WRITE-BLOCKING PROTECTION
• A fundamental component of digital evidence collection is performing forensically sound acquisition of storage
media.

• You can achieve part of this goal by ensuring that a write-blocking mechanism is in place before you attach the disk to
the forensic acquisition host.

• When you attach a disk to a PC running a modern OS, automated processes significantly increase the risk of data
modification (and therefore evidence destruction).
• attempts to automatically mount partitions,
• generate thumbnail images for display in graphical file managers,
• index for local search databases,
• scan with antivirus software,
• timestamps might be updated.
• Deleted files in unallocated parts of the disk might be overwritten.
• Discovered malware or viruses (the very evidence an investigator might be looking for) could be purged.
• Journaling filesystems could have queued changes in the journal log written to disk.
• There may be attempts to repair a broken filesystem or assemble/synchronize RAID components.
 ESTABLISH FORENSIC WRITE-BLOCKING PROTECTION
• Write blockers were designed to protect against unwanted data modification on storage media. Requiring the use of
write blockers in a forensic lab’s standard processes and procedures demonstrates due diligence.

• NIST Computer Forensic Tool Testing (CFTT) provides formal requirementsfor write blockers.

• The Hardware Write Block (HWB) Device Specification,Version 2.0 is available at

http://www.cftt.nist.gov/hardware_write_block.htm.

• This specification identifies the following top-level tool requirements:

• An HWB device shall not transmit a command to a protected storage device that modifies the data on the storage device.
• An HWB device shall return the data requested by a read operation.
• An HWB device shall return without modification any access-significant information.
• Any error condition reported by the storage device to the HWB device shall be reported to the host.

• Both hardware and software write blockers are available, as stand-alone alone hardware or software packages, or
bootable forensic CDs. In some cases might have built-in read-only functionality.
 HARDWARE WRITE BLOCKERS
• Write blockers can provide status information to the acquisition host system. An example is a tableau-parm tool
(https://github.com/ecbftw/tableau-parm/) which can query the Tableau hardware write blocker for information.
• You can use this open-source tool to verify the write-blocking status of a disk attached with a Tableau write blocker.
For example:
• $ sudo tableau-parm /dev/sdg
• WARN: Requested 255 bytes but got 152 bytes)

• ## Bridge Information ##
• chan_index: 0x00
• chan_type: SATA
• writes_permitted: FALSE
• declare_write_blocked: TRUE
• declare_write_errors: TRUE
• bridge_serial: 000ECC550035F055
• bridge_vendor: Tableau
• bridge_model: T35u-R2
• firmware_date: May 23 2014
• firmware_time: 09:43:37
 HARDWARE WRITE BLOCKERS (CONT)
• ## Drive Information ##
• drive_vendor: %00%00%00%00%00%00%00%00
• drive_model: INTEL SSDSA2CW300G3
• drive_serial: CVPR124600ET300EGN
• drive_revision: 4PC10302

• ## Drive HPA/DCO/Security Information ##

• security_in_use: FALSE
• security_support: TRUE
• hpa_in_use: FALSE
• hpa_support: TRUE
• dco_in_use: FALSE
• dco_support: TRUE
• drive_capacity: 586072368
• hpa_capacity: 586072368
• dco_capacity: 586072368
 FORENSIC WRITE-BLOCKING
• Attaching an NVME drive using a PCI Express write blocker produces the following dmesg output:
• [194238.882053] usb 2-6: new SuperSpeed USB device number 5 using xhci_hcd
• [194238.898642] usb 2-6: New USB device found, idVendor=13d7, idProduct=001e
• [194238.898650] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
• [194238.898654] usb 2-6: Product: T356789u
• [194238.898658] usb 2-6: Manufacturer: Tableau
• [194238.898662] usb 2-6: SerialNumber: 0xecc3500671076
• [194238.899830] usb-storage 2-6:1.0: USB Mass Storage device detected
• [194238.901608] scsi host7: usb-storage 2-6:1.0
• [194239.902816] scsi 7:0:0:0: Direct-Access NVMe INTEL SSDPEDMW40 0174PQ: 0 ANSI: 6
• [194239.903611] sd 7:0:0:0: Attached scsi generic sg2 type 0
• [194240.013810] sd 7:0:0:0: [sdc] 781422768 512-byte logical blocks: (400 GB/373 GiB)
• [194240.123456] sd 7:0:0:0: [sdc] Write Protect is on
• [194240.123466] sd 7:0:0:0: [sdc] Mode Sense: 17 00 80 00
• [194240.233497] sd 7:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
• [194240.454298] sdc: sdc1
• [194240.673411] sd 7:0:0:0: [sdc] Attached SCSI disk

• The write blocker operates as a USB3 bridge and makes the NVME drive available as a SCSI device. This particular write
blocker supports PCI Express drives using both AHCI and NVME standards.
 SOFTWARE WRITE BLOCKERS
• Software write blockers are difficult to implement. Simply mounting a disk as read-only (mount -o ro) will not
guarantee that the disk won’t be modified.

• The read-only property in this context refers to the filesystem, not the disk device. The kernel may still write to the
disk for various reasons.

• Software write blocking must be implemented in the kernel, below the virtual filesystem layer and even below the
other device drivers that implement a particular drive interface.

• Tools such as hdparm and blockdev can set a disk to read-only by setting a kernel flag. For example:
• # hdparm -r1 /dev/sdk
• /dev/sdk:
• setting readonly to 1 (on)
• readonly = 1 (on)

• The same flag can be set with blockdev, like this:

• # blockdev --setro /dev/sdk
 LINUX FORENSIC BOOT CDS
• Forensic boot CDs are helpful when:
• A PC is examined without opening it to remove a disk.
• A write blocker is not available.
• PCs need to be quickly checked during triage for a particular piece of evidence before deciding to image.
• Linux-based tools (Sleuth Kit, Foremost, and so on) are needed but not otherwise available.
• A forensic technician needs to perform work via ssh remotely.

• Several popular forensic boot CDs that are currently maintained include:
• Kali Linux (formerly BackTrack), which is based on Debian: https://www.kali.org/
• Digital Evidence & Forensics Toolkit (DEFT), which is based on UbuntuLinux: http://www.deftlinux.net/
• Pentoo, a forensic CD based on Gentoo Linux: http://pentoo.ch/
• C.A.I.N.E, Computer Forensics Linux Live Distro, which is based on Ubuntu Linux: http://www.caine-live.net/