Keep Your SD Cards Data Safe With The SD Locker





41 thoughts on “Keep Your SD Cards Data Safe With The SD Locker

    1. Absolutely! only fools think that an SD card will store something forever. It will not, There are only a very few “long term” flash storage devices out there, Sandisk Memory Vault is one of them.

      1. You can just copy it every 6 years to a new storage, and you’ll have to since the SD card will probably be outdated at some point and you won’t be able to get readers for them.
        Already the full sized ones are making room for the micro ones.

    1. > 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 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.

  1. 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.

    1. 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?

      1. 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.

        1. 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.

          1. 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.

    1. 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.

      1. 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.


        1. 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.

    1. You could either set the microcontroller with a fixed password to use, or maybe use Morse code on the buttons! Or have 5 passwords and use the buttons to select. Or some other way. But that doesn’t matter, this is just for flipping the write-protect bit, not the password (I think!).

  2. 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.

  3. 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.

  4. 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.

    1. 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

Leave a Reply
