±Partners and Sponsors

±Your Account


Nickname
Password


Forgotten password/username?


Membership:
New Today: 0
New Yesterday: 3
Overall: 26785
Visitors: 107

±Follow Forensic Focus

Join our LinkedIn group

Subscribe to news

Subscribe to forums

Subscribe to blog

Subscribe to tweets

Software write blocker

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Go to page 1, 2, 3  Next 
  

Software write blocker

Post Posted: Fri Nov 18, 2005 7:35 am

Can somone please give me the neame of a software write blocker? THX  

Earn
Senior Member
 
 
  

Re: Software write blocker

Post Posted: Fri Nov 18, 2005 10:04 am


arashiryu
Senior Member
 
 
  

Re: Software write blocker

Post Posted: Sat Nov 19, 2005 11:02 am

Can anyone comment on the general reliability of software write blocking?
_________________
fatrabbit 

fatrabbit
Senior Member
 
 
  

Re: Software write blocker

Post Posted: Sat Nov 19, 2005 2:12 pm

With -any- write-blocking solution, obviously, before use, you should be testing it yourself, hashing disks, attempting to write to them while write-blocked, and then hashing afterwards, making sure that no writes went through. Also, making sure all other intended commands (reads) are going through properly.

I can't comment on 3rd-party windows solutions for write-blocking. But linux and bsd drivers in read-only mode have been used for many years, and have been put through a number of tests.

[EDIT] If you plan to use a driver in a linux or bsd kernel, be sure to be using a stable (non-new) version, as you want to be sure the kernel and drivers have undergone community testing as well -- but this should go without saying. [/EDIT]

Bottom line: If the driver is stable, and you've tested it yourself, there's absolutely no reason to discredit it as a write-blocking solution.

Any device can fail, be it hardware or software -- you must test any device you plan to use ... that's just common sense. There is, however, no effective difference between using a tested and proven software write blocker, and a tested and proven hardware write blocker as far as quality of write-blocking.

[EDIT] After some thought, I decided to add on to this statement. The common arguments against software-level write protection (besides those about human error -- which are baseless, because hardware protection requires human interaction as well) are mostly based around failure. Now, as is known by every educated RAID administrator in the world, hardware failure is REAL -- it happens all the time, and, unlike a software failure, hardware failure often happens with no information, no debug or error outputs, nothing. A controller failure (in this case, inside of the write-blocking device), a chip malfunction, or a number of other things can all happen in any hardware device. When this happens in a RAID controller, often data is immediately corrupted on the hard drives, with no notification to the user.

As part of this ammendment, I don't want to give the impression that software write-blocking techniques are immune; far from it. An ideal system (due to the relatively low risk of hardware failure) would include hardware write-blocking. However -- you don't know how well built that device is ... unless you're a chip and board designer. There are not hardware write-blockers for every possible device you may need to acquire from. I simply want to be sure that everyone is aware of hardware failure as a real, and regular part of the computer industry.

So my conclusion (and I'm sorry this is so long) is that well-designed hardware has a lower rate of failure than software, however, a hardware failure will result in unknown results -- often with no notifcation of error. When possible, well-designed hardware (to reduce writes when hardware fails) is an optimal solution. I would love to see an electrical engineer's analysis of a number of popular commercial hardware write-blocking devices, to see how they stand up under different types of failure. [/EDIT]  

Last edited by cblume on Sat Nov 19, 2005 10:27 pm; edited 3 times in total

cblume
Member
 
 
  

Re: Software write blocker

Post Posted: Sat Nov 19, 2005 3:39 pm

Thanks for the reply. I've read a few documents that warn against software based write blocking on windows systems for a variety of reasons, they also list a few reasons against using it with linux. I'll have to do more research and testing.
_________________
fatrabbit 

fatrabbit
Senior Member
 
 
  

Re: Software write blocker

Post Posted: Sat Nov 19, 2005 6:09 pm

I'd love to see the documents you're referring to (that warn against using linux driver-level write blocking). I've noticed quite a bit of ignorance in the community on this matter, and if there's any real critiques, I'd love to read them, and learn from them -- and if they're baseless -- it would be good to be able to argue against them.  

cblume
Member
 
 
  

Re: Software write blocker

Post Posted: Sun Nov 20, 2005 7:13 am

cblume, I'll try and dig them out and send them to you, although it did take me a while to find them and I'm not sure if I saved any of the relevant ones. The documents where pitched at a conceptual level as opposed to a low level technical analysis of specific drivers or applications. To paraphrase though, they highlight the inherent difficulty in trying to control the highly complex and unpredictable nature of PC based systems, that are specifically designed to write to media, with a form of control (write blocking) software. Only one of a high number of points of failure need to occur to circumvent the write blocking mechanism, not to mention the installation of additional applications and OS updates. One document mentioned that EXT3 mounted as read only will still incur a write to update the journal count, don't know how accurate this is though. These aren't my opinions as I've yet to do testing so don't shoot the messenger! I'll try and pass the documents to you when I dig them out.
_________________
fatrabbit 

fatrabbit
Senior Member
 
 
Reply to topicReply to topic

Share this forum topic to encourage more replies



Page 1 of 3
Go to page 1, 2, 3  Next