zoukankan      html  css  js  c++  java
  • 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,继而确定数据包。

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

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

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

       

  • 相关阅读:
    02-链路层
    01-TCP/IP概述
    ARM Cortex-A9 (tiny 4412)
    STM32 f407 温湿度采集报警
    arduino mega 避障报距小车
    归纳法调试
    python 数据类型Ⅲ(字典)
    Python 数据类型Ⅱ(列表,元祖)
    Python 数据类型(str,int,bool)
    Python while循环&格式化输出&运算符
  • 原文地址:https://www.cnblogs.com/backahasten/p/7404301.html
Copyright © 2011-2022 走看看