The New Hotness

My DSC-F717 just crashed as I took a picture in the Basement Laboratory; it stalled while writing a picture to the memory stick. This camera is known to have problems with its ribbon cables and I’ve fixed it a few times before, but right now I have other things to do. Who knows? Maybe it’s a different problem altogether.

Thus, the pertinent question is how to grab the image files from the Memory Stick, even with a damaged filesystem. This trick will work with any memory device, so it’s not just a Memory Stick thing.

The camera crashed with the Memory Stick activity LED stuck on. Turning the camera off didn’t work: it jammed in the power-down sequence. So I poked the Reset button, which snapped the camera back to 1 January 2002, just after midnight. Alas, it now couldn’t read the Memory Stick, which meant either the filesystem is pooched or the camera’s card socket has gone bad again.

Mmm, do you know where your camera’s Reset button is? It might not even have one, in which case you just yank the battery. If you can yank the battery, that is.

Anyhow…

With the camera turned off: extract the memory card, poke it into a suitable USB card reader, and poke that into your PC (running Linux, of course).

If the filesystem isn’t too badly damaged, you’ll probably get a popup asking what to do with the new drive (the memory card). Dismiss that, as you don’t want anything writing to the memory without your explicit permission, which you won’t give.

Figure out which device corresponds to the card and which partition to use:

dmesg | tail
[29846.600524] sd 5:0:0:2: [sdd] 1947648 512-byte hardware sectors (997 MB)
[29846.606022] sd 5:0:0:2: [sdd] Write Protect is off
[29846.606030] sd 5:0:0:2: [sdd] Mode Sense: 23 00 00 00
[29846.606033] sd 5:0:0:2: [sdd] Assuming drive cache: write through
[29846.608748]  sdd: sdd1

In this case, the Memory Stick was intact enough to have a valid partition table, so it could be successfully mounted. However, you don’t want any attempt to write the data, just to keep a bad situation from getting worse. You do that by mounting the device read-only:

sudo mount -o ro /dev/sdd1 /mnt/part

You’ll need a suitable mount point; I created /mnt/part early on to hold manually mounted disk partitions.

The FAT filesystem seemed to point to valid files, but attempting to display them didn’t work. So unmount the device before proceding:

sudo umount /dev/sdd1

Switch to /tmp or anywhere you have enough elbow room for a few files the size of the memory card.

Run dd to make a bit-for-bit copy of the entire drive:

sudo dd if=/dev/sdd of=memstick.bin bs=1M

The bs=1M should dramatically speed up the transfer; the default is, IIRC, 512 bytes.

After this, everything you do uses memstick.bin, not the memory card itself. If you’re paranoid like me, you’ll make a copy of the file before you do anything hazardous. You could even make two copies directly from the memory card and compare them, which might be instructive.

To find your precious JPG images among the rubble, look for their magic Exif headers:

strings -t x memstick.bin | grep Exif
  68006 Exif
 258006 Exif
 680006 Exif
 848006 Exif
 a18006 Exif
 bf0006 Exif
 e00006 Exif
 fe8006 Exif
11e8006 Exif
1420006 Exif
... snippage ...

Because the strings search ignores the (presumably broken) FAT directory structure, you’ll find all the image files on the drive, whether or not they’ve been deleted, partially overwritten, or whatever. This is great for forensics and terrible if you’ve got something to hide. You have been warned.

The -t x parameter returns the string’s starting offset in hex, which you need to find the actual starting offset of the file: it’s 6 bytes lower! Your mileage may vary, so be prepared to fiddle around a bit.

You could write a bunch of code to parse the JPG header and extract exactly the number of bytes required, but this is no time for subtle gestures. I just yank out whatever the largest possible image file could be, because image-processing programs only process the valid stuff anyway. So, knowing that this camera produces images in the 2.4 MB range, this extracts the first image:

dd if=memstick.bin of=image.jpg bs=$((16#1000)) count=1K skip=$((16#68))

The $(( … )) notation evaluates the numeric expression within and the 16#… notation expresses a hexadecimal value.

Soooo, bs=$((16#1000)) says that the blocksize is 4096 bytes, which you can deduce from the fact that all the Exif headers start 6 bytes from a multiple of 0x1000. Again, your camera may do things differently, but the general notion should get you started.

If you’re fussy, you’ll note that the headers are actually on multiples of 0x8000 bytes, but using 0x1000 means you can read the high-order digits right off the strings dump. Why make things more complicated than necessary?

Given a 4K blocksize, count=1K extracts a 4MB chunk: 1024 blocks of 4096 bytes each. That’s larger than the largest possible image file from this camera; adjust it to suit whatever you expect to find. Don’t be stingy, OK?

The skip=$((16#68)) says to begin extracting data 0x68 blocks into memstick.bin. You read that value directly from the strings output, which is easy enough.

You could write a tidy Bash script to eat the strings values and spit out the corresponding file chunks. I had few enough images this time to just do it manually, which beats having to debug some code…

Good luck!