因为您有 5 条消息中的 3 条完全相同，并且因为其他两条差异很小，所以前两条消息似乎很可能只是被错误地捕获。

尝试检测这种情况的方法是多做几次相同的事情，看看该模式是否成立。

更一般地，对这样的协议进行逆向工程通常首先收集尽可能多的数据。这包括：

1. 美国联邦通信委员会 (FCC) 数据库类型批准数据库条目通常描述射频发射的详细信息
2. 专利信息经常揭示专有消息格式的细节
3. 适用的技术标准，例如本例中的蓝牙
4. 网络上提供的产品信息
5. 产品随附的技术信息
6. 产品附带的逆向工程软件
7. 搜索互联网，看看是否有人已经为你完成了这项工作
8. 您创建的注意事项和相关的捕获文件
9. 有关制作公司的财务/新闻信息。有时会有关于收购产品线的公告或与第三方开发商的交易公告，可以帮助您发现其他查询线。
10. 来自芯片供应商的示例代码。对于某些消费产品，该设备或多或少是由芯片供应商作为样本或参考设计信息提供的定制代码。

所有这些都可以而且经常会产生有用的信息。此外，研究其他类似的协议可以让您深入了解这些数据包中可能包含的数据类型，有时还可以了解各个字段的特定细节，例如 CRC 或校验和计算的细节。

您已捕获蓝牙 RFCOMM 帧。这些包括由蓝牙堆栈处理并且对上覆应用层透明的各种控制字段。（想想串行端口就像添加了开始/停止/奇偶校验位的通信，但只是通过蓝牙代替。）

在你的框架中：

• 第一个字节0B是地址字段。
• 第二个字节EF或者FF是控制字段。
• 第三个字节2B是有效载荷长度字段（0x2B=> 21 字节有效载荷）
• 如果控制字节 = FF，则第 4 个字节与基于信用的流量控制有关。
• 最后一个字节9A或者86是帧校验和

因此，有效载荷数据从第 4 个或第 5 个字节开始，并以倒数第二个字节结束。

在您的情况下，所有 5 个帧都具有相同的 21 字节有效载荷数据，这是应用程序传输的数据，而另一端将接收该数据。

00 11 17 70 02 24 b0 a1 e5 f0 b1 44 0d 8e 53 8f 26 68 8a 3f 07

现在推测，每个 Pebble 应用程序都有一个独特的 16 字节 UUID 帽子，我希望它成为卸载命令的一部分。如果我们假设 UUID 是数据包的最后 16 个字节，那么我们的数据如下-

00 11 17 70 02 [uuid]

的00 11在开始时出现的可能振振有词是某种形式的（大端）长度字段（17个字节）的。在这种情况下，我猜 uuid 与前面的组合02构成 17 个字节。这将导致以下有效载荷结构：

[length] 17 70 { 02, [uuid] }

如果我的推测是正确的，那么这仅剩下17 70和02表示卸载的组合。

通过更多的捕获（卸载不同的应用程序或安装应用程序），应该可以证明（或反驳！）这一点。