Reverse engineering on BlocNotes

Reverse engineer Cubii elliptic bike BLE protocol

Wed, 13 Sep 2023 00:00:00 +0000

Introduction

I recently bought a Cubii under desk elliptical bike, I have two use cases for it:

Physiotherapy after a foot surgery
Help me to warm-up in my cold home office in the winter

Added bonus, doing light exercise. I definitely not find it as enjoyable as using a full size machine, or doing “real” sports, but this is just my preference and I am stuck at home with crutches anyway 😅

So my second hand model is a Cubii pro: no screen to display statistics, but with Bluetooth connectivity, which means that I had to install yet another proprietary app. I doubt usefulness of collecting those data but as it is BLE communications I wondered if it would be easy to reverse engineer the protocol by spying on the frames…
It appeared to be even easier to look into the Android application to find everything I need to dump the data into InfluxDB, and a fun weekend project.

Decompiling the Android application

I never decompiled any Android application but I knew that it was not hard, especially as Java is interpreted and not a compiled language. A quick search pointed me to Jadx, which did all the magic to extract the code from the Android APK to human readable Java files. Then it took only few minutes to get to the interesting code:

Calories conversion

From the class CubiiBleManager:

calories = this.this$0.getCalories(this.$revolutions, (latestCubiiNoLive == null || (cubiiResistance = latestCubiiNoLive.getCubiiResistance()) == null) ? 1 : cubiiResistance.intValue());
distance = this.this$0.getDistance(this.$revolutions);

public final double getCalories(int i, int i2) {
    // Oliv': i=revolutions, i2=resistance selector
    double d = 0.717d;
    switch (i2) {
        case 2:
            d = 0.733d;
            break;
        case 3:
            d = 0.767d;
            break;
        case 4:
            d = 0.833d;
            break;
        case 5:
            d = 0.9d;
            break;
        case 6:
            d = 1.033d;
            break;
        case 7:
            d = 1.267d;
            break;
        case 8:
            d = 1.483d;
            break;
    }
    return i * 0.03d * d;
}

public final double getDistance(int i) {
    // Oliv': i=revolutions
    return i * 1.93E-4d;
}

BLE UUID

From BLEConstants:

Name	UUID	BLE defined
RPM	00001731-2927-efef-cdab-eba0fe583711	No
Battery	00001732-2927-efef-cdab-eba0fe583711	No
Break position	00001733-2927-efef-cdab-eba0fe583711	No
Revolutions	00001734-2927-efef-cdab-eba0fe583711	No
Device info	0000180a-0000-1000-8000-00805f9b34fb	Yes
Software version	00002a28-0000-1000-8000-00805f9b34fb	Yes
Hardware version	00002a27-0000-1000-8000-00805f9b34fb	Yes
Cubii BLE service	00001730-2927-efef-cdab-eba0fe583711	No
Cubii motorized BLE service	6e400001-b5a3-f393-e0a9-e50e9ecadc24	No
Cubii + BLE service	6e400001-b5a3-f393-e0a9-e50e24dcca9e	No
Cubii+ OTA BLe service	0000fe59-0000-1000-8000-00805f9b34fb	Yes

Read BLE value from broadcast

From broadcastUpdate() in file BLEService:

GetIntValue() documentation, constant list here:

Type	Value
Float	52
Sfloat	50
Sint16	34
Sint32	36
Sint8	33
Uint16	18
Uint32	20
Uint8	17

Integer revolutions = bluetoothGattCharacteristic.getIntValue(18, 0);
Integer rpm = bluetoothGattCharacteristic.getIntValue((bluetoothGattCharacteristic.getProperties() & 1) == 0 ? 17 : 18, 0);
Integer battery = bluetoothGattCharacteristic.getIntValue((bluetoothGattCharacteristic.getProperties() & 1) == 0 ? 17 : 18, 0);
// Hardware revision
byte[] value = bluetoothGattCharacteristic.getValue();
// Software revision
byte[] value2 = bluetoothGattCharacteristic.getValue();

Read value from BLE service

From file BLEService:

    private final void readRPM() {
        BluetoothGatt bluetoothGatt = this.mBluetoothGatt;
        BluetoothGattService service = bluetoothGatt == null ? null : bluetoothGatt.getService(UUID.fromString(BLEConstants.CUBII_BLE_SERVICE));
        if (service == null) {
            Logger.INSTANCE.d(this.TAG, "Cubii service not found!");
            return;
        }
        BluetoothGattCharacteristic characteristic = service.getCharacteristic(BLEConstants.Companion.getRPM());
        if (characteristic == null) {
            Logger.INSTANCE.d(this.TAG, "Battery level not found!");
        } else {
            readCharacteristic(characteristic);
        }
    }

Easter egg

