蓝牙马蹄锁分析过程
2023-12-13 18:3:3 Author: 看雪学苑(查看原文) 阅读量:6 收藏

手头有一个马蹄形状的自行车锁,手机通过蓝牙可以操作开锁。正好最近在学习低功耗蓝牙(BLE)协议,就拿它练练手。



抓包

网上有挺多抓包方式,包括手机端HCI,这里推荐国外的开源项目Sniffle。Sniffle是英国网络安全公司NCC Group在2019年底开源的一个基于使用TI CC1352/CC26x2硬件的蓝牙5和4.x LE嗅探器(抓包工具),最新的release版本是2022年8月发布的1.7。使用Sniffle需要购买指定的蓝牙开发板,并刷入固件才能使用,电脑通过串口与蓝牙开发板通信。


Sniffle项目中fw文件夹是固件源码,如果只是抓包的话,在Sniffle项目release1.7中有上传的编译好的固件,根据型号下载。


搜索相关资料得知,可以在TI网站上安装UNIFLASH软件来进行刷固件:https://www.ti.com/tool/UNIFLASH?keyMatch=&tisearch=search-everything&usecase=software%23downloads#downloads

抓包测试

Sniffle抓包方式是开发板抓到数据之后,通过串口发送给PC,PC收到数据包之后再根据设定条件来过滤数据,最后根据参数决定是否保存成pcap文件。因此需要用参数-s 指定某个串口,串口可以通过设备管理器查看,共有两个,选择UART的串口:




从README中可以知道python_cli中的sniff_receiver.py为抓包脚本,支持多个参数,这里简单介绍下常用的设置:
-a 只抓广播包,不知道设备mac地址的情况下,可以用此参数
-m 只抓特定mac地址的数据包,可以从广播包中分析出目标设备mac地址
-o 抓包结果保存到pcap文件

下图是命令sniff_receiver.py -s COM7 -m xx:xx:xx:xx:xx:xx -o data.pcap的显示:




下图是保存的pcap文件中的BLE开始连接过程截图:




至此抓包工作完成,下面开始分析数据包。


分析数据包

根据BLE协议栈,链路层主要是维持连接,我们暂时不关注链路层,所以使用wireshark显示过滤器btatt只显示att协议数据包。




前面主要是GATT的过程,这里只简单介绍一下:GATT层定义了一个4层树形框架,其中根节点为Profile(配置),它有不同的Services(服务),不同的服务有不同的Characteristics(特征),不同的特征通过一个具体的Value(值)或者Descriptor(描述符)来定义。网上关于GATT的资料很多,看的迷迷糊糊地,反正是没特别明白这东西。大致意思就是通过GATT交互可以知道BLE设备有哪些接口,这些接口是可读/可写等等。


可以把GATT当做接口说明,是固定的,跟应用层交互关系不大,直接跳过。往下翻在215帧Sent Write Command, Handle: 0x000d出现了可变数据,很大概率是应用层数据。




简单查看后续数据包发现所有的发送数据包长度都是16字节,无可见字符串与00等数据,很明显是加密了,大概率是AES(因为16字节正好一整行,并且安卓上对称加密普遍采用AES)。


有加密就要有密钥交换方式,有的开发者采用固定字符串在代码中写死,有的是动态传输或计算的,比如SSL的密钥交换算法。一帧一帧的往前翻数据包,发现第一个应用层数据帧在214帧:




这一帧是Handle Value Notification,之前没有Master发送给Slave的应用层数据,并且这个数据长度超过16,多次抓包前面的14 00 80是固定的,根据经验猜测是每次开始通信之前,Slave先把本次会话密钥发送给Master,一次一密,防止重放攻击


逆向APP分析

既然数据包加密了,再分析pcap就没有啥意义了,于是打开jadx开始逆向APP。首先搜索AES,简单翻找后发现提取key的方式:




这里的20不就是刚才数据包开头的0x14么,密钥是从下标3开始的,0x15的话是从下标4开始。最开始看数据包还有疑问,为什么前3个字节不变的情况下,后面是17个随机字节而不是16呢?看到代码就明白了有两种情况,干脆生成17个字节,各取所需。


再看加密函数,ECB模式无IV,无填充,直接拿key解密后续数据就行。




这里有个疑问,ECB模式要求数据16字节对齐,不填充怎么凑齐16字节?直到解密数据后发现:



好家伙,怪不得不用填充,自己手动填充了00。填充00意味着得有地方写明长度,不然末尾字节恰好为00咋办?继续逆向看代码吧。



通过logcat可以知道,command和command2就是发送的数据包,在调用mBleService.sendMessage之前进行了加密。那数据的组包就是getCommand干的了。继续进入getCommand发现jadx出错无法显示:



于是祭出版主的GDA:



通过GDA的逆向分析,弄清出了组包格式。
数据包示例:08 01 02 000D9038 E0
长度:1字节,包含自身的有效数据长度
方向:1字节,0表示BLE设备回复,1表示发送给BLE设备
功能码:示例中02表示验证密码,05表示开锁
参数:不同功能码参数数量和长度不同,具体可看getCommand函数。示例中0xD9038换算成十进制是888888,即锁的密码(这个锁限制密码只能是6位数字
校验码:前面的数据逐字节相加,最后与上0xFF

通过简单分析不难弄懂开锁流程:
1、蓝牙完成连接后,锁主动发送本次会话密钥给手机端;
2、手机端生成确认密钥功能码并加密发送,锁再回复确认数据包;
3、手机端将十进制密码转成16进制,发送验证密码功能包,锁回复验证结果;
4、如果密码正确,手机端点开锁会发送05开锁功能码打开锁;
5、开锁完成后,锁马上主动断开连接,节省功耗。

中间有穿插时间戳同步的数据包,就不多介绍了。这里额外提一句:逆向最怕的是无法反编译、反汇编,GDA还是很强大的,只要能反编译,再难看也能给他一点点的梳理明白。有总比没有强!


电脑发包解锁

既然已经搞清楚了加解密方式,并且数据包已经解密,那我们构建数据包通过电脑发送过去,一方面能验证加密,另一方面也能熟悉电脑端蓝牙怎么使用。说干就干,网上一通资料查找,说是PC端Python环境下,只有bleak库支持低功耗蓝牙(文章是几年前的,不确定现在其他库是否支持)。安装完bleak库,在examples文件夹里有不少示例,网上也有不少代码可以参考。下图是其中一个示例代码:



可以看到bleak用起来还是很简单的,给定设备的mac地址,之后就是连接、配对(BLE多数不用配对)、收、发完事。针对锁的流程,我们将发包过程写在了数据包接收的回调函数中:




已知密码的情况下,上述代码可以直接使用电脑完成开锁。


第一代远程开锁

通过以上工作,算是初步掌握了BLE蓝牙的一些基本协议和使用,比如GATT就是BLE设备(服务器)的接口说明,定义了一些Characteristics(特征)的读、写、通知权限,PC/手机(客户端)通过Characteristics可以实现与BLE设备通信。Characteristics在代码中是UUID形式,在数据包中是以Handle形式,Handle与Characteristics是一一对应的,对应关系是在GATT中定义。


只是电脑开锁,还需要密码。进一步探索发现APP中有远程开锁的功能,用户在输入密码之后会生成一个有效期10分钟的临时密码,发送给车附近的好友,就可以通过点击输入临时密码按钮开锁。如下图:




经过测试,这个锁是3年前的,属于第一代远程开锁。通过解密分析临时密码开锁数据包如下:

08 01 06 6532E77A 07

密码开锁功能码是05,这个临时密码是06,但是参数怎么和密码开锁一样是4个字节呢?继续去逆向APP找代码,第一代远程开锁临时密码生成函数如下:



参数str就是用户的密码,比如888888,临时密码就是时间戳与密码异或了一下。如此简(Fu)单(Yan)的算法,那10分钟有效是怎么实现的?因为锁的固件没有获得,只能猜测锁收到后与密码进行异或还原时间戳,然后判断是否(当前时间戳-还原时间戳)≤600。怎么验证呢?


一番思索后发现,这个异或操作将密码的精确判断和时间戳的范围判断混在了一起,聪明的读者可能会想到一个问题,还原的时候只是拿密码进行了运算,并没有对密码精确判断(临时密码丢失了密码信息,也无法精确判断)。如果以上推断成立的话,保证时间戳相差很少的情况下,那么理论上密码就可以范围一些。怎么验证?很简单,输入一个相近的密码比如888886来生成临时密码,如果这个临时密码能开锁就验证推断正确。


实验证实了猜测,在临时密码那里,888886一样可以开锁!那这个……岂不是可以爆破?


这个锁密码必须是6位数字且不能以0开头,那范围从100000到999999,总共是90万个可能。10分钟有效就是600秒,考虑到时间戳本来可能就差几秒,我们取590来计算,900000/590≈1525。也就是说时间戳在10秒以内,我们最多尝试1525次就可以开锁!当然,这个爆破的前提是锁不限制次数和频率。先生成爆破代码试试:



经过实验发现没有限制可以爆破,时间上来看,1秒钟至少可以尝试10次以上,最长在2分钟多一点就可以解锁,平均在1分钟多一些就可以爆破成功。

进一步分析,通过临时密码成功开锁的遍历密码与真实密码之间相差最多600,我们可以再回到密码开锁的方式,最多尝试600次就可以获得真实密码,差不多再花费1分钟。


综上,无密码情况下可以实现2分钟左右开锁,再花1分钟即可获得精确密码,这个异或的设计真是“神来之笔”。


二代远程开锁

第一代临时密码这么大的坑,那么有理由相信第二代远程开锁理论上应该功能更多,安全性更强。但是笔者没有二代锁,所以没法进行尝试。这里贴出来逆向代码:




第一代临时密码参数只有真实密码一项,有效期固定10分钟。第二代临时密码有效期最长居然能有一年(365天),如果算法设计不佳,那岂不是稀释的更厉害?createTempPwd2G函数的逆向可以通过GDA来分析,这里就不贴出来生成过程了。由于密码长度限制前几位是0,而时间戳前几位短时间内又不变,一代算法异或后前几位是不变的,二代临时密码在设计上增大了随机性,但是就笔者经验来看安全性依旧堪忧。只是没有二代锁,无法验证,就此停笔。


结论

在这个万物互联的时代,形形色色的产品层出不穷,受限于产品竞争压力,各个厂商首先要做的是功能迭代,在安全性上不会投入太多精力,毕竟首先要生存下来再说安全性,因此笔者对锁的安全性设计并不感到意外。本文重点是展现了BLE抓包方法,以及过程中分析的思路,希望能对刚入行的新人起到参考作用。

看雪ID:supertyj

https://bbs.kanxue.com/user-home-318073.htm

*本文为看雪论坛精华文章,由 supertyj 原创,转载请注明来自看雪社区

# 往期推荐

1、2023 SDC 议题回顾 | 芯片安全和无线电安全底层渗透技术

2、SWPUCTF 2021 新生赛-老鼠走迷宫

3、OWASP 实战分析 level 1

4、【远控木马】银狐组织最新木马样本-分析

5、自研Unidbg trace工具实战ollvm反混淆

6、2023 SDC 议题回顾 | 深入 Android 可信应用漏洞挖掘

球分享

球点赞

球在看


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458531433&idx=1&sn=123ba839fca50caa3358328125b9d1d9&chksm=b0d128a07e9cf3dd971a69fb53687188eae6b1be1fa64fb0b5eadde34f0ea69e23c5fb0448c4&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh