Software write bloc...
 
Notifications
Clear all

Software write blocker

15 Posts
9 Users
0 Likes
3,465 Views
 Earn
(@earn)
Posts: 146
Estimable Member
Topic starter
 

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

 
Posted : 18/11/2005 5:35 pm
arashiryu
(@arashiryu)
Posts: 122
Estimable Member
 

http//www.ncjrs.org/pdffiles1/nij/203196.pdf

http//www.cftt.nist.gov/software_write_block.htm

 
Posted : 18/11/2005 8:04 pm
(@fatrabbit)
Posts: 132
Estimable Member
 

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

 
Posted : 19/11/2005 9:02 pm
(@cblume)
Posts: 13
Active Member
 

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]

 
Posted : 20/11/2005 12:12 am
(@fatrabbit)
Posts: 132
Estimable Member
 

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.

 
Posted : 20/11/2005 1:39 am
(@cblume)
Posts: 13
Active Member
 

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.

 
Posted : 20/11/2005 4:09 am
(@fatrabbit)
Posts: 132
Estimable Member
 

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.

 
Posted : 20/11/2005 5:13 pm
(@cblume)
Posts: 13
Active Member
 

Thank you – I'd love to read them. I edited my previous post, but I'll add a bit.

I think I was a little overzealous-sounding with my initial response. Although not technically incorrect, I may have been misleading – yes, there are more points of failure in a software write-blocking based system. So, strictly, if the systems are working as they are intended, software-based write-blocking is not at a disadvantage.

I do recommend hardware write-blocking when available – however, nothing is perfect, hardware fails – and not all writes can be prevented (there was a paper written on internal disk writes, which would require disabling the HD controller to eliminate).

 
Posted : 20/11/2005 10:19 pm
(@branerift)
Posts: 59
Trusted Member
 

I use two different types of Hd blockers, but what about USB write blockers? Is there something that is available software wise?

 
Posted : 05/01/2006 6:24 am
(@bjgleas)
Posts: 114
Estimable Member
 

This is something we use at the office.

http//www.windowsitpro.com/windowsstorage/Article/ArticleID/44380/44380.html

Q. How can I mark my USB storage devices as read-only?
InstantDoc #44380
John Savill's FAQ for Windows

A. Windows XP Service Pack 2 (SP2) introduces a new registry subkey that lets you mark USB-based storage devices such as memory sticks as read-only devices. This is a useful security capability that can prevent users from copying data from their systems and taking that data offsite via a USB device. To enable the USB write protection, perform the following steps

Start the registry editor (regedit.exe).
Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies subkey. (Create the StorageDevicePolicies subkey if it doesn't already exist.)
From the Edit menu, select New, DWORD Value.
Type the name WriteProtect and press Enter.
Double-click the new value and set it to 1. Click OK.
Close the registry editor.
Restart the computer.

To disable this change, you can either set WriteProtect to 0 or delete it.

 
Posted : 05/01/2006 12:12 pm
Page 1 / 2
Share: