逆向智能门锁漏洞分析PART（二）

BTSNOOP （安卓蓝牙 HCI 记录器）

最终，BTSNOOP必须成为我最大的发现之一，当想要捕捉一个完整的蓝牙会话之间的中央（手机）和外设（锁），我尝试各种方法来捕获我的OTA蓝牙会话，包括北欧的nRF嗅探器开发板nRF52840-DK，Sena的UD100加密狗，Ubertooth-One和德州仪器CC2540加密狗。所有这些方法的问题在于，由于蓝牙低功耗 （BLE）通道跳跃，它们无法跟踪连接。北欧nRF52840-DK在与 Wireshark 和北欧的 BLE 嗅探器插件一起使用时非常接近，但不幸的是，数据包捕获是在链路层（而不是主机控制器接口层），导致无法解析的加密数据。

由于它不是在 HCI 层捕获的，这意味着它容易受到 CCM AES-128 BLE 安全密钥交换协议握手的影响。根据我的判断，这意味着如果nRF52840-DK在配对时没有嗅探，它将完全错过安全握手，导致数据包没有解密。

重要提示：NRF 嗅探器缺点！

如果 KeyWe 锁在配对后执行通道跃点，但在 App 传输第 1 个数据包之前，nRF 嗅探器将错过初始 CCM AES-128 BLE 安全密钥交换。这将导致加密的”无用的”数据包。这是 nRF 嗅探器无法遵循通道图的一个缺陷。注意：CCM AES-128 BLE 安全密钥交换是所有蓝牙低功耗 OTA 无线连接中的安全协议，可防止 MiM 窃听。

CCM AES-128 BLE 安全密钥交换：

（这是与 KeyWe 项目无关的一般信息）

临时密钥在蓝牙配对过程中使用。短期密钥用作首次设备对加密连接的密钥。短期密钥使用三条信息生成：临时密钥和两个随机数，一个由从站生成，另一个由主项生成。

使用短期密钥加密连接后，其他密钥将分发。长期密钥替换加密连接的短期密钥。身份解析密钥用于隐私。连接签名密钥用于身份验证。

幸运的是，有一个极好的方法来捕捉蓝牙流量使用您的ANDROID设备！

在 Android 手机上

•转到设置

•如果未启用开发人员选项，请现在启用

•转到开发人员选项

•启用选项 启用蓝牙 HCI 窥探日志

•执行需要捕获的操作（会话）

•禁用选项 启用蓝牙 HCI 窥探日志

•使用亚行（安卓调试桥）将文件复制到 PC

•感兴趣的文件btsnoop_hci.log

注意：通常，我会保留启用蓝牙 HCI 窥探日志的选项，因为它在我的根测试手机上

获取btsnoop_hci.log蓝牙会话的完整信息

列出的android文件

调出的btsnoop_hci日志文件

重命名btsnoop_hci.log btsnoop_hci-07-31-20.log（与我的会话日期一起附加）

WIRESHARK 分析

将btsnoop_hci.log导入 Wireshark，我们可以看到OTA加密数据包交换。这与 Frida 函数十六进制提供了交叉引用用户会话活动的一种有价值的方法。从我在 KeyWe 锁研究期间生成的大量会话中，我可以确认这些数据包交换在每个会话中遵循相同的顺序，并且永远不会变化。在下面的示例中，我们可以看到由应用程序启动的打开密钥交换，然后是门。

示例 1：应用程序发送应用程序编号 + 门返回门号 + 门发送 Hello

有趣的注意：（在上面的截图）：fb2b28c68b3f99c514b98fada4bf0b89 （传输 #2） 可以解密与通用键复制门号！

这可以通过使用免费的在线 AES-128 密码工具在这里验证：http://aes.online-domain-tools.com/

输入加密数据包 fb2b28c68b3f99c514b98fada4bf0b89 并输入密钥（通用键） c88ff4150f4ac27934a6c5e6741efac 后单击解密

使用在线 AES-128 密码工具是将 Wireshark 会话数据与 Frida 十六进制数据关联到的方便方法。接下来的几个屏幕截图显示了各种蓝牙 OTA 流量如何与应用程序的已知函数调用重合的示例。这为我们提供了大量有关程序流和执行的信息。

示例 2：应用程序发送欢迎 + 门发送开始 + 应用程序和门两个交换门模式

示例 3：APP 发送 eKey = 门发送 eKey（身份验证和授权）

示例 4：门状态 = 门时间集交换

示例 5：门状态交换

重放攻击

如屏幕截图所示（上图），可以使用 btsnoop_hci.log（捕获）在 Wireshark 中分析整个蓝牙会话，并与使用 Frida 工具找到的数据并排进行比较。另请注意，通过无线发送的每个加密数据包都可以通过确定传输方向（应用程序到门或门到应用程序）并使用适当的密钥（AppKey 或门键）进行解密。

