SCSI 68 Pin Write Blocker

This case was developed to test commands like "mount -o ro,loop …". In a single block device configuration (a journal is on the same block device with data), OSFClone will fail too. Even if you mount an Ext3 file system read-write and then pull the plug, booting OSFClose will recover the file system (but I don't have test images for this case on GitHub, so I didn't gave any links for it).

Still the point is that OSFClone (or other "forensics" distro) should NOT have any automatic "mount" command for the "source" drive, the options are
1) Clone (whole disk) no mount needed of either source or target
2) Image (whole disk) no mount needed for source, mount needed for target
3) Image (partition only) no mount needed for source mount needed for target (this only may be the case when the source is mounted, if the distro does not "behave", though it is entirely possible, without mounting, to extract the partition data (extents) and feed them to the dd command).

So, if OSFClone does actually mount, even with "mount -o,ro,loop" any partition, yes, it is possible - in some cases - that the source device is altered (I still believe that a number of concurrent conditions need to be met for this to happen) though in any case the "relevance" of what may be altered could be debated.

Since the Author of OFSClone is a member here, I am PMing him to let him know of the thread and he may be able to comment.

As a side note (and shameless plug 😯 ) this
http//reboot.pro/topic/18953-is-winfe-forensically-sound/
is how I personally dealt at the time with WinFE's
http//reboot.pro/topic/18953-is-winfe-forensically-sound/
in those tests a WinFE 4.0 or later seems to behave correctly even when mounting volumes, whilst there may be "edge cases" (even when not mounting) with disk signature in WinFE 3.0 and earlier, solvable by using grub4dos and direct disk writing .

jaclaz

This case was developed to test commands like "mount -o ro,loop …". In a single block device configuration (a journal is on the same block device with data), OSFClone will fail too. Even if you mount an Ext3 file system read-write and then pull the plug, booting OSFClose will recover the file system (but I don't have test images for this case on GitHub, so I didn't gave any links for it).

Still the point is that OSFClone (or other "forensics" distro) should NOT have any automatic "mount" command for the "source" drive, the options are
1) Clone (whole disk) no mount needed of either source or target
2) Image (whole disk) no mount needed for source, mount needed for target
3) Image (partition only) no mount needed for source mount needed for target (this only may be the case when the source is mounted, if the distro does not "behave", though it is entirely possible, without mounting, to extract the partition data (extents) and feed them to the dd command).

So, if OSFClone does actually mount, even with "mount -o,ro,loop" any partition, yes, it is possible - in some cases - that the source device is altered (I still believe that a number of concurrent conditions need to be met for this to happen) though in any case the "relevance" of what may be altered could be debated.

Since the Author of OFSClone is a member here, I am PMing him to let him know of the thread and he may be able to comment.

As a side note (and shameless plug 😯 ) this
http//reboot.pro/topic/18953-is-winfe-forensically-sound/
is how I personally dealt at the time with WinFE's
http//reboot.pro/topic/18953-is-winfe-forensically-sound/
in those tests a WinFE 4.0 or later seems to behave correctly even when mounting volumes, whilst there may be "edge cases" (even when not mounting) with disk signature in WinFE 3.0 and earlier, solvable by using grub4dos and direct disk writing .

jaclaz

There are many reasons why a Linux OS will automount a file system when booting in the live mode (Live CD / Live USB). For example, every Ubuntu-based distribution will attempt to mount block devices available in the system until it finds the boot medium, because a boot loader doesn't pass the information about the boot device to a kernel (so a kernel will execute userspace scripts to locate the boot medium by searching for specific files on each drive being probed). Other distributions may use different signs, e.g. file system labels and file system UUIDs (Fedora is an example of such a distribution), so they don't need to mount any file systems to finish the boot. KNOPPIX Live CDs may mount file systems to locate updates for the live image. And so on.

So, if OSFClone does actually mount, even with "mount -o,ro,loop" any partition, yes, it is possible - in some cases - that the source device is altered (I still believe that a number of concurrent conditions need to be met for this to happen) though in any case the "relevance" of what may be altered could be debated.

When WinFE fills the MBR disk signature, a forum discussion on more than one page is happening. Applying a journal to an unclean file system is not better than that. Of course, some other forensic distributions wipe $LogFile in an unclean NTFS, sync RAID1 volumes in LVM, but this is not an excuse in our situation -)

