我尝试破解我的智能振动器时学到了什么

我拥有一款智能振动器已经一年多了。可能有些人不太了解，智能振动器是指可以通过蓝牙连接，利用应用程序进行控制的振动器。通常情况下，这款应用程序会连接到互联网，这样远程用户就可以通过它来控制振动器。在这种情况下，远程用户会向应用程序发送一条消息，然后应用程序会通过蓝牙将这条消息转发给振动器。

我平时很少做硬件或联网设备的有趣项目，所以我想，不如破解一下我的震动棒，借此多了解一些物联网设备的知识。具体来说，我说的“破解”是指“逆向工程震动棒和应用程序之间通信的协议”。我要逆向工程的震动棒是Vibease 。友情提示：如果你在办公室、公共图书馆，或者在火车上旁边有个爱管闲事的人，这个链接会把你带到一个卖情趣用品的电商网站。希望这能帮你避免一些尴尬！

我首先对使用蓝牙的物联网设备进行了一些研究。我当时的想法，或者说我希望，物联网设备在使用蓝牙方面会有一些标准化的协议或规范。

我首先弄明白的是蓝牙和低功耗蓝牙之间的区别。低功耗蓝牙（有时也称为蓝牙4.0）是蓝牙的一个版本，它比之前的版本更节能。这对物联网设备来说尤其有利，因为这意味着它们可以长时间依靠电池供电。我可以证实这一点。我的振动器充满电后可以使用很多次，这让我非常惊讶。这种“低功耗”的区别在于，低功耗蓝牙模块在不使用时会保持“睡眠模式”，从而降低能耗。您可以通过此链接了解更多关于它们的区别。

我决定四处看看有没有其他关于物联网设备逆向工程的文章，偶然发现了这篇文章。文章中，作者逆向工程了一个智能灯泡。目前我的知识还不足以炫耀，但我感觉我正在尝试做的事情可能要复杂一些。首先，控制灯泡颜色的应用程序只需要修改LED显示的颜色，而振动器则由多个电机组成，有时还需要协同工作。尽管如此，这篇文章还是让我对蓝牙低功耗（BLE）设备有了相当不错的了解。

文章重点介绍了外围设备（例如振动器）如何使用蓝牙低功耗 (BLE) 连接到代表设备不同方面的服务（例如振动器的电池或电机），从而读取和写入某些特性（例如设备的电池电量或电机的每分钟转速）。文章提到可以使用名为 NRF Connect 的应用程序与蓝牙设备进行交互。我打开 iPhone 上的 App Store，下载了该应用程序，打开振动器，然后使用该应用程序连接了它。

连接到振动器后，应用程序检测到了三个不同的服务。第一个是电池服务，第二个是设备信息服务。从名称上很容易推断出它们的用途。我猜想它们都是只读服务，允许应用程序（以及像我这样爱窥探的用户）读取电池电量和振动器的详细信息。第三个服务被 NRF Connect 工具标记为“未知”。我猜测这个服务负责读取和写入振动器电机的状态。

我决定查看“电池服务”以了解能找到哪些信息。正如我所料，“电池服务”中只有一个名为“电池电量”的特征，其值为“读取通知”，值为“0x64”。这是一个十六进制（以16为基数）数字，转换为十进制为100。电池已充满电，随时可用！

我进入了“设备信息”服务，发现它有几个“读取”属性，涉及设备的序列号、型号和其他详细信息。以下是该屏幕的屏幕截图，部分细节已被模糊处理。

这一切都相当容易，但我仍然需要弄清楚应用程序是如何与电机连接的。我导航到名为“未知服务”的页面，看看能否找到一些线索。

有意思！这项服务混合使用了“读取通知”和“无响应写入”特性。它包含两个“读取通知”特性和两个“无响应写入”特性。我推测每个特性都对应振动器上的一个电机。也就是说，振动器有两个电机，每个电机都可以读取和写入数据。这与振动器的物理特性相符。振动器两端各有一个电机，而且它们彼此独立运行。

我注意到与电机关联的两个“读取通知”特性有点奇怪。其中一个特性读取到的值为“0x0000”（上面的屏幕截图显示的是“0x0100”，因为我是在采集到初始读数一段时间后才截取的。我不确定为什么在我第一次看到它到想起要截图的这段时间里，这个值会发生变化。真是个谜。哇，这段括号里的内容有点长了……），这对应于一个关闭的电机（或者至少我是这么认为的），而另一个特性读取到的值为“N/A”。当时，振动器是开启的，但没有振动，所以我发现一个电机发送零值而另一个发送空值很奇怪。我决定快速搜索一下，看看这是否是BLE设备上特性的常见问题，但没有找到任何有用的信息。

