BLE Protocol Reverse Engineering

[nccchirag]

Inputs from @matthias-schulz

yee-rc detected as F8:24:41:C1:D1:1F (Yeelink) -67 dBm.
 

 │   Handles    │ Service > Characteristics │  Properties   │         Data         │
├──────────────┼───────────────────────────┼───────────────┼──────────────────────┤
│ 0001 -> 001a │ fe95                      │               │                      │
│ 0003         │     0001                  │ WRITE, NOTIFY │                      │
│ 0007         │     0002                  │ READ          │ 0000                 │
│ 000a         │     0004                  │ READ          │ O993yDåo8f04X        │
│ 000d         │     0005                  │ WRITE, NOTIFY │                      │
│ 0010         │     0007                  │ WRITE         │                      │
│ 0013         │     0010                  │ WRITE         │                      │
│ 0016         │     0013                  │ READ, WRITE   │ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ │
│ 0019         │     0014                  │ READ, WRITE   │ L8e"ëad<01cúýéû 

LL Data: 05 22 ea 7f 8e f9 d1 c2 e0 ab df 41 24 f8 bb 3d e9 b1 d9 16 42 08 06 00 43 00 00 00 d0 07 ff ff ff ff 1f 10
[i] Got CONNECT_REQ packet from c2:d1:f9:8e:7f:ea to f8:24:41:df:ab:e0
 |-- Access Address: 0xb1e93dbb
 |-- CRC Init value: 0x4216d9
 |-- Hop interval: 67
 |-- Hop increment: 16
 |-- Channel Map: 1fffffffff
 |-- Timeout: 20000 ms

LL Data: 13 09 08 e1 00 00 00 00 00 00 00
LL Data: 0b 09 09 01 00 00 00 00 00 00 00
LL Data: 06 10 0c 00 05 00 12 01 08 00 10 00 20 00 00 00 c8 00
LL Data: 0a 0c 08 00 04 00 11 06 01 00 1a 00 95 fe
LL Data: 13 0c 00 08 06 00 24 00 00 00 c8 00 08 00
LL Data: 1e 0a 06 00 05 00 13 01 02 00 00 00
LL Data: 12 0b 07 00 04 00 10 1b 00 ff ff 00 28
LL Data: 0a 09 05 00 04 00 01 10 1b 00 00
LL Data: 12 0d 09 00 04 00 06 01 00 ff ff 00 28 95 fe
LL Data: 0a 09 05 00 04 00 07 01 00 1a 00
LL Data: 12 0d 09 00 04 00 06 1b 00 ff ff 00 28 95 fe
LL Data: 0a 09 05 00 04 00 01 06 1b 00 0a
LL Data: 12 0b 07 00 04 00 08 01 00 1a 00 02 28
LL Data: 0a 09 05 00 04 00 01 08 01 00 00
LL Data: 12 0b 07 00 04 00 08 01 00 1a 00 03 28
LL Data: 06 1b 17 00 04 00 09 07 02 00 18 03 00 01 00 06 00 02 07 00 02 00 09 00 02 0a 00 04 00
LL Data: 1e 0b 07 00 04 00 08 0b 00 1a 00 03 28
LL Data: 06 1b 17 00 04 00 09 07 0c 00 18 0d 00 05 00 0f 00 08 10 00 07 00 12 00 08 13 00 10 00


LL Data: 05 22 08 e4 ad a2 ac c8 1f d1 c1 41 24 f8 60 58 ac 0b 72 86 a0 08 06 00 43 00 00 00 d0 07 ff ff ff ff 1f 10
[i] Got CONNECT_REQ packet from c8:ac:a2:ad:e4:08 to f8:24:41:c1:d1:1f
 |-- Access Address: 0x0bac5860
 |-- CRC Init value: 0xa08672
 |-- Hop interval: 67
 |-- Hop increment: 16
 |-- Channel Map: 1fffffffff
 |-- Timeout: 20000 ms

