【ESPHome】ESP32 DIY通用蓝牙网关，接入米家系门锁等各种设备

XCray

ruan_yhang 发表于 2021-5-29 19:01
蓝牙广播的数据，比如：48441a033c967e9fca5654edb6d67617d932a539262e30ac 一共24个字节，前面4个48 44  ...

我开始也这么以为的。后来看了下蓝牙温湿度计2的插件以及github上几个大神的文章，发现用的是AES 128 CCM (CBC+MAC)加密算法，明文可以是任意长度、密文长度和明文相同。

根据mibeacon文档，最短的可以是4个字节（2个字节的id、1个字节的长度标识、1个字节的载荷），最长的是13个字节（小米规定ble object最长不能超过10字节）。

ruan_yhang

XCray 发表于 2021-5-29 19:06
我开始也这么以为的。后来看了下蓝牙温湿度计2的插件以及github上几个大神的文章，发现用的是AES 128 CCM ...

关键最长13个字节指的是明文，广播出来的是24个字节的密文呀，密文从哪开始到哪结束不知道。
github上大神的链接能分享出来吗，学习一下。

XCray

ruan_yhang 发表于 2021-5-29 19:27
关键最长13个字节指的是明文，广播出来的是24个字节的密文呀，密文从哪开始到哪结束不知道。
github上大 ...

密文和明文的长度是相同的，从哪开始到哪儿结束，严格遵循mibeacon，很容易就可以挑出来。
比如这是蓝牙温湿度计2的几条：

58585B0519 xxxxxxxxxxxx 36BCBF36   0D0000 3691BD41（电量10）
58585B0517 xxxxxxxxxxxx 5E3721CBC8 0D0000 F1902519（温度24.0）
58585B0515 xxxxxxxxxxxx FB9F3561E6 0D0000 52008CCF（湿度64.4）

xxxx那一串是mac，前面一段和后面两段看mibeacon文档就知道，也可以知道xxxx后面就是加密后的ble object。
也就是说，这一个mibeacon里，只有ble object是加密的，其他都是明文。

具体到你刚才发的那个，48441a033c967e9fca5654edb6d67617d932a539262e30ac，其中967e9fca5654edb6d67617d9这12个字节是密文，而其中真正的有效载荷是9个字节（去掉id和长度标识）。

这是我说的那篇文章：
https://github.com/Magalex2x14/LYWSD03MMC-info

对了，除了配对的时候，平时大概多久可以在TTL接口看到一次token/beaconkey有印象吗？

另外，我怀疑我用的榉树的蓝牙网关并不会在TTL口打印这个信息，因为我特意把蓝牙温湿度计2删了重新绑定，一直没收到包含“key”的消息。
你那个网关消息前面是ots，应该是螃蟹芯片的模组，猜测是不同模组sdk或不同开发团队关于debug的处理方式不一致的原因

ruan_yhang

XCray 发表于 2021-5-29 19:34
密文和明文的长度是相同的，从哪开始到哪儿结束，严格遵循mibeacon，很容易就可以挑出来。
比如这是蓝牙温 ...

1. 我也正在验证这个，我用的设备是创米万能遥控器作为网关，锁是米家智能门锁标准版。最新发现，今天当网关连上WiFi时，会自动获取 beaconkey数据，竟然和两天前的数据一致。
2. 还有一个问题，我看了github帖子，CBC+MAC，MAC 4个字节是前四个字节吗？Object不够16个字节后面补0？

XCray

ruan_yhang 发表于 2021-5-31 10:15
1. 我也正在验证这个，我用的设备是创米万能遥控器作为网关，锁是米家智能门锁标准版。最新发现，今天当 ...

你咋还在纠结长度问题？不补0，是多长就多长，4个字节的明文加密后就是4个字节的密文、5个字节的明文加密后就是5个字节的密文。

另外，这个MAC不是MAC地址，而是消息鉴权码之类的加密算法里的名词。
~~~~~~~~~~~~~~~~
你的网关看来还可以尝试这个思路，我的估计不行了——我把网关删掉、重置、重新绑定，只给了这么两行：

08:00:01.442 [M: miio C: info F: deal_with_token L: 228]: token is already existed and do not need to regenerated
14:10:25.508 [M: miio C: info F: on_recv_handle_transaction L: 2084]: otu:valid down req:bind_key.

