SCSI 68 Pin Write Blocker

You missed the "..also makes it easy to incorporate legacy components, hosts and drives, into evolving SAS topologies" - the fact that it just didn't happen is another story 😉

Rest assured I didn't miss it, but again the topology has little to do with hardware/bus compatibility, however - and surprisingly - SAS interfaces are actually compatible with SATA drives, strangely enough. (through an adapter, not a converter)

But it wouldn't in any way solve the OP problem, a good ol' Adaptec will have no write blocking, if hardware hard blocking is a requisite a Scsi write blocker would be anyway needed.

Why exactly wouldn't a Linux bootable CD such as this and read-only mount of the scsi device work? ?

As said it would ) if hardware write blocking is not a - for *whatever reasons* - a compulsory requirement, personally I do trust tested and verified "Read Only" operating systems, but professionals in the field (for their own reasons) seemingly do not (JFYI)
http//www.forensicfocus.com/Forums/viewtopic/t=8679/
starting from around here
http//www.forensicfocus.com/Forums/viewtopic/p=6566565/#6566565
several posts revolve around the write blocker yes, write blocker no "issue".
(and on the possibility that even a write blocker may not write block 😯 )

jaclaz

Why exactly wouldn't a Linux bootable CD such as this and read-only mount of the scsi device work? ?

Is this Live CD really read-only?

As far as I know it resides in ram - when it boots, it detects the available drives and uses a script to image the selected source to the target drive with either dd (dc3dd) or AFF or EWF (libewf). You should always check a tool before using it anyway - it does have the option to do a checksum (md5/sha1/sha256/sha512) of a disk before/after imaging it so you can easily do a hash verification on a tested disk or partition.

.. professionals in the field (for their own reasons) seemingly do not (JFYI)
http//www.forensicfocus.com/Forums/viewtopic/t=8679/
starting from around here
http//www.forensicfocus.com/Forums/viewtopic/p=6566565/#6566565
several posts revolve around the write blocker yes, write blocker no "issue".
(and on the possibility that even a write blocker may not write block 😯 )

Yes, that is understandable - but if standard operating procedures or accreditation or whatever dictates the definite use of a hardware write blocker (usually they should be verified too), then I would expect they would provide such devices to the examiners so that they can cover the available options on disks they might find out there, including scsi ..

Why exactly wouldn't a Linux bootable CD such as this and read-only mount of the scsi device work? ?

Is this Live CD really read-only?

As far as I know it resides in ram - when it boots, it detects the available drives and uses a script to image the selected source to the target drive with either dd (dc3dd) or AFF or EWF (libewf). You should always check a tool before using it anyway - it does have the option to do a checksum (md5/sha1/sha256/sha512) of a disk before/after imaging it so you can easily do a hash verification on a tested disk or partition.

In fact, it's not read-only. It automatically activates swap partitions on a disk and mounts file systems on a disk in the r/w mode.

In fact, it's not read-only. It automatically activates swap partitions on a disk and mounts file systems on a disk in the r/w mode.

Well, it would need r/w access to the target partition in order to write the image file wouldn't it?

Here's what the say on how it works

.. uses Tiny Core Linux as the base OS. During boot, Tiny Core Linux does not automount any connected drives on the system. When imaging, you specify a source drive/partition and a destination location. The source will be mounted as Read Only and the destination will require it to be mounted with write permissions ..

In fact, it's not read-only. It automatically activates swap partitions on a disk and mounts file systems on a disk in the r/w mode.

Well, it would need r/w access to the target partition in order to write the image file wouldn't it?

Here's what the say on how it works

.. uses Tiny Core Linux as the base OS. During boot, Tiny Core Linux does not automount any connected drives on the system. When imaging, you specify a source drive/partition and a destination location. The source will be mounted as Read Only and the destination will require it to be mounted with write permissions ..

That is not an excuse for altering data on a source drive. Just try this simple validation case to see that a file system actually gets automatically mounted and modified.

That is not an excuse for altering data on a source drive. Just try this simple validation case to see that a file system actually gets automatically mounted and modified.

I don't have a reason to doubt you. Actually I tried to test it with the smallest drive I found lying around (old laptop 40Gb IDE), and after a couple of hours imaging etc, while rehashing the original drive to check if it was altered or not, the disc decided to die on me, so I gave up lol
Anyway, any other suggestions for easy to use linux versions that could do the job, and support old scsi controllers ?

That is not an excuse for altering data on a source drive. Just try this simple validation case to see that a file system actually gets automatically mounted and modified.

I don't have a reason to doubt you. Actually I tried to test it with the smallest drive I found lying around (old laptop 40Gb IDE), and after a couple of hours imaging etc, while rehashing the original drive to check if it was altered or not, the disc decided to die on me, so I gave up lol
Anyway, any other suggestions for easy to use linux versions that could do the job, and support old scsi controllers ?

I will suggest grml and ALT Linux Rescue in the forensic mode.

@kacos
To be "strict"
1) IF the scope is to make a "clone" there is No need whatever of filesystem R/W support, nor to "mount" anything, direct disk access (R/W, which is "standard") is enough.
2) Nothing prevents from having a Linux distro with (say) NTFS read only support (or even no NTFS support whatever) to read only the RAW source and have R/W support on (say) EXT2/3/4 only for the target to save the image.

@thefuf
The "simple validation case" seems to me like a (nice BTW ) ) very "narrow" case, involving specifically an Ext4 journaled filesystem divided on two disks with a log modified to contain an error, as said really nice, but unlikely to apply to a single disk or in most non-Ext4 multidevice setups.
The patch is in any case something needed if a filesystem is actually mounted, and a forensic imaging software should not have auto-mount on.

jaclaz

@thefuf
The "simple validation case" seems to me like a (nice BTW ) ) very "narrow" case, involving specifically an Ext4 journaled filesystem divided on two disks with a log modified to contain an error, as said really nice, but unlikely to apply to a single disk or in most non-Ext4 multidevice setups.

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 OSFClone 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).

Edit "OSFClose" -> "OSFClone".