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

  • 1
    \$\begingroup\$ You may find more results searching for "SD emulator". \$\endgroup\$
    – Bort
    Mar 10, 2017 at 14:29
  • 1
    \$\begingroup\$ I smell a big XY problem here. You might want to elaborate on why you want to do that, what problem you are trying to solve. The fact that there is not much available so far should give a hint that it may not be the right solution for many problems. \$\endgroup\$
    – PlasmaHH
    Mar 10, 2017 at 14:30
  • 3
    \$\begingroup\$ Even if it's an XY problem, I think it's an interesting question/problem, I would like to see if someone can give any insights. The only problem I can foresee is if there are any critical timing issues. \$\endgroup\$
    – pipe
    Mar 10, 2017 at 14:37
  • 2
    \$\begingroup\$ You're overestimating the capabilities of an SD card. It doesn't understand or implement the FAT filing system any more than a hard disk drive does, that's the job of the device it's plugged into. It simply provides an array of storage blocks that the host does whatever it wants with. So it would be up to you to look at the data stream going to the card and figure out what is being written. Are you sure it's even FAT? The device would be perfectly entitled to format the card however it wanted. \$\endgroup\$
    – Finbarr
    Mar 10, 2017 at 17:36
  • 1
    \$\begingroup\$ If the device caches heavily then you may struggle to guess what order the device writes are meant to be serialised in. Most particularly if the FAT tables aren't written back until later. Is it the sort of machine that's likely to do that, or would it just write blocks without caching them? \$\endgroup\$
    – sh1
    Mar 10, 2017 at 17:52

3 Answers 3


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.

  • \$\begingroup\$ Superb answer with many considerations given. Thank you! Your first option; could you elaborate on that a bit more? What do you mean by a device that behaves like a microSD card, could this be a microcontroller emulating a fat32? What would I need the parallel process for? \$\endgroup\$
    – Zimano
    Mar 10, 2017 at 14:52
  • \$\begingroup\$ @Zimano: If all you want to do is emulate an SD card, you might as well just use an SD card. The normal reason for wanting to emulate one is to be able to have actions on the SD card also affect something else, so the "parallel process" would be the "something else". \$\endgroup\$
    – supercat
    Aug 31, 2017 at 15:17

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.


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.