LL Data: 13 09 08 e1 00 00 00 00 00 00 00
LL Data: 0b 09 09 01 00 00 00 00 00 00 00
LL Data: 12 0b 07 00 04 00 10 01 00 ff ff 00 28
LL Data: 0a 0c 08 00 04 00 11 06 01 00 1a 00 95 fe
LL Data: 13 0c 00 08 06 00 24 00 00 00 c8 00 08 00
LL Data: 1e 0a 06 00 05 00 13 01 02 00 00 00
LL Data: 12 0b 07 00 04 00 10 1b 00 ff ff 00 28
LL Data: 0a 09 05 00 04 00 01 10 1b 00 00
LL Data: 12 0d 09 00 04 00 06 01 00 ff ff 00 28 95 fe
LL Data: 12 0d 09 00 04 00 06 1b 00 ff ff 00 28 95 fe
LL Data: 0a 09 05 00 04 00 01 06 1b 00 0a
LL Data: 12 0b 07 00 04 00 08 01 00 1a 00 02 28
LL Data: 0a 09 05 00 04 00 01 08 01 00 00
LL Data: 12 0b 07 00 04 00 08 01 00 1a 00 03 28
LL Data: 0a 1b 17 00 04 00 09 07 02 00 18 03 00 01 00 06 00 02 07 00 02 00 09 00 02 0a 00 04 00
LL Data: 12 0b 07 00 04 00 08 0b 00 1a 00 03 28
LL Data: 0a 1b 17 00 04 00 09 07 0c 00 18 0d 00 05 00 0f 00 08 10 00 07 00 12 00 08 13 00 10 00


LL Data: 05 22 40 9f ce 64 21 c3 a3 d5 c1 41 24 f8 12 8c e2 7b eb 6e 0f 08 06 00 43 00 00 00 d0 07 ff ff ff ff 1f 05
[i] Got CONNECT_REQ packet from c3:21:64:ce:9f:40 to f8:24:41:c1:d5:a3
 |-- Access Address: 0x7be28c12
 |-- CRC Init value: 0x0f6eeb
 |-- Hop interval: 67
 |-- Hop increment: 5
 |-- Channel Map: 1fffffffff
 |-- Timeout: 20000 ms

LL Data: 13 09 08 e1 00 00 00 00 00 00 00
LL Data: 0b 09 09 01 00 00 00 00 00 00 00
LL Data: 12 0b 07 00 04 00 10 01 00 ff ff 00 28
LL Data: 0a 0c 08 00 04 00 11 06 01 00 1a 00 95 fe
LL Data: 0a 09 05 00 04 00 01 10 1b 00 00
LL Data: 12 0d 09 00 04 00 06 01 00 ff ff 00 28 95 fe
LL Data: 0a 09 05 00 04 00 07 01 00 1a 00
LL Data: 12 0d 09 00 04 00 06 1b 00 ff ff 00 28 95 fe
LL Data: 0a 09 05 00 04 00 01 06 1b 00 0a
LL Data: 12 0b 07 00 04 00 08 01 00 1a 00 02 28
LL Data: 0a 09 05 00 04 00 01 08 01 00 00
LL Data: 0a 1b 17 00 04 00 09 07 02 00 18 03 00 01 00 06 00 02 07 00 02 00 09 00 02 0a 00 04 00
LL Data: 12 0b 07 00 04 00 08 0b 00 1a 00 03 28
LL Data: 0a 1b 17 00 04 00 09 07 0c 00 18 0d 00 05 00 0f 00 08 10 00 07 00 12 00 08 13 00 10 00
LL Data: 12 0b 07 00 04 00 08 14 00 1a 00 03 28
LL Data: 0a 14 10 00 04 00 09 07 15 00 0a 16 00 13 00 18 00 0a 19 00 14 00
LL Data: 12 09 05 00 04 00 04 04 00 05 00
LL Data: 0a 0e 0a 00 04 00 05 01 04 00 02 29 05 00 01 29
LL Data: 12 09 05 00 04 00 04 08 00 08 00
LL Data: 0a 0a 06 00 04 00 05 01 08 00 01 29
LL Data: 12 09 05 00 04 00 04 0b 00 0b 00
LL Data: 0a 0a 06 00 04 00 05 01 0b 00 01 29
LL Data: 0a 0a 06 00 04 00 05 01 0e 00 01 29
LL Data: 0a 0a 06 00 04 00 05 01 11 00 01 29
LL Data: 12 09 05 00 04 00 04 14 00 14 00
LL Data: 0a 0a 06 00 04 00 05 01 14 00 01 29
LL Data: 12 09 05 00 04 00 04 17 00 17 00
LL Data: 0a 0a 06 00 04 00 05 01 17 00 01 29
LL Data: 12 09 05 00 04 00 04 1a 00 1a 00
LL Data: 0a 0a 06 00 04 00 05 01 1a 00 01 29
LL Data: 12 0b 07 00 04 00 12 13 00 90 ca 85 de
LL Data: 0a 05 01 00 04 00 13
LL Data: 12 09 05 00 04 00 12 04 00 01 00
LL Data: 0a 05 01 00 04 00 13
LL Data: 12 13 0f 00 04 00 12 03 00 8c d1 cf 62 43 fb b1 d3 f8 2a f2 b9
LL Data: 1a 05 01 00 04 00 13
LL Data: 06 13 0f 00 04 00 1b 03 00 5e 6a 72 c9 52 b1 95 a9 2c 0f 1f 51
LL Data: 1e 0b 07 00 04 00 12 03 00 99 7b 30 c5
LL Data: 06 05 01 00 04 00 13
LL Data: 1e 07 03 00 04 00 0a 19 00
LL Data: 06 11 0d 00 04 00 0b 4c 0a 2a 21 a8 c9 4a 69 63 4c e7 31
LL Data: 1f 02 02 13

