Breaking the nooLite wireless light control

Hello!

In our previous article, we showed how our home automation controller works with NooLite system devices without using native USB dongles for transmitting and receiving a signal. To make this possible, we carried out reverse engineering of the NooLite protocol.
')
Actually, this article contains a description of the protocol and tells how we analyzed it.

Introduction

About the NooLite system on Habré a lot has been written before. The system consists of wireless consoles and executive devices that operate at a frequency of 433.92 MHz.

Communication in the system is one-way - the console sends data by radio, and the actuators receive and process it. There is no return channel, and consequently, there is neither acknowledgment of receipt of the message, nor control of the status of executive devices.

Special attention is given to the communication scheme of consoles and actuators in Noolite. In the system, each console has one or several addresses. These addresses are sewn into consoles during production and are different for each console. Each executive unit can be tied to one or several control panels (more precisely, addresses), while the unit stores in memory a list of allowed addresses from which control signals can be received.
The binding is carried out as follows: first, on the executive unit, it is necessary to press a special (single) button, after which the light bulb on the unit starts flashing rapidly, indicating that it has entered the programming mode. Then in the programming mode, again using a special button, you need to translate the remote control that you want to bind. After that, you need to click on any button on the remote that will send a special binding signal. The executive unit receives this signal, after which it is necessary to confirm its entry into the memory by another pressing of the programming button.
Uncoupling the console from the unit is done in a similar way.

The interesting thing about this scheme is that the unique identifiers in the system have not execution units, but consoles. Accordingly, the commands from the console have the form "I have a remote control with the address NNN, I send the command XXX". All blocks configured to “listen” to the given NNN address execute command XXX after receiving such a message.

Getting started

Of course, we started by dismantling Noolite consoles.

(before and after)

(various other photos of disassembled and assembled devices can be found in the above article )

What is visible inside?

Inside the board you can see three large touch pads that implement the touch buttons.
An antenna at 433MHz is drawn on the motherboard in the upper right quarter.
The big round thing on the left is a lithium battery. To her minus we soldered for convenience the wire.

The scheme on the right implements all the logic and the transmitting part. Microcircuit in the case with 8 legs - PIC12F microcontroller.
The button to the right of the microcontroller is visible, and even to the right is the entire analog part.

The analog part is a transmitter that transmits data in called OOK modulation. The transmitter is fully analog and assembled on discrete components. The carrier frequency at 433.92 MHz is set by the SAW resonator , which is indicated in the diagram by ZQ1.

Transmission scheme

In such devices, in the overwhelming majority of cases, the so-called OOK modulation is used . OOK stands for "on-off keyring", i.e. such a subtype of amplitude modulation, in which the modulation is actually carried out on-off transmitter. Thus, the presence of a signal at a certain time instant at a frequency of 433.92 MHz means a logical unit, and the absence means a logical zero.

As stated above, the radio transmitter circuit is very simple and completely analog. A digital signal (a sequence of zeros and ones that is sent on the radio) comes from the leg marked in red in the photo. Accordingly, the presence of voltage on the leg turns on the transmitter, the absence turns it off.

We remove the data

We decided not to take the data using a radio receiver, but simply by recording the signal from the digital output of the chip. This approach is noticeably simpler, since you can work directly with the digital signal and it is free from any kind of interference.

Remove the signal will be a logical analyzer. Roughly speaking, a logic analyzer is an oscilloscope that has a one-bit ADC, i.e. can distinguish only the presence and absence of voltage in the channel. Logic analyzers are used, oddly enough, to analyze digital signals.

In our work, we use a logical analyzer. Open Bench Logic Sniffer is an open project with open firmware and open software. It costs only $ 50 and has a decent capture speed of 50 million samples per second. The used client application OLS is written in java and cross-platform.

In principle, for the purposes of this article, much cheaper logic analyzers on the Cypress CY7C68013A chip (search by the keywords “saleae clone” or “usbee clone”), which cost the Chinese something like $ 7, would be suitable.


(Layout with the actual logical analyzer, arduinka and RFM69H radio module used in Wiren Board Smart Home )

Dumps

So, we brought the signal with the marked red legs to the first channel of the logic analyzer, connected the ground and set up a trigger in the analyzer client. This is what happened:


In the picture there is a package dump, which forwards the NooLite remote by radio when a button is pressed.
What can you say on this picture? Actually quite a lot:

The minimum length of ones and zeros is the same and is 500us. Data is transmitted at the physical level at a frequency of 2000 bit / s.

At the beginning of the transmission package, a large piece of a rectangular meander is visible. This is the so-called preamble, which helps the receiver to adjust the frequency of data transmission (bit rate) for a specific receiver. Both the receiver and the transmitter use the built-in RC generators to clock the microcontroller, so the “2000 baud” of the receiver and transmitter can differ by 10 percent.

