本文内容较长，所以将目录整理在最前面，用于方便各位读者查阅，目录如下：

下面就开始正文：

本篇我们与各位读者分享一些关于Loock Touch智能门锁的研究内容，该门锁由云丁科技公司出品，云丁科技是一家专注于研发和生产智能家居安全产品的公司，旗下有两大品牌，分别是针对家用市场的“鹿客”和针对公寓市场的“云丁”。Loock Touch是鹿客品牌的主打产品之一，其架构与云丁品牌的D2、D3智能门锁很相似，最新的鹿客旗舰产品是Loock Touch 2 Pro，其硬件架构与此前所有产品均不同，变化较大。
由于胖猴实验室一直和云丁科技有良好的合作关系，所以接下来的几篇的分析和讨论中，我们只对分析方法和研究过程做讨论，而不涉及任何有关漏洞的细节，这与此前的关于海康萤石智能网关的文章类似。

在之前的文章中，我们分析了果加智能门锁，链接为https://bbs.pediy.com/thread-259530.htm，在本次分析中我们依旧以BLE开锁为分析切入点。云丁鹿客的Loock Touch门锁同样可以通过手机BLE直接开锁，那么我们就从app的开锁流程开始分析。
应用市场中下载到的云丁鹿客智能门锁的配套app加了梆梆企业版的壳，脱壳之后可以看到该app打印出来的日志（脱壳不在本系列文章的讨论范畴中，分析iOS版也是可以的）。我们操作手机开启门锁后，app的日志中有这样几条记录吸引到了我们。

图2-1 app开锁时打印的日志
根据上图中3个红框中的记录内容，我们可以推测开锁过程是基于Challenge/Response模式进行认证的，具体过程如下：
（1）app与门锁建立BLE连接后，当使用app开启门锁时，app会先下发一条通知指令，告知门锁准备进入开锁流程；
（2）随后门锁会向手机发送一组数字，称之为Challenge；
（3）app对Challenge进行处理生成Response并发送给门锁，门锁验证Response正确时，就会开锁。
我们对比了多次开锁时的app日志，发现每次开锁时第（1）步发送的通知指令仅有一个字节内容不同，如下图所示：

图2-2 通知指令对比
上图中，我们对比了3条通知指令，发现仅有第7个字节不同，在app封装数据包的代码段中，可以确定这个字节的含义是seqID，即数据包的序列号。因此我们可以推测这一条通知指令的作用类似于TCP协议中的SYN数据包，仅起到握手的作用，而门锁对手机的认证过程，主要是第（2）和第（3）步，那么接下来我们就分析一下app是如何处理Challenge并生成Response的。

通过在代码中搜索日志内容，我们可以确定，app收到Challenge数据后，会由下图中的方法进行处理。

图2-3 Challenge数据处理
上图中， handleCommand方法用于处理BLE返回数据，门锁返回的Challenge就作为参数传给了方法sendUnlockCommandNewProtocol，从参数和方法名称来看，这就是处理Challenge数据、生成Response并发送回门锁的方法。
进一步查看代码，我们发现在sendUnlockCommandNewProtocol方法中，最终调用了下图中的encryptBleKeyNewProtocol方法对Challenge数据进行处理，该方法返回后的数据，添加包头后会被直接发送给门锁。

图2-4 对Challenge数据进行加密
上图中，参数arg13即为Challenge数据，可以看到该方法中使用了AES EBC加密，密钥是参数arg9，加密完成后使用密文又异或了一组固定数据。
经过以上分析我们可以推测，开锁流程中，门锁对手机的认证依赖于图2-3中的AES EBC算法，即双方使用相同的密钥对Challenge进行加密和解密处理，仅当手机拥有正确的AES密钥才能通过认证开启门锁。那么开锁流程的安全性，就取决于门锁与手机使用的密钥是否安全了。

图2-3中，加密密钥是参数arg9，通过对arg9的回溯可以确定，对Challenge进行加密的密钥通过resetBleToken方法获取，如下图所示。

图2-5 加密密钥的获取
resetBleToken方法中发出了一个http请求，收到返回的BleToken并进行处理后，会对一些变量进行赋值。图中的mBleKey是BleKeyInfo类型的变量，其token成员变量，就是2.2.1章节中Challenge数据的加密密钥。下文中，我们将以BleKey来代称这个加密密钥。
由以上分析可以知道，BleKey是app从服务器上请求到的，这里就有两种可能：（1）每次app与门锁建立通信时，都会请求一个Key并下发给门锁；（2）当app与门锁建立通信时，如果没有可用的BleKey，才会向服务器发送请求。
为了验证以上推测，我们使用手机多次重复开启门锁，这样使手机和门锁反复建立通信，这时我们在app日志和抓取到的数据包中，都没有发现这个请求以及相关内容，可以判断app应该是本地保存了BleKey，而不需要从服务器获得了。
我们可以通过清空app缓存的方式，删除本地存储的BleKey，删除后app开锁时的日志发生了一些变化，如下图所示：

图2-6 删除app的蓝牙钥匙后app开启门锁时的日志
对比图2-6和图2-1中的日志内容，可以看到删除BleKey后，在开启门锁时先执行了resetBleToken，这和我们的分析吻合。这里我们注意到，resetBleToken之后，还有另外一条日志sendBleKeyCommandNewProtocol，这里是向门锁发送BleKey的方法，下面我们先继续手机获取BleKey这一过程的分析，手机向门锁下发BleKey的过程将在2.2.4节中分析。
与此同时，我们在fiddler中也抓到的对应的http请求，如下图所示。

图2-7 reset_token请求
app收到返回的BleToken后，会使用AES CBC算法，对上图中红框内的secret和token进行解密，相关代码如下图所示:

图2-8 reset_token返回值的处理
此时可以确定，app从服务器获取到的BleKey同样被AES CBC加密算法保存。通过图2-8可以看到，其密钥由方法getCryptSecret返回，与方法名称对应，这个密钥我们就称之为CryptSecret，下一步我们就来分析CryptSecret的来源。

BleKey解密时的密钥通过getCryptSecret方法获得。那么我们可以从这个方法入手，相关代码的搜索结果如下图所示。

图2-9 获取CryptSecret的代码流程
上图中，getCryptSecret方法返回的是this.mCryptSecret，而这个变量是通过setCryptSecret赋值的，setCryptSecret方法则是在getSecret方法中被调用。在getSecret方法中，可以看到CryptSecret是从云丁鹿客的服务器获取到的，其url为”api/v1/crypt_secret”。同样的，我们在fiddler里也可以抓到crypt_secret数据包，如下图：

图2-10 crypt_secret请求及其响应
由于这里的信息有些敏感，所以我们做了打码处理。

2.2.2节中说到sendBleKeyCommandNewProtocol函数负责向门锁下发BleKey，该函数如下图所示。

图2-11 手机向门锁下发BleKey的函数
结合上图与图2-6的日志和图2-7中reset_token请求的返回数据包，可以发现，手机向门锁下发BleKey的流程非常简单，就是对reset_token返回数据包中的totalData进行base64解码，解码后的二进制数据直接通过BLE通信发送给了门锁，门锁对totalData的处理我们将在后续文章中分析。

经过第二章的分析，我们可以将Loock Touch门锁的开锁流程总结如下图所示。

图2-12 开锁流程图
上图中，开锁流程可以分为两个部分：
（1）虚线部分表示，当app没有存储可用的BleKey时，会向服务器请求CryptKey和BleToken两组数据，以CryptSecret为密钥，对BleToken中的数据进行AES CBC解密后，就可以得到BleKey。
（2）实线部分则是当app中有可用的BleKey时，会以BleKey为密钥对Challenge进行AES EBC加密，密文异或一组固定数据后，作为Response的主要内容并发送给门锁，当Response校验成功后才会开启门锁。

上文中，我们着重关注的是手机端是如何处理和发送BLE消息的，那么接下来就看看门锁这边针对BLE消息的处理流程。

