Eye-Fi Config Version 002

Infinitely more features!! Changes from 001:

• Automatically discover mount point (works in Linux, definitely needs portability)
  
• Actually list the log command-line option in the help

Download here

Tool Available for Download

I've uploaded an early version of my configuration tool so that others can play with it. It's available from my web site.

Please download any play with it and do not forget to report bugs back to me. At this stage, I'm sure there are plenty of them. I'm also happy to take patches if I'm missing features or you find behavior annoying.

Chris Davies' software is much more mature than mine, so I'll probably switch over to using his once he releases it. But, you can all at least play with my version for now.

Really sneaky card snooping

I just did something I thought was pretty neat. I was trying to validate that my approach of dumping the card log was OK. This is mostly because I get some gunk out of there sometimes, and it just doesn't look like completely correct data, like I'm missing something. It is hard to do an apples-to-apples comparison with the official software logs because the log on the card is constantly being written, and you can never fetch the exact same data twice.

So, I turned off all the file writing in my control application. Then, I started it up like normal and told it to do a log dump. It sat in its loop, waiting to get the control sequence that it never wrote back from the card. (Remember that the manager writes a number to a file, then expects to get that same number back when the command is done). It'll never get out of that loop, right? Well, no.

Simultaneously, I told the manager to dump the card's log. My software sat there and read the files along with the manager, but I let the manager do all the writing. My software walked along in lock step with the manager as it went about its business dumping the entire log. This let my software do the reading, but the official software do the writing (and its own reading).

What I ended up with was two virtually identical logs, except for the last byte, which my software truncated. I need to go fix that now.

Handling corrupt JPEGs

If you haven't it figured out, yet, I'm lazy. But, I've been taking my card out of the PC reader and putting it in my camera to take a picture every time I want to get the card to go onto the network. I decided to just create a JPEG on the card instead of actually taking pictures. The quickest way to do that was just to dd some random gunk into a JPEG like this:

    dd if=/dev/urandom of=/media/EYE-FI/dcim/100dchef/dsc_0000.jpg

That works, technically. The card even tries to upload it. But, the server gets a bit annoyed because, somehow, I guess random data isn't a valid JPEG very often. :)

[00:54] Starting to upload "/public/DCIM/100DCHEF/DSC_0000.JPG"...
[00:54] Server has 0 of 77312 bytes for DSC_0000.JPG.tar (file ID 779166).
[00:55] Uploaded 77312 bytes for DSC_0000.JPG.tar. Waiting for the response...
[00:55] Probing for listener at 10.6.0.60:59278.
[00:56] Returning from upload function with error 28.
[00:56] Starting to upload "/public/DCIM/100DCHEF/DSC_0000.JPG"...
...

It will apparently sit in that loop for quite a while. It did until I stopped it by deleting the picture. I bet the card does not quite have the resources to validate JPEGs itself, so it just uploads the raw files to the server. The server returns with that "error 28" and the persistent little card retries.

It might be nice to have a limit on these retries. But, I don't think it's quite that simple. You want the card to be persistent. Wireless isn't exactly a lossless transmission medium, and its bound to have problems uploading from time to time. It's a matter of figuring out when to retry and how much. It might be reasonable, though, to have some special handling of corrupt files. TCP should keep the files consistent during transmission, and I would imagine that most of the corrupt files that the server sees are also corrupt files on the card. There isn't much reason to keep trying to upload these.

Card Registration in WINE

I realized the other day that I'd left out a critical portion of the whole process: card registration. You still need the EyeFi-supplied software to register the card for the first time, or to add and remove online services. It might be nice in the future if EyeFi could make registering or adding and removing photo services a web-only procedure that didn't require running the manager software at all. I'm pretty sure the card doesn't actually get consulted when you change the web services, so this should be possible in theory.

I deleted my account, and recreated it. Interestingly, the software didn't to anything to the card when the account was deleted. That seems to indicate to me that all of the smarts about the card registration are on the EyeFi API server. The manager software doesn't do anything like tell the card when it is not registered any more. The card can figure that out on its own from the server.

This is supported by the fact that the very first thing the card does after it gets power or sees a new picture is do a DNS query for api.eye.fi, then POSTs some XML to it with its MAC address and a field called "cnonce" that looks like an MD5. These folks have looked into how this works in more detail.

I wouldn't mind getting my hands on another brand-new card to see exactly what the card's behavior is when it is fresh out of the box. I wasn't smart enough to trace it from the beginning.

Interesting EyeFi Articles

Here are a couple of articles about the EyeFi card from a security researcher's point of view. They're very interesting and do make a few good points about how the card functions and what a few of its limitations are. It definitely taught me a few things about how the card works.

They also make the point that the EyeFi developers "get it" when it comes to security. That's very high praise, and I'm very glad to hear that they've been so responsive.

Thanks for the links, Ben!