附注：学习新事物时，高效搜索非常困难，所以我的搜索语句可能不够清晰，无法获得理想的答案。如果您了解蓝牙低功耗（BLE）以及造成这种情况的原因，请务必告诉我！

总之，我注意到 NRF Connect 应用提供了一个选项，可以写入可写的特性值。这时，我做了任何一个合格的工程师都会做的事：测试一些随机值。我尝试发送“0x64”，它对应十进制值 100，看看这个特性值是否能设置电机的功率等级。结果失败了！

我注意到其中一个特征读取到的零值是一个四位数的十六进制数，所以我尝试发送“0xffff”，但还是不行。真麻烦！

所以，这时我决定尝试其他方法。与其猜测数值，不如打开手机上的 Vibease 应用，在应用里设置振动，然后查看“读取通知”特征值。棘手的是，我无法同时使用手机上的 NRF Connect 和 Vibease 应用，所以我必须想办法从笔记本电脑连接到振动器。我在 Mac App Store 上找到了一款名为LightBlue 的应用，想着可以用它来读取每个特征值，同时通过应用控制振动器。但奇怪的是，当我通过手机应用连接到振动器时，却无法从笔记本电脑连接到它。其实这并不奇怪，完全合情合理。如果我要开发一款智能振动器，我肯定不希望多个设备同时连接到它。

我决定看看有没有适用于 iOS 的蓝牙监听器。我想要一个能在后台运行，并记录手机通过 BLE 发送的所有消息的工具。考虑到苹果对安全性的重视，我估计这种应用在未越狱的 iPhone 上可能无法使用，但我还是决定碰碰运气。一番搜索之后，我找到了StackOverflow 上的一个帖子，里面详细介绍了如何在 iOS 上以“诊断模式”运行蓝牙。我不确定能从苹果提供的日志中获取哪些信息，但我觉得值得一试。最终，我按照StackOverflow 帖子中提供的iOS 蓝牙日志记录官方教程生成了日志。

题外话：苹果公司到底是怎么回事？为什么他们要设计那么多莫名其妙的按键组合才能访问产品的诊断功能？我知道他们为什么要把这些功能设置得这么复杂，但天哪，我感觉按这么多键最后都要得关节炎了！

诊断日志记录的结​​果是一个.tar.gz位于上述说明中指定目录下的文件。我解压缩了该目录，发现其中包含多个诊断文件。

哎呀，我这是给自己惹了什么麻烦？这时，我决定采用一种久经考验、专家推荐的解决问题的方法，叫做“大量点击，大量阅读”。具体做法是打开并阅读大量文件，直到找到一个能解释清楚的为止。

我找到了一些似乎与蓝牙日志记录相关的文件，但在 Wireshark 中打开它们时，却出现了一些完全没有意义的数据。

我还找到了一些引用我用来控制振动器的 Vibease 应用的文件。结果发现它们只是崩溃报告文件。原来，每当我在 Vibease 应用连接到振动器的情况下，尝试从其他设备连接振动器时，Vibease 应用就会崩溃。真有意思！

到目前为止，我已经尝试了足够多的方法，不得不再次重新审视整个方案。经过一番研究，我发现，在安卓系统上嗅探 BLE 信号并获取易于在 Wireshark 中解析的日志非常简单。感觉苹果生态系统在这方面限制了我，不过话说回来，我对这方面还不太熟悉，可能只是不知道该用哪些工具。我又搜索了一下，看看有没有其他适用于 iOS 或 Mac 的蓝牙嗅探器，但一无所获。大多数解决方案都推荐购买像Ubertooth One这样的设备，它专为蓝牙实验而设计。但这款设备价格不菲，零售价在 120 美元到 200 美元之间，远远超出了我这个大学生的预算。我找不到像在安卓系统上那样，直接在 iOS 手机上嗅探 BLE 信号的方法。

我想先暂停一下这个小实验，直接发布这篇博文。如果您是物联网领域的专家，并且对我的后续工作有什么建议，请务必告诉我。

虽然我最终没能实现逆向工程我的振动器与其应用程序之间使用的通信协议的最终目标，但在这次小小的冒险中，我学到了很多东西。

• 当我们使用支持蓝牙低功耗（BLE）连接的设备时，底层运行着大量的技术。这让我想起了那些描绘如果我们能看到WiFi信号世界会是什么样子的图片。海量信息不断地传输，以至于我们在字面意义和比喻意义上都变得“视而不见”。
• 对 iOS 应用进行诊断会生成大量信息。这是我第一次对我的 iPhone 进行分析和记录，看到所有可用的信息很有意思。我可能会对一些经常崩溃的应用进行类似的诊断。如果有时间，我可能会在这里写一篇博文。
• 逆向工程很有趣（但有时也很令人沮丧）。

下次再见！