After the pre-memory the data begins. The data follows a very recognizable Manchester coding pattern: in the code there are only pairs of long zero-long units and short zero-short units. “Long” sections with a constant level are exactly twice as long as short ones, i.e. represent two "physical" bits. There are no sequences of zeros or ones longer than 2 bits in the package.
Such a pattern is obtained if the source data is encoded as follows: transmit two bits, “01” for each unit and “10” for each zero. What is the Manchester code is described in detail in Wikipedia, but if very briefly, it is used for two things: firstly, it allows you to get rid of the constant component of the signal, and secondly, does not require the frequency of the receiver and transmitter, allowing you to restore the frequency from the received signal.

Another observation regarding data: in the packet, the same data block is transmitted twice. This is done apparently to reduce the chances of packet damage due to interference and interference (recall, Noolite does not confirm message delivery)


(two identical data packages, larger)

We digitize data

Unfortunately, in the software for the logic analyzer there are quite few possibilities for analyzing arbitrary protocols. We did not manage to make Manchester coding decoder work in it, so we will write our own.

To begin with, we export data in the form of csv. The time of each change of our signal will be recorded in the file.



(picture from wikipedia)

The decoding logic of the Manchester code is very simple: you can see that the long gap between the edges encodes a data bit that differs from the previous one. If the next data bit does not differ from the previous one, it will be encoded by two short intervals between the edges.

Analysis

Press different buttons on different consoles, write down what happens. In the process, we noticed that sending commands for dimming is done in an original way: when you start pressing the button, the remote sends one command (“start increasing brightness”), when released, sends another one (“finish increasing brightness”).

We collect statistics in the tablet:


Some help is given by the documentation on the original Noolite modules for the computer.

First, take the command codes from the documentation and try to find them in the bit stream. The command code is found in 4 bits, starting with the second. The code is written under the LSB scheme, i.e. the first significant digit backwards.

In addition to the command, two bytes of the address are easily distinguished (they remain unchanged for any commands of one console) and filled with zeros of the “argument”. At repeated sending of the same command between the two possible values, the value of the first bit and the last 8 bits changes.

All parcels have constant parity, i.e. The xor of all bits gives the same value. This behavior hints at having a checksum.

Check sum

The first idea was that parity is used as a checksum, which is written to the first bit of the parcel. This version was supported by the parity of the parcel that was preserved and that the first bit was set apart from the other bits in the packet.
However, attempts to figure out the value of the last byte did not lead to anything good.

The next idea, which turned out to be correct, was that the checksum is the last 8 bits. The first bit is used so that the receiver can distinguish two consecutive button presses from one (as we said, with one press, the package is repeated several times for reliability).

The first candidate for the checksum is of course the CRC . However, the CRC-8 algorithm generally has three 8-bit parameters, and the enumeration of a pair of frequently used combinations did not lead to success.

We send commands

It was decided to try to generate Noolite packets and check their “validity” with the help of an execution unit that flashes when receiving a valid packet.

To do this, we put a simple sketch for arduino, which was connected to the input of the analog part of the disassembled console but no olight.



Here we are simply issuing edicles and zeroes to the line using digitalWrite (). The duration of the pulses is adjustable delay.

After we checked that we can reproduce one of the recorded packets, and the noolight block takes it as its own, we began further experiments.

Checksum 2

As it was written above, it was necessary to understand the algorithm for generating the checksum.
The CRC algorithm has a good property that you can check: this checksum is linear in the arguments.



Thus, if you take two well-known packages, add them up bitwise (that is, make xor), then the resulting package will have the correct checksum!

Having chosen two suitable packages, we check this assumption and confirm that the check sum is linear in the arguments.

Checksum 3

Our next action was brutfors checksums. Using a binary search for a given sequence of bits, the checksum is selected in a few minutes. This is done in an obvious way: run the sketch, sorting the checksums from 1 to 128 and look at the receiver. If during the work of the sketch he blinked (received a valid package), then we know that the required checksum is somewhere from 1 to 128. And so on.

Now that we can determine the checksums of an arbitrary package, we can try to restore the function. Since CRC is linear in the arguments, then, knowing how the cheksum changes as each bit changes, you can restore the function.

To restore the function, it is necessary to select the checksums to the number of packets equal to the number of bits in the packet, i.e. to 29 packets.


This is done all slowly and had enough time to get bored. So, having passed more than half of the bits, we decided to quickly try to sort out the cheksumma offline.

Checksum 4

As stated above, the CRC has several input parameters: a polynomial (8-bit), an initial value (8-bit), a value that is added at the end (8-bit). In addition, 1 bit - sets whether the algorithm is inverted or not.

In addition to these parameters, it is possible to prepare bytes in different ways with which the CRC algorithm operates. In the noolite package, 29 bits, i.e. non-integer number of bytes. The question arises, how to form the first byte. In addition, each byte can be inverted when calculating the CRC. Moreover, theoretically, not only bits in a byte, but also bytes in pairs (words) can turn over.

Let's go through all this with brute force. For brute force, we used Python and the crcmod library.



Function found! This is the “crc8_maxim” scheme, the first 5 bits are first achieved with zeros to the left. Then all bytes are written to the LSB, i.e. roll over.

Subtotal

Now we know almost everything about the protocol and can generate arbitrary on, off, start brightness adjustment and end brightness adjustment commands with arbitrary address values, emulating arbitrary Noolite consoles.

This, however, is not quite enough. The fact is that among these commands there is no “set brightness to level X” command, which is very inconvenient when used with the smart home system. It is rather strange to control the brightness with the help of the delay between two commands, as it is done in conventional Noolite consoles.

At the same time, the documentation for the NooLite computer modules shows that such commands exist. For example, the documentation for the command with code 6 says " value = 6 - set the brightness specified in" Data Byte 0 ", set the brightness specified in Data Byte 0, 1, 2 ".
The natural contender for "Data Byte 0" is the penultimate byte in the packet, which in our experiments was always zero. However, attempts to send a command in which this non-zero byte was unsuccessful. Apparently, the format of the parcel when sending commands with arguments is different.

Extended Commands

To deal with the commands with arguments and put an end to the parsing of the Noolite protocol, you need native NooLite modules.

(I would immediately like to thank the thinking-home.ru store and the dima117 habrovich person for the promptly provided devices for this)

If you have a native module, you can send commands, for example, using this program .

In addition to the command to set the specified brightness, there are also commands that control the mode of switching the brightness and color of RGB blocks NooLite, as well as setting the value of color (RGB).

This time, we will intercept commands using the RFM69H packet radio, which is installed in Wiren Board Smart Home using our protocol parsing code .

What happened:



It can be seen that the last byte, which was zero in our experiments, is in fact the choice of format. We observed fmt = 0, except that values ​​of 1, 3 and 4 are possible.

Format 1 is used for the brightness setting command, with one byte with a brightness value added to the beginning of the packet.
Format 3 is used for the color setting command, 4 bytes are added to the beginning of the packet. The first three set the color components, the fourth is always zero, its value is unclear (apparently reserved).
Format 4 is used for mode switching commands. In this format, 4 bits of the argument are added to the beginning of the packet after the command. The entire packet is shifted to calculate the checksum, i.e. bytes are counted from the left border, the remaining bits are padded with zeros to a byte.

Total

Total, we completely understood how the Noolite protocol works. What can you say about the protocol:

1. Preamble and Manchester coding are used, this is good practice
2. Only 16 bits of the address are used. This is certainly better than 4-8 bits in very cheap Chinese radio sets, but still quite a bit. For example, new Chinese chips for radio controls have a code length of 21 bits. 16 bits are only 65,536 possible combinations, which allows you to sort them out pretty quickly. If you have a powerful transmitter and a good antenna, for example, you can start sending a command to turn off the light in a loop with all possible addresses. Such a thing will sort out all the addresses in a couple of hours and is guaranteed to turn off the light of all your neighbors. And since the connection is one-way, the number of neighbors by which you can turn off the light is limited only by the power of your transmitter.
3. The redundancy in the protocol is implemented by re-sending the packet and monitoring its integrity. Availability of integrity control is an absolute advantage of the protocol. On the other hand, redundant coding could be implemented in a more compact way, although in the case of the transmission of short packets by radio, this may not be an advantage
4. The protocol completely lacks any protection. In this case, it would be quite possible to use the code type KeeLoq - this is the code, which, roughly speaking, is based on the synchronization of the counters in the transmitter and the receiver, is used in car key rings. You can even implement something similar on hardware, which is now used in NooLite
5. A rather strange package structure is used. The choice of format (that is, including the length of the package) is encoded by the last byte of the packet. Thus, it is necessary to separate packages at the physical level. More logical (and often used) is the encoding of the packet length at the very beginning of this packet. It is also not very clear why the packet is not trimmed at the byte boundary. Quite a strange saving on three bits, given that as much as 8 bits are allocated for the format code.

Although this is not related to the protocol itself, we found the results of the opening of pocket radio consoles interesting:

PS

NooLite manufacturers are going to release the MT1132 module with a UART interface, which is intended for use with Arduino, etc. or in their own devices.

We heard rumors that it would be more adequate to cost than native USB charms .

Uncovered advertising

Actually, as you probably already understood, the NooLite protocol was analyzed in order to add support to Wiren Board Smart Home - our home automation controller with Linux on board and great opportunities for connecting peripherals, which, in particular, has a universal transceiver at 433MHz.

We send the order for the first batch to the plant this Wednesday, so we decided to extend the pre-order for three days until Tuesday, March 18, inclusive . You can buy a controller (shipping at the end of April - early May) in our store .