Prefered Forensics Distro / Practice images

thefuf

First off let me state that I learn something more about Linux from each of your posts - thank you.

QUESTIONS

1) Is your validation screenshot located at (https://github.com/msuhanov/Linux-write-blocker/blob/d13c0b57c888cff254fb940342aad797aa8c4172/validation/ext4/images/1.png) showing that after a user mounts the first partition of storage device A "sda1" in "read-only" mode "-o ro" that the MD5 hash values of both sda and sdb have been altered as a result of the mounting? I see from the screenshot that the first MD5 values you generated do NOT match the MD5 hash values you generated after sda1 was mounted "read-only".

2) Casper I researched "Casper" and this appears to be a system designed to, amongst other services, create persistency between boot sessions in Live Linux environments. Apparently, a part of the Casper code scans a given computer system to identify storage devices such as hard drives that could be mounted? And then furthermore, when the Casper code identifies and encounters a "dirty file system" (such as the NTFS example in your screenshot) within one of the storage systems it scanned on the computer, the Casper code then "cleans up" the "dirty file system", thus changing the underlying evidence?

3. The "spoliation" problem you are describing - is it analogous to making minor but measurable changes to the "book case" holding the user (human) generated books but NOT the user (human) generated book content itself?

You may send me a bill for providing your Linux expertise/teaching or the next time you are in Chicago, I will definitely buy you a nice steak dinner at Gibsons (http//www.gibsonssteakhouse.com/).

Regards,

Larry

1) Is your validation screenshot located at (https://github.com/msuhanov/Linux-write-blocker/blob/d13c0b57c888cff254fb940342aad797aa8c4172/validation/ext4/images/1.png) showing that after a user mounts the first partition of storage device A "sda1" in "read-only" mode "-o ro" that the MD5 hash values of both sda and sdb have been altered as a result of the mounting? I see from the screenshot that the first MD5 values you generated do NOT match the MD5 hash values you generated after sda1 was mounted "read-only".

Yes, data on both drives were altered. This happened because the file system is split between two block devices the first contains data, the second contains a journal. Such a layout may be used to increase write performance (see this example).

Apparently, a part of the Casper code scans a given computer system to identify storage devices such as hard drives that could be mounted?

The problem is that a boot loader is reading from the boot medium using BIOS interrupts or EFI calls, but an operating system's kernel is using direct access to the boot medium (no BIOS interrupts or EFI calls to read data), and there is no universal way to tell a kernel what drive is used to boot a system (for example, there is no well tested way to tell a kernel that a BIOS drive 0x80, used to boot a system now, is the same as /dev/sdb). This is why a kernel is launching a helper program in order to find the boot medium using different signs Casper is mounting almost every file system recognized by a kernel looking for specific files until it finds the medium having these files (and this medium is considered to be used to boot a system). This is not the sole functionality of Casper, of course, Casper may also search for a persistent storage drive (used to store user data when working with a live distribution), and do other initialization tasks. And, the worst thing, there is no protection against Capser choosing an evidentiary drive as the boot drive -)

And then furthermore, when the Casper code identifies and encounters a "dirty file system" (such as the NTFS example in your screenshot) within one of the storage systems it scanned on the computer, the Casper code then "cleans up" the "dirty file system", thus changing the underlying evidence?

A file system driver is responsible for recovering a file system, not Casper. Casper only runs a command to mount a file system on a specific device.

When searching for the boot medium, Casper looks at various file systems, including Ext3, Ext4, and NTFS (yes, it's possible to boot Ubuntu from a USB stick with NTFS), and asks a system to mount them read-only. However, in Linux, the words "read-only" mean a different thing a file system is considered to be read-only when you can't create/delete/modify/rename/move files and directories; this doesn't mean that no writes are issued to an underlying drive. When you mount a "dirty" (not properly unmounted) file system read-only in Linux, it may be recovered and brought to the consistent state by a kernel using a journal.

3. The "spoliation" problem you are describing - is it analogous to making minor but measurable changes to the "book case" holding the user (human) generated books but NOT the user (human) generated book content itself?

If we talk about the NTFS issue, the ntfs-3g driver is wiping the $LogFile. This doesn't touch user data, but the $LogFile itself may contain data of forensic value. IMHO, it is analogous to burning a draft version of chapter in a book.

You may send me a bill for providing your Linux expertise/teaching or the next time you are in Chicago, I will definitely buy you a nice steak dinner at Gibsons (http//www.gibsonssteakhouse.com/).

Okay -)