±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 32893
New Yesterday: 9 Visitors: 148

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

RSS Feed Widget

±Latest Webinars

LinuxLEO Website and Training Materials - Updated

Computer forensics training and education issues. If you are looking for topic suggestions for your project, thesis or dissertation please post here rather than the general discussion forum.
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Go to page 1, 2  Next 
  

LinuxLEO Website and Training Materials - Updated

Post Posted: Tue Sep 12, 2017 7:57 am

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.

Thanks,
Barry  

bgrundy
Senior Member
 
 
  

Re: LinuxLEO Website and Training Materials - Updated

Post Posted: Tue Sep 12, 2017 2:42 pm

Thank you! Nice update!

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

thefuf
Senior Member
 
 
  

Re: LinuxLEO Website and Training Materials - Updated

Post Posted: Thu Sep 14, 2017 10:19 am

wow thanks...back in 2008, it helped me prepare for SANS GCFA. Smile  

ganron
Member
 
 
  

Re: LinuxLEO Website and Training Materials - Updated

Post Posted: Sun Sep 24, 2017 12:11 pm

- thefuf

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 Wink ).
_________________
Paul Tew

Retired Forensic Analyst and Researcher 

binarybod
Senior Member
 
 
  

Re: LinuxLEO Website and Training Materials - Updated

Post Posted: Sun Sep 24, 2017 12:43 pm

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

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

jaclaz
Senior Member
 
 
  

Re: LinuxLEO Website and Training Materials - Updated

Post Posted: Sun Sep 24, 2017 1:35 pm

- jaclaz
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.


It is possible to create a simple IDE-to-IDE write blocker without firmware (using an FPGA).  

thefuf
Senior Member
 
 
  

Re: LinuxLEO Website and Training Materials - Updated

Post Posted: Sun Sep 24, 2017 2:40 pm

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

Tableau T356789iu devices are running Linux (this model is a pure write blocker).

- binarybod
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 Wink ).


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 Very Happy ).  

thefuf
Senior Member
 
 

Page 1 of 2
Go to page 1, 2  Next