[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?
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. :)
Well… Still better than instagram :-)
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.
Looking at the price per GB, I go with M-Disc
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.
How hard would it be to put a knock or tap sensor in one of these? Then you can’t accidentally jostle it to rw. Some silly pattern of touches or else it doesn’t allow reads?
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
Goatse.
> 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.
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.
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?
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.
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.
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.
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.
Here’s a wikipedia article: http://en.wikipedia.org/wiki/Wear_leveling
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?
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.
Yes, but in most cases _OS_ side will be good enough.
That depends on whether you trust your OS’s SD card drivers! Perhaps there’s sneaky malware that writes itself to write-protected cards.
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
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.
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.
how could one use the PWD register with a microcontroller?
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!).
Oh wait, were you asking how it’s done? Quick Google gives
https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf
which has everything, I think you need around 4.3.7.1. Search for “password”, can’t go far wrong.
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.
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.
Can the write-protect and un-protect be done from the OS and card reader instead through special hardware?
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.
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.
Because none of the current leading desktop OSs support this feature (even if it is easy to implement) so your card would look broken to them. Wouldn’t want that…
That is exactly what I would want…
I wonder why the voltage regulator is used here – wouldn’t 3V straight from the batteries be sufficient?
Maybe to maintain a constant 3.3V even as the battery voltage drops? I don’t know the exact specs of the regulator
can this be done with usb thumb drives?
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
Will there be a similar way for usb thumb drives?
What @HackJack already asked: Is there a software solution to set the temporary write protect bit?
Can we use the Arduino Ethernet Shield which comes with SD Card Slot to send commands e.g. tmp_write_protect ?