而重置门锁，ttl口啥都看不到。。。
看来这个网关的程序员比较有水平，知道这么敏感的信息不宜打印在debug里。。。。。。可气！

ruan_yhang

XCray 发表于 2021-5-31 11:29
你咋还在纠结长度问题？不补0，是多长就多长，4个字节的明文加密后就是4个字节的密文、5个字节的明文加密 ...

那就换个网关吧，也不贵，我今天抓了一个上午的包，每隔一段时间就会收到 beaconkey，数值一样。
我是在下面这个链接里面找到的这个网关，听说后面出的网关没这个功能强大。https://github.com/killadm/LOCK2MQTT
你发的 github 帖子我仔细看了下，他收到的协议根据对不上现在的mibeacon 广播协议，我猜测 Random Number 对应他的 ext.cnt，MIC对应他的 MAC tag ，这样的话最后一个 RSSI又是什么鬼？
顺藤摸瓜，我又找到一个帖子，里面的协议和上面的差不多，也有一个RSSI字段，不明白什么意思，可能V3版及之前用的是他们这一版协议，到V4版改掉了。
https://github.com/nccchirag/yeelight-ble-rotary-dimmer/issues/1

XCray

ruan_yhang 发表于 2021-5-31 15:43
那就换个网关吧，也不贵，我今天抓了一个上午的包，每隔一段时间就会收到 beaconkey，数值一样。
我是在 ...

换网关的话，我还不如干脆换多模网关呢，可玩性更高。主要是我手上已经有了一个chuangmi IR遥控器，实在懒得再弄一个回来了。

回到正题：那个帖子里内容没问题，和mibeacon的协议是完全吻合的。现在对于小米各种蓝牙设备（除了门锁）的ble beacom解密都是没问题的，几个插件和esphome都已经做到极致了。

还无法确定的是门锁类产品的加密方法是不是和蓝牙温湿度计等产品一致，这一点估计你很快就可以确认

XCray

ruan_yhang 发表于 2021-5-31 15:43
那就换个网关吧，也不贵，我今天抓了一个上午的包，每隔一段时间就会收到 beaconkey，数值一样。
我是在 ...

你试试这段代码，填入你门锁的mac地址和key，看看解出来是啥。注意mac地址是逆序。

from Cryptodome.Cipher import AES
import binascii

mibeacon = '48441a033c967e9fca5654edb6d67617d932a539262e30ac'
mac= 'xxxxxxxxxxxxxx'
pdid = mibeacon[4:8]
fcnt = mibeacon[8:10]
ecnt = mibeacon[-14:-8]

nonce = binascii.unhexlify(mac+pdid+fcnt+ecnt)
key = binascii.unhexlify(b'xxxxxxxxxxxxxxx')

aad = b"\x11"
ciphertext = binascii.unhexlify(mibeacon[10:-14])
cipher = AES.new(key, AES.MODE_CCM, nonce=nonce, mac_len=4)
cipher.update(aad)

decrptdata = cipher.decrypt(ciphertext)

print("decrptdata:",binascii.hexlify(decrptdata))

复制代码

这段代码我已经用蓝牙温湿度计2的消息验证过，没问题，这里我已经根据你门锁的消息修改了每个字段的正确位置

ruan_yhang

XCray 发表于 2021-5-31 18:44
你试试这段代码，填入你门锁的mac地址和key，看看解出来是啥。注意mac地址是逆序。

试了你的代码，没问题。解出来的结果和网关输出的一致！！！！！！

XCray

ruan_yhang 发表于 2021-5-31 23:34
试了你的代码，没问题。解出来的结果和网关输出的一致！！！！！！

太好了！

这是一个重大进展！可以说成功就在眼前！

比较好的方案是利用ESP32、同时接收TTL消息和BLE广播，就可以实现这个思路了。
当然，继续用8266接TTL、用HA主机自带的蓝牙收BLE广播也完全没问题。

可惜我的网关不输出这个重要数据，我也没办法完成最后的代码整合和调试了。要不你继续？

或者哪位朋友能借我个创米小白遥控用一段时间？
（ps. 为了让更多朋友看到，我厚着脸皮自己加精置顶了。。。）