【转载汇总】关于QQ读取Chrome等浏览器历史记录事件

以下为整理的内容

v2ex用户mengyx发帖《QQ 正在尝试读取你的浏览记录》称“前些天用 QQ，为了防止一些流氓行为，特地去的 MS Store 里面安装的 QQ 桌面版。幸好之前用火绒的自定义拦截功能，设置了一些重要或敏感数据目录的保护。结果拦截到QQ独取chrome浏览器的历史记录。”

拦截日志如下：

帖子发出后马上有人进行了分析研究，看雪论坛的用户对QQ的行为进行进行了逆向分析，实锤了QQ在独取chrome的历史记录，并且是读取了所有浏览器的历史记录。分析帖子如下：

《关于QQ读取Chrome历史记录的澄清》

今天看到群里有同学发了一篇v2ex上的帖子（https://www.v2ex.com/t/745030），说QQ会读取Chrome的历史记录，被火绒自定义规则拦截了，本来我是不信的，但是他说他复现了，而且是QQ登录10分钟后才会去访问。

这我就想去验证下了，开虚拟机装QQ、Chrome，然后打开Process Monitor开始等。规则简单的过滤下。

果然看到了读取AppData\Local\Google\Chrome\User Data\Default\History等目录的操作。

而且时间也是恰到好处的十分钟。

这是实锤了QQ和Chrome过不去啊，这我可不信，把规则去掉，重新翻了一下才发现果然是冤枉QQ了啊

受害人之多令人震惊，仔细一看，这玩意是遍历了Appdata\Local\下的所有文件夹，然后加上User Data\Default\History去读啊。User Data\Default\History是谷歌系浏览器（火狐等浏览器不熟，不清楚目录如何）默认的历史纪录存放位置，Chrome中枪也就很正常了。

然后就该研究研究QQ为啥要这么干了，读取到的浏览器历史记录又拿来干啥了呢？

挂上x32dbg，动态调试找到位置。

然后去IDA里直接反编译出来，如下（位置在AppUtil.dll中 .text:510EFB98 附近）

这一段的逻辑还是很好看懂的，先读取各种 User Data\Default\History 文件，读到了就复制到Temp目录下的temphis.db。回去看下Procmom，果然没错

再之后的操作就简单了，SQLite读取数据库，然后“select url from urls”，这是在干什么大家都懂哈。后面就不接着讲了，有兴趣的可以自己接着看。

结论，QQ并不是特意读取Chrome的历史记录的，而是会试图读取电脑里所有谷歌系浏览器的历史记录并提取链接，确认会中招的浏览器包括但不限于Chrome、Chromium、360极速、360安全、猎豹、2345等浏览器。

晚上来编辑一下，刚才去试了下TIM，果然经典重现，而且比QQ还离谱，不多说直接上图。

1月17日晚上看雪论坛用户anhkgg也发表了一个帖子《QQ后台读取历史记录？有点冤枉企鹅了!》，试图在分析QQ读取记录的原因。帖子内容如下:

起因

今天看雪一篇帖子关于QQ读取Chrome历史记录的澄清访问量突然爆发，貌似引起了很大的震动。

帖子内容大致是，作者(qwqdanchun)看到v2ex一篇帖子《QQ 正在尝试读取你的浏览记录》说QQ后台尝试读取你的浏览器历史记录。

然后本着探索的精神，作者去简单抓取了一下QQ的文件访问行为，和简单的逆向分析。

然后得出结论是，QQ并不是针对Chrome，而是会遍历读取所有浏览器历史记录，确认会中招的浏览器包括但不限于如Chrome、Chromium、360极速、360安全、猎豹、2345等浏览器（看出了吗，就是所有使用chrome内核的浏览器）。

这个…我有点…震惊！不敢置信。

所以，根据作者帖子提供的线索，我也去看了看QQ相关位置的代码，究竟是做什么功能，一探究竟。

仅仅做技术探究没有针对qwqdanchun的意思，如果不对，请原谅。

分析

原帖作者通过history搜索到关键代码，我也照着做了，然后发现了不同的事情。

可能有点先入为主，原帖作者并没有怎么仔细看相关代码的逻辑和功能，认为QQ读取了chrome历史记录文件并进行了sqlite数据操作。

