For those that might be interested, the guidebook and materials at www.linuxleo.com have been updated. The guide is still a beginners guide...this is not "sequel". I've started teaching again and so it was time for a refresh. Much of the material remains the same (still works), but a lot has been added, and commands and output updated as needed. The guide went from ~190 pages to just over 300 pages.

There's also a YouTube channel (empty for now...subscribe for notifications) that will mostly be used for demo videos and related stuff. Comments are welcome at bgrundy @ linuxleo.com.

On page 93 you write: Keep in mind our previous discussion regarding write blocking. But the discussion starts later on the same page, so there is a next discussion, not a previous one.

Also, teaching examiners to trust hardware write blockers more than software ones is a bad practice (in my opinion). Some hardware write blockers run Linux too. And there are issues too (and a simple act of attaching a suspect drive to a hardware write blocker may result in write requests being sent to that drive).

Also, teaching examiners to trust hardware write blockers more than software ones is a bad practice (in my opinion). Some hardware write blockers run Linux too. And there are issues too (and a simple act of attaching a suspect drive to a hardware write blocker may result in write requests being sent to that drive).

In truth, neither are 100% safe but I would opt for hardware blockers.

With software blocking you are at the mercy of kernel code and library writers who's first priority is to ensure the disk & file system drivers actually work. Ensuring nothing is written back to the disk comes some way down their priority list.

At least with a hardware blocker the company making them has a reputational stake in the process. I once went to a demonstration by a hardware blocker manufacturer and was heartened by them admitting that they sometimes get it (accidentally) wrong, for example, when the chip manufacturers change the API allowing undocumented write-backs. In this example the write-blocker manufacturer was made aware (quite quickly) by their users and issued a patch forthwith.

I am not aware of any hardware write blocker that uses Linux or any other OS as a background system (incidentally, wouldn't that make it a 'software' blocker?), there is no need to mount the filesystem at all, I would soon ditch it if it did. All that is needed is a chip (or number of chips) that allow all read operations and disallow ANY writebacks.

Bottom line - both have to be taken on faith unless you have lots of expensive equipment to PROVE that under all circumstances there are no writebacks. I used hardware writeblockers for many years without any problem. I used software write blocking too when I had to, though I had less success with this (mainly due to having occasional fat fingers and/or being slow of thought ).
_________________Paul Tew

I am not aware of any hardware write blocker that uses Linux or any other OS as a background system (incidentally, wouldn't that make it a 'software' blocker?), there is no need to mount the filesystem at all, I would soon ditch it if it did. All that is needed is a chip (or number of chips) that allow all read operations and disallow ANY writebacks.

Strictly speaking, if the "hardware" write blocker has a "firmware" (i.e. it can - one way or the other - be "patched" or "updated"), it is a "software" write blocker anyway.

jaclaz
_________________- In theory there is no difference between theory and practice, but in practice there is. -

In truth, neither are 100% safe but I would opt for hardware blockers.

With software blocking you are at the mercy of kernel code and library writers who's first priority is to ensure the disk & file system drivers actually work. Ensuring nothing is written back to the disk comes some way down their priority list.

This is why the write blocking functionality should be implemented in a single spot somewhere in a kernel.

- binarybod

At least with a hardware blocker the company making them has a reputational stake in the process.

Reputation should never replace validation.

- binarybod

I once went to a demonstration by a hardware blocker manufacturer and was heartened by them admitting that they sometimes get it (accidentally) wrong, for example, when the chip manufacturers change the API allowing undocumented write-backs. In this example the write-blocker manufacturer was made aware (quite quickly) by their users and issued a patch forthwith.

The explanation mentioning API changes is really odd. If a hardware write blocker is implemented on top of a microcontroller, then there should be modified (custom) firmware created using the original one provided by the vendor of the microcontroller. For example, a Tableau T35u write blocker is using an ARM Cortex M3 microcontroller from Texas Instruments, its firmware is based on what Texas Instruments provides to customers. If things change in the original firmware, developers from Guidance Software should notice that in the vendor's source code before they start distributing an update of customized write blocking firmware. If they don't, well, there is no valid reason to blame the API change. Also, what API?

- binarybod

I am not aware of any hardware write blocker that uses Linux or any other OS as a background system (incidentally, wouldn't that make it a 'software' blocker?), there is no need to mount the filesystem at all, I would soon ditch it if it did. All that is needed is a chip (or number of chips) that allow all read operations and disallow ANY writebacks.

Tableau TD3 & TX1 devices are running Linux (these are forensic duplicators, but both are capable of acting as a network-based write blocker, and both have "write blocked" ports).

Bottom line - both have to be taken on faith unless you have lots of expensive equipment to PROVE that under all circumstances there are no writebacks. I used hardware writeblockers for many years without any problem. I used software write blocking too when I had to, though I had less success with this (mainly due to having occasional fat fingers and/or being slow of thought ).

And I saw a Tableau TD3 device writing to a drive attached to a "write blocked" port. Also, I saw a Tableau T356789iu device blocking perfectly legal and usual read requests. A "reputational stake" is pretty bad here (but things may change since I found my software write blocking patch implemented in Tableau TX1 ).