March 18, 2016 at 21:44

Managing a SkyKettle Kettle from GNU / Linux

Introductory


Quite a lot even at Giktimes advertise the equipment of the company Redmond which supports R4S technology - Ready For Sky.

Everything would be fine, but this technique is controlled via Bluetooth from a smartphone. And no more. There is, they say, an option with some kind of gateway and control from the cloud ... but to put my favorite kettle out is no joy.

The situation is strange. On the one hand, Ready For Sky is a consortium - an allseenalliance, which, it seems, is some kind of open-source. On the other hand, I did not see a piece of code or a line of documentation for the protocol of my teapot. I suspect that inside is something like a NORDIC SEMICONDUCTOR chip - and perhaps you need to read the dock on it.

Anyone who buys appliances with closed protocols commits violence against the future.

This article describes the first step in controlling a kettle in GNU / Linux - the ability to turn it on and off from the console (with reservations). This is important because if you want tea, you do not take your hands off the keyboard and set it to boil. Then go drink it. Before that - you had to look for a smartphone and put fingers on it - it’s easier to get to the kettle. Another plus is access multiplexing - so far you can keep only one smartphone connected to the kettle, and the results of the console request can be broadcast to many places.

I think everyone can expand this approach to a small web application.


How to get exchange data

Starting from Android 4.4, it seems that the option - Settings-> Developer Options-> Enable Bluetooth HCI snoop log has appeared in the development menu (By default, the development menu is hidden). When this option is enabled, all phone communication via Bluetooth is logged into the btsnoop_hci.log file (the file name in the phone’s memory may differ depending on the settings). Further, this log can be copied to a PC and analyzed there using wireshark. He conveniently and accurately shows the entire exchange, opening and unpacking packages.
The scenario, therefore, is trivial - we work with the teapot from a standard application, save the log, and analyze it. The next task is to repeat the exchange of their funds, posing as a telephone.

What is an exchange protocol?

I'm not a big Bluetooth specialist, but Bluetooth Low Energy devices have several protocols on top of the actual connection - one of them is the GATT / BT ATT protocol - en.wikipedia.org/wiki/List_of_Bluetooth_protocols#Low_Energy_Attribute_Protocol_.28ATT.29 , which in turn is add-on on top of the L2CAP protocol. It is on BT ATT that the kettle and smartphone communicate.

If you scan and interview the kettle for primary services, we get something like

     gatttool -b E7:5A:53:79:82:A4 -t random --primary

  • attr handle = 0x0001, end grp handle = 0x0007 uuid: 00001800-0000-1000-8000-00805f9b34fb Generic Access
  • attr handle = 0x0008, end grp handle = 0x0008 uuid: 00001801-0000-1000-8000-00805f9b34fb Generic Attribute
  • attr handle = 0x0009, end grp handle = 0xffff uuid: 6e400001-b5a3-f393-e0a9-e50e24dcca9e UART Service


It is through the last service that communication will be conducted.
Now you can see all the detailed features -

    gatttool -b E7:5A:53:79:82:A4 -t random --characteristics

  • handle = 0x0002, char properties = 0x0a, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb read write
  • handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb read
  • handle = 0x0006, char properties = 0x02, char value handle = 0x0007, uuid = 00002a04-0000-1000-8000-00805f9b34fb read
  • handle = 0x000a, char properties = 0x10, char value handle = 0x000b, uuid = 6e400003-b5a3-f393-e0a9-e50e24dcca9e notify read
  • handle = 0x000d, char properties = 0x0c, char value handle = 0x000e, uuid = 6e400002-b5a3-f393-e0a9-e50e24dcca9e write

I am somewhat confused by the absence in the enumeration handle 0x000c, which is used in communication. Anyway.

So, how is the communication going:
- the smartphone establishes a connection with the kettle
- reads, like I just did, the possibilities of the kettle.
- then initiates communication, writing down 0x0100 using handle 0x000c (which, as if during the polling, is absent)
- then sends the teapot commands using their own protocol (or maybe it is a protocol from NORDIC), and periodically polls its status - all this on top of UART Service> ATT > BLE

How to manage it?

The question is naturally divided into hardware and software. Everything is not complicated with the first one - I bought the first dongle I got on ALI and it earned - ru.aliexpress.com/item/Bluetooth-4-0-Dongles-Mini-USB-2-0-3-0-Bluetooth-Dongle-Adapters -Dual-Mode-adapter / 32292553074.html

The software part is much more complicated. Actually under GNU / Linux we have no choice - BlueZ. And there are problems with that.
If I understand correctly, a typical way to work with BlueZ is through DBUS. C / C ++ / Phyton bindings seem to be there, but not for the BT ATT protocol. But for him there is a gatttool command-line tool.

It would seem that this is good - an open source tool, and you can see how it works - code.metager.de/source/xref/linux/bluetooth/bluez/attrib. But the source code is of little use - it does not easily separate from bluez and glib. To finish and collect it separately I was too lazy. And I would like to introduce some corrections. Gatttool has an inversion of abstraction - it hides the establishment of a connection in the "non-interactive" mode from the user, and cannot be reasonably automated in the "interactive" mode. Moreover, with the documentation in blueZ, everything is very bad.