[nccchirag]

BLEScanner Connection Data

Custom Service
0000FE95-0000-1000-8000-00805F9B34FB
	Custom Characteristic
		UUID: 00000001-0000-1000-8000-00805F9B34FB
		Properties: WRITE,NOTIFY
		Write Type:WRITE REQUEST

		Descriptors:
		Client Characteristic Configuration
		UUID: 0x2902
		Notifications or indications disabled
		Characteristic User Description
		UUID: 0x2901
		token
	Custom Characteristic
		UUID: 00000002-0000-1000-8000-00805F9B34FB
		Properties: READ
		Value:
		Hex: 0x0000

		Descriptors:
		Characteristic User Description
		UUID: 0x2901
		productid
	Custom Characteristic
		UUID: 00000004-0000-1000-8000-00805F9B34FB
		Properties: READ
		Value:\ ?
		A *
		Hex: 0x5C0B1F0A410C2AB0394B

		Descriptors:
		Characteristic User Description
		UUID: 0x2901
		ver
	Custom Characteristic
		UUID: 00000005-0000-1000-8000-00805F9B34FB
		Properties: WRITE,NOTIFY
		Write Type:WRITE REQUEST

		Descriptors:
		Characteristic User Description
		UUID: 0x2901
		wificfg
	Custom Characteristic
		UUID: 00000007-0000-1000-8000-00805F9B34FB
		Properties: WRITE
		Write Type:WRITE REQUEST

		Descriptors:
		Characteristic User Description
		UUID: 0x2901
		eventrule
	Custom Characteristic
		UUID: 00000010-0000-1000-8000-00805F9B34FB
		Properties: WRITE
		Write Type:WRITE REQUEST

		Descriptors:
		Characteristic User Description
		UUID: 0x2901
		authentication
	Custom Characteristic
		UUID: 00000013-0000-1000-8000-00805F9B34FB
		Properties: READ,WRITE
		Write Type:WRITE REQUEST

		Descriptors:
		Characteristic User Description
		UUID: 0x2901
		sn
	Custom Characteristic
		UUID: 00000014-0000-1000-8000-00805F9B34FB
		Properties: READ,WRITE
		Write Type:WRITE REQUEST

		Descriptors:
		Characteristic User Description
		UUID: 0x2901
		beaconkey

[saeugetier]

When looking at the names of the services, the name "authentication" is noticeable. Hopefully the dimmer has not to be activated by using some cryptographic keys. Due to the fact that the device is very cheap, it might be a very weak authentication.

Maybe a look on other Xiaomi reverse engineering projects might help. I found a project about the Mijia temperature sensor. I'm not sure if this sensor has some authentication implemented: https://github.com/mspider65/Xiaomi-Mijia-Bluetooth-Temperature-and-Humidity-Sensor

But there is a demo project for the Mijia (from a chinese guy), which implements some authentication: https://github.com/MiEcosystem/mijia_ble