A forensic examiner may consider various modifications of source data to be acceptable, but many examiners rely on what developers or NIST wrote, and these examiners often don't know exactly what data modification issues are possible when using a tool. Losing the contents of $LogFile in a NTFS when booting a live distribution validated by NIST without this issue mentioned isn't unimportant.

Edit fix a typo.

A forensic examiner may consider various modifications of source data to be acceptable, but many examiners rely on what developers or NIST wrote, and these examiners often don't know exactly what data modification issues are possible when using a tool. Loosing the contents of $LogFile in a NTFS when booting a live distribution validated by NIST without this issue mentioned isn't unimportant.

Sure ) , personally I believe that "less is more" and having a nice, little distro that only does cloning imaging and that SURELY does not auto-mount anything seems to me like very nice.
Any of the distro's around (including the ones you suggested) are - in my perverted mind - too "generic use" and rely anyway on the user not doing something "stupid" accidentally, if the OS is designed to only image (or clone or both) there is no such risk, I hope that OFSClone is (or will become)

Set aside the (rather irritating) slowness of it's internal dd command, grub4dos would do nicely for a "pure" clone, like would do a good ol'DOS/FreeDOS, but both have too many limitations with buses supported that they are not practical.

As said before, all in all in a Linux distro the ONLY command needed is dd (or a derivative) having RAW disk access to the source and RAW disk access to the target (if in "clone" mode) or filesystem R/W access on target (if in image mode).
This should result in a very small distro with "no other option" or command, or if you prefer, as I see it the user should have no possibility to mount or write to the source device, to do that he/she would need to reboot to a DIFFERENT distro residing on a different media or however need ot provide an explict password to unblock the no-mount policy, same concepts I try to have on WinFE(s), still as a side note and JFYI
http//reboot.pro/topic/19730-dmde-basic-disk-imaging-test-and-results/?p=183875
(and following few posts).

As an example (reversed) the (possibly verified) Kali Linux "forensic mode"
http//docs.kali.org/general-use/kali-linux-forensics-mode
since it is an option in the bootloader, may accidentally be not chosen, nullifying the whole point of the exercise.

jaclaz

Jaclaz pointed me to this post.

We are the authors of OSFClone. Obviously it is a valid concern that the source drive gets modified while imaging / cloning.

Over the last couple of days we did some testing on EXT formatted drives (EXT2,3 & 4). Ext3 & 4 with internal journalling.

Before doing anything we did a MD5 on the drives.

Then we mounted the drives using the same read only options that OSFClone uses. For example,
mount -o ro /dev/sdx

Then we ran a bunch of typical Linux commands, cd, ls, on the read only drive.

Then we did a dismount.

Then we recalculated the MD5 again. There is no change in the hash. So there was no change to the drive as a result of the mount.

Then we repeated this all again WITHOUT read only option. (which OSFClone does not do unless you specify the device as the output location). Mounting like this, does change the MD5 checksum, even if you don't explicitly write to the drive.

The latest release of OSFClone also uses the noswap bootcode. So it shouldn't be creating swap files. Older releases seem to be creating it on a RAM drive in any case. fstab reported, /dev/zram0

So for the nominal case we think it is OK. At least on our test hardware.

But there are many edge cases and too many permutations to test everything. 'Dirty' file systems, buggy disk controllers, multiple different device driver versions (which one gets loaded depends on your hardware), SSDs running Trim, UEFI BIOSs now having disk access before the O/S is even booted, etc, etc…

We haven't looked in detail the Github kernel patch suggested above. It may well close off a few of the edge cases, but not all of them, (and it seems to break other stuff).

So here is our recommendation.
OSFClone does its best not to leave artifacts or alter the source evidence drive. However due to different hardware, drivers variations and disk states, there could be a small chance of contamination, especially when the source drive is from a Linux / Unix machine. When integrity is of the utmost importance, we recommend using a write blocker.

We haven't looked in detail the Github kernel patch suggested above. It may well close off a few of the edge cases, but not all of them, (and it seems to break other stuff).

Maybe TheFuf will be able to comment on this, I hoped that the the result of the discussion would be a "final" documented and verified patch, and/or modifications to the OFSclone that bettered it, in the sense of something one can trust, not something that "should work but maybe doesn't", and - as I see it - there are "edge cases" and "edge cases", an EXT3/4 partition unmounted "dirty" by the resident OS while still "edge" is IMHO not "extremely rare".

