Wednesday, October 12, 2016

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.

Sunday, August 28, 2016

[nugget] sudo on windows!

Hi Guys,

Today i'll give you a tiny tip that makes our lives on windows a little more comfortable.

When working with linux one have a fairly easy way of elevating his/her privileges, we have both sudo and su.
In windows, while running as an administrator on the computer, some privileged commands are inaccessible yet until we would confirm UAC (User Access Control). Furthermore, if we are using a command line tool, the command prompt usually doesn't even ask for it. It is up to us launching command prompt as an administrator.

Thus, I have devised a small little trick that I already use several years, making a "su" out of "cmd.exe"

  1. Copy system32\cmd.exe to the same folder
  2. Rename it to su.exe.
  3. Right click on su.exe -> Properties -> Compatibility -> "Run this program as an administrator"
That's it, you can now use su instead of right click, run as admin...

Now for sudo we'd just create a batch file in system32 called sudo.bat [I'm new to blogger, styling will come later]:


@echo off
su /c %*


now we can do, for example:
sudo notepad c:\windows\system32\drivers\etc\hosts

Have fun.

Saturday, August 6, 2016

Home automation concepts and CAN Bus Home automation

Edit: Since then, much has passed, cheap 802.11 chips and solutions (such as esp8266 or the esp32), cheaper products for mostly any use, both in wall and in the electrical panel. So information here is not up to date and not much relevant.
===========
I Recently started researching home automation options for personal use. And I found that, in general, you have basically 2 approaches in 2 categories when talking about standard relaying/lighting control which is usually most of the required endpoints.

Data transmission: I define this as the communication used by smart switches(I,E. just a simple sensor), to either a central smart hub or to a relay module (tasked with actually switching the load).
They can be roughly categorized into 2 groups:

  • Wired, technologies like C-BUS, KNX-TP, X10, HAPCAN(see below)
  • Wireless: Wifi 802.11 based smart plugs/switches, KNX-RF, Z-Wave, ZigBee
Most of the information above I found through wiki

Power transmission: I define this as the manner of which power (on off) is transmitted to the consumer (light switch):
  • Central: I.E. All of the smart consumer are routed into an electrical box and relay in the junction box carry voltage to the load.
  • Distributed: The relaying occurs in different places through the house, usually on the power outlet (such as most of the "Smart power outlet" of WiFi ones) or the existing wall switch (some of the Z-Wave wall switch and `in wall relays`).

Like with everything, there are advantages and disadvantages, for some reason I only see disatvantages in most of the :
  • Wireless WiFi band technologies 2.4Ghz (ZigBee also in that range) - In today's environment there sometimes of tens of WiFi network around us, which causes interference you should not necessarily dismiss.
    • WiFi specifically is an overkill for simple things like relay module or a simple sensor/switch.
  • Z-Wave is fairly good solution, but not all modules can be found in all authorized frequency ranges. That means you cannot use all modules anywhere, plus different frequency modules are not compatible, plus in some countries (like mine) the allowed frequency range is such that there are almost no modules to choose from, let alone central hubs (Like Vera for example)
  • KNX-TP Is proprietary and extending it / creating a custom module is basically, not possible..
  • X10 - I Have heard it has many reliability issues and if I recall well even read stories where a neighbor X10 device switched on a device in a person house. Security - this is basically a bus shared with your neighbors. I Dislike the idea.
  • C-BUS: Again, looks mostly proprietary and relatively low accessibility bus and closed system.
  • Ethernet - I do not want to mix my high speed network with the low speed. If this would be the choice, it would have to be separated with the home network.
    • Advantage: Existing PoE solution
    • Disadvantage, Cannot use Ethernet Bus topology. wires, again would be needed to route to a central location. Although Ethernet is actually a BUS, it is only possible with coaxial cable which then renders PoE not possible.
So what are the needs I see? First for the data transmission I wish for:
  • A low speed, reliable, tolerant and Collision-detectable bus with relatively cheaply and accessible hardware
  • Option to carry sensor/module power (somewhere from 5-24v) to the endpoints in order not to have a transformer in the module.
  • In so that I can implement less common controllers, TV control IR blaster, RGB led strip, alarm/motion sensors, etc.
One of the hardware wire protocols I'm familiarized with is CAN bus/protocol. If you don't know, CAN is a relatively simple, differential(I.E less affected by noise), 2 wire(no ground required) bus+protocol, usually transmitted over Twisted-Pair, used in every car made since the 80's.

CAN bus can be carried over a pair in CAT5/6 STP/UTP Cable, That leaves 3 more pairs that can be used to carry power GND and power voltage.
HAPCAN Is such an open solution, They've made everything open, including hardware schematics and software, Also, interacting with the bus is easy as connecting a CAN-enabled microcontroller to it. (Such as the Teensy 3.1/3.2, that has build-in can controller) or a CAN module to any microcontroller, Also PC's could be interfaced with CAN-USB adapters available for purchase.

This is an interesting project, I still have one issue with it, although different modules are decentralized, The switching and power transmission is done in the electrical box, this means that all High mains-supply voltage smart-consumer, should be wired independently to the electrical box. Which overheads in electrical box room and tens of meters of wiring.

BTW, Some of the above technologies also requires wiring mains back to electrical box for each 
KNX and ZigBee (sometimes, depends on the module).

What's in here?

In recent times I started researching things that are less trivial and are less documented and not a whole lot of people have interest in them and not always found online.
I Am information security researcher, sometimes, I am assigned to investigating peripheral interfaces of a device, that's where it gets interesting and physical (and logical) interfaces are needed in order to connect a testing equipment (a fuzzer if you would) to the tested interface.

I did however managed to get to some insights, and I thought it would be pity to not share this information (that is usually fairly simple).

In this blog I'll share things I'm working on, be it work related directly or just some interesting projects I'd like to discuss or other pieces of related information and things I see intresting.