耶鲁智能门锁的简单测试（下）
Last updated
Last updated
上一篇文章的分析中，我们发现Yale智能门锁的通信中存在两个问题，本篇文章将分为两个部分描述如何利用这两个问题：
a. 嗅探BLE通信获取productInfo；
b. 使用获取的productInfo控制门锁。
Yale门锁的BLE通信没有加密，所以我们通过嗅探的方式可以直接获取Authentication Request和Authentication Response，利用这两个数据包的Payload做减法运算即可得到productInfo。
嗅探BLE通信需要有专用的硬件工具，我们使用的是CC2540 Dongle，配合TI的Packet Sniffer软件，如图2-1所示。
Dongle直接接到电脑的USB接口即可使用，Packet Sniffer软件可以对Dongle进行配置，并显示嗅探到的BLE消息。
我们在第一篇文章中介绍过，Master在Scanner状态下，会不断扫描并接收Slave在Advertiser状态下发出的广播包，广播包的发送和接收都是在3个广播信道上进行的，Master想要与某个扫描到的Slave建立连接时会进入Initiator状态并向Slave发起连接请求，双方建立连接后会在37个通信信道上以一定的规律进行调频通信。
由于连接建立后，双方以跳频的方式进行通信，因此我们只能在Master和Slave建立连接时，也就是Master在Initiator状态下发出CONNCET_REQ数据包时，就开始跟踪双方的通信，才有可能嗅探到所有通信内容。
因此，Dongle的工作原理如图2-2所示，整个嗅探流程可以分为三个步骤：
a. 启动完成后，Dongle工作在某一个广播信道上，会嗅探所有该信道上的广播包；
b. 当探测到CONNECT_REQ数据包时，说明该信道上有Master和Slave准备建立连接，此时Dongle会解析CONNECT_REQ数据包的内容，获取主从设备的信息及双方第一次跳频通信的通信信道；
c. 此后，Dongle只会过滤步骤b中主从设备之间的通信，并跟随双方的跳频，这样双方所有的通信都被嗅探到了。
一个Dongle只能监听一个广播信道的通信，而通信双方可能会在3个广播信道中随机挑选一个建立通信，因此如果只有一个Dongle时，可能需要多次尝试才能获得需要的数据，有多个Dongle时则可以分别将它们配置为监听不同的广播信道，选择Dongle并配置监听信道的方式如图2-3所示。
介绍完嗅探工具，我们就可以尝试嗅探通信了。
嗅探的操作非常简单，配置好Dongle后，点击Packet Sniffer中的开始嗅探按钮，就可以看到Dongle接收到的所有广播包，如图2-4所示。
开始嗅探后，我们在Dongle附近尝试在app里连接门锁，如果手机和门锁恰好是在Dongle监听的广播信道上建立连接，那么就可以抓到后续手机和门锁之间所有的BLE通信，如图2-5所示。
图2-5中，黄色数据包之后，手机和门锁就已经开始跳频通信了，可以看到Channel字段每次通信都会变化，而建立通信前的最后一个广播包的类型就是CONNECT_REQ，Dongle是通过这个数据包来跟踪双方随后的跳频通信的。
正如上文所提到的，Dongle一次只能监听一个广播信道，所以我们可能需要多次重复才能嗅探到手机和门锁的通信。
嗅探到通信之后，我们只要找到Authentication Request和Authentication Response即可，要定位这两个数据包，则需要知道数据包的特征和结构。
回想上一篇文章，在生成Payload并发送Authentication Response之前，调用过一个makeACKFrame的函数，从函数名看，这个函数的作用是将Payload封装成ACK Frame，我们就从这里着手分析。
首先我们看一下调用makeACKFrame的地方，如图2-6所示。
调用makeACKFrame函数时传入了4个参数，其中v2、v3分别是已经初始化好的变量，所以Authentication Response中应该有两个固定内容的字节，v4显然是个累加的计数器，最后一个参数arg7，我们上一篇文章中就提到了，这个参数是encodeCounter函数的返回值，也就是Authentication Response的Payload。
我们在上一篇文章中获取到的日志，如图2-7，send 72ACK的内容，起始字节是0x72和0xA1，而图2-6中，参数v2和v3分别包含了HexString(72)和HexString(A1)。所以，我们可以推断Authentication Reponse起始字节是固定的0x72A1，这一点可以作为数据包的特征。帮助我们在嗅探到的通信中寻找Authentication Response。
makeACKFrame的结果在v1中，打印Log时调用了v1.toString()，这个函数如图2-8所示。
在toString函数中我们能直观的看出Authentication Response的数据包结构：
a. 开始的两个字节是event和source；
b. 第3个字节表示数据包的序号，第4个字节则是长度，我们暂时还不清楚这是数据包的长度还是Payload的长度；
c. 第5字节开始是数据包的Payload；
d. 最后一个字节是校验，校验算法暂时未知。
通过数据包的特征，我们在嗅探到的通信中定位到图2-9了这样一组数据包。
根据起始字节是0x72A1这一特征，第二个数据包应该就是Authentication Response，那么第一个数据包应该是Authentication Request，Response数据包的结构分析如图2-10。
按照类似的方式取出Request数据包的Payload，按照上一篇文章的分析，只需要将Response的Request两个数据包的Payload做差即可得到这个门锁的productInfo，做差过程如图2-11。
我们在已绑定了门锁的手机中查看app的数据库，其中显示了已绑定门锁的productInfo，如图2-12所示。
对比图2-11我们计算出来的结果，和2-12中数据库里的product_info字段数值，二者前6字节是相同的，上一篇分析中在分析productInfo变量的使用时，其中也只有6个字节参与了计算，所以我们推测后两个字节是无效字节，下一章的操作中可以看到，这两个字节置0也能够开启门锁。
前文提到app数据库中有product_info字段，而app在构造Authentication Response时直接使用了这个字段的数值，那么如果我们在未绑定门锁的手机上，跳过门锁绑定步骤，直接将门锁的相关信息写入到app的数据库中会出现什么情况呢？接下来我们对这种情况进行实验。
修改数据库最方便的办法就是，通过ADB将app中的数据库（位于/data/data/com.irevo.blepack/databases目录下）拉取到电脑上，在电脑上修改完成后再推送回app。
要操作/data目录下指定app的文件，需要我们拥有root权限或者使用run-as指令，在未root的手机中，执行run-as + 包名，就可以直接以root权限进入该应用的沙盒中查看数据库、xml、各种信息文件等内容。使用run-as指令，需要指定的应用处于允许debug的模式，所以我们在上一篇文章中添加Log代码时，也在AndroidManifest.xml文件中添加了Android:debuggable = true的标签。
在未绑定门锁的手机中，数据库应该是空的。空数据库的填写方式如图3-1所示。除了product_info外，还有一个module_addr字段需要注意，这个字段应该填写门锁的蓝牙地址，这个地址可以在门锁附近，使用nRF Connect扫描周围设备获取。
数据库填写完成后，使用ADB指令推送回手机，即可使用该手机控制门锁了。如图3-2所示，手机最初并没有绑定门锁，在我们将数据库推送进手机后，重启app，会发现手机开始尝试与门锁建立连接，稍等片刻连接建立之后，就可以直接用这个手机打开门锁了。
我们用了两篇文章记录了Yale门锁的漏洞分析及利用过程。
首先我们从Yale Bluetooth Key这款app的Log着手，定位到了app中的关键代码，随后通过对关键代码的分析，发现了门锁与手机之间的身份认证环节存在漏洞，最终通过嗅探门锁与手机之间的BLE通信，我们利用身份认证的漏洞在未绑定门锁的手机上打开了门锁。
这次对智能门锁的安全测试仍然是从BLE入手的，重点分析的是手机端的app。