There is a small copy/paste typo in BLEService. If the RPM BLE service cannot be found the warning is about the battery :-)

    BluetoothGattCharacteristic characteristic = service.getCharacteristic(BLEConstants.Companion.getRPM());
    if (characteristic == null) {
        Logger.INSTANCE.d(this.TAG, "Battery level not found!");
    } else {
        readCharacteristic(characteristic);
    }

BLE connection mode

Cubii is using connected BLE mode, then either notify you with new data or accumulate them between two consecutive read operations.

Reading data and sending them to InfluxDB

Thanks to Python, the libraries Bleak (BLE) and InfluxDB it was fairly easy:

Connect to the device
Subscribe to notifications
Accumulate/average data for 15 seconds
Write them to InfluxDB
In case of disconnection, restart in 1.

Cubii is sending the data every 3 seconds but I am sending them only every 15 seconds to avoid extra disk space. It could easily be down sampled inside InfluxDB thanks to tasks but yeah, it was not really required in the beginning for the small amount of data, and all the actions are done in the Python code, easier to manager for such small project

Dashboard

As expected I have no real use of the data but it was fun, so I draw the data in Grafana:

Grafana dashboard with the collected data

Code

The Python script is hosted on Gitlab.

Tools

jadx: Decompile and transform Dex to Java
Apktool: Decompile/recompile APK
BLE assigned numbers

Reverse engineer a wireless temperature sensor - Rika pellet stove

Sun, 04 Dec 2022 00:00:00 +0000

I own a Rika Filo pellet stove, which I like, but it is on the expensive side of the market and the Wi-Fi module to remote control it was a no-go. This article describes the way I reverse-engineered the radio protocol.
As it is my sole heating system and winter is coming, I wanted a non invasive approach to avoid breaking anything, so I hooked up a logic analyzer to record the commands sent by the micro-controller to the radio chip, which helped me to learn the RF parameters + actual payload.

1. Hardware

The wireless temperature sensor is really simple:

Battery holder - with polarity inversion protection :-)
ATmega48 micro-controller
TI CC1101 radio transceiver
Temperature sensor in a SOT-23 package?

Fortunately, the ATmega is using a programming port called “ISP”, which shares the SPI port, and there is a nice 0.1" 2x3 header footprint on the PCB. I soldered the pin headers and easily used them to connect a logic analyzer, in order to spy the commands sent by the ATmega. The only missing signal was the chip select, which I found on a pull-up resistor between the batteries.

2. Understanding the SPI commands

I initially used LogicAnalyzer by El Dr. Gusman: a nice project based on Raspberry Pi Pico RP2040, which I recommend. Then I lent it to a friend so I finished with my work’s Saleae device.
As Dr. Gusman’s logic analyzer can export to Sigrok I wanted to use the integrated CC1101 decoder to figure out the commands sent by the device. It did not work, I tried to debug it, figured out that the bug was already fixed, compiled the latest Sigrok then… the decoder was not able to decode my frames for a reason I did not understood. I gave up and wrote a quick and dirty parser which, in the end, would have been a faster solution :).

Fill TX buffer and send data

3. Radio parameters

Decoding the SPI commands gave the following parameters:

Modulation: FSK
Manchester encoding: No
Forward Error Correction (FEC): No
Carrier frequency: 868.317 MHz
Frequency deviation: 19042 Hz
IF frequency: 304.687 kHz
Bandwidth: 203.125 kHz
Datarate: 115051 bauds
Sync mode: 30/32 bits
Preamble length: 32 bits
Sync word: 0x4904
Whitening: Yes (Seed: 0x01FF)
FSK header: implicit/fixed length, ie address and size are not added by the chip
CRC: Yes (16 bits. polynomial: XX, init: XXX)
Transmitted packet length: 5 bytes
Bit shift between preamble and sync word (not in SPI recording, I discovered it later…)

Despite the Sigrok CC1101 protocol analyzer issue, it was not that hard. I had everything I needed to simulate the Rika temperature sensor, so I took a Semtech LR1110 eval board I had laying on my desk, set the right parameters and the payload, flashed the eval board and… it did not work :(

4. Radio analysis

I doubled check each parameter, they where correct. What could be the issue then? Time to look at the FSK signal itself: I used an SDR stick with the wonderful Universal Radio Hacker software to record the transmitted payload and try to understand the issue.

4.1 Preamble

Small detail, the preamble was shifted by one because the TI chip is transmitting 0xAA, but the Semtech chip is transmitting 0x55. Fortunately, the LR1110 allows to select the number of bits of sync word to transmit, so I can added the missing ‘0’ bit before my sync word and set its length to 33 instead of 32.

4.2 What the…Whitening?

Now the difficult part: the preamble and the sync word are the same between both records, but not the payload and the CRC. It has to be a whitening issue! Both chips are using a PN9 algorithm, and I set in the Semtech chip the same init than TI is using: 0x01FF. What next? It took me a while to understand that the CC1101 starts the whitening on the most significant bit of each byte, while LR1110 starts the whitening on the least significant bit!

Whitening: Also called scrambling, is to avoid long series of the same bit. Alternate bits helps the receiver to avoid desynchronization as TX and RX clock do not perfectly match.

4.3 Wrapping-up

Knowing this I was able to implement the whitening in software, and this time, it worked! The pellet stove was receiving my packets :-)

