chatgpt写java代码怎么弄 关于Nokelock蓝牙锁破解分析
专业出黑
本文为看雪论坛精华文章
看雪论坛作者ID：
前言
今年西湖论剑的时候是一个蓝牙题都没做出来，之前复现师傅出的硬件题的蓝牙部分也没完全弄懂，于是下定决心通过几个设备来研究研究。
刚学pwn的时候，对宿舍楼下的小蓝车就有所“垂涎”，一直在思考如何打（太可刑了）。
经过给小蓝车app投资数次1.5米巨资过后，作为名义上的股东，我大概弄清楚了小蓝车的锁应该也是蓝牙的（因为每次连它都让我开蓝牙233）。
为了避免下半辈子只能在几平米的空间活动，我在某鱼上淘到了一款蓝牙锁作为小蓝车的平替。
这里简单**一下研究的过程。
nRF蓝牙抓包
首先需要解决的问题是获取蓝牙锁的MAC地址，因为最后我们需要使用（后面会提到这个工具）直接通过MAC地址与蓝牙锁交互。
比较好用的是nRF这个软件（苹果手机可以用），能够直接扫描查看周围的蓝牙设备。
但如果直接在生活区进行抓包干扰因素非常多：
于是我们跑到一个没有其它设备的地方轻触指纹区域，当亮起红光的时候：
在nRF上就能看到设备名和MAC地址了：
可以看出设备名为，MAC地址为F0:45:DA:AA:F4:36。
蓝牙扫描
初步扫描
通过树莓派+蓝牙适配器的组合
环境搭建详见：[原创]基于树莓派的蓝牙调试环境搭建-智能设备-看雪论坛-安全社区|安全招聘| ()
使用的scan on功能，就能扫描出设备：
表示我们的蓝牙调试环境没有问题。
使用尝试连接并使用看查所有：
然后通过命令看查所有的特性：
其中是特性的句柄，char 是特性的属性值，char value 是特性值的句柄，uuid是特性的标识。
虽然扫描出了和，但我们还不能直观的知道这些服务是用来干什么的，而且也没法将特性和服务配对。
下面我们使用这一个强大的工具中的"ble.recon"模块，进行深入的扫描和理解。
深入扫描
githu仓库：
个人认为仓库给出的安装教程非常的模糊，很多东西都没有说清楚，所以这里简单讲讲我是怎么安装的。
环境：或树莓派4b 安装：
（1）首先需要安装go环境：
sudo apt install golang-go
（2）go“换源”：
echo "export GOPROXY=https://goproxy.io,direct" >> ~/.profile && source ~/.profile
（3）安装依赖：
sudo apt install build-essential libpcap-dev libusb-1.0-0-dev libnetfilter-queue-dev libssl-dev libnl-3-dev libnl-genl-3-dev pkg-config
（4）安装软件包：
git clone https://github.com/bettercap/bettercap.git
cd bettercap
make build
sudo make install
然后输入如下命令就能够使用低功耗蓝牙功能了：
sudo bettercap
ble.recon on
具体的用法可以参考官方手册：
对于我们刚才提到的需要，使用ble.enum就好啦：
可以发现，通过ble.enum，能够形象地看出所属的以及它们的属性。
接下来我们就可以通过蓝牙嗅探，看看在开锁的过程中涉及的服务和特征。
蓝牙抓包
初步扫描
通过 one，我们嗅探到了如下的蓝牙数据：
可以看出大致分为"Write "和" Value "两类，我们各点开一个看看。
"Write "：
" Value "：
可以发现它们的分别是0x3和0x6，分别对应的是前面里获取的UUID为36f5和36f6的特征，十分合理。
于是以后的抓包我们可以给出如下过滤（上面那张图片这么规整已经是过滤过后了的）：
(btatt.opcode == "Handle Value Notification" && btatt.handle == 0x6 ) || (btatt.opcode == "Write Request" && btatt.handle == 0x3)
多次尝试抓包，发现value的值差别很大，猜测有所加密 那么下一步就要从安卓逆向的角度分析app里的加密模式和密钥了。
思路二：从BUG日志中获取蓝牙HCI日志
实际上可能会出现很难抓到包的情况，所以这里提供第二种思路供大家尝试：
嗅探是中间信道，很可能会受到干扰，于是我们尝试从手机的蓝牙日志里直接获取和锁的通信。
首先需要打开开发人员选项，一般的手机都是在"关于本机"的位置点击多次版本号就可打开。
进入开发人员选项后，开启"蓝牙HCI信息收集日志"。
然后我们需要使用"adb"这个调试工具，连上手机，然后dump下BUG日志。
解压这个zip文件，在解压目录下会生成同名的一个txt文件：
把它拖到里面（不知道为啥，在我的上会有问题），然后下载一个叫.py的脚本并把它放在和这个文本文件同目录下，执行如下命令：
LC_CTYPE=C sed -n "/BEGIN:BTSNOOP_LOG_SUMMARY/,/END:BTSNOOP_LOG_SUMMARY/p " bugreport-ASK-AL00x-HONORASK-AL00x-2023-04-03-08-31-01.txt | egrep -av "BTSNOOP_LOG_SUMMARY" | python btsnooz.py > hci.log
（ps：为什么命令会和官方的教程有点不太一样，因为产生了如下的报错和解决办法）
然后就得到了能够用查看的蓝牙日志"hci.log"了:
可以看到效果非常好，但是在笔者的手机上的数据会有一个问题，就是value显示不全：
不知道是不是脚本对数据包有所切割，反正就感觉很离谱。
而且这种方法对我平时用的手机也不生效，甚至不能产生hci.log文件。
app逆向分析（初步）
将apk拖进JEB中，然后在层级的com...b.b里面能找到加密和解密的地方：
差别就是Ciper.init()的第一个参数，询问一下：
观察类中的这两个方法，都涉及两个byte数组参数arg2，arg3：
arg2对应的是密文/明文，arg3对应的是密钥。
具体的用Ciper类加密可以参考这一篇文章：Java使用类实现加密，包括DES，DES3，AES和RSA加密 - 蔡昭凯 - 博客园 ()
经过上面的分析，我们知道了加密算法是AES而且是ECB模式无，但是还不知道密钥和密钥长度。
接下来我们尝试在apk里进行插桩，目的是打印密文/明文，密钥来分析实际上开锁的时候在apk中的数据。
app插桩
插桩过程
实际上插桩这步是劳烦oacia爷帮我做的，教程同步到了他的文章：[原创]对某apk的一次插桩**-安全-看雪论坛-安全社区|安全招聘| ()
写的非常好，这里就不再班门弄斧了。
可能唯一没太讲清楚会遇到问题的是，使用他给的smali进行插桩会和上的项目会有一点点差别：
invoke-static {p0}, LSewellDinGLog;->Log([B)V
在最后插桩的时候，这里从变成B类（字节数组）了，如果还是使用类会有问题。
因为我们重写的java源码是对字节数组进行的操作，可以参考原来的apk里类似对字节数组的操作的smali代码：
然后还有一个神奇的问题，就是在笔者的电脑上使用回编译过后的apk，会缺少签名、主SDK等等东西：
这种APK在我的手机上安装不了，但雷电模拟器能装（但先要使用这个工具对回编译的APK进行签名）。
于是我把雷电模拟器里的apk导出来，它的这些东西又变正常了：
非常神奇，然后顺利成章的我的手机也能装了。
插桩打印信息分析
通过adb工具，我们能够连接安卓设备并且执行一些命令。
这里我们通过adb 命令来搜索查看插桩打印的信息：
F:platform-tools>adb logcat -s SewellDinG
--------- beginning of main
03-27 17:18:08.895 31117 31117 D SewellDinG: 05010630303030303082E3C89616017D
03-27 17:18:08.895 31117 31117 D SewellDinG: 241F632E5907042061014C1A3A45193B
03-27 17:18:08.895 31117 31117 D SewellDinG: 6629B62C88A7E50525E92C328AF258E6
03-27 17:18:10.114 31117 31117 D SewellDinG: 732F5CB22C06B0C2D0D17AD31D165805
03-27 17:18:10.114 31117 31117 D SewellDinG: 241F632E5907042061014C1A3A45193B
03-27 17:18:10.114 31117 31117 D SewellDinG: 05020100E3C896010202000000000000
03-27 17:18:11.770 31117 31117 D SewellDinG: 530B1FCA1467A408A321E71F3D152127
03-27 17:18:11.771 31117 31117 D SewellDinG: 241F632E5907042061014C1A3A45193B
03-27 17:18:11.772 31117 31117 D SewellDinG: 050D0100E3C896010202000000000000
03-27 17:18:37.864 31117 31117 D SewellDinG: 05010630303030303082E3C89601635C
03-27 17:18:37.864 31117 31117 D SewellDinG: 241F632E5907042061014C1A3A45193B
03-27 17:18:37.864 31117 31117 D SewellDinG: 3FFA9BE0BA05D2ECC8CF74D2CDB7867C
03-27 17:18:39.263 31117 31117 D SewellDinG: 732F5CB22C06B0C2D0D17AD31D165805
03-27 17:18:39.263 31117 31117 D SewellDinG: 241F632E5907042061014C1A3A45193B
03-27 17:18:39.263 31117 31117 D SewellDinG: 05020100E3C896010202000000000000
03-27 17:18:40.923 31117 31117 D SewellDinG: 530B1FCA1467A408A321E71F3D152127
03-27 17:18:40.923 31117 31117 D SewellDinG: 241F632E5907042061014C1A3A45193B
03-27 17:18:40.924 31117 31117 D SewellDinG: 050D0100E3C896010202000000000000
解密
在插桩打印的信息中有两个点值得我们注意：
（1）"B"这个字符串一直在重复，且一直处于一组数据的中部。
（2）出现了以"050D"、"0502"、"0501"开头的后面不大一样的疑似有规律的数据。
根据我们的插桩，一直处于中部的数据只可能是密钥，那么"B"就是密钥的某种形式。通过密钥创建的方法""的参数类型可以看出，这是密钥的16进制字符串表示：
对输入如下指令即可自动生成解密脚本：
请用python实现一个密钥的16进制字符表示形式是241F632E5907042061014C1A3A45193B的ECB模式无padding的AES-128解密程序，并以16进制字符串的形式输出打印明文
解密脚本：
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives.ciphers import Cipher
from cryptography.hazmat.primitives.ciphers.algorithms import AES
from cryptography.hazmat.primitives.ciphers.modes import ECB
from cryptography.hazmat.backends import default_backend
import binascii
# 转换输入的16进制字符串为字节串
key_hex = "241F632E5907042061014C1A3A45193B"
key = binascii.unhexlify(key_hex)
#key = b"[B@7ef20235"
# 创建 AES 密钥
if len(key) == 16: # 128 bit
algorithm = algorithms.AES(key)
else:
raise ValueError("Invalid key size")
# 创建解密器
backend = default_backend()
cipher = Cipher(algorithm, modes.ECB(), backend=backend)
decryptor = cipher.decryptor()
# 解密密文
#iv = "a20e10ec8ebfd6069c1f84a9cff39e33"
iv = "51653e25e098f5e74e0f152062ee6d5d"
encrypted_data = binascii.unhexlify(iv)
decrypted_data = decryptor.update(encrypted_data) + decryptor.finalize()
# 打印解密结果
print(binascii.hexlify(decrypted_data))
运行结果：
对我们之前的里的数据都进行解密，然后把结果用XLS表示出来：
在app里的com...mode.order可以发现和"Write "解密出来的头4个字符有关的enum：
添加到表格中：
发现有一个特别令我们欣喜的东西——""
是否意味着我们把这个value的值通过蓝牙工具发到锁中锁就开了？
答案是否定的，这个value以及它解出来的text是会变的，这一点比照前面adb打印插桩的同样的"0501"开头的数据就知道。所以我们还需要知道怎么获得这个"变"的东西。
值得注意的是，同样在这个地方有个""字样：
猜测变化的值和这里有关。
至于有没有和" Value "有关的类似的enum，在com...mode.a里找到了这个：
不难看出，这里的代码应该是app接收到蓝牙锁返回的" Value "的value，将它解密过后根据前4个字符去执行对应的功能。而且根据"0202"这个分支里的具体内容已经能大致猜测这里响应的内容是什么了——电池电量，因为有个（v1
