The Tiniest SD Card Locker


In case you weren’t aware, that little ‘write protect’ switch on your SD cards probably doesn’t do anything. It’s only a switch, really, and if an SD card reader doesn’t bother to send that signal to your computer, it’s completely ineffective. Then there’s the question of your OS actually doing something with that write protect signal.

The better way to go about write protecting an SD card is using the TMP_WRITE_PROTECT bit on the SD card’s controller. [Nephiel] came up with an amazingly small device to set that bit, with the entire circuit fitting inside an old Playstation memory card.

[Nephiel] based his project on [Karl Lunt]’s SD Card Locker we saw late last year. [Karl]’s SD Locker uses an ATMega328 microcontroller, a pair of AA batteries, and an SD card socket to perform the bit toggling. This is still a very small device that fits inside an Altoids tin, but [Nephiel] thought he could make it smaller.

The new and improved version uses an ATTiny85 for SPI access to the SD card. A single button and LED serves as the user interface: with the LED off, the SD card is writable. Press the button, the card is locked, and the LED lights up.

45 thoughts on “The Tiniest SD Card Locker

    1. Suppose they could. Just like the write-protect notch on floppies (aaaah, remember them!). I think it’s more intended at preventing accidental overwriting by the user. Though there is, I recall from reading the last article here on this, a permanent irreversible write-protect bit.

      Still most malfeasants wouldn’t even HAVE a device like this. I’m surprised PCs don’t offer the option. Then again I’m not. With the amount of devices that have a limited interface, it might be hard to get the concept across to users, of why their card won’t store any more photos or MP3s. Especially since the bit is invisible, and ignores the actual plastic switch on the casing.

      I think this is something the SD Consortium added in for completeness, then thought better of actually using. Users of consumer gear don’t even have to be as able as PC users.

    2. Yeah, unlocking lost or stolen cards is as easy as locking them, but what I really wanted was a cheap and easy way to write-protect some USB drives to use on untrusted computers. Just load a MicroSD card with whatever is needed (e.g. diagnostic tools, patches, live distros), lock it, and put it on a USB reader. It provides another layer of security against viruses and malware.

      1. That is brilliant and exactly what I was thinking when reading the post ( useful for “freezing” a live distro or the like ). I will certainly have to look into this a little more. Thanks for passing on the knowledge.

          1. While I think every USB stick should come with a write protect switch, and most every USB stick could have one cheaply added if I didn’t have to sign a NDA just to see a flash drive controller data sheet, paying $21 for a portable bootable anti-malware toolkit that still has enough room to shoehorn in a few distros is _cheap_

        1. My ignorance to locking-mechanisms never cease to amaze me. But now that i have found out SD cards were using an “advisory” type lock-tab, i just extended that to include USB-memory sticks. So are you saying the locks on USB drives like these are “hard-wired”?

    1. I think there’s a limited demand, not much real use for it, and it’d confuse the hell out of people when their cards wouldn’t write any more, despite the little plastic switch. Or worse, on mini and micro cards, no plastic switch.

      Not that it’s not a well-done hack, just not for public consumption.

    2. Avoiding confusion is probably the reason these protection features (the locking bits and the plastic switch) are not widely used in consumer products.

      The design of the locker is quite simple, and the parts are cheap and readily available. It’s not hard to make, just time-consuming. The hardest part is the code and [Karl Lunt]’s already done that (I just took out the features I didn’t need).

      IMHO anyone likely to have a need or a use for this kind of device would probably build one rather than buying a commercial product.

      1. Nephiel, it may not be worth turning this into full-blown commercial product, but would you be willing to sell me a unit? I need to lock microSD cards that we want to use for media distribution but don’t want people to erase the media in order to use the cards for other purposes (we don’t mind people copying the data, we just don’t want to end up giving away free microSD cards!). This seems like the perfect solution, but I don’t have the time to devote to researching/building properly. Ideally, I would love to have two buttons, one for the TMP bit and one for the PERM bit.
        Please let me know if you’d be willing to build/sell me a unit.


  1. I always (until recently, this is not the first time i see this mentioned) thought the write protect tab was a physical switch controlling a mechanical write protection mechanism (as are done in floppies). Or at the very least a switch disconnecting a trace to a pin required to do writing.

    Now that i think about it, that is rather naive since no card-reader have something like that build in (in my defense, before now i havent given it _that_ much thought)

    1. Actually, it IS just like floppies.

      Take apart an SD reader sometime. Amongst the various fingers and such is a mechanical switch that makes/breaks contact depending on the position of the plastic write-protect gimick.

      I’ve got a USB-SD dongle here which I’ve modded slightly to allow writing to cards no matter the position of the plastic write-protect gimmick. Works well.

      1. There are many readers that only take the card half-way in and in those the switch never gets far enough in to make a difference.

        So now ive come to the following understanding:

        All (so far known) Floppy drives fully support the locking mechanism (mechanically or optically) And the OS is left to follow my decicison w/ regards to the tab.

        Some SD- card readers support the locking mechanism physcically on the card (but not all cards feature the tab) – it is still upto the OS to deal with it (which most or all consumer OSs seem to do thankfully).

        No (or rare enough to be effectively no) SD-card readers support setting/unsetting the Readonly(tmp) bit – but they all seem to support it in firmware once it is enabled.

        (mind you, i just woke up and still got sleep in my eyes, but this still seems about right)

        1. Even with a reader that reports tab status and an OS that supports it, there’s a driver between the two. Nothing stops a driver from reporting the card as writeable to the OS. However, with the TMP bit set, the card itself will refuse to be written until that bit is cleared, which in practice no card reader can do regardless of driver or OS.

          Also, the SD socket I used only takes the card halfway in (it’s fully inserted in the pic) yet it has a pin to address the plastic tab. The reader I scavenged it from ignored that pin, though.

          1. It is this inconsistency that bugs me.

            Yes, the best “level” to un/set this Readonly bit on is on the cards mcu. then the OS can do whatever it wants and your data is still safe (the lowest level is usually the best, but also the most difficult to reach usually). Altenatively one could fix the driver to always report the card as readonly – most likely the OS would not run ahead over that and try anyways (and the driver could just drop that request on the floor and laugh – infact you could do this without reporting it was locked).

            It reminds me of Advisory file locks that require you to check if it is locked, and if you ignore checking you are still allowed to to as you please.

            Or the good old readonly attribute in DOS, that you could simply (blindly) unset on every file before attempting to delete (or unset readonly, write your viral code to the executable, set the readonly, and nobody is none-the-wiser without thorough checking of the file contents). But at least everyone could unset the readonly attr. of a file when some jester had set set it. the TMP bit requires specialised functions that are not part of the standard OS.

  2. Floppy disks didn’t have any mechanical write protection mechanism. They worked the same way SD cards do. There was a small push button inside the drive that would be pressed or not pressed depending on the state of the write-protect switch on the disk. It was up to the drive to enforce the actual write protection, and shorting a trace on the drive’s PCB would disable the protection check entirely.

    1. Good point on the floppy. I guess my wording was wrong, the “button” inside the drive was mechanical (and this is also the feature i mention missing from SD readers). Does there actually exist any floppy drives/hacks that disable this writeprotect?

      Regarding that the shorting would disable the check entirely. im not familiar with how SD cards work so i wrongfully thought that the SD cards worked in a way where it would be possible (that is, i do not know what the pins do, and it would be entirely plausible to have a pin for writing (and only writing) and shorting the trace to it would disable it). Reality being different. And me never bothering to think much about it.

      But as i said, how i thought it worked was wrong. so from that i made further wrong assumptions.

      1. For hacks, on many later drives the floppy write-protect slider was read with an LED / opto that shone through the hole. A blocked hole meant write-enable. So you’d just need to snip a leg of the LED, or if not possible, stick a bit of paint over it or the sensor, or short the opto.

        Older drives using mechanical sensors could be bypassed easily, either shorting or removing part of the switch.

        I assumed myself the write-protect on SD cards would do something. Connecting it to a switch that went to the card’s CPU would be enough to do it.

        1. All my floppy drives are of the old mechanical type i think. but thats probably mostly cause all my hardware is of a certain age :-)

          I see your point about simply removing the switch – sometimes the most obvious solutions never occur to me. Though i guess a hacked floppydrive is rather stupid since you can always slide the tab or just drill a hole in the disk anyways… But perhaps if you have a box of random floppies and are dd’ing the same image to them all, a hacked drive would be easier than checking each floppy (it was annoying enough to just manually change them when installing that 13 floppy game, and that was without doing any inspection of the disks)

    1. Assuming the upgraded version makes it obvious which bit you are flipping, I could imagine it being usefull in a few rare cases where you really do not ever want to change what is on the card (or are relying on the data on the card for security so do not want people flipping bits in the its memory)

      1. then again, they could just copy content of write protected card to new one, so unless there is a password it is hardly any good for anyone (it could be if cards are more reliable – i.e. write protecting your holiday\wedding etc. pictures, but imo sd card isn’t best media for long term storage)

        1. I was not talking about protecting from wear and tear. but protecting from intentional damage/changes to the data you rely on, by a program or person getting the chance.

          (a very basic example (and not very good) would be reading a file/bit on the card to see if the computer should unlock. Or reading a ip/email-address to send sensitive data to – and i did qualify it with “a few rare cases”, but HAD readers do tend to make things for “rare cases” or even “no reason”)

  3. @m4rkiz
    Had to use the “reply” on my own post. hope you still see this.

    True, I havent exactly thought the idea all the way through to a workable implementation, it was merely a top-of-the-head thing.

    Cloning could be an issue to the unlocking example. But the sending of sensitive data to an address read from the card will still work, in that case a clone would be of no use (beyond the ability to read the info). Though i am sure given a bit of time you can probably poke a hole in that idea too :)

    I just do not like dismissing things right away as useles just because there is no immediately obvious benefit. And a SD card locker with the added option (and careful warnings that it is permanent) is stil a SD card locker, just with an extra feature (and we all know hacks can not have too many features!)

      1. That sounds interresting, i tried checking wikipedias article on Secure Digital, but i can not find any reference to this, even under Security (but perhaps its part of the DRM?)

        But admittedly i didnt spend much time researching. Do you happen to have a link to something that wont require me to read the full SD spec?

        I also wonder if a cloned card can have the same ID or if that is in ROM or similiar? And wouldnt making a HW SD-card emulator (putting micro of your choice on a stripped SD card, emulating a cards functions and its ID (or maybe reflashing the existing controller if that is possible)) make this feature *almost* (you still eliminate evildoers not having such an emulator available) as insecure as just reading a file on the card?

        From what i read at wikipedia it seems the Secure part is in the bits mentioned in this article, the write-protect tab, a password (i have never seen this used, and wiki does not mention how portable it is) or DRM (under drm it mentions that some symbian phones can format a locked card – im not sure if they mean passwordlocked or drmlocked).

        Maybe you or someone else could expand on this?

          1. from the comments there [Karl Lunt] writes: “Check the SD Group spec on CMD42. There is a bit you can set in the CMD42 packet that will do a full erase of the card’s data. You lose the data and the password; the card is essentially cleaned. See section, Forcing Erase.”

            Which means the password is not (as) usefull for protection against intentional corruption of the data (though not as bad as bit-flipping at will)

            He also notes: “Note also the PERM_WRITE_PROTECT bit in the CSD (section 5.3.2) is described by the spec as \“Permanently protects the entire card content against overwriting or erasing (all write and erase commands for this card are permanently disabled).\” But this conflicts with CMD42, which claims to allow full erase. I haven’t tested to see what actually happens if you try to erase a perm-locked card.”

            So the actual safety of this feature is a bit up in the air i guess.

            And now I realise that ID and Password may be refering to the same thing? If so then the ID is userchangable and not very useful for uniquely identifying the card.

          2. I just want to add that my “complaints” (some based on my own misconceptions, always glad to be corrected) about the reality of SD card locking/passwording is not a dig at your CARDlocker, which works as advertised and does serve its purpose. And it looks pretty nifty too. (But where is the PS1 one version for those of us who havent upgraded console in a while? that looks like a PS2 or later memcard!!! ;-)

            I could probably also figure this out if i did my own indepth research, I just have a tendency to like discussing these things (reality is rarely as cut-and-dry as you read it in official specs.) – esp. when i have access to people “in the know” ;-)

  4. GPLv3

    I have locking and am adding passwords to a Sparkfun Openlog which is just slightly larger than a micro SD. The FAT32 lib now works with 64Gb. Right now it needs serial, but I should see if I can do a switch + LED. I have micro to fullsize sd adapters too

  5. This is very useful for my work, where most of the time I have to deal with infected computers and this way I won’t need to buy a switch protected USB drive for each distinct job. Just changing SD card will make the thing. Could it be done with smaller SD cards?

  6. So, is there a way to do this from a computer instead of microprocessor? I end up with a crapload of memory cards and disks that are locked in some read-only mode or another and I’m scratching my head trying to find a way to turn that off.

    1. I think you would need (to write) a special driver for supporting setting/unsetting this bit. and then you would need to write an application interfacing the driver. Though it could be some drivers already support this and you could get away with just writing the application (which would be a software analogue to this build).

      A “computer” is in reality just a big “micro” with a lot of extra features and hardware after all – remember the first home computers were infact called microcomputers and used microprocessors.

      tl;dr: It is possible but may require more skill/knowledge in a specific area of computing than most regular people have. (as in – if you have to ask, you probably arent one of those people. no insult meant – i could probably not do it myself despite 20+ years of hobbyist progamming experience) – and dont you just love when “tl;dr” becomes the longer part? :)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.