Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I'm currently using a USB flash drive with a live distribution. At times I would plug it into terminals I cannot trust.

My threat model here is solely the risk of unauthorized modifications to the live distribution image on the flash drive. Unfortunately, a live CD is not convenient enough (the file system has to allow writes when used on a secure terminal and constant remastering is too cumbersome).

I'm considering now if a physical write protect (read only) switch on the flash drive is reliable enough to be trusted. I mean such as can be seen on older flash drives (e.g. PQI U339H).

From what I've found so far, the write protection is said to be done completely on hardware level, but I couldn't verify if there's indeed no way to circumvent it. For sure with SD cards there is (as it's basically software level information that doesn't have to be respected by rogue systems).

For instance the SD Simplified Specification describes it as:

4.3.6 Write Protect Management

Three write protect methods are supported in the SD Memory Card as follows:

  • Mechanical write protect switch (Host responsibility only)
  • Card internal write protect (Card's responsibility)
  • Password protection card lock operation.

Mechanical Write Protect Switch

A mechanical sliding tablet on the side of the card (refer to the Part 1 Mechanical Addenda) will be used by the user to indicate that a given card is write protected or not. [...]

A proper, matched, switch on the socket side will indicate to the host that the card is write-protected or not. It is the responsibility of the host to protect the card. The position of the write protect switch is unknown to the internal circuitry of the card.


Do you know of some similar technical explanation of how this kind of write protection works on USB flash drives and would relying on it for security be wise?

share|improve this question
Writing to a Flash drive requires a high voltage (15 Volt or so) which is not needed in read-only mode. A sane choice would be to disable the charge pump which generates the necessary 15 Volt. But while sane, this has one disadvantage: a failing block with recoverable errors can no longer be saved by copying it. –  MSalters Dec 30 '13 at 22:15
@MSalters: I've never seen any recent flash chips which required an externally-provided high voltage supply for normal write operations. Incorporating charge pumps on the chip makes it possible for a manufacturer to use whatever precise voltages would work best for various operations. Further, unless a board has a reason to keep a high-voltage supply active all the time, the energy required to charge up an external HV supply may vastly exceed the amount of energy required to perform a few flash writes. –  supercat Jul 18 at 18:27

6 Answers 6

up vote 9 down vote accepted

Physical write protect on a USB drive should work in all cases. The write controller is in the drive itself. Thus, excepting a wholly insane implementation, the physical write protect switch is secure.

Physical write protect is always kind of a semi-soft thing, but it's usually at the drive internals. With a floppy drive where the controller is external to the device, one could craft a drive that ignored the write-protect slider. I think SD cards are the same as floppy drives in that regard, though I won't make a bet on it because I know those include some circuitry for things like wear-leveling.

share|improve this answer
That's in fact my assumption I'm trying to confirm. As to SD cards, I've added an excerpt from SD specifications showing that mechanical switches are explicitly host based. Only internal card protection would work, but it's not that common (optional to the standard). But I suppose it's this kind of internal solution that is used on flash drives, however I couldn't find anything precise about it. –  Karol Piczak Jun 2 '11 at 15:46
You don't find it because the Mass Storage specification is a subset of USB, and it isn't explicit in regards to the write switch because the specification allows any medium to be represented using that specification. The host machine doesn't have to know whether it's an SD card with a USB front-end or a hard drive. It IS possible for somebody to design a drive that tell the OS it is read-only but will respond to write commands. It would be stupid to do so. Because each implementation is different, this can happen. That said, the medium interface in the USB has full control over how it acts. –  Jeff Ferland Jun 2 '11 at 17:05
How can this be explained, then?… –  axeoth Jul 11 at 11:35
@axeoth: See my answer. –  supercat Jul 18 at 18:55

First of all here is a link to a page with a list of usb sticks with such write protection switches: There is some info there, and they too imply that it's a hardware protection.

Now, if you are really serious about it, you can consider usb write blockers, commonly used for forensic purposes but can be used like this too. Here is one example:

share|improve this answer
As the creator of that first page with the list of drives, I have absolutely no firsthand knowledge of the actual implementations being used. I could see it being either a flag to the on-drive controller that writes should not be allowed or a physical interruption in circuit traces, but I think the first is far more likely for cost & reliability reasons. It still comes down to trusting the controller implementation. For the truly wary, I suspect Kanguru will be your best bet both for drives and for getting detailed technical responses. –  fencepost Aug 7 '11 at 23:14

Although many low-level flash chips do provide a hardware "write-protect" pin, operation is completely unspecified if the state of that pin changes in the middle of a write operation; while changing the pin around the time an operation is started might always have the effect of either preventing the operation altogether (if done soon enough), allowing one last write operation to complete (if done just after the chip recognized the command), or perhaps creating bits with weird intermediate logic levels, some data sheets expressly refuse to specify that consequences are limited to those.

The purpose of the write-protect pins is not to allow end-user control via an external switch, but more typically to allow the manufacturer of the product to either ensure that the contents of a pre-programmed chip won't be changed once it's soldered into the final application circuit, or allow the manufacturer to ensure that it can only be changed via special factory-programming cable.

If the firmware in a flash controller is designed properly, having a firmware-readable "write-protect" switch should be essentially as good as a hardware-interlocked one. An alternative which would be even better would be to have the switch connected to a latching circuit such that the write protect pin could only change to allowing writes when the switch was enabled to do so, but once the processor had taken action that required the ability to write, it could ensure that it kept that ability even if the switch changed in the interim. Such an implementation might require extra hardware, however.

With regard to the observation by axeoth that some drives may only check the switch when a drive is mounted, I would suggest that such behavior (which would not be incompatible with a latching design as I described above) might be motivated by a deficiency in the USB Mass Storage Device specification--most notably the lack of a means by which a device can say to the operating system "I would like to remove myself from the system; please ensure that any pending data gets written to me, and either let me know when that's done, or let me and any human nearby know if there's a problem". If such a behavior were supported, flipping the switch from write-enable to write-protect mode could prompt the device to request a clean unmount and then remount itself as a read-only device. Without such an ability, however, a device would have to either perform a "rude" unmount, delay acknowledgment of the switch, or have write operations report "unexpected" failures. While a rude unmount would perhaps be the best behavior, some users may be annoyed if flipping the switch after they think data is written results in data loss.

share|improve this answer
Thanks! Nice answer! –  axeoth Jul 21 at 6:16

Have you considered hashing your image and checking the hash after boot and/or before shut down? An attack that would replace your boot image seems a very low probability but the hash could give you peace of mind. A live image boot expects to be from read-only media so all changes are made in local memory (to be lost with power off) and not to the image thus that is not an attack vector. To attack your boot image the attacker would need to know you were not booting from a CD and know where you image was, what release, etc.

share|improve this answer
Yes, in general this would help. But to be honest, when I look at the question now, I think my attack vector as described in its current state is purely theoretical and too specific. I also doubt any kind of attack would be that targeted. I should have described it as pertaining to the avoidance of unwanted data corruption. –  Karol Piczak Jun 2 '11 at 16:03
So, a bit less specific version - would a read-only switch work as a reliable fail-safe mechanism when a write was not intended? Be it from malicious tampering with the live image or more probably just due to accidental erasing/overwriting when left mounted on another system. –  Karol Piczak Jun 2 '11 at 16:04
The example device appears to need a special driver. So if properly configured with said driver and residing in the expected OS the answer appears to be yes. I personally dislike specialty devices with proprietary drivers like U3 as they take some control and decisions away from the user and replace it with unexpected behaviors and features. –  zedman9991 Jun 2 '11 at 18:32
But wow would you check the hash? Where are ya gonna get the hashing software? If the USB drive is compromised, then it could be modified to have malicious hashing software. Asking untrusted software to validate itself is pointless. It's like asking aviation passengers "are you a terrorist?"; any self-respecting terrorist is gonna lie, in that situation. Thus, @zedman9991's answer does not seem useful. –  D.W. Jun 3 '11 at 1:15
The live boot OS has hashing routines like MD5 so a one line script would address that. I take your point but in my mind you would have to be a very personally targeted individual as you are running from a read-only image that you controlled until boot time. The attack against the hash would have to find the personally created hash, the checking script, and modify all against that read-only image. This question was slightly modified from the original so please correct me as appropriate as I may be missing important points. –  zedman9991 Jun 3 '11 at 12:46

I wanted to post this as a comment to @Jeff Ferland's answer, but it was a bit too long.

Jeff, it seems your explanation is the best I can get. Every implementation is vendor specific, but every sane implementation should provide hardware level write protection.

I would have to verify my actual flash drive, but looking instead at an example of flash drive internals, the write protect feature is stated explicitly in the datasheet for the embedded Hynix NAND Flash:

A Write Protect pin is available to give a hardware protection against program and erase operations.


When the Write Protect signal is Low the device will not accept program or erase operations and so the contents of the memory array cannot be altered. The Write Protect signal is not latched by Write Enable to ensure protection even during power-up.

I think I can safely assume it's the same for all major manufacturers. So unless I'm very unlucky with some faulty implementation, I should be safe relying on physical write protection switches.

share|improve this answer
This seems sensible, for the most part. But... I guess the paranoid in me has lingering doubts. After all, for all I know, perhaps there are lots of insane implementations out there. If that sounds implausible, perhaps it is worthwhile to look at the history of how vendors who implemented hardware-encrypted disks and USB drives have fared; a surprising number of them have had devastating and elementary security flaws (like, not "encrypting" using XOR; or, not actually encrypting, but just storing the "key" on flash and checking it in software before allowing access). –  D.W. Jun 4 '11 at 5:28

If you don't have a hardware switch or don't trust the physical switch itself there is a hardware solution that will work, but requires copying data.

Burn your OS image to a dvd or hard drive and verify it with a hash. This is your back up. Now copy it to a few usb 3 drives, since they are cheap these days. Each time you boot with one, it will be considered dirty. After using it copy from the backup image to create a new usuable clean one.

If you need to use Apple or Windows, you can use solid state internal drives instead of usb drives and boot clean and virus free each time for the Internet. If you have to 'call home' for an app in which you use to create sensitive data with this solution will allow you to sign in with that app with a pristine OS copy, then unplug the Internet when that's loaded, then plug in your sensitive data for work.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.