在此前的文章中，我们已经介绍了通过gdbserver调试海康萤石固件程序的方法，链接为https://bbs.pediy.com/thread-261679.htm，通常情况下，gdbserver是运行于Linux系统环境中的调试器程序，通过使用Linux系统提供的调试接口以完成调试工作，并不需要太多硬件上的辅助。而在某些场景中，例如，没有Linux操作系统时，gdbserver等工具就无法满足我们的调试需求了，此时需要直接使用MCU提供的硬件调试接口和功能，以完成调试工作。通过阅读MCU的芯片手册，可以找到MCU提供的调试方式、调试引脚等详细信息。
为了使用MCU的调试接口，我们还需要与之对应的硬件调试器。与IDA、GDB等调试器软件类似，通过硬件调试器，我们也可以完全掌握被调试程序的执行状况。一般情况下，硬件调试器是通过USB接口连接到PC主机的，而硬件调试器与MCU之间的通信接口则有许多种。不同的MCU，支持的接口也不尽相同，具体信息需要查阅各芯片的手册。
本篇文章要研究的Loock Touch门锁使用的MCU型号为EFM32GG280F512，通过翻阅芯片手册，可以找到其调试接口信息如下图：

图3-1 EFM32调试接口
上图中的调试接口名称为SWD接口，常见的使用SWD接口的硬件调试器有JLink、STLink等。
我们目前使用的调试器SEGGER JLink（下文简称为JLink）提供了对JTAG和SWD两种调试接口的支持，具体使用时，只需要连接到对应的引脚即可，JLink中两种接口的引脚如下图所示：

图3-2 SEGGER JLink的引脚定义

JLink调试器可以通过调试接口读写芯片内置的Flash，从而获取完整的固件。并不是所有芯片都可以通过调试接口提取固件，很多设备在发行版中启用了读保护（Readout Protection）机制，使得我们无法通过调试接口读到Flash内容，所幸本文中的设备并没有启用该机制。
接下来，我们就寻找并尝试用JLink连接芯片的调试接口。

在门锁的电路板上，主控MCU一旁有一排过孔，我们已经在将排针焊接到这排过孔上了，如下图所示：

图3-3 MCU及其部分接口引脚
图中，左侧红框内就是我们焊上的排针，电路板上标注了排针对应的MCU引脚名称。经过万用表测量，可以确定红框中的IO和CLK引脚就是芯片的SWDIO和SWCLK两个引脚，我们在图2-1中提到这两个引脚是SWD调试接口的一部分，那么我们将这几个引脚按照如下图的方式连接到JLink调试器。

图3-4 调试接口与JLink的连接
上图左侧是图3-1中的排针，右侧是SEGGER JLink的引脚。连接完成后，将JLink连接到电脑的USB口，并打开JLink Commander命令行工具（JLink的相关工具和使用手册等都可以在SEGGER的官网下载到：https://www.segger.com/downloads/jlink/），执行下图中的命令：

图3-5 使用JLink连接SWD接口
下面逐一解释上图中6个红框的内容：
（1）命令行工具开启时，会首先对JLink的状态进行检测（SEGGER官网的JLink，无论价格还是到货时间都不理想，所以我们选择了某宝，从这里打印的JLink固件信息来看，某宝的似乎是盗版产品）；
（2）输入connect指令，控制JLink开始通过调试接口连接MCU；
（3）输入？指令选择要调试的芯片型号，在弹出的对话框中，我们按照芯片的厂商和型号，选择如下图的选项；

图3-6 芯片型号选择
（4）输入s指令，选择调试接口的类型为SWD；
（5）选择接口的通信速率，一般保持默认即可；
（6）当出现第6个红框中的内容时，说明JLink已经通过SWD接口连接到了MCU，接下来我们就可以读取固件或者进行调试了。

上文提到，调试器可以读写芯片的内置Flash，而固件代码就存储在芯片内置Flash中，所以我们只需要将Flash中代码区域的数据读出并保存下来，就相当于拿到了固件。按照我们分析果加门锁时的思路，翻阅芯片手册，可以确定代码存储在内存地址为0x0~0x100000的区域。我们通过JLink Commander命令行工具的savebin命令（该命令的使用方法可以去JLink的手册中查阅）将这一区域中的二进制数据保存下来。

图3-7读取固件的二进制数据
上图中，我们拿到了固件代码，并将其命名为LoockEfm32Fw.bin。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！