之前9.7.23.29368的时候，用pcqq_get_key.py和pcqq_rekey_to_none.cpp是能正常解密的，更新到9.7.25.29417之后就不行了。
用x64dbg来手动hook，发现获取key的方式还是一样的，因此我又尝试着改动pcqq_get_key.py。
根本问题在于找不到name_function的十六进制特征了，我不确定这个对应的是哪个函数。不过key_function仍然可以找到。
name_function实际上的用途就是从它的第一个参数中得到数据库文件的路径，并进而判断是否是Msg3.0.db。而在我前面hook的过程中也发现，实际上key_function的第一个参数也是数据库的路径，我不确定这是否是9.7.23.29368之后才有的更新，还是原本就是这样。
总之，修改方法就很简单了，把name_function相关的代码都去掉，用key_function的第一个参数来获取数据库路径：
Interceptor.attach(key_function, {
onEnter: function (args, state) {
var ebp = this.context.ebp;
console.log("[-] sqlite3_key called");
//var dbName = funcName(args[0], NULL).readUtf8String();
var args0 = ebp.add(0x08).readPointer();
var dbName = args0.readCString();
......
pcqq_rekey_to_none.cpp这里的问题是找不到open函数了。但毕竟这里解密不需要hook QQ本身，只是需要加载KernelUtil.dll而已，于是我直接找了一个9.7.23.29368版本的KernelUtil.dll，改一下文件名放在Bin下面，改成加载这个旧版的dll而不是新版的，就能正常解密了。
之前9.7.23.29368的时候，用pcqq_get_key.py和pcqq_rekey_to_none.cpp是能正常解密的，更新到9.7.25.29417之后就不行了。
用x64dbg来手动hook，发现获取key的方式还是一样的，因此我又尝试着改动pcqq_get_key.py。
根本问题在于找不到name_function的十六进制特征了，我不确定这个对应的是哪个函数。不过key_function仍然可以找到。
name_function实际上的用途就是从它的第一个参数中得到数据库文件的路径，并进而判断是否是Msg3.0.db。而在我前面hook的过程中也发现，实际上key_function的第一个参数也是数据库的路径，我不确定这是否是9.7.23.29368之后才有的更新，还是原本就是这样。
总之，修改方法就很简单了，把name_function相关的代码都去掉，用key_function的第一个参数来获取数据库路径：
pcqq_rekey_to_none.cpp这里的问题是找不到open函数了。但毕竟这里解密不需要hook QQ本身，只是需要加载KernelUtil.dll而已，于是我直接找了一个9.7.23.29368版本的KernelUtil.dll，改一下文件名放在Bin下面，改成加载这个旧版的dll而不是新版的，就能正常解密了。