I want to corrupt my memory!

May 26, 2008 7:03 AM

How can I corrupt memory? I have a plain SD card, and I'd like to be able to reliably make the memory corrupt. Can this be done?

Basically, I want to get that error that everyone dreads when it shows up on the digital camera. That the card is corrupted and needs to be formatted.

I've found many resources on how to recover from corrupt memory, but none that give any idea how to cause it consistently. The only information I've found are the things that might cause it - running on low batteries, unplugging during file copies and the like.

I've spent some time with a hex editor, attacking the headers and such of the memory stick, but none of these have caused corruption.

Any ideas?

posted by ChrisManley to computers & internet (18 comments total)

if the card is garbage, try microwaving it for a few seconds... the ESD should cause all sorts of entertainment.
posted by jenkinsEar at 7:33 AM on May 26

I think most of these cards use a FAT32 filesystem. IIRC, FAT keeps track of which blocks belong to a file in two ways --- with a linked list (each block points to the next), and in the file allocation table (FAT), which is an index to the whole disk that is stored in memory. Have you tried overwriting the FAT with junk?
posted by qxntpqbbbqxl at 7:38 AM on May 26

@qxntpqbbbqxl - I haven't, no. How would you go about that?

@jenkinsEar - I expect that would work, but I want to be able to recover from the corruption after the fact. So I don't want to break the card.
posted by ChrisManley at 7:42 AM on May 26

I would try zeroing out the first 512 bytes. I don't know how memory sticks are laid out, but most drives have a partition map in the first sector, and removing that may cause the effect you are looking for. Interesting question, though. What size is the card?
posted by procrastination at 7:45 AM on May 26

@procrastination - I'm working with a 1gb card at the moment.

I did open it with a hex editor and destroyed the first couple sectors, which looked like header information to me.

I thought that would do the trick - but both the device and the computer seemed to have no trouble reading from the memory after the headers were whacked. (In fact, the device actually re-wrote the headers on the fly somewhere along the line.)
posted by ChrisManley at 7:49 AM on May 26

May I ask why you wish to corrupt it rather than, say, wipe it?
posted by kalessin at 7:55 AM on May 26

Huh. I would suspect then that there is a backup boot record somewhere else on the card. Checking the FAT boot sector specs, it seems that the two bytes at hex offset 32 (or decimal offset 50) contain the sector number of the backup boot record. So, here is what I would try next: go to offset 50 from the start of the disk, and get the two bytes that are there. Convert those to from hex to decimal. Multiply that by 512, and then go to that byte offset on the card. See if the format matches that of the first sector. If so, zero 512 bytes there, then zero the first 512 bytes. That should get both the main and backup boot record.
posted by procrastination at 7:59 AM on May 26

Have a look at these links and see if you can divine any information from the SD specs.
posted by Mach5 at 7:59 AM on May 26

Update:

I tried a different card (a 2gb one) and zeroing the first sector seems to have put it into a corrupt state.

I'm still not sure why my other card was recovering so well when I did this.

@kalessin - I'm working on writing code to interact with a device and need to make sure it deals properly when it encounters a corrupted memory card. So, I'm trying to find a reliable way to corrupt a card for testing purposes.
posted by ChrisManley at 8:01 AM on May 26

I'm working on writing code to interact with a device and need to make sure it deals properly when it encounters a corrupted memory card. So, I'm trying to find a reliable way to corrupt a card for testing purposes.

You don't know what corrupt SD cards look like in the wild. Without that information anything you build will just deal with the cases that you generate.

The only information I've found are the things that might cause it - running on low batteries, unplugging during file copies and the like.

You should reproduce the situations that are likely to cause corruption, see what data get trashed, and then build your test cases based on that information.
posted by rdr at 8:19 AM on May 26

@rdr -

I agree it's not ideal. However, having at least a basic scenario that is easily re-producible is a good start.

Currently, any type of corruption causes various crashes in the code. Being able to debug this is going to be a big help.

However, going forward, we're going to have to look at specific cases of corruption - and see what we can do as far as data recovery and the like go.

As a first step, I'd like to see the application display reasonable error messages when it encounters a corrupt SD card.

Thus far, working with the hex editor and killing the headers as suggested by procrastination is working well. Just need to make sure any back-up headers get destroyed as well.
posted by ChrisManley at 8:38 AM on May 26

I don't mean to drag this out but I don't understand part of your problem.

Filesystems are supposed to present a consistent data store to a programmer. The logic for handling filesystems is part of whatever os you're using. Putting file system consistency checks, or even worse implementing some type of data recovery, in your application code seems odd. If you do this, then your code is going to keep growing until you basically duplicated the operating system logic for filesystem handling and recovery.

Have you considered doing a consistency check before you access data, perhaps by using a cut down version of fsck.msdos? You wouldn't have to check the entire filesystem. You'd just need to be sure that you could get to the data that you're going to be requesting. Once you've done a consistency check you'd know that any crashes you're seeing are not caused by corruption.
posted by rdr at 9:03 AM on May 26

back in highschool, we used to corrupt floppy disks by starting a format and then unplugging the machine. maybe something similar would work for you here?
posted by Oktober at 10:39 AM on May 26

Find a Linux/Unix/Mac box and:

dd if=/dev/random of=/dev/yourdevice bs=128k

Where yourdevice is the device name of the SD card (try running the mount command to find it)
posted by puddpunk at 1:58 PM on May 26

I corrupted a 1GB SD card by deleting all the files on it in my Windows computer, rather than formatting it in my camera, as I usually do. May work for you....
posted by Lynsey at 3:23 PM on May 26

Copy a big file to the card then physically remove it while the write is still happening?
posted by AmbroseChapel at 4:29 PM on May 26

puddpunk: You mean

dd if=/dev/urandom of=/dev/yourdevice bs=128k

And yes, this will give you a nicely corrupt card.
posted by Skorgu at 5:45 PM on May 26

I have to think that

shred -n 3 /dev/yourdevice

will also work.
posted by Caviar at 10:23 AM on May 27