小米手环2的连接认证机制
之所以小米手环2没有1那么方便调戏，是因为2中加入了认证机制，如果连接手环的中心设备不能完成认证，手环就会在十几秒后主动与中心设备断开连接，即使是在这几十秒里也只有对认证有关的characteristic进行操作时，手环才会应答。下面我简要分析一下小米手环2的连接认证过程。
包含认证characteristic的service的UUID：0000fee1-0000-1000-8000-00805f9b34fb
认证characteristic的UUID：00000009-0000-3512-2118-0009af100700
- 打开手环的认证通知
获取认证characteristic的descriptor，并以要求response的方式向descriptor写入0x01,0x00 - 获取随机数
向认证characteristic中以不要求response的方式写入0x02,0x00。之后手环会把0x10,0x02,0x03+16 bytes的随机数这一共19bytes的数据以认证Characteristic的notify的形式发送给我们。如何获取随机数时出错，手环会在认证Characteristic的notify中发送0x10,0x02,0x04
告诉我们出错了，这时因重新写入，再获取一次。 - 加密随机数
在获取随机数之后，我们要用16bytes的key对随机数进行AES-ECB加密，至于这个key哪来的呢。。。我也不知道，自然是和网络账户有关（打开小米运动时需要先用微信或小米账户登录，并且只要登录同一账户，在不同手机上都可以连接手环，也就是说账户与key对应，不过我不确定一个账户对应几个key，如过是我，我就会拿网络账号直接算个MD5当成key，这样是一一对应）。当然这就意味着这个key可以瞎编一个，只要16bytes就行，不过如果你非想知道，那需要打开手机的蓝牙日志，解绑手环，再重新绑定，然后用adb拉取日志，再用wireshark打开，之后寻找手机与手环认证时的数据包，其中包含着key。 - 发送加密后的数据
加密随机数后，我们要把加密后的数据加上0x03,0x00的前缀后再以不要求response的形式把这18 bytes写回认证Characteristic。这之后手环会将我们对随机数加密的数据与手环自己用预存在手环中的key加密随机数后的结果进行比较，如果相同，则认证通过，手环会在认证Characteristic的notify中发送0x10,0x03,0x01告诉我们认证成功。如果不同，则手环仍以notify的方式发送0x10,0x03,0x04告诉我们加密结果不符，这时要么是我们加密错误，要么是我们的key不正确，这样就还需下一步骤。小米通过这种机制来区分手环和其对应的手机，以防止周围有多个手环时配对错误。 - 发送秘钥
针对第4步中key错误时，和手环根本从未绑定过（即没有预存过key）的情况，我们需要向手环发送key来覆盖（保存）key。将0x01,0x00+16 bytes的key 这一共18 bytes以不要求response的形式写回认证Characteristic中。（这也就是为什么我们能在手机的蓝牙日志中截获key）这时手环会震动，并显示要求我们点击手环上的按键，如果招办，手环会清除原有数据，也就是恢复出厂了。如果我们不管它，它亮一会儿就消停了。（但是这种机制没有黑名单也没有超时机制，也就是说我们可以一直发送key，让手环震动不停，逼手环主人点一下按键，这其实是小米手环2的一个漏洞，或者说不足之处）如果在发送key时出错，手环会以notify的方式发送0x10,0x02,0x01告诉我们key发送失败。