The kettle breaks the connection very quickly - within a second. And the protocol requires immediately after reconnection to send 0x0100 to the 0x000e handle - so we have two choices -
1. Try to wrap the gatttool interactive mode and access it - working in the background via bash or python.
2. Send 0x0100 to the 0x000e handle always. In the hope that it includes something inside, and this something will not turn on again once again.

I did not master the first approach, although I tried very hard, the fact is that gatttool does not use pure stdout, but the GNU Readline Library for output, and the wrapper task was as complex as the reassembly task. Because he went the second way.

So back to the communication protocol.

It is time to dive into the wilds.
The first step is to log in to control the kettle.
For this, the smartphone selects the key and sends consecutively sends to the 0x000e handle and receives responses from the 0x000b handle. From this simple exchange it can be seen that the messages on the handle are numbered and the responses come with the same number - for easy identification. Each exchange starts at 0x55 and ends at 0xAA (striped numbers). Usually the 3rd byte of the response repeats the command number. Now you need to go to the teapot and press the + button on it for 10 seconds. Just as they did with a smartphone. In this case, the output will change to Now it will always be this way. The key is remembered. What kind of team uses a smartphone after authorization?

SEND 55:00:ff: [8 байт ключа] :aa
RECV: 55:00:ff:00:aa
SEND 55:01:ff: [8 байт ключа] :aa
RECV: 55:01:ff:00:aa
SEND 55:02:ff: [8 байт ключа] :aa
RECV: 55:02:ff:00:aa





SEND: 55:1e:ff: [8 байт ключа] :aa
RECV: 55:1e:ff:01:aa


Sending immediately after switching on - the meaning is not clear until the end

SEND: 55: counter :01:aa
RECV: 55: counter :01:02:06:aa

Here the value of 4 and 5th bytes remains a mystery.
Boil and / or maintain

SEND: 55: counter :05:00:00:28:00:aa
SEND: 55: counter :05:00:00:00:00:aa - просто включить чайник.
SEND: 55: counter :05:01:00:5f:00:aa
RECV: 55: counter :05:01:aa // 01 status meens OK

The format is apparently this: So far 5, 7 bytes of the request are not clear to me - I did not see them non-zero
55: counter :05:[надо ли поддерживать]:00: [температура поддержания] :00:aa


Off

SEND: 55: counter :04:aa
RECV: 55: counter :04:01:aa // 01 status meens OK

Request Status

SEND: 55: counter :06:aa
RECV: 55: counter :06:00:00:00:00:00:0c:00:00:00:00:51:00:00:00:00:00:aa - kettle is on in boiling
RECV: 55: counter :06:00:00:28:00:00:0c:00:01:02:00:33:00:00:00:00:00:aa - kettle is on
RECV: 55: counter :06:00:00:00:00:00:0c:00:00:00:00:3e:00:00:00:00:00:aa - kettle is off
RECV: 55: counter :06 00 00 28 00 00 0c 00 01 00 00 64 00 00 00 00 00 aa
RECV: 55: counter :06 01 00 28 00 00 0c 00 01 02 00 64 00 00 00 00 00 aa - kettle finished boiling
RECV: 55: counter :06 01 00 28 00 00 0c 00 01 02 00 63 00 00 00 00 00 aa - a while after finished boiling

общий вид:
55: counter :06: keep warm? :00: keepwarm temp? :00:00:0c:00:01: heater? :00: temp :00:00:00:00:00:aa

heater - нет полной уверенности, но состояние где-то в районе 10-12ого байтов.
- 0x00 - off
- 0x02 - on
temp
- градусы Цельсия текущей температуры (в чайнике)
keepwarm temp
- градусы Цельсия температуры, которую надо поддерживать

Most bytes except the temperature are not yet clear to me. It should probably be a kettle emptiness sensor.
How to use it

- install bluez on your GNU / Linux system and check that you have gatttool - it should go bundled.
- find out the MAC of your teapot by calling
bt-device -l
- download the script from the repository below
- run one of the following commands (maybe you need to have rights to write in bluetooth)
(if not done yet, authorize the application by clicking "+" on the teapot.)

. /connect.sh [KETTLE MAC] auth - just waiting for authorization
./connect.sh [KETTLE MAC] query - request status in a loop
./connect.sh [KETTLE MAC] queryone - request status once
./connect.sh [KETTLE MAC] keeptemp - enable in the mode - boil and maintain
./connect.sh [KETTLE MAC] on - enable
./connect.sh [KETTLE MAC] off - disable

- Remember that only one device can control the kettle at any given time - if you have an application running on your smartphone that is active, nothing will work.

Problems remain

1. It is not clear when deauthorization occurs. Obviously not for reconnect. Perhaps the exhaustion of 255 counter requests.
2. The code on bash is tied to delays and all sorts of races are possible. This is terrible. One must still gut gatttool and make a neat implementation.
3. Perhaps you need to dismantle the kettle to understand what color offal is and what else you can do with it on BT? can alter and add something useful there?
4. I will authorize you all with a hard-coded key ... and then I can manage all your dummies if you are my neighbor. All this also needs to be fixed.
5. Scrap out all the details of the protocol. Are there any vulnerabilities?

Where to get it?


Well, the raw repository - github.com/PimenovAlexander/r4s-bluetooth .
There are dumps that can be viewed using wireshark.
If you have other R4S devices, you can try to break them as well. If someone understands in Bluetooth, tell me where this 0x000s handle came from.
Tags:

Also popular now: