QQ后台读取历史记录？有点冤枉企鹅了!

起因

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

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

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

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

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

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

分析

原帖作者通过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, 0xC892E7BA0xB829484C, 0x520F7CC3, 0x94EC8A73, 0xD808E790xDDA1029, 0x9E67F3BB, 0xB18ACC45, 0x597CF4380x2564591C, 0x5B11347B, 0x846A0F72, 0xEF704A8

结论

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

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

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

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

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

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

(完)