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