Note: I also had to implement the CRC16 as the whitening is applied to it:

FSK payload, from Semtech SX126x datasheet

5 Payload analysis

5.1 Header

The payload is surprising, in FSK we explicit header can often see preamble | syncword | payload length | address | payload |. In our case, the DIP switch on the board allows to change the second byte, which corresponds to the address but the first byte is always 0x11, so it might actually be a custom Rika header…

=> header is one byte, 0x11

5.2 Address

The second byte is an address directly correlated to the first three DIP switches, 1 is the LSB, and 3 is the MSB:

| Switch #3 | Switch #2 | Switch #1 | Address value |
+ --------- + --------- + --------- + ------------- +
|    Off    |    Off    |    Off    |      0x00     |
|    ...    |    ...    |    ...    |       ...     |
|    On     |    On     |    Off    |      0x06     |
|    On     |    On     |    On     |      0x07     |

Note on switch #4: as written in the documentation it is selecting power output of 1 dBm (Off) or 10 dBm (On).

5.3 Battery

The last byte was more difficult to figure out and I must admit that I decided to not bother with it until I found Hublol’s github project when writing this article, who already did some reverse engineering. Even if the radio parameters are not fully described on Github he found that this byte was the battery. I do not plan to use it, but for the completeness of the reverse engineering I hooked my lab power supply and recorded the value transmitted when I swiped the voltage from 1.8 V to 3 V:

Graph - Sent value = f(supply voltage)

| Supply voltage (V) | Value sent | Trendline |
+ ------------------ + ---------- + --------- +
|         3.0        |     215    |    213    |
|         2.8        |     193    |    193    |
|         2.6        |     172    |    172    |
|         2.5        |     159    |    162    |
|         2.3        |     143    |    142    |
|         2.1        |     118    |    122    |
|         1.8        |      97    |     62    |

=> The function encoded_value = voltage_V * 100.02 - 87.556

5.4 Temperature

I eventually figured out that the temperature is encoded in the first two bytes, it is weird as I was not able to find a “usual” way to encode the temperature… I then swiped the values with steps of 256 and read the temperature displayed by the stove: the conversion is not linear!
As we usually heat around 19°C, I did a linear trendline between 15 and 22°C where I want the highest precision: the room never reached more than 22°C thanks to the stove, and the temperature accuracy below 15°C is not important as the stove need to heat at full power

Graph - temperature = f(sent value)

| Value | Displayed        |           Hublol         |         Trendline        |
|  Hex  | temperature (°C) | temperature (°C) | delta | temperature (°C) | delta |
+ ----- + ---------------- + ---------------- + ----- + ---------------- + ----- +
| 4080  |       2.0        |        -0.80     |  2.8  |         2.4      | -0.4  |
| 4500  |      10.2        |         8.20     |  2.0  |        10.2      |    0  |
| 4600  |      11.9        |        10.20     |  1.7  |        11.9      |    0  |
| 4700  |      13.7        |        12.20     |  1.5  |        13.7      |    0  |
| 4800  |      15.4        |        14.20     |  1.2  |        15.4      | -0.1  |
| 4900  |      17.2        |        16.20     |  1.0  |        17.2      |    0  |
| 4A00  |      18.8        |        18.20     |  0.6  |        18.9      | -0.1  |
| 4B00  |      20.5        |        20.20     |  0.3  |        20.7      | -0.1  |
| 4C00  |      22.4        |        22.20     |  0.2  |        22.4      |    0  |
| 4D00  |      24.0        |        24.20     | -0.2  |        24.1      | -0.1  |
| 4E00  |      25.6        |        26.20     | -0.6  |        25.9      | -0.3  |
| 4EAD  |      26.8        |        27.55     | -0.8  |        27.0      | -0.2  |

=> The function is encoded_value = temperature_celsius * 0.0068 - 109.91.

6. Code

The library to create the payload, as well as the whitening and CRC, is on available on Gitlab.

7. Conclusion

I am now able to replace Rika’s temperature sensor, so I will be able to create a “smart thermostat” and remotely control my stove to rise the temperature when I am returning from vacation, or prevent its start when the sun will heat the house in the next hour or so. Next step is to create a dedicated board to be able to control the remote from LoRaWAN.

I tested it against Rika pellet stove Filo and Sumo, but I am surprised that the temperature encoding differs so much from Hublol’s findings; he might have a more recent stove where they changed the electronics, I will ask him…