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
Best Answer
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.