Controlling the Wattcher Display

To measure the power consumption of my house I’m using a Wattcher. The Wattcher consists of two parts: A sender module and a Display. The communication between the two modules is wireless.

Currently I only use the sender, which I hooked up to a Raspberry Pi to get a much more accurate measurement and a historic log. So to keep in line with the whole sustainability concept of the Wattcher, I went looking for a way to reuse the display unit for a different purpose.

The Hardware

The main part of the Wattcher display is a 7-Segment display array that can display numbers between 0 and 10000. It also has a button to configure it and to request some calculated values.

Of course I wanted to know what was inside of the device so I tried opening it. This is rather hard because the two half’s are connected by pins that are glued. So my casing didn’t survive completely undamaged.

 

Inside there is a PIC microcontroller with a nRF905 RF module connected to it. The programming pin’s of the PIC are actually connected to some pad on which a connector can be soldered. Connecting my programmer showed that the chip is read protected.

The Communication

The easiest way to change the behaviour of the display would be to just reprogram the PIC microcontroller. But because the device is protected against reading the code memory, this would mean I will never be able to use the module in its original function again. So I looked for a less destructive approach.

The way the display is normally controlled is through RF, using the nRF905 chip. There are good data sheets available for the nRF905, and modules containing this chip can be bought very cheap on Ebay. So I decided to ordered some to play with.

The nRF905

After receiving the modules I hooked one up to my Raspberry PI and quickly found out that they where no good in controlling the Wattcher display. The Wattchers documentation states a carrier frequency of 868.4 MHz is used. However the modules I bought on Ebay have an antenna matching network that is specific to the 433 Mhz band. Luckily they weren’t completely useless. Because by having full control over one of these chips allowed me to write a frame receiver and decoder using software defined radio.

According to the Datasheet GFSK modulation with a +/- 50 kHz deviation. The bit rate is 100 Kbit/s. Using these parameters I made very simple GnuRadio project with just a GFSK demodulator in it that writes to file/FIFO. I thought this would be a bit to simplistic, but the output file actually showed signs of a manchester encoded signal.

Next I converted the output bit stream to a VCD file for analyse in GTKWave. The bit stream outputted by GnuRadio has only one bit per byte, while my VCD file generator expects 8-bit per byte. For this I wrote a extra tool to pack the input stream. A voila, through the magic of shell pipes, I had a VCD file.

Using GTKWave and the documentation, I was able to determine the frame structure that the nRF905 module uses. The frames have the following structure:

+----------+------------+-------------+------------+
| Preamble |   Address  |   Payload   |    CRC     |
| (10-bit) | (1-4 Byte) | (1-32 byte) | (0-2 byte) |
+----------+------------+-------------+------------+

Where:

• Preamble: The Preamble consist of a 10-bit value of 0x3f5. The preamble is also manchester encoded
• Address: The address of the target node(s). Depending on the configuration can be 1, 2, 3 or 4 bytes
• Payload: the payload data. Length depends on the configuration of the chip
• CRC: The CRC calculated over the Address and Payload fields. This can be 16-bit, 8-bit or absent depending on the configuration. The 16-bit CRC is a CRC16-CCITT with start value of 0xffff. The 8-bit CRC I haven’t analysed.

All bits, including the preamble, are Manchester encoded. There is no inter-frame gap. So if the auto-retransmit function is used you’ll end up with one long bit stream. Interesting thing is that there seams to be no bit stuffing used. So if there is a value of 0x3f5 somewhere in the address, payload or CRC fields, there is noway to distinguish this from the preamble.

With this information I wrote a little tool to decode the nRF905 frames from the output of the GFSK demodulator. The decoder automatically tries to detect the frame length and CRC settings in use. The source can be found here.

As it normally goes, only after having figured this all out, I found out that there was already someone who did the same. See http://www.embeddedrelated.com/showarticle/548.php.

Wattcher protocol

Using the nRF905 frame capturing I was able to analyse the protocol used by the Wattcher.

The Wattcher display and sender communicate in a Master-Slave fashion, where the display only sends a frame after receiving one from the sender. This is probably done because the sender is battery powered. Because the sender now only has to keep it’s receiver enabled for a very short time after having send a frame. The rest of the time it can completely power down the RF unit.

The Wattcher’s use the following nRF905 configuration:

Address Length	4
Payload length	16
CRC	16-bit
Address	0xaa61cc16
Sync/Pairing Address	0xc12cc21c

Normal mode

The payload of a packet send by the Wattcher sender contains the following information:

| 40 10 20 4a | aa 00 | ab | 00 | 00 75 96 | 00 0a | 00 00 00 |
|  Wattcher   |       |Vbat|    |  19-bit  | Disp. |          | 
| Virt. Addr. |       |    |    |  Counter | Value |          |

The nRF905 payload starts with a 32-bit ‘virtual’ address that couples a Sender module to a Display module. Then there are two fixed bytes. The 7th byte is a battery indicator, changing this causes a replace battery message to be displayed on the Wattcher display. Then there is a 19-bit counter which increases about 1’s per millisecond. It starts at 0 after sending a frame and is stopped when the sender receives a reply from the display unit. After this there is the value that will be displayed on the display.

When the display receives a frame from the sender it replies with the following message:

| 40 10 20 4a | a6 | 02 58 | 00 00 00 00 00 00 00 00 00 |
|  Wattcher   |    | Cval  |                            |
| Virt. Addr. |    |       |                            |

Again this starts with the Wattcher couple’s unique address. Apart from that the only useful information is the ‘C’ value as configured on the Display unit. The Sender uses this value to calculate the value to display from the amount of impulses registered by it’s sensor.

Sync mode

A Wattcher Display and a Sender are paired together by the 32-bit virtual address at the start of each frame. The Wattcher allows creating a new pairing by long pressing the red button on the Display and the Sender. When this is done the units will enter a sync mode.

In sync mode another nRF905 address, 0xc12cc21c, is used to distinguish the traffic from the normal traffic. Other than that nothing is changed to the nRF905 settings.

The sender will determine a new random virtual address for the pair. This is send in a frame with the following structure:

| c1 3a 11 4a | 1c | 00 00 00 00 00 00 00 00 00 00 00 |
|New Wattcher |    |                                  |
| Virt. Addr. |    |                                  |

The Display with answer with the following frame:

| c1 3a 11 4a | 2c | 00 00 00 00 00 00 00 00 00 00 00 |
|New Wattcher |    |                                  |
| Virt. Addr. |    |                                  |

Taking Over Control!

So now I can receive the traffic, but I wanted to control the Display unit!

As I mentioned above the nRF905 module I got from eBay was no good, because it’s matching network seemed to kill the RF signals in the 868 MHz band. I came to this conclusion because the Nordic nAN900-04 application note for the nRF905 describes a different matching network for the 868 MHz band then for the 433 MHz band.

A closer look at my module and the circuit diagrams of the application note showed that the matching network for the different bands only really differ in the values of the components. So I got the idea to just replace the components.

Although this does sound simple, it proved to be rather challenging. Mainly because: A) The components are rather small SMD component. and B) The values of the components are of such a small order that any parasitic capacitance introduced by bad soldering will have a relative large effect.

First attempt proved to be a failure. After sending one frame the sender would continue to oscillate until the module was completely powered down. Yeah, I’ve got a jamming device;).

The second attempt proved more successful. I’m now able to send working frames when using the module is ‘auto-retransmit’ mode for 10 Millisecond. That’s good enough for my purpose.

But even though I was able to send frames and receive them with my SDR setup. I wasn’t able to control the Wattcher display. This was caused by the nRF905 module being tuned at a offset of about 100 kHz of the requested frequency. When I started looking into replacing the crystal for a better one, I found that the C_l value of 12 pF specified in the reference design was actually very hard to get. I assumed that the makers of this cheap module would also have run into this problem and just used some common crystal. While using a crystal with another C_l, they apparently didn’t update the values of the C₁ and C₂ capacitors. This would explain the fixed tuning offset.

Guessing the C_l was actually the much more common value of 16 pF. I calculated, using the formula in the datasheet, that the capacitors should be 33 pF. And so I finally took over:

Doing Something Useful

Ok, now I can display a number… but what shall I do with this tremendous power. As it happens I was already playing around with a DHT22 Temperature/Humidity sensor. So I wrote some code to combine all of this on a Raspberry Pi. And now I have an exclusive, designer, temperature display!

The picture above shows my setup. Note the crappy soldered SMD components between the antenna and the nRF905, which is the replaced matching network

The source code of all tools I used is available on github: nrf905_stuff and generic radio stuff

Advertisement

Reversing Somfy RTS

Some time ago we got new motorized blinds at my office which are controlled by a small wireless remote control. This made me curious how these remotes actually work, and if I would be able to control the blinds from a PC.

In this post I’ll explain the process of reverse engineering the protocol. For a detailed explanation of the protocol it self see here.

Capturing the communication

The remotes are of the type Somfy Smoove Origin RTS. Some searching revealed that RTS stands for “Radio Technology Somfy” and is a proprietary system. It uses an OOK(/ASK) modulated signal on 433.42 Mhz.

This was very convenient since I already had a microcontroller with an Aurel RX-4M50RR30SF 433.92 Mhz OOK receiver attached laying around from an other project. Although the frequency’s don’t exactly match, the receiver is able to pick up the signal if the remote is within ~10 meters. The microcontroller, a Cypress EZ-USB FX2, was running a very simple program that samples the data output from the RF receiver every 35 us and forward it to my PC through USB.

With this setup I created traces of different button presses; 4 times ‘up’, 4 times ‘down’ and so on.

Analysing traces

The trace files are just a big bunch of 1’s and 0’s, not very readable. So I searched for a way to plot the traces.

I started of using GnuPlot. Although very cumbersome and time consuming, I was able to get some useful images out of it. Later I converted my trace files to VCD files and used GTKWave. GTKWave isn’t very user friendly either, but it works a lot better then GnuPlot, especially with longer traces.

The image below shows 4 traces of pressing the same button. The frames are clearly visible and it is pretty obvious that there is a preamble at the start of the frame.

GTKWave showing 4 traces of Somfy RTS frames

The next image is a close up of the data. One thing I noticed when looking at the differences between traces is that there is always one point where all traces change state, followed by a point where only some or none of the traces changes state. I highlighted this in the image below, red always changes, blue sometimes. This suggests that the actual data bits are encoded in the edge at the point where the signal always changes state. One obvious encoding that springs to mind when seeing this is Manchester encoding.

Close up of Somfy RTS data. On the red markers the signal level always changes, on the blue only sometimes

Payload Data

Now I knew how the data was modulated, framed and encoded I could actually analyse the frame payload data. As always when reverse engineering I started by making a list of data fields I would expect to be in the protocol and then started comparing the frames from the different traces.

This directly showed that pressing the same button multiple times resulted in different data. Suggesting that the protocol is not static, but uses some kind of rolling code/sequence number. Comparing the traces of two different buttons shows that the upper nibble of the second byte is probably the button code.

Looking at the bytes that change with every button press I noticed that some actually behave as counters that constantly increase by 1, but with some bits flipped. So I assumed that there was some sort of XOR based obfuscation going on. Using these counters I started XOR’ing nibbles together, till the counters increased as expected. This finally brought me at a point where I was able to predict the data multiple frames ahead of the current frame. But it wasn’t perfect.

Patents…

With all the information gathered so far I went back to Google and stumbled upon US Patent 8,189,620 B 2. Skimming through it I found an image of the frame structure I already determined. Hmmm… interesting! Reading further I found that this patent almost completely describes the RTS protocol. With this new information I was able to determine the obfuscation algorithm used.

An other interesting patent I found was US 7860481 B2. But that one doesn’t describe the payload data.

Taking over control!

Now I could decode the protocol I went on to write a program to actually send out my own frames. Given a captured address, rolling code and ‘encryption key’ I was indeed able to control the blinds. Victory!

To transmit I use a Aurel TX-SAW-MID 5v transmitter hand soldered on an experiment board. The antenna attached is a home-brew 1/4 lambda antenna with 4 radials. I was told this antenna design should sort of match the output impedance of the transmitter, although I’ve got no tools to test this.

With this setup I was able to control the blinds at about 5 meter distance, with a wall/coated window in between. This isn’t very impressive, although expectable given that I’m transmitting at 0.5 MHz above the centre frequency of the receiver. And all soldering and wiring is suboptimal. The actual range also depends on the blinds. One of them I wasn’t able to control at all, even when standing next to it.

One problem was that if I controlled the blinds with my program, the rolling code would advance. This caused the original remote to become out of sync. Luckily the blinds allow multiple remotes to be bound to it. This way I could create a virtual remote with my program with its own rolling code.

Security

When I started of I didn’t expect this to be secure in any way. The requirements on security probably aren’t very high for these systems, since some attacker controlling my blinds would just be very annoying. But it is actually better then I anticipated(as in just replaying a frame doesn’t work).

Obviously the ‘encryption’ doesn’t offer any protection. Even if the algorithm would have been strong, only 4 bits of the 8-bit ‘key’ actually change(in a predictable manner…). And the ‘key’ is send with the frame in the clear.

So what about the rolling code? Well it is 16-bit, so there is a chance of 1 out of 65535 that you guess the next value of the code. But if the receiver only accepted the next value of the rolling code as valid and the remote is out of range, one button press would mean that receiver and remote will be out of sync. To prevent this the receiver uses a window in which the rolling code must fall. This size of this window is somewhere in the order of ~100. So this would give a chance of 1 in 655 to guess a working rolling code, or not? Somfy actually did something clever here, because the receiver seems to shrink the window every time it receives an incorrect rolling code! So in worst case you still have to try 65535 codes.

An important thing to note is that the rolling code is sequential and starts at 0. So especially for new systems it is relatively easy to predict/calculate an approximation of the rolling code using the usage frequency + age of the system. Also the address isn’t a random number, but seems to be assigned sequentially. So given the age of the system, or the address of an other remote in the system you might be able to greatly reduce the address space to search.