Geekly Articles each Day
📜 ⬆️ ⬇️

Manage SkyKettle Kettle from GNU / Linux

Introductory


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

Everything would be fine, but this technology 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 expose my favorite teapot outside is no joy.

The situation is strange. On the one hand Ready For Sky is in the consortium - allseenalliance, which, it seems, is some kind of open source. On the other hand, I have not seen a code fragment or a line of documentation for the protocol of my teapot. I suspect that inside something like a NORDIC SEMICONDUCTOR chip - and maybe you should read the dock on it.
')
Anyone who buys equipment with closed protocols commits violence against the future.

This article describes the first step in managing a teapot 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 are not taking your hands off the keyboard and put it to boil. Then go drink it. Before that - I had to look for a smartphone and clap my fingers at it - it's easier to walk to the teapot. Another advantage is access multiplexing - while you can only keep one smartphone connected to the kettle, and the results of the console query can be broadcasted in many places.

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


How to get exchange data

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

What is the exchange protocol

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

If we scan and query the teapot for primary services, we’ll get something like

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



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

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


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

So, how is the communication:
- the smartphone establishes a connection with the kettle
- reads, like me just now, the capabilities of a teapot.
- then initiates communication by writing down the handle 0x000c (of which the value 0x0100 appears to be when polled and not)
- then it sends commands to the teapot according to its own protocol (or maybe it is a protocol from NORDIC), and periodically polls its status - all this is on top of UART Service> ATT> BLE

How to manage it?

The question is naturally divided into hardware and software. It's not difficult with the first one - I bought the first dongle 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

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

It seemed to be a good thing - an open source tool, and you can see how it works - code.metager.de/source/xref/linux/bluetooth/bluez/attrib . But there is little confusion from the source code - it is not easily separated from bluez and glib. I was too lazy to finish off and collect it separately. And I would like to make some corrections. Gatttool has an inversion of abstraction — it hides a connection from the user in a “non-interactive” mode, and cannot be reasonably automated in an “interactive” one. Moreover, the documentation in blueZ is very bad.

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

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

So back to the communication protocol.

It is time to dive into the wilds.
First of all, to control the kettle you need to log in.
A smartphone for this selects the key and sends successively the parcels to the handle 0x000e and receives answers from the handle 0x000b

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


From this simple exchange it can be seen that the messages to the handle are numbered and the answers come with the same number - for ease of identification. Each exchange starts with 0x55 and ends with 0xAA (striped numbers). Usually the third byte of the response repeats the command number.

Now you need to walk to the kettle and press the "+" button on it for 10 seconds. Just as they did with the smartphone. In this case, the output will change to
SEND: 55:1e:ff: [8 ] :aa
RECV: 55:1e:ff: 01 :aa

Now it will always be with this request. Key remembered. What kind of team uses a smartphone after logging in?
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

There remains a mystery value of 4 and 5th bytes.
Boil and / or support

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 looks like this:
55: counter :05:[ ]:00: [ ] :00:aa

5, 7 request bytes are not clear to me - non-zero ones I did not see them
Power 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 of the bytes except the temperature I do not understand. Must be, probably, the gauge of emptiness of a teapot.
How to use it

- put yourself on GNU / Linux bluez and check that you have gatttool - it should be included.
- to find out the MAC of your kettle calling
bt-device -l
- download the script from the repository below
- execute one of the following commands (you may need to have rights to write to bluetooth)
(if not already done - authorize the app by pressing "+" on the kettle.)

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

- remember that only one device can control the teapot at any one time - if you have an active application on your smartphone running and active - nothing will work.

Problems remain

1. It is not clear when deauthorization occurs. Obviously not by reconnect. Possible by exhausting 255 meter requests.
2. The bash code is delayed and all sorts of races are possible. It's horrible. You must still gut gatttool and make a neat implementation.
3. Perhaps it is necessary to peel the teapot to understand what color of offal is it and what else can you do with it on BT? can alter and add something useful there?
4. I will author you all with a hard-coded key ... and then I can manage all your kettles if you are my neighbor. This is all too correct.
5. Unzip all the details of the protocol. Are there any vulnerabilities?

Where to get?


Well, the repository is raw - github.com/PimenovAlexander/r4s- bluetooth.
There are also dumps that can be viewed using wireshark
If you have other R4S devices you can try to break them too. If someone understands the Bluetooth pliz tell me where did this 0x000s handle come from.

Source: https://habr.com/ru/post/371965/

More articles:


All Articles