SD Card slave controller emulation

As hackers, we sometimes need to intercept and fiddle various communications; Such as HTTP (using proxy) raw TCP (for example EchoMirage etc).

When auditing smart endpoints system for vulnerabilities, we need to take it to the next level. If this is testing actual hardware using some SPI MiTM or other example such as tools that enables USB Interception such as the FaceDancer or USBProxy.

Where I'm working I was lucky to use both FaceDancer and USBProxy to test USB implementation of an end system.
The tested device also had a native SD Card slot. When researching I found there is no such framework to test lower level implementation of SD Card controller/Driver or even for faults in the end application layer.

And thus became my conquest for implementing a

SD Card Slave Controller

Lets put a few things aside

• I know a bit about hardware but don't know anything about hardware design
• Don't have a clue about HDL/Verilog/VHDL
• Don't know if I'm going the right way or if it's going to work
• It will, however, be very interesting and I'd probably learn a TON in the process.

Why hardware

Typical SD Card controllers fires up the CLK in an SD bus at ~500kbps minimum. Hance, sampling rate should be at least 1Mbps; While also need to parse the protocol, which does requires more processing. I Even started implementing (bitbang-ing) the protocol on a 80Mhz Cortex M4F I had lying around. Well, Either I did something wrong or it is still too slow to parse the SD frames correctly.

But I know SD Card also support SPI, Why not to use available SPI-Slave?

It is true, All SD-Spec-Confirming SD cards should support SPI mode; BUT, The cards start up in native SD mode, 1 Data bit(citation needed). While we can choose to work with SPI mode if we are the READER, it is not us to decide that if we are the CARD, plus, since native SD is faster, and all cards should support it, my informed guess say that no high speed card reader actually put the SD into SPI mode. this also goes for other basic properties such as starting baudrate.

However, other features of the protocol (Supported maximum speed, number of data lines, etc) are negotiable with the reader.

Physical layer

Well, I have some access to skilled individuals who were able to set me up with 2 "platform" (basically, just wiring that I can connect to the proper equipment) to mess around with.

1. First, SD/Micro Card adapter are easily taken apart, then with some skill one can extract all pins to external headers
   <pic>
2. There are such micro sd card extension cables, again, with a skilled hand this could be made in to fully blown wiring to do a MiTM for the bus or sniffing via logic or other.

How will it blend?

So here are a couple of assumptions i'm using:

• Implementing only in software is probably hard, or, will require some really fast processor
• Thus at least some level of protocol implementation would be in hardware, In a similar fashion in which today's sd cards implement the bus protocol using a hardware core.
• So the most logical way is to implement something on a FPGA using HDL
• In the end there should be some kind of CPU, after some research, one of the possibilities of FPGA is the Xilinx seriues, Maybe the Papilio board.
• The Xilinx FPGA has a `Arduino-like` implementation on the FPGA (ZPUino),
• We can actually build our own cores and connect it to the arduino-ish proccessor!
• VERY COOL.
• How can we connect out core to the Wishbone bus (the on-chip periphial bus used by ZPUino)
• We have a Wishbone IP Core generator to connect our HDL core implementation to the wishbone bus; No need to implement wishbone - You supply this tool with a file describing the registers you wish expose to the wishbone bus as a slave device and the tool generates the adapter where on one side there are the standard wishbone signals; and on the other side you can connect the values of the adapter to your core.
• I Will be using Xilinx ISE & VHDL for all of this. And if everything turns out ok, I'll throw the ZPUino and use ZPUino's IDE (Arduino-Like environment)

I Already have some very-early implementation of the SD protocol wire (recive only); I'll shere it in the fallowing posts (Would probobly take some long time, I don't have much time to work on).
Meanwile You can have an initial:
Wishbone IP Core Generator
Definition file (*.wb)

peripheral {
 name = "SD Card Slave Controller";
 hdl_entity = "wishbone_sdcsc";
 description = "SD Card Slave Controller IP Core";
 c_prefix = "sdcsc";
 hdl_prefix = "sdcsc";
 prefix = "sdcsc";

 reg{
  name = "Status register";
  description = "status bits";
  prefix = "status";

  field{
   name = "CMD ready";
   prefix = "rdy";
   type = BIT;

   access_dev = WRITE_ONLY;
   access_bus = READ_ONLY;
  };
  field{
   name = "Overflow";
   prefix = "ovf";
   type = BIT;

   access_dev = WRITE_ONLY;
   access_bus = READ_ONLY;
  };
  field{
   name = "Sanity error";
   prefix = "snt";
   type = BIT;

   access_dev = WRITE_ONLY;
   access_bus = READ_ONLY;
  };
 };

 reg{
  name = "CMD Data Register L";
  description = "CMD Data Register L";
  prefix = "cmddatal";

  field{
   name = "CMD Data L";
   type = SLV;
   size = 32;
   -- From ip to wishbone
   access_dev = WRITE_ONLY;
   access_bus = READ_ONLY;
  };
 };
 reg{
  name = "CMD Data Register H";
  description = "CMD Data Register H";
  prefix = "cmddatah";

  field{
   name = "CMD Data H";
   type = SLV;
   size = 16;
   -- From ip to wishbone
   access_dev = WRITE_ONLY;
   access_bus = READ_ONLY;
  };
 };
}

Till next time.