目录一、简介二、抓取数据三、包头解析四、包裹体解析四.1第一部分4.2第二部分4.3第三部分
一.概述
本文主要记录微信蓝牙数据的分析过程。 需要两个文档：
《微信蓝牙外设协议104.pdf》
《Protocol buffer.pdf》
《Protocol buffer.pdf》的文章举例分析了一系列数据。 这篇文章主要通过一组数据，记录以下两篇文章的使用方法。
二、抓取数据，首先要使用拦截工具抓取一系列空中数据。
以下是APP向空中发送的蓝牙数据：
Fe 010014753100000 a 0012063008001 a 2231800，其中实际传输的数据为33008001a223，其余均与微信协议相关。 我们通过这组数据来看看微信蓝牙协议是如何分组的。
三、包头解析在《微信蓝牙外设协议104.pdf》一文协议部分第7节，说明了微信蓝牙数据包由包头和包裹体组成。
我们采集的数据首先是
//包头fe010014//FE01.1800全长7531//命令。 以下内容见0000//编号///包裹体0a00120633008001a2231800在《微信蓝牙外设协议104.pdf》附录第11段，指令代码可见。
还可以看到，这里的7531表示数据是从APP发送过来的蓝牙设备。
四.包裹体解析从包头中得到命令号7531，然后通过7531发现这是APP发送到蓝牙设备。 现在分析壳体。
返回《微信蓝牙外设协议104.pdf》微信的Protobuf协议部分的第2部分，可以看到APP向蓝牙设备发送RecvDataPush命令。
然后全文搜索RecvDataPush命令，得到以下定义：
那么，这个定义怎么使用？ 这个时候，需要看我们的第二篇文章《Protocol buffer.pdf》。 到此为止，捕获的数据与第二个事例的数据类型正好相同，建议直接查看原文。
为了加深理解，我会转换成自己的语言来说明。
长包裹体分为三个部分，正好对应于我们调查的定义中的三个内容。
要使用这三个内容，需要两个东西。 第一个是数据类型表：
第二个是计算公式
key=field3 | type利用这两个东西，最终将结构体定义的三个部分
key1value1key2value2key3 value 34.1部分要求的基本推式推式推式=1； 首先，可以看到索引值为1，即field=1。
required在这篇文章中解释如下。
Required前缀表示必须在序列化字段之前分配值，而optional前缀表示可以不分配值。
以下两个BasePush相当于char a。 这意味着必须根据数据类型BasePush在表中查找相应type列的值。 发现表中没有BasePush。 《微信蓝牙外设协议104》返回全局搜索BasePush，找到以下定义：
消息库推送{
}
这里可以得到两个信息。 BasePush的真正数据类型是消息，而内容是空的，即按value=0处理。
在表上。 类型=2:
在那里可以计算
因为key=field3 | type=13 | 2=10=0x0A，所以会得到第一部分的最终结果。
0A 00
4.2第二部分请求字节数据=2； 如果Data索引值即field为2、类型为bytes、根据查找表对应的type为2
key=field3 | type=23 | 2=18=0x12，传输的数据为33008001a223，长度为6字节。 得到第二部分的最终结果：
12 06 33 00 80 01 a2 23
如果传输的数据长度超过128字节，则无法直接输入。 必须使用Varint算法。 可以看到下面的笔记。
4.3第三部分第三部分与第一部分方法相同，需要先返回《微信蓝牙外设协议104》查找EmDeviceDataType :
实际数据类型为enum，值为0，即使用供应商定制数据。
在表中查找enum数据类型，得到type=0。
因为key=field3 | type=33 | 0=24=0x18，所以会得到第三部分的最终结果。
18 00
到此为止，我要分析完整个数据。 本文所述逻辑略有跳跃，既有从分析的角度说话，也有从数据包的角度说话。 但是，不管怎样，都是为了说明协议啊。 有时间的话请再回来重新整理。