Reverse engineering wireless water meter network - Part 1

Hello,

tl;dr - This is How I "hacked" - Identified, Isolated, demodulate, decode and analyzed a wireless water meter sensor network (Version 2 as mentioned here) that works on 4-fsk modulation with CC1120 (or similar) chip, using SDR, this series will include as much information as one could use to get ideas for his/her own projects :)

I Would try not to include information that is numerously available in other places, modulation, demod, how to identify signals and what are the different techniques, go to youtube/google for that, U don't need me :)

This posts would be divided to - I don't yet know how many parts, let's just start

BTW - Sorry for the image sizes, couldn't resize them without loosing quality 

Chapter 1 -  Circumstantial Background

DISCLOSURE: This chapter only presents the subject as I see it and reflect only, my totally biased opinion.

Local water companies in the past were part of the municipality water payments used to go directly though them and additional "water supplier" was redundant 

However, a while back some folks, that I can only guess wanted to increase cohesion and get some free meals, managed to pass a law setting up tens of privately-owned, locally-monopoly companies, in a very very small country to allocate, manage and sell the water to everyone under the national infrastructure.

As, expected the prices of water shoot up and this created a whole lot of jobs that there wasn't any need for them in the first place, with the bloated prices and now that's a whole pile of companies that needs to make money, some more, let's say "technological opportunities". Or in other words, how to get this money, from the hands of civilians or somehow-regulated company into the hands of private contractors.

One such methods is the use of an Automated Water Metering system, or AMR.

Why do I say this in this form? well:

• You can read the municipally RFQ (Michraz?) In there you could see that, usually they narrow the eligible companies very much, preserving the cartel in this area.
• You can see that they often argue at court trying really hard to get a piece of the pie for another one. Prevailing a contract in a certain municipality usually guarantees contracts for years ahead (see next bullet)
• The all use different, proprietary, custom technologies to implement their solutions. Switching between them, is a hassle, and not I said that, a 3rd party did...

Chapter 2 - The problem

AMR Solution means water suppliers can collect data in some periodic interval and can even provide them to the costumers. However, in my city, data is not exposed to the costumer by any reasonable means. Sure you can call the water company, wait in line and then beg to get your AMR reading. but that's not the way this should be in the 3rd millennium, especially, when the data is already existing and there, you just need to make it accessible.

So I can't get a recent updated meter reading. In addition the use of this system should help the provider identify leakages and thus they could Text the consumer - Although both the building and on my personal water meter I had a few of these, we never got any SMS as they say they would, the water just kept on flowing.

So,

Can we get our water meter readings without the help of the supplier?

Chapter 3 - Background & Method

Technical background

I Don't want to invest in this too much, you can read online, basically anything goes depending on the implementation. The goal is to get the reading from the meter to a central location, either every dT time, request response with static basesstations or even driving with a broadcasting/receiving antenna, 3g networks, LORA, BLE, whatever, I guess there are hundreds of different methods out there.

They are usually battery operated, and thus need to be low power, some might have a local: leakage detection algorithm, temper detection function, "halted meter" detection algorithm, low battery, etc. This data should also somehow needed to be transferred to the either basestation or central location.

Method

The idea is to catch these transmitting in-air and decoded them; Whenever the utility company gets the reading, I would get it too. Using some sort of an SDR with a raspberry pie setup hooked up to some antenna.

Chapter 4 - Getting techy: V1 Meters (older, 2FSK)

Okay so my local setup was as follows:

a bunch of a classical, "dumb" meters were connected with wires into some enclosed device nearby which had the manufacturer name stamped on it.

There is also some 5 digit id with a barcode on the device, which I guess is the transmitter id.

Recording

For those of you that already know all the tricks for RF hacking - Yes, there is and was a lot of material from the FCC on this kind of devices, although frequency band may change, overall architecture would probably not. But apparently, that's not enough these days.

The FCC Documentation stated that the transmitter can be triggered to send with a magnet, setting up my SDR with relatively low gain and being closely allowed my just to brute-force the range and see were I see a burst that corresponds with my magnet tap.

Demodulation

Following NCC Groups guide was very helpful, at first at least. This part was done long ago, so back then- Universal Radio Hacker Did not exist, yet. Trying out millions of ways to recover a clock from the signal was virtually impossible with my tiny understanding of DSP.

I Could not get any reasonable results, so I turned over to GNURadio mailing lists asking what I'm doing wrong. Andy Walls from the mailing list, helped me figure that one out, so demodulating FSK, TWICE, proved to get me the underlaying bits. they could later be sliced with Michel Ossman's Whole Packet Clock Recovery (WPCR) script

Decoding

I Have managed to get my hands on a MS-DOS Binary that is part of this solution, investing heavily in RE & IDA proved me that the decoding is not done in this binary maybe this is offloaded in some embedded hardware at the receiver side. But, it did proved helpful to find out more features that might be lurking in the transmission . For instance, each transmission has some kind of counter attached to it so the receiver could identify dropped frames,

With the bitstream in place - Trying to find the meter id or transmission number or the reading that is on the physical meter proved to be impossible. NRZ, RZ, Inverted non inverted, reversed, aligned to 8 bit 7.

Nothing. I couldn't find any meaning in the bitstream, although it did seem to have some pattern.

Working on multiple transmitters

Since this is a dense residential area, there were multiple of these units, each with it's own stamped-id, I thought I could get multiple recordings and check against the transmitter id. I still couldn't find any match between the ID and the recovered bits.

Eventually, I started to try and identify MANUALLY if changes in certain bits of the meter id changed somewhere in the bitstream, consistently. this was virtually impossible to do it by hand,

And then... It struct me...

Chapter 6 - Identifying data with excel spreadsheet

..."Wait just a moment, what am I trying to do?

- Well, I'm trying to find a CORROLATION between each of the bits of the known id, to anywhere in the bitstream.

- Hell, why shouldn't I do correlation with excel?"

I thought to myself

Well, you can,

just set up the known data with the unknown data side-by side 

I have removed the most valuable bits that are the same across all IDs (on the left) and the starting bits (I.E. 1st bit received by the receiver) that are the same across all captured data, as it would not produce any meaningful results.

PEARSON function allowed me to calculate correlation between different columns, each bit if the id(s) with each beat in the captured data(s), with some excel magic, we got a table with the correlation data.

Data with alternating hops 

There are some:

•  1s-Meaning where's a bit value with value X on the id, it correlates to bit value X on the capture. And
• -1s - Meaning where's a bit value with value X on the id, it correlates to bit value !X on the capture. 

After filtering from it, a pattern emerged, the transmitter id IS in the capture, in "bit hops" of 16 and 20 bits, alternating. This proved to be 100% reliable.

So there might be some shift register or some encoding that messes with the data, I've decided to call it a "field" and it should start with a bit number, and then hop according to this pattern.

I checked out the other fields, and one of them proved to contain the transmission counter :)

You can check out the script for that in this github-repo/ticket where I solved this guy's issues.

Part 1 Conclusion

It took A WHOLE LOT OF TIME AND EFFORT but this project was driving me crazy, I wanted desperately to solve it, and I eventually did, but until I've done so, and as mentioned on chapter 1 - They dont care pouring a whole lot of money, the meters were replaced by a newer generation

Well... Figuring this out would help me work out the new generation (This was the same vendor), right?

I Couldn't be more wrong...

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.

[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.

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`).

This guy explains gives a little bit of background on this

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.