Is it possible to spoof a microSD FAT32 filesystem?

Question

I have some hardware outputting data to a MicroSD. I can't control this process and instead of it outputting data to a MicroSD, I want some sort of spoofer I can insert into the MicroSD slot that allows the data sent to the microSD to be intercepted by, say, a microcontroller, who in turn saves it on its own microSD.

I have found this piece of hardware, which I feel is somewhat in the direction of the solution I'm looking for. The problem now is with spoofing the filesystem of MicroSD's so the hardware thinks it has a regular microSD inserted.

To what extent is this possible? It comes off as fairly straightforward to me, but I'm sure I haven't foreseen many issues. My idea is that I just hook up the breakout to pins on a Raspberry and get it over with. I'm pretty sure the hardware checks for a valid formatted storage first, but that's what the extra card slot is for. Effectively I'm duplicating the data this way.

I haven't found much information on the internet on this topic.

Similar question: https://stackoverflow.com/questions/13699203/sd-card-emulator

Answer 1

Attempting to fully emulate the behavior of a microSD card in a way that will work with all devices that might try to use it is apt to be difficult without some specialized circuitry and a lot of work. On the other hand, many devices which make use of microSD cards don't use all of their features, and communicate at a rate significantly below the maximum allowable rate for SD cards. Consequently, it may be possible to use a data analyzer to see which SD-card commands and features are actually used by the application of interest and focus on emulating those.

There are two approaches one might take to the task of capturing output:

• Have a device which behaves like a microSD card and allows arbitrary files to be stored upon it, and then have some parallel process which examines the contents of the card.

• Have a device which behaves like a microSD card which has a fixed pattern of data stored upon it in fixed places, and rely upon the fact that a particular device which tries to write data will do so in predictable fashion. I haven't seen this approach used for microSD, but openSDA uses it for USB mass storage devices, and I think the same principle could work with microSD. For example, if a device always writes a file by writing a directory entry with zero size, then writing to available clusters in numerical order, and finally writing the directory entry with an updated size, a device which sees a write to a directory entry followed by a write of some data clusters followed by another write to the directory could interpret that sequence of events as creating a file of the specified size holding the specified data.

If one couldn't afford much flash storage, the second approach could allow one to get by with less than the first, especially if one wanted to extract only some of the information that had been written to files. The first approach would require more mass storage, but the placement of new data on disk would vary according to the placement of previously-written data. By contrast, it's possible that the software which writes to the disk might behave absolutely consistently and predictably if the results of trying to read the disk never change. If the first directory entry always reads as blank, and the first 20 clusters always read as available, an attempt to write a file might always read the first directory entry, see that it's available, and use it, then check the availability of the first 20 clusters, see that they're available, and use them. If the firmware of the device you're interfacing with isn't likely to change, such behavior might simplify the task of capturing data from it.

Answer 2

I'm trying extract data from a hardware device that I have no control over, nor any other interfacing solutions, that's why I'm so limited in my options of getting data out of it.

Building this interceptor device (which may prove to be significant effort), you may be upset with the results you see.

• it is a big question if you will find more data than is being written to the card. Device may perform some swapping or intermediate data logging - will it help you in your main task?
• SD-card is actually a removable device, why not performing specific (required) actions on the main device and then analyze the results of its actions taking image of the card (e.g. using Disk Imager) and analyzing it?
• the SD-card emulation device you think to create will be slave device, it will not be able to give commands to the main device, thus it will give you no more control over the main device.

Thus while it sounds to be nice challenge, the usability of it is questionable, unless you are looking for something specific - if it is the case, share and we may be able to help/advise you further.

Answer 3

I will propose two dumb solutions, with the goal of making your life a lot simpler, by not having to implement a FAT emulator.

Solution 1: Let it write to a micro-SD card.

Insert a MUX in the signal lines which allows to connect the SD card to another micro. Once in a while, have the micro power down your device (or otherwise simulate a removal of SD card), then switch the MUX, take ownership of the signal lines, read the data back, and return control of the SD card to the logger.

If your logger has a predictable writing pattern (like once every minute) then you can probably sneak reads in between the writes.

Solution 2: ....Let it write to a micro-SD card.

Well, okay, a virtual one.

Grab a Linux SBC with an external port which can emulate a micro SD card, like a quad SPI or something.

Program this to respond to basic SD commands like read, write, etc. You now have a SD card emulator.

Redirect reads and writes to a file on the Linux SBC's filesystem, which will be an image of your virtual SD card.

And then... tada! Mount it. It contains a FAT image. You got linux. Mount it read only, and read the files.