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的逆运算。

       

  • 相关阅读:
    设计模式--22、状态模式
    设计模式--21、备忘录模式
    设计模式--20、迭代器模式
    关于分布式事务、两阶段提交协议、三阶提交协议
    分布式系统的一致性探讨
    分布式系统的BASE理论
    分布式系统的CAP理论
    Kafka集群环境搭建
    Elasticsearch插件head的安装(有坑)
    centos6 x64安装elasticsearch5.5.2启动报错
  • 原文地址:https://www.cnblogs.com/backahasten/p/7404301.html
Copyright © 2011-2022 走看看