ZJevon 发表于 2021-3-9 12:57

某聊天工具消息记录数据库文件解密逆向分析

本帖最后由 ZJevon 于 2022-12-29 12:44 编辑

## 0x00 简介

每一个聊天工具账号登入后会在“ \Document\Tencent Files\账号” 的目录下Msg3.0.db 文件里写入加密后的聊天记录信息。
!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210308211244.png)

查看QQ的Bin目录下的Dll文件可以知道QQ用的是sqlite的数据库,sqlite默认是没有实现加密的函数只是提供了接口,网络上有一些开源的加密库比如wxsqlite3,sqlcipher等。

## 0x01 前期准备

先再IDA中分析sqlite.dll,查找含有version字符串的函数然后交叉引用,找到上一个函数就可以发现当前QQ使用的sqlite的版本号,可以从网上Down下来源码方便进一步分析,下载链接在文末。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210308211748.png)

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210308211800.png)

sqlite的加解密简易流程

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309094749.png)

## 0x02 获取加密所需的函数

在sqlite.dll里对这些函数下断点动态调试发现没有断下来,结合网络上前辈的分析,IDA中打开KernelUtil.Dll函数名字都很类似,猜测这个Dll就是tx自己对sqlite的具体实现。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210308215915.png)

我们可以先在CMultiSQLite3DB::innerOpen等open函数下断点,并打开火绒剑对文件操作进行监控。具体下断点的方法就是附加聊天工具进程然后在模块里找到KernelUtil.Dll,在IDA找到要下断点的函数的偏移,就是要下断点的位置。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210308220931.png)

然后观察堆栈传递的参数结合火绒剑和x96dbg单步步过,就可以找到是哪个函数真正打开db文件。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210308221237.png)

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210308221340.png)

结合sqlite源码和IDA分析可以还原参数和函数名。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210308221502.png)

在innerOpen这个函数中我们可以看到CppSQLite3DB::execDML这个函数,我们可以大胆猜测它是封装了sqlite3_exec,结合源码进行重命名。sqlite3_exec的第三参数和第四个参数是回调函数,主要的作用是接收sql语句执行的结果,这个在后续编写Demo有用到,具体用法在文末的链接可以参考。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309103314.png)

sqlite3_key的具体实现函数我们可以在IDA中观察CppSQLite3DB::key这个函数并结合sqlite3的源码可以推测真实设置key的函数,不妨在此处下断点,后续抓取Key时有大作用。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309101322.png)

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309112639.png)

至此我们获得了后续抓取解密Key所需要的几个函数地址,在x96dbg的对应偏移位置下上断点。

## 0x03 抓取解密Key

key是云端生成的理论上**没有账号的密码是打不开这个聊天记录文件的**,并且在每次重启聊天工具进程后的密钥都是不一样的,所以这里得注意**抓到密码后关闭进程后得备份Msg3.0.db**这个文件,文件于key是一一对应的。

我们先让它正常登入然后在火绒剑观察它是什么时候对Msg3.0.db进行操作的。可以发现是在比较前面就打开了Msg3.0.db所以大胆猜测是在其进程在刚启动的时候执行解密操作。接下来附加QQ进程开始调试。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309110940.png)

在附加它进程的时候得注意,选择上面那个进程,下面那个是登入进程在登入成功后会自动销毁了。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309105354.png)

在CreateFileW下断点观察火绒剑和x96dbg堆栈直到发现它打开了Msg3.0.db这个文件

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309111749.png)

一直F9直到调用sqlite3_open函数的参数有Msg3.0.db(期间可能有多个地方调用了open,真实的是先调用open后调用key,多次尝试可以试到真实获取解密Key的地方),根据上文可知sqlite会先打开对应db文件并在后面在设Key,根据IDA分析结果可以知道原视Key是16位的,扩展之后变成16 * 17位了。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309112340.png)

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309114249.png)

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309114400.png)

有了扩展Key可以直接调用sqlite3_key_impl这个实现函数,也可以使用原始16位Key直接调用sqlite3_key。备份好Msg3.0.db和Key开始编写demo。

## 0x04 总结

总的来说主要是要找到sqlite解密的各个函数的偏移地址和解密Key,有个小坑就是Key是动态的而且和Msg3.0.db一一对应的,每次抓到Key得记得备份Msg3.0.db。所以我们可以直接调用tx的KernelUtil.Dll,在Load KernelUtil.Dll的时候要注意放在QQ\Bin 目录下不然会导入失败,因为KernelUtil.Dll还有导入其他的Dll。

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309123845.png)

!(https://jev0n-1252378932.cos.ap-shanghai.myqcloud.com/img/20210309124343.png)

## 0x05 参考链接

sqlite v3.8.8.1下载链接:(https://www.sqlite.org/2015/sqlite-amalgamation-3080801.zip)

sqlcipher v3.3.1下载链接:(https://codeload.github.com/sqlcipher/sqlcipher/zip/v3.3.1)

[**撬开PC QQ的本地SQLite数据库(适用于Msg3.0.db等)**](https://www.52pojie.cn/thread-1370802-1-1.html)

(https://blog.csdn.net/zscfa/article/details/77119522)



***本文仅供学习参考,切勿用于违法违规行为***

JuncoJet 发表于 2021-3-9 17:07




发现TIM的Key地址是固定的,流弊了!就是个写死的全局变量啊
而且不同QQ号,也是一样的

15555559119 发表于 2021-3-10 07:15

这是大哥,真专业。要是能做个小程序,给小白,小白直接调取这个文件 然后读取本地消息那就更加牛逼了。

ZJevon 发表于 2021-3-11 13:52

jack940213 发表于 2021-3-11 13:13
如果我使用旧密码备份了聊天记录文件,然后退出QQ,在更改密码后重新登录是否也能读取这个聊天记录文件呢

这个Key以及Msg3.0.db是一一对应的和修不修改密码是没有关系的,每次重新登陆远程都会下发一个新的Key老的Key对应新Msg3.0.db自然就没用了。

Fxhlt 发表于 2021-3-9 13:03

厉害了哥   

lvyiwuhen 发表于 2021-3-9 13:07

牛,我曾经也想过研究,奈何水平有限,没想到你替我实现了:lol

壹分叁拾秒 发表于 2021-3-9 13:18

大神就是大神,牛!!

apie 发表于 2021-3-9 13:23

每次key都是动态的,那么是不是意味着Msg3.0.db文件都会在登陆之后有变化?那其他文件呢?如果本地聊天记录有好几g,每次登陆也都会变吗?

glau29 发表于 2021-3-9 13:25

这研究精神,佩服佩服{:1_893:}

ZJevon 发表于 2021-3-9 13:39

apie 发表于 2021-3-9 13:23
每次key都是动态的,那么是不是意味着Msg3.0.db文件都会在登陆之后有变化?那其他文件呢?如果本地聊天记录 ...

其他文件可以登入QQ-下线后看修改时间来判断是否被修改了,Msg3.0.db我试的几次都是会变化的,我感觉他应该是追加了本次登录到下线期间的修改内容。

断桥隔爱 发表于 2021-3-9 13:45

这个真的是大牛级别

lin326326 发表于 2021-3-9 13:58

POC呢{:1_889:}

Flymeee 发表于 2021-3-9 14:09

这个就叫专业。
页: [1] 2 3 4 5 6 7 8 9 10
查看完整版本: 某聊天工具消息记录数据库文件解密逆向分析