现在，我们已经有了密钥，知道如何解释所有数据，我们可以尝试使用重放攻击来操作锁。同样，F-Secure在他们的Github中提供了一个不错的工具，他们称之为”open_from_pcap”。根据预先录制的 pcap 会话中的信息，此工具允许他们重放会话并操作锁。当然，当他们在脚本中重新编辑其脚本时，keys.py无害。然而，正如我前面所说，我最终能够对功能进行逆向工程。因此，通过将 F-Secure 的 REDACTED keys.py我自己的版本交换，它允许我在open_from_pcap上实现”btsnoop_hci.log”工具。

使用我的 Sena UD100 蓝牙 USB 适配器，运行“open_from_pcap”脚本的第一个结果如下所示：

显然，我修改keys.py正确确定了公钥、AppKey 和DoorKey，但在 eKeyVerify 阶段失败。

在不深入地了解 F-Secure 的编码的情况下，open_from_pcap python 脚本在另一个脚本 （decode_from_pcap）中调用一个函数，该脚本据称会从会话 pcap 中检索 eKey。不幸的是，这对我来说并不适用。也许这与他们的 pcap 文件与我的 btsnoop_hci.log 文件的格式结构不同（从 Wireshark 会话中保存为 pcap）有关，不管怎样，我决定放弃破译他们的代码，而是修改了‘open_from_pcap’文件，使用我的硬编码 eKey，而不是尝试检索它。

顺便说一下，F-Secure 人员需要从 pcap 检索密钥的原因是，当创建帐户时，eKey 会在线存储，并且不存在于任何 OTA 传输中。但是，通过使用 Frida，它可以通过将 javascript 注入 eKeyVerify 函数来检测，该函数提供返回值的十六进制（见下文）。

正如您从上面的屏幕截图中看到的，作为测试的一部分，我决定删除我的（旧）KeyWe 帐户并创建一个（新）帐户。通过这样做，我也许能够确定从一个用户帐户到另一个用户帐户发生哪些更改，以及 eKey 是否可预测。从我所看到的，没有明显的可检测模式。eKey（也称为用户密码）是在所有者创建其帐户时生成的，因此在帐户设置期间，密钥是完全随机的，并且可能从用户密码派生。此外，当我创建新帐户时，我故意只更改了原始密码中的一个字符。此处意在说明，这可能有助于我确定 eKey 是否仅派生自用户密码。

从上面的屏幕截图中，似乎很清楚的是，eKeyVerify 函数是由应用程序调用的，并且传递的参数是一个 6 字节的值 （eKey）。返回的值可以假定为由应用程序（使用 AppKey 加密）发送到门的修改结果 eKey。在不深入挖掘代码的情况下，我只能假设 6 字节值 （eKey） 提供了指向存储的实际（修改的） eKey 的链接。无论如何，这个6字节的eKey是完成重播会话所需的全部。

将 eKey 硬编码到replay.py脚本中，导致以下重播会话：

成功！！

此重放是成功的，因为我能够获得eKey（用于身份验证和授权）从我扎根的手机使用Frida提取它。就目前情况，由于合法所有者的 eKey 无法以这种方式访问，因此此重放攻击无法在野外工作。同样，正如我前面所说，eKey不是传送OTA的。

考虑以下代码段捕获我的手机的btsboop_hci.log和相应的 Frida 十六进制的 eKeyVerify 函数：

Wireshark 捕获显示打开数据包传输（密钥交换、握手等）。密切关注此会话中的第 8 个数据包。它显示应用程序发送的加密数据包，其中包含修改后的 eKey 值。从 Frida 十六进制，另请注意，6 字节 eKey 值被枚举为修改后的 eKey 值的字节 （5：11）。

根据我们学到的关于此数据包在传输前如何加密的知识，我们知道这将是一个使用 AppKey 作为密钥的 AES-128 密码。

使用在线 AES-128 密码工具解密第 8 个 OTA 加密数据包：46402315a85a72e66e9671d0444b513af使用AppKey：e022c1193ebb3882efc9cf79b6e557d1 作为密钥， 正如我们所了解的，6 字节 eKey 值被枚举为解密修改的 eKey 值的字节 （5：11）。

（见下文）

这个小练习清楚地表明，如果我们可以在野外合法所有者的打开数据包交换的OTA捕获，我们将有我们需要的一切（包括他们的用户密码 + eKey）来危害他们的家庭安全，并解锁他们的门！

总结

我不得不承认，我花了大量的时间研究（按几个月的顺序）这个项目，主要是因为处理沉重的混淆的代码，但也由于学习曲线涉及学习任何新的工具。熟悉 Frida 工具及其许多功能和实现中有几个对我来说是这个项目的要点之一。此外，能够对 Android 应用程序进行逆向工程同样有益，同时意识到 F-Secure 通报发布以来已经一年一段时间了，供应商已经有足够的机会来减轻他们的影响。因此，我强烈同意F-Secure研究人员的发现，因为固件更新功能肯定会减轻他们的大量暴露，并且使用自定义（内部）加密算法一开始就不是非常好。

结尾之际，我还要处理一些未完成的研究，这是OTA捕获我的非根个人电话和 KeyWe 锁之间的会话，以创建一个重放攻击，将在野外工作。无论如何，为了减轻他们的曝光率，我强烈建议 Guardtec KeyWe 智能锁的当前所有者尽快将移动应用程序升级到最新版本（本文撰写时的版本 2.1.0）。