write-protected usb flash drive

[Polytropon]

On Sat, 24 May 2014 17:54:11 +0100, Arthur Chance wrote:
> On 24/05/2014 17:32, Warren Block wrote:
> > On Sat, 24 May 2014, Polytropon wrote:
> >
> >> On Sat, 24 May 2014 16:22:59 +0100, Arthur Chance wrote:
> >>> OK, thought I'd better try my own advice rather than just handing it
> >>> out. I put a microSD card out of an old phone into a SanDisk mSD -> SD
> >>> adapter and plugged that into my SanDisk SD -> USB adapter, mounted it
> >>> (FAT32 file system already on it) and wrote a file to it. Worked as
> >>> you'd expect. I then unmounted and unplugged it, flipped the write
> >>> protect switch and tried to remount. Result was
> >>>
> >>> mount_msdosfs: /dev/da5s1: Input/output error
> >>>
> >>> Mounting it read-only was fine. So, the write protect is honoured by at
> >>> least some SD -> USB adapters.
> >>
> >> This is already on file system level. It _should_ work the same
> >> at upper layers, for example when using dd to write NULs to the
> >> device with the write protection on - an error should (correctly)
> >> occur in that case.
> >>
> >> When a r/o mount is forced, the routines accessing that file
> >> system cannot avoid the write protection. Still writes are
> >> possible _aside of_ the file system which should be prevented
> >> by the switch as well. It's probably a good idea to check that
> >> too, e. g. put in the card with write protection on and then
> >> try dd or newfs on it.
> >
> > These are worthwhile tests, but remember that they are done in an
> > environment where everything is playing by the rules and trying to do
> > the right thing.  The drivers will try to support the write-protect switch.

This is, on FreeBSD for example, things work as they are
supposed to work.



> > Malicious software could use custom or patched drivers to ignore the
> > settings of the switch or anything else.

This is especially problematic in closed-source products
where no real indication of operating system and driver
functionality can be obtained. "Trial & error" is the
only way here, and even then you can't be fully sure.



> > The card reader microcontroller might be responsible for the write
> > protect, which would make it much safer than just being honored by
> > higher-level drivers.
> 
> I'm not sure how one could easily test that.

It seems there are too many "moving parts" involved here. :-(



> I will note that when I tried using dd to write to a write protected 
> card the IO indication light on the USB adapter blinked, which I presume 
> meant the write attempt wasn't thwarted at the driver level, but I'd 
> have to plough through at least the umass and cam code to even start to 
> get some degree of certainty on that.

A good idea! Think about "camcontrol format" for example.


-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...