BLE安全入门及实战（2）
目录
BLE的分析
1、使用蓝牙扫描APP
2、使用工具bleah
3、使用工具gatttool
获取BLE的数据
1、手机蓝牙日志
2、认证过程分析
3、ubertooth嗅探
4、中间人
BLE的分析
1、使用蓝牙扫描APP
环境：android
工具：no.nordicsemi.android.mcp_87.apk
依次点开可以看到相应的属性及属性值
2、使用工具bleah
地址：https://github.com/evilsocket/bleah/ 安装上，直接运行bleah。
输出
这个就是我们模拟出来的智能门锁。
使用bleah -b "b8:27:eb:90:28:e1" -e 连接
输入的内容为：
工具已经做好了data的解析
可以看到handle为 000c的是可写的，uuid是： 6834636b-6d33-4c30-634b-436852436d44，是属于厂商自定义的uuid值，但是此时并不知道是写入的啥值才能操作智能门锁。
3、使用工具gatttool
直接运行 gatttool -b b8:27:eb:90:28:e1 -I
此时出现：
提示连接成功，此时已经与智能门锁建立了链接
使用 primary查看主要的server
使用 characteristics 查看所有的属性
使用 char-read-hnd或 char-read-uuid来读取里面的值
我们来读
是ASCII码，转码的话可以看到就是 raspberrypi
里面还有
两个方法，就可以往智能门锁中写入蓝牙数据。
获取BLE的数据
1、手机蓝牙日志
首先需要打开开发者调试工具，抓取蓝牙数据包，这个网上有不少的教程，这里不再细说。
抓取到的log文件可以直接用wireshark打开，这里做了两个操作，一个开锁，一个关锁。
wireshark打开后的界面显示如下：
APP端为localhost，智能门锁为remote。
结合下文的协议栈可以看到上层的协议为ATT：
过滤协议ATT：
可以看到均是对handle为000c的写操作，符合前面的分析。
直接看数据值，有两个值：bb010203040506070809101112131415 和 aa010203040506070809101112131415
也就是说发送这两个数据就会产生开锁和关锁的操作，这里先记录下来，后面我们演示攻击时候再用。
这时候直接发送这个数据，门锁是不认的，原因是没有进行配对操作，在看树莓派上的日志输出可以看到：
里面是包含了认证的过程的。
我们在手机上抓包认证过程：
2、 认证过程分析
我们分析这个认证过程：
‑ 客户端请求handle:0x0013 uuid:6834636b‑6d33‑4c30‑634b‑436852537434
‑ 服务器端返回一个值：769675d7c11f336ae6573e7e533570ec
‑ 客户端写入一个值：e1cbdfb88d05890a935bf830fb9fbd1000
此时完成了认证过程。
客户端应该是利用服务器返回的值计算一个值，与服务端一致则可通过认证 这个值的计算过程在app中应该是存在的，我们反编译APP查找计算逻辑。
反编译的过程不再多说。
找到的逻辑为：
calculateResponse函数为：
相关的配置信息是：
从这个配置信息也能看到开锁和关锁的蓝牙数据。
加密逻辑采用了AES算法：
1. 首先使用key对传递过来的挑战码进行AES加密，生成下一步用的加密key
2. 使用生成的加密key对登入密码”DDAAFF03040506070809101112131415”进行加密，生成认证码
关键是找首次加密的key,在第一次启动的时候会有个唯一的设备号，第一次的私钥应该是和设备号的生成有关。
初始化设备和app，重新使用wireshark抓包 门锁传递密钥.log
可以看到是app给设备端写的密钥，所以应该是app生成的密钥信息，然后写给设备端。
触发这个写密钥的操作为：
app首先请求设备端的handle为0x0013的值，设备返回未空，
也就是”BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB” 后面app向0x000c写一个设备号，然后写密钥信息进去，然后设备AES计算完成配对。
其实设备端留有个后门：
有个万能密钥：4861636b6d654c6f636b4d6173746572
3、ubertooth嗅探
ubertooth是个很强大的蓝牙嗅探工具，安装比较复杂，你要信任docker的话直接用docker启动ubertooth就可以，还是比较方便的。
需要注意的是需要特权模式，将dev目录挂载到docker里面
docker run --rm -it --privileged -v /dev:/dev meatmanek/ubertooth:latest
查看版本号：
root@da81bdbaf272:/ubertooth-2015-10-R1/host/kismet/plugin-ubertooth-phyneutral# ubertooth-util -v
Firmware revision: 2015-10-R1
说明docker识别了设备
上面我们知道了模拟门锁的mac地址为：b8:27:eb:90:28:e1，只要使用ubertooth ‑f ‑t b8:27:eb:90:28:e1 跟踪数据，进行嗅探即可。
4、中间人
采用的工具是https://github.com/DigitalSecurity/btlejuice
搭建测试环境，具体过程不细说了，具体用到了一个虚拟机，可以在https://mega.nz/#!vxU0zIwJ!fMotiX3ARWcwNm67IAtn2ymHKldpVJgo43YkVZrtH4A 下载虚拟机镜像 过程中出现了vbox无法识别usb设备的问题，这个只需要把当前用户加到vbox的组里就行，还有出现一些无法发现 service的问题，具体可以在issus中查找到问题原因。
搭建好了之后：
vbox运行代理:btlejuice_proxy
宿主机运行btlejuice ‑u 代理ip ‑w
打开本地的8080端口，出现web页面
后面直接操作即可，很直观的操作。
下面主要是分析，我们用APP连接设备，看到web上有数据输出，也就是说代理已经截获到了app与设备之间的数据：
根据前面的分析得知read首先去读取的是挑战码，然后APP根据AES计算处认证值写入设备完成匹配，看到第二条数据应该就是认证码，第三条数据是写入开锁的操作。