So here is our recommendation.
OSFClone does its best not to leave artifacts or alter the source evidence drive. However due to different hardware, drivers variations and disk states, there could be a small chance of contamination, especially when the source drive is from a Linux / Unix machine. When integrity is of the utmost importance, we recommend using a write blocker.

Well, with all due respect ) this is more "common sense" advice than anything else.

I mean while there are of course no certainties in this world, I hoped we could have at least a list of "common cases" where the OFSclone (or other specific distro or mini-distro) was "guaranteed" (in the sense that at least was tested and found to be read only in the specific case).

Would there be issues with "size" of the disk/image?
I mean could we assemble a repository of mini-images with those "edge" cases that were tested?

Still, in my simplicity, a mini-distro with the only scope of creating a forensic sound dd-like image should NOT mount *anything*as there is no real *need* to mount a filesystem to image it.

At the end of the day my "hal@§§ed" workaround consisting in making a dd-copy of the MBR, then zeroing it with grub4dos in order to make it "non-partitoned" (and thus unmountable) still sounds like a not too bad idea.

jaclaz

Before doing anything we did a MD5 on the drives.

Then we mounted the drives using the same read only options that OSFClone uses. For example,
mount -o ro /dev/sdx

Did you boot OSFClone to calculate an original hash value? Because OSFClone may alter the data before you run md5sum or a similar tool, and you will not notice the changes made before you calculate an 'original' hash value, and there may be no more changes after that.

The latest release of OSFClone also uses the noswap bootcode

OSFClone (MD5 of the ISO image f01bc586442bb221e003d2e288673223) didn't use the noswap boot option when running from a CD and did activate a swap partition from a HDD. Now I see that you released an updated version (MD5 of the ISO image 920cc747a3b205beeb9f1f2919aa0dfd), and the noswap boot option has been added to the isolinux.cfg.

an EXT3/4 partition unmounted "dirty" by the resident OS while still "edge" is IMHO not "extremely rare".

Yes, you can encounter such a file system state when dealing with a hibernated operating system or when dealing with a machine after pulling the plug.

I mean could we assemble a repository of mini-images with those "edge" cases that were tested?

Yes, we can. But disk images alone can't cover all known issues the same disk image can yield different results depending on what medium was used (HDD, SSD, flash card, etc.).

We've been doing some additional testing over the last week.

So it seems imaging Linux / Unix drives with the Ext2, 3 and 4 file system is not 100% forensically sound with OSFClone V1.1.1001, depending on the process being used.

If the source drive is already connected when you boot the machine, then one disk sector gets modified when you boot OSFClone from USB or CD. The sector is offset 1024, which is the first copy of the EXT superblock.

In these circumstances the following fields get changed in the EXT superblock sector.
Volume last mount time
Volume last write time
Mount count
Number of KiB written

No other changes were seen (in our test cases to date, on our specific hardware). And this doesn't effect Windows drives, FAT32 & NTFS.

If you connect a drive after boot (hot plug it) then these changes don't occur. This applies both to USB and SATA connected drives. You can't hot plug older style IDE drives.

So hot plugging is the way to go if you have Linux drives, else use a write blocker, or else accept a few bytes in the superblock being changed.

We've been doing some additional testing over the last week.

So it seems imaging Linux / Unix drives with the Ext2, 3 and 4 file system is not 100% forensically sound with OSFClone V1.1.1001, depending on the process being used.
…

So hot plugging is the way to go if you have Linux drives, else use a write blocker, or else accept a few bytes in the superblock being changed.

This is good news ) (the writing only happens in a small subset of cases and anyway it doesn't - IMHO - represent such a big issue), still, and still IMHO, the advice about using a write-blocker or accept the (minimal) change is sub-optimal.

Maybe TheFuf (when and if he has time for it) may check if his kernel patch resolves the issue and/or provide a patched kernel and/or provide a set of instructions to apply the patch (suitable for the "layman" or however for the "non-expert" Linux user).

As I see it OFSclone could become, once patched/modified/whatever, a "reference" tool with a sort of (if not "guarantee") "reasonable expectation" of being read-only and need NOT the use of a write-blocker.

jaclaz