[nccchirag]

thank you @saeugetier for the assistance
yes, it seems authentication might be weak and the dimmer supports mi Home app so, mostly it would be implementing the same authentication as the one mentioned in the link you shared. Let me have a look

@0xabadc0fe 你能在这里协助吗？ 谢谢

[saeugetier]

I'm interested in the encoder as well. So I ordered a sample as well. The microcontroller might have an external flash which hides some secrets.

An interesting article about how to reverse BLE can be found here.
https://medium.com/@yogeshojha/i-hacked-xiaomi-miband-3-and-here-is-how-i-did-it-43d68c272391
Maybe the authentication process is the same as for the Mi Band 3. The IOT gadgets and the fitness tracker are developed by different teams, but with some luck it might be the same.

[nccchirag]

there isn't any external flash inside, just one BLE module (TLSR8267 controller). All those article have one thing in common which is, (Device) <----> (Mi Home App), hence one can snoop BLE packets using developer mode settings in an Android phone but with this dimmer/encoder the command is sent to ceiling light and not to the app hence snooping is difficult. Here's the link to the image that details how communication happens. I'm stuck as I don't have the ceiling light to verify the same.

The only way I can think getting around this is to emulate esp32 as a rotary encoder by advertising the same characteristics and inspect packets sent to it. Authentication happens just once when the dimmer is paired to the light. At this time all 3 devices are required - Mi Home App, Dimmer & Light
Check this operation demo. During the demo the phone Bluetooth seems Off (unless he has hide that icon from status bar, which is rare). The dimmer is enumerated in the app via the ceiling light (which has both BLE & Wifi), and I think the pairing process is complete before that

[nikko82]

I've been able to authenticate to the dimmer (I think) using a ESP32 and a ported version of the authentication logic from here: https://github.com/aprosvetova/xiaomi-kettle
The productId seems to be 950.
I'm stuck at what to do after authenticating. I've tried to write 0x92, 0xAB, 0x54, 0xFA to authCharacteristic, and writing 0x99, 0x7b, 0x30, 0xc5 instead which is what I can see from your log in the first post. I then read verCharacteristics (UUID 0004), or UUID 0014 which it seems like is read in the log. I've then tried to update the list of characteristics, but it doesn't change (maybe I need to run some command to update it?).

Could you post a log showing what happens after the authentication is done, with some commands going from the dimmer? If you could also upload the pcap-log that would be nice. (I suppose the log is from BtleJack?)

[nccchirag]

sorry @nikko82 I haven't been able to take out time for this, thank you very much for your input. will give it a shot when time permits. The previous logs were shared by @matthias-schulz so can't comment on it.

[nikko82]

I found out, thanks to https://github.com/drndos/mi-kettle-poc/blob/master/mi-kettle.py that the last thing that is send to authCharacteristic must be calculated with cipher(token, [0x92, 0xAB, 0x54, 0xFA]).

I've found the product key both by automating a brute force attack where I tried all keys until authentication was successful and also by reversing the cipher algorithm and brute forcing based on the data in the log from @matthias-schulz. Both ways gave the productId of 950.

Using that productId and the token i found from the response I was able to calculate the same authentication values that was sent by the lamp in the log. This makes me very confident that all the data I'm sending to the dimmer is correct. But still I can't figure out how to subscribe to commands from the dimmer.

[saeugetier]

@nikko82 sounds good. I wish you good luck. As soon as my device arrives, I will take a look, if i can help with reversing.

[nikko82]

@saeugetier do you have a micro:bit or any other equipment that you can use to sniff the traffic?

[saeugetier]

@nikko82 I think I have several devices which can be used for sniffing. But I don't have a Yeelight light. I only own the dimmer.

[saeugetier]

For your information: currently I'm working on an esp32 implementation of the dimmer knob. It is not fully working for now. But you can stay tuned:

https://github.com/saeugetier/LowPowerDimmerKnop

Reversing the protocoll doesn't seem easy. Building an own firmware seems to be the way with less effort. But the hardware has to be modified. The new implementation will use wifi and mqtt.

Current state: the rotary encoder and push button are evaluated via ULP. Next step is to remove all debug variables and write the wifi code. Very next step: enable OTA and wifi setting dialog via button on top.