BT785: Difference between revisions

From RevSpace
Jump to navigation Jump to search
Line 86: Line 86:
5f08353bf0ae6a7f231ee94df6100ce8
5f08353bf0ae6a7f231ee94df6100ce8
</pre>
</pre>
This can be decoded as follows:
* header says this is a block of 0x81 bytes, sequency number 0x40, with security flag 0x04
* determine iv = first 16 bytes after the header = 65db80c3df1cde3aebe8bf8ceee18b39
* calculate key = md5(first 6 bytes of local key) = md5("<z)o}E") = 64ba62ad750c312d08e10aa343769fbf
* decode remaining bytes using AES in CBC mode with the iv and key just determined

Revision as of 11:35, 12 October 2025

Project BT785
Connecting a BT785 EC meter to raspberry pi
Status In progress
Contact bertrik
Last Update 2025-10-12

Introduction

This page is about reverse engineering the BT-785, an inexpensive Tuya-compatible water electrical conductivity (EC) meter. It measures EC and temperature, and has a display and communicates its reading over Bluetooth Low-Energy (BLE) to the Tuya app on a phone. The goal is to understand the communication protocol so we can communicate with it from the raspberry pi in the Karaburan project.

Analysis

BLE characteristics in NRF-connect

On the lowest level, it uses bluetooth low-level with the GATT profile on the right:

Most important seem two characteristics:

  • 00000002-0000-1001-8001-00805f9b07d0: module to phone, notifies of data from the EC meter
  • 00000001-0000-1001-8001-00805f9b07d0: phone to module, we write data to the EC meter

The device connects to the Tuya app on a phone. Data transfer is encrypted.

While the tuya app is running, we can see notifications coming in, for example:

00 31 46 05 36 46 B1 F5 36 55 B2 56 34 E1 B3 C9
13 33 0A D9 17 E8 FE 4F 5C 9A 70 CE DB 26 A6 17
22 CC DF 65 7D F7 0D 01 02 0A 33 45 B0 C1 A5 A8
42 F5 C1 B2

Composition of the data:

  • 0x31 is the length of the data
  • 0x46 probably some sequence number
  • 0x05 the "security flag" indicating the type of encryption
  • 36 46 B1 F5 36 55 B2 56 34 E1 B3 C9 13 33 0A D9: 16 bytes of initial vector
  • rest: encrypted data, padded to 16 bytes unit

Another example:

00-31-40-05-8A-8B-20-8F-95-46-06-C0-CF-B2-9C-98
45-F8-E5-0F-8F-43-86-79-CA-1A-11-4B-30-F5-CB-1C
3F-93-3C-41-CE-27-DD-23-82-8A-2A-95-AE-71-4E-BF
DC-50-F2-32

HCI snoop log

...

Protocol

The protocol has the following steps:

  • Pairing: Initially, when the EC meter is paired with the Tuya app, a key is generated. This key is stored inside the meter and stored in the app. You can register with the Tuya developer console, link your device to the console, and fetch this key. Example key: '<z)o}Ezmuw01.TxQ'. Let's call this the 'local key'.
  • Session start When the EC meter is powered on and communication starts, the session is started by the host sending a 'device info request'. The response contains a session key. This exchange is secured using part of the 'local key' (only 6 bytes!?).
  • Measurement, the device sends measurements as encrypted notifications.

The encrypted frames typically do no fit in basic GATT frames. A GATT notification can typically hold only about 23 bytes of data.

An encrypted frame contains of a 5-byte header, a 16-byte IV, so basically no room left for the actual data.

I see in the app-device communication that the MTU is increased before session start:

BLE MTU negotiation

Pairing

I plan to not investigate this, just let the device and the app figure this out, then fetch the local key from the API

Session start

The very first step is probably upping the MTU, since by default GATT only allows very small blocks of data to be exchanged.

The phone sends a device info request: Encrypted, this looks like

...

The device responds with:

0081014004
65db80c3df1cde3aebe8bf8ceee18b39
f2be5ee93a59f09e0c65af2963440497
394317d56482a56e2ed32d05c727585b
980b73b3266e782acb9a7705233c5807
444cacccef3daa3e1eec12c271069a42
9ed448d8312d33212f0a886abaa5cecb
ed8ca761eea1daaef97cd5fc9033fb09
5f08353bf0ae6a7f231ee94df6100ce8

This can be decoded as follows:

  • header says this is a block of 0x81 bytes, sequency number 0x40, with security flag 0x04
  • determine iv = first 16 bytes after the header = 65db80c3df1cde3aebe8bf8ceee18b39
  • calculate key = md5(first 6 bytes of local key) = md5("<z)o}E") = 64ba62ad750c312d08e10aa343769fbf
  • decode remaining bytes using AES in CBC mode with the iv and key just determined