BLE直接Data channel抓包方法汇总

之前一致在做一些有关与BLE安全研究的“基础设施建设”工作，我们知道，在BLE进入跳频之后，所有的固定标志都会消失，但是是不是意味着没办法了？不是的。我会提出一些恢复出来的方法。

首先，前导码分析，BLE包的前导码是10101010或者01010101，且与Access Address的LSB有关，所以，按照协议，BLE包的前九位是101010101或者010101010，我们可以通过这个，对整个的数据进行一次初筛。但是这个初筛还远远不够，因为仅仅9位特征，在每秒1M的速率下很容易就会产生一个假的数据包，我们还需要更多的校验。

RFU表示的是为未来的协议进行预留，在协议4.0中，RFU是这样的

协议中规定，RUF应该为0

　这样的话，我们的特征比较位就多了6位，过滤掉的无效包的数量是成几何状增长的。这里需要注意的是，真正的蓝牙芯片是不会进行这个筛选的，也就是如果发送方的芯片不按套路出牌，接收方也是可能准确的收到包的，由于蓝牙芯片的底层不开放，我也不清楚具体的实现，还有，这只是针对蓝牙4.0，如果之后的协议有更改，要具体分析。

Access address也是可以作为一个检验的条件的，如果上上述条件（前导码和RFU）满足的情况下，去截取Access Address，收到了两个一样的，那就基本可以确定这个就是一个正在使用中的Access Address，继而确定数据包。

恐怕最令人信服的确定方法，就是ＣＲＣ校验了，因为它本身就是做这个的，可是在data channel里的ＣＲＣ计算好像并不那么容易，ＣＲＣ的三个要素是生成多项式，输入值和ＣＲＣ初值，可是ＣＲＣ初值是在双方的CONNECT_REQ包中随机由主机确定的，正如上文所说，data channel中没有固定的成分，所以我们要恢复出CRC的初值，这对未来包的确定，甚至伪造发包都十分有用。

CRC初值的计算我用了一个比较有意思的方法———“解方程”，或者叫，约束性求解。我使用了SMT-lib语言进行了一个bit输入下的逆操作，求解引擎输出值显示BLE的CRC24算法生成多项式是可逆的，并输出了一组特解。我并不清楚这个特解是否为唯一解。

后来有仔细看了看bit序列，感觉用约束性求解有点麻烦了，在已知输入输出和生成多项式的条件下，直接使用LFSR就行了，也就是生成CRC的LFSR的逆运算。