Keep Your SD Cards Data Safe with the SD Locker

sdlocker_1

[Karl Lunt] has come up with a simple circuit for protecting data you have stored on SD cards. As is relatively well-known, the little lock switch on the side of most SD cards really doesn’t do anything more than the switch on floppies or the tabs on VHS or cassette decks. It’s up to the reader/writer to check the status of the tab and decide if it should write to the card or not. Not a very safe system. However, it’s not the only write protection system built into SD and SDHC cards. As part of the standard, cards have three protection methods: A TMP_WRITE_PROTECT bit, a PERM_WRITE_PROTECT bit, and a PWD register.

The PERM_WRITE_PROTECT bit permanently write protects the card. The bit can not be reset, so you should be really sure you want to keep the data on the card forever. The PWD register is a password register. The card will not allow any access (read or write) unless a password is provided. The TMP_WRITE_PROTECT bit is a temporary write protect. This is the bit that [Karl] is working with. When TMP_WRITE_PROTECT is set, the card can be read but not written. Note that there is no true protection here, as anyone can modify the bit. However, this should stop grandma from accidentally deleting your wedding pictures.

[Karl's] device is very simple. A card is inserted into an Altoids tin enclosure. One button locks the card, another unlocks it. Three LEDs return status – power, card locked, and card unlocked. Under the hood, he’s using an Atmel ATmega328 to set and clear the TMP_WRITE_PROTECT bits. Power is provided by two AA batteries, and regulated with a Pololu 3.3v boost regulator. [Karl] has also included a serial port for control and debug information. We think this is a great hack, however one thing we’re not sure of is how or if these features are implemented in all cards. We’re relatively sure the name brand cards stick to the SD/SDHC spec sheet, but what about all the knockoff and no name brands from overseas?

Comments

  1. w says:

    One should seek annulment immediately upon learning that one’s spouse intends to keep one’s special wedding day memories “safe” on an SD card. :)

  2. Hirudinea says:

    Of course the dickish thing to do would make this set the perm write protect and castrate somebodies 64gb card with one picture on it.

    • The most suitable single image? trollface.jpg

    • Former Sandisk Customer says:

      > Of course the dickish thing to do would make this set the perm write protect and castrate somebodies 64gb card with one picture on it.

      SanDisk actually does this with their USB keys. No joke! Google “sandisk write protected” if you don’t believe it. There is a 19 page thread on forums.sandisk.com running from december 2011 onwards with ever more complaints about USB keys suddenly being write protected, and the only solution they offer is to return the key and get a replacement WOW – they found a perfect way to ruin a high profile brand.

  3. rainsbury says:

    Nice one, and for photographs taken on holiday I try to avoid knock off and cheap cards anyway so I am not too fussed if they don’t respond. I was surprised though when somebody mentioned they have a limited number of times you could write to the card.

    • prof_braino says:

      I’m confused about the “limited number of writes” thing. We hava data logger that writes a record that is several (~128) byte longs. It writes this record to SD several times a second. The SD have one big file on it. Re-writing the record rewrites the file header over and over, at least this one location is getting beaten upon. After several months it still has not failed. We’re talking millions of writes so far. What am I doing wrong, why doesn’t it fail?

      • tzj says:

        Sd-cards “even out” wear on the sectors to prevent that very use case from causing premature failure. Basically, every time it rewrites the file, it saves it to a different free sector.

        • Quin says:

          And the controller chip in the card (better brand usually means better controller) will do what is called wear-leveling.Each of the first 128 byte messages will cause the blocks to get shuffled around on each write, until it fills a whole block (size depends on the card maker, the flash chip, and the controller; on GB cards, it may still be in the kB size). Once the block is full, if you just let that one file expand, that block will probably be set in place and the next block will bounce around. The file table, for what ever format you use, will change invisibly to reflect that; you at an application layer will never see it. It’s only at the lower OS and the hardware level that you deal with this.

          And modern cards have a pretty high rewrite number, each block or page can be rewritten to 10,000 to 10,000,000 times, depending on a lot of different factors (chip batch, temperature, leveling, how erases are performed).

          Now, assuming your flash file system is smart enough to read unwritten to pages in a block as the end of file, and you are writing 128 bytes, then you might not even need to erase each page or block as you go. Just write your 128, then write the next 128 until you fill a 512 page, then keep writing at the page level til the block is filled. In which case, still assuming a good file system and controller chip, the only time you’d actually do a rewrite would be when you null out the log file. A bad controller and file system might cycle the page each time you write 128 bytes, so you’d get 4 rewrites before a page was filled, then 128 total rewrites before a 16kB block is filled and filed away (assuming a small block size, larger ones would mean more rewrites and a shorter life span). Suppose a 4GB card, and that’s 262144 blocks that each suffer 128 rewrites by the time the card is full. So you empty the card, another rewrite on every block (and hope the file system gets moved around or never needs changing, cause 128*262144 is way past the life span of a single block) means you’d fill the card 78 times before hitting the 10k rewrite limit. But that is an absolute best case where the controller chip and the file system work together relatively well. Worst case, every write writes over a block, and you have large blocks of about 512KB, you’d get just under 950 days (if I did my thinking and math right). All assuming that you write once a second. At 4 times a second, cut the later lifespan by a fourth, and the earlier would stay the same. but at 512 bytes a second (4 writes) you’d fill the card by 3 months and change. So failure should occur at worst(1 write per second, large blocks) in 3 years of use, at best (small blocks, but good table and controller, but 4x the writes) in 20.

          • Greenaum says:

            Even with wear levelling, isn’t it possible he just got a longer-lasting card through luck? There’s a lot of scope between ten thousand and ten million.

          • Tiersten says:

            What Quin said ^

            The endurance stats will be worst case and at the temperature extremes that the manufacturer rates the flash.

            When a sector does wear out, it will do it gradually. You’ll find it just starts to get really unreliable due to how the cell wears out. It may read back okay straight away but if you leave it for a long period of time then it may not be valid data any more. This is something you need to be wary of because a card may be quietly corrupting data when a quick test gives the all clear.

      • tzj says:

        Here’s a wikipedia article: http://en.wikipedia.org/wiki/Wear_leveling

  4. matt says:

    Although I can appreciate the work that went in to this hack, does it really serve a useful purpose? I mean how many readers or OSes out there ignore the write protect status?

    • Zac says:

      The thing is that this is not _OS_ side, this is _card_ side. If the bit is set on the card, it denies writes by the OS. The only way that the OS can write to it is by resetting the write protect bit, which would only be possible if the SD card reader driver supported such an action without user permission.

    • Nate B says:

      That depends on whether you trust your OS’s SD card drivers! Perhaps there’s sneaky malware that writes itself to write-protected cards.

      • Karl Lunt says:

        Actually, there are two use cases involved here. The first, as you point out, is that the OS or malware can simply override the write-lock slider if you have the card inserted into a laptop’s SD card slot.

        The second use case is plugging the SD card into a USB adapter and using that on your laptop. In this case, the OS has no idea of the state of the write-lock slider, so the OS couldn’t enforce the write-lock, even if it wanted to.

        The best way around both scenarios is to use the card’s temp write-lock bit in the CSD register. Granted, if the OS or malware can figure out that the “drive” you are using is an SD card in a USB adapter and IF the OS or malware is set to unlock/modify/lock the card, then your data is still at risk.

        Karl

        • megal0maniac says:

          The second use case isn’t necessarily true. The majority of card readers, even cheap Chinese ones (and I’m including those where the card only goes half way in) honour the lock switch. It is up to the reader controller to determine read-only or not, not the software. If the switch is set, then the controller will not process write commands and the OS is informed of this upon enumeration.

        • Greenaum says:

          Micro (and I think mini) SD cards don’t have the write-protect toggle anyway. And they’re already way more common than those gigantic full-size ones, with all their bulkiness.

  5. ss says:

    how could one use the PWD register with a microcontroller?

  6. Useful, as booting from write blocked SD card is one way around malware that hacks the BIOS and prevents booting from CD/DVD as a couple of recent worms do.

    Someone should make a small board that takes 4 or more microSDs with different versions of (insert OS here) and fits into a pendrive sized case.

  7. Greenaum says:

    Wouldn’t it have been easier / cheaper to just use 3 batteries and a LDO regulator instead of the boost circuit? I suppose the boost sucks the last bit of voltage out of the batteries, but I don’t see current draw being a problem in a micro you use once in a blue moon. He could even use 3xAAA instead of 2xAA.

  8. HackJack says:

    Can the write-protect and un-protect be done from the OS and card reader instead through special hardware?

  9. I’ve done this before, so here’s my summary on how various OSs react to to this: BADLY!

    Windows does not read this bit, and ignores write failures. this results on Windows letting you happily “overwrite” the data for a while, only to have it magically revert to whatever that card really stores when you eject and reinsert it. This happens because Windows caches the writes and does not realize the card refused to actually perform them. If you strat running low on RAM, it will get more confused yet as as sectors get reloaded from the card and the filesystem driver will not be sure what to make of this pieceiwse old-and-new picture.

    OSX reacts much the same way as windows does

    Linux (with some controllers) will detect write protection on attempt to write and yell about it. With other controllers, it will will fail in other random ways. When i investigated this (a few years back) it did not preemptively read this bit on card insertion, even though it is easy since the bit exists in a register that must be read during card initiation anyways.

  10. Freddy says:

    Why isn’t the password feature more widely known and used? Imagine your camera using the password feature to protect your pictures on the SD card.

  11. volt says:

    I wonder why the voltage regulator is used here – wouldn’t 3V straight from the batteries be sufficient?

  12. Fernie says:

    can this be done with usb thumb drives?

    • matt says:

      If you created your own thumbdrive then yes, otherwise no unless you’re using a special thumb drive with this feature built in. It isnt that hard to implement if you find a USB MCU and some USB MSD example code

  13. ferdna says:

    Will there be a similar way for usb thumb drives?

  14. Rajib Ghosh says:

    What @HackJack already asked: Is there a software solution to set the temporary write protect bit?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 94,528 other followers