Casper is responsible for searching for a root file system (typically, an image of live environment) on all supported devices (because a bootloader does not pass any information about device used for booting to the kernel), mounting it and executing /sbin/init program on a mounted root file system that will continue the boot process. Most Ubuntu-based forensic Live CD distributions use Casper (a set of scripts used to complete initialization process during early stage of boot). The only solution here is to use '-o ro,loop' flags. Currently, there is no specific mount flag to disable orphan inodes deletion. When mounting Ext3/4 file systems all orphan inodes are removed, even if '-o ro' mount flag was specified.

List of distributions that recover Ext3 (and sometimes Ext4) file systems during the boot: Helix3: damaged Ext3 recovery during the boot hard drives) during execution of initrd scripts (these scripts mount every supported file system type on every supported media type using only '-o ro' flag in order to find a root file system image). For example, several Ubuntu-based forensic Live CD distributions mount and recover damaged Ext3/4 file systems on fixed media (e.g.

As described above, this may result in data writes to evidentiary media. Incorrect mount flags can be used to mount file systems on evidentiary media during the boot process or during the file system preview process. To disable data writes: use 'ro,loop' flags. 'norecovery' flag does not help (fixed in recent 2.6 kernels). To disable journal updates: use 'ro,loop' flags 'nolog' flag does not work (see man mount). To disable recovery: use 'noload' flag, or use 'ro,loop' flags, or use 'ext2' file system type When mounting (and unmounting) several journaling file systems with only '-o ro' mount flag a different number of data writes may occur.

no data modification was found after unmounting the file system), but it is known that damaged (i.e not properly unmounted) Ext3 file systems cannot be write protected using only '-o ro' mount flags (write access will be enabled during file system recovery).Īnd the question is: will many users test damaged Ext3 file system (together with testing the clean one) when validating their favourite forensic Live CD distribution? My answer is 'no', because many users are unaware of such traits.Įach problem is followed by a list of distributions affected (currently this list is not up-to-date). The article says that all tests were successful (i.e. Finally, it turns out that many Linux-based forensic Live CDs are not tested properly and there are no suitable test cases published.Īnother side of the problem of insufficient testing of forensic Live CDs is that many users do not know what happens 'under the hood' of the provided operating system and cannot adequately test them.įor example, Forensic Cop Journal (Volume 1(3), Oct 2009) describes a test case when an Ext3 file system was mounted using '-o ro' mount flag as a way to write protect the data. Unfortunately, community-developed distributions are no exception here. Currently, many vendors of such Live CD distributions spread false claims that their distributions 'do not touch anything', 'write protect everything' and so on. 3.5.1 rebuildfstab and scanpartitions scriptsįorensic Live CDs are widely used during computer forensic investigations.

Extfs list orphaned inodes