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

Alexie

XCray 发表于 2021-5-4 06:36
哈哈，这是雷军的工作失误。这么重大的事情竟然没专门给你汇报。。。

开发文档里说的，小米IoT开发者平 ...

zigbee芯片，目前靠谱的就silicon lab.. 国内供货估计得断货到8月 - 绿米也一样拿不到。 还有个TI，芯片没啥问题但是SDK一堆坑.. 我们还在填。 国内的也就泰凌微了吧，芯片怎么不知道，SDK肯定到处是坑。 蓝牙的... 两个手都数不过来

另外， 一个zigbee芯片的价格可以买三无个的BLE芯片了....

---
为啥Aqura选择zigbee ？ 因为只要符合zigbee 3.0标准，很多其他家的网关可以进去，不被限制死只有小米的米家网关。 但是对小米... 人家要的是封闭不是开放，谁家的产品都能接近来米家我生态链兄弟伙还怎么出货，小米的蓝牙有套自己的Mi mesh，也是基于SIGMESH改的。 天猫是自己的Ali mesh... 反正，就是通不了...

XCray

Alexie 发表于 2021-5-6 10:04
zigbee芯片，目前靠谱的就silicon lab.. 国内供货估计得断货到8月 - 绿米也一样拿不到。 还有个TI，芯片 ...

嗯，我也相信小米是基于封闭的考虑。开放不符合小米的最大利益。单单从这一点，以后买小米的东西都得小心谨慎了。

芯片荒也就最近几个月才出现的，小米决定不推广zigbee的时间更早。至于成本和开发的难易程度，我不了解，但感觉你说的不错。

sdfd

XCray 发表于 2021-5-5 10:21
https://miecosystem.github.io/miot-plugin-sdk/module-miot_Bluetooth.IBluetoothLock.html
这里找到了相 ...

SDK好像是成为企业开发者才能获取，这里有获取说明
https://iot.mi.com/new/doc/embed ... kstart?keywords=sdk

ruan_yhang

我使用NRF52832 抓取的小米智能门锁和米家APP之间的蓝牙包，协议内容感觉和你的不太一样。

ruan_yhang

neroxps 发表于 2021-5-2 21:39
据大佬说蓝牙是自带 AES-128 硬件加解密，key是临时的，根据米家服务器下发的 token 来生成，也就是说，抓 ...

采用暴破方式几乎是不可能的，侧信道倒是有可能。关键还是那个token，需要从云服务端获取，不联网的话很难。

XCray

ruan_yhang 发表于 2021-5-13 15:06
我使用NRF52832 抓取的小米智能门锁和米家APP之间的蓝牙包，协议内容感觉和你的不太一样。
...

“门锁和米家app之间的蓝牙包”——那应该是基于GATT的，从你图片里贴的这条消息看不出任何可以解读的信息。

我用esp32抓出来的，是门锁发出的广播数据，未加密的service adv严格符合小米MiBeacon文档的说明。而加密了的manufacture adv前面4个字节也和文档严格匹配——

48409701：
- 48对应的二进制是01001000，含义是已加密、含Object，不含mac、cap、mesh；
- 40和未加密的消息是一样的，含义是未绑定、无操作、旧版本认证、版本号0100；
- 9701是产品pid，我用的门锁的pid就是197，换成十进制407，这个和蓝牙网关ttl输出的消息里的pid是可以对应上的。

关键是后面的加密了的数据，token可以很方便的从服务器获取到，但怎么用来解密就查不到什么有价值的说明了

ruan_yhang

XCray 发表于 2021-5-13 16:17
“门锁和米家app之间的蓝牙包”——那应该是基于GATT的，从你图片里贴的这条消息看不出任何可以解读的信 ...

我刚刚抓了下广播包，然后把 Service Data 跟网关串口打印的数据进行比较，猜测协议是 10 44 +PDID +Frame Counter+ MAC地址。但是 44 01 具体是什么含义还在摸索。

UUID 16: Xiaomi Inc. (0xfe95)
Service Data: 10 44 1a 03 db 35 d9 31 64 7e d1

"id":716046697,"method":"_async.ble_event","params":{"dev":{"did":"1011169549","mac":"D1:7E:64:319:35","pdid":794},"evt":[{"eid":7,"edata":"0013f09c60"}],"frmCnt":221,"gwts":190}

XCray

ruan_yhang 发表于 2021-5-13 18:07
我刚刚抓了下广播包，然后把 Service Data 跟网关串口打印的数据进行比较，猜测协议是 10 44 +PDID +Fram ...

你抓的这个Service Data长度只有11个字节，而我的是12字节（至于为何，下面可以解释清楚）

解析如下：
10：二进制0001 0000，含义是只包含mac，其余都不含（所以这个报文里没有cap，比我的少了一个字节）
44：二进制0100 0100，含义是安全认证、版本4
db：序号，这应该是唯一会变化的字节
1a03，即十六进制31a，转成十进制就是794，和串口数据理的pdid是对应的。
35d931647ed1，mac地址，和串口数据也是一致的。

真正有意义、并且难办的，是开锁时的加密的manufacture data。
其实广播包和串口数据是不能一一对应的，串口只是debug输出。

neroxps

XCray 发表于 2021-5-13 16:17
“门锁和米家app之间的蓝牙包”——那应该是基于GATT的，从你图片里贴的这条消息看不出任何可以解读的信 ...

AES-128 用 token 解密试试

XCray

neroxps 发表于 2021-5-13 20:18
AES-128 用 token 解密试试

我考虑过这个思路，但无奈有一个想不明白的问题：

按说，AES-128加密出来的密文长度最小就是128bit，也就是16字节。

可是收到的广播包总长度只有16和25个字节，去掉已经明确含义的头和尾，真正的载荷（Object）只有4个字节和13个字节！——原来以为至少16个字节才能解密、这个长度是无法用AES算法解密的 对加解密还是太不懂了
-------------------------------------------------------------
感觉离成功又近了一步：
看了一下蓝牙温湿度计2的数据，Object长度有4、5两种，而且确实可以解密（ESPHome LYWSD03MMC组件）
Magalex2x14/LYWSD03MMC-info: LYWSD03MMC reverse engineering note (github.com)联系到这位作者，经他知道弄清了这个蓝牙温湿度计的消息解密方法。

但是，这个方法无法直接用于门锁消息的解密
门锁的token长度只有24、而解密算法要求的key长度是32，简单补0无效解出来不可读

蓝牙温湿度计的token和key也不知道有什么关联，也就是说不知道有没有可能通过token推算出key来。。。