其实呢？如果仔细一点，就会发现下面的代码。

很明显，QQ仅仅暂时拷贝了chrome历史记录文件到临时文件temphis.db，然后刷选了url进行了一些检测，log信息中看到关键字ptjcur Detect2。

然后通过DeleteFile删除了临时文件temphis.dbg，中间代码也并没有发现什么上传服务器的代码。

所以我觉得原帖作者得到QQ后台读取浏览器历史记录，并臆测可能会对用户做什么危害的行为，有上升到了用户隐私上，这个结论确实是有点不妥的。

因为读取历史记录和删除临时文件中间并没有什么上传服务器之类的操作，所有都是本地完成的。

这个结论对企鹅有点不公平，对一个如日冲天的互联网公司不公平。

不能因为某些xx历史行为，就无脑接受坏人设定，不清楚细节就轻易下结论，当然我并不否认那些历史xx行为。

为了搞清楚真相，我进行了更深入的分析，发现一些新的东西。

读取历史记录相关逻辑是在一个线程中，线程首先会判断dns domain是tencent.com或者存在SNGPERF，则bint为1，那么后面的读取历史记录也就不会做了（这是不针对企鹅内部环境？）。

如果bint是0，则开始detect。

首先通过urlcache（后面再读取chrome历史记录）读取url信息（ptjcur Detect1）。

然后计算url的md5，比几个固定的md5值比较。

如果md5匹配，会解析url分析&后面的参数，然后继续把这个参数做md5计算，和一些md5比较，匹配存入一块内存。

具体后续有什么动作，经过这些简单的分析还不能确认，所以也不能轻易对其下结论。

需要比较url的md5如下，有条件的朋友可以去跑跑看结果是什么，然后企鹅究竟要作什么就一目了然了。

0x1C6389BA, 0xF2FA5666, 0xF2A2E0D3, 0xC892E7BA
0xB829484C, 0x520F7CC3, 0x94EC8A73, 0xD808E79
0xDDA1029, 0x9E67F3BB, 0xB18ACC45, 0x597CF438
0x2564591C, 0x5B11347B, 0x846A0F72, 0xEF704A8

结论

最后总结，经过上面的分析，我们并不能对QQ的行为下结论，并不能因为临时读取和计算了一下url，就判定是对用户隐私的侵害（有可能真的如某些人说的，这可能是对某些不雅网站的检查呢）。

当然，在这件事情中，QQ并不完全是无辜者，读取用户浏览器历史记录是一个非常敏感的行为，应该必须让用户清楚得知道，你并没用用此信息做什么伤害用户利益的事情。

最后的最后呢，我想到一个非常有意思的点，说不定这件事情就是因为开发人员一个不小心搞出来的乌龙呢？

哈哈，知道我说的什么吗？就是前面我提到的，判断dns域名是不是tencent.com，bint为0，才会有后面一系列行为，所以我当时很迷惑的猜测，对企鹅内部环境并不检测。

而可能因为开发人员手误把if(bint)写错成了if(!bint)导致检测了非企鹅内部环境，而其实这个功能只是针对企鹅内部环境做的。

当然，这只是我的猜测，具体还得看看企鹅自己的解释。

v2ex帖子里提到“以History为关键字，最早可以追溯到9.1.5版本（2019年6月），这么说此种行为至少已经进行一年半了”。

既然有时候交流缺少不了QQ，那只能通过HIPS软件或者带有HIPS功能模块的软件对QQ读取浏览器等其他数据记录的行为进行限制处理了，以火绒为例：

- SSH(和 Key)数据 C:\Users\XXX\.ssh
- GPG 数据 C:\Users\XXX\.gnupg
- 微信数据 C:\Users\XXX\Documents\Tencent Files
- 浏览器数据 C:\Users\XXX\AppData\Local\Microsoft\Edge C:\Users\XXX\AppData\Local\Google\Chrome
- WinSCP数据 D:\Program Files (x86)\WinSCP\WinSCP.ini
其他软件数据根据软件数据存储情况操作添加即可,也可以参考火绒论坛里的规则。其他HIPS软件设置不做拓展，因为我没有。