|
[邀请码已发][原创]QQ2010本地聊天记录文件Msg2.0.db的进一步研究[申请邀请码]
这是行不通的,如果你了解了QQ的加密算法,呵呵 |
|
[讨论]对QQ2010的一点想法,纯讨论
服务器解密38H所用的算法和密钥未知,就算假设其解密算法是QQ惯用的,不知道密钥也无济于事,而且这个密钥不会出现在客户端。 “服务器的验证是对这38H的数据解密后与QQ号比对”这个我赞成。 我现在想的是,服务器很可能针对每个QQ号的所有Msg文件维持一个解密38H的密钥;极端的情况是只使用一个密钥用来解所有QQ的所有Msg文件的38H数据,当然这个风险比太大,一旦泄漏就完了,所以可能性较小,或者服务器为每个Msg文件维持一个解密38H的密钥,但如此会导致服务器负担很大,而且关联也比较困难,所以可能性最小。 现在的问题是无法知道这38H数据解密所得明文的构成,如果是极端情况的话,只有腾讯内部相关人员知道这个密钥,那么这些人就可以解开随便一个Msg文件,当然这只是我的YY,呵呵。 如果是针对每个QQ生成的,那就比较困难了,可能通过变换该QQ号或者该QQ的密码进行生成,但是我已经尝试过QQ号或密码的N次MD5进行试验,未发现可解;所以更普遍的可能是随机生成然后保存在服务器,对于这一种情况,就没办法了 |
|
[邀请码已发][原创]QQ2010本地聊天记录文件Msg2.0.db的进一步研究[申请邀请码]
现在已经发现并不是公钥加密,而是本地生成初始的密钥,然后发送给服务器,服务器加密之后返回给本地客户端,然后客服端将这个返回的加密内容存放在matrix.dat文件中。 以后登录时,客户端就把这个加密的内容发送给服务器,服务器将解出的密钥返回给客户端,然后客户端用这个密钥解密本地消息。 在不知道服务器上的加密算法和密钥的情况下,就只有通过解密报文来截获服务器返回的该密钥 |
|
[邀请码已发][原创]QQ2010本地聊天记录文件Msg2.0.db的进一步研究[申请邀请码]
1.替换的的确只是matrix.dat中38H; 2.解密算法就是QQ惯用的算法,以TEA16次循环为基础的类似CBC模式加密算法,可以逆向出来的; 3.解密密钥是从报文中截取的,前提是要能解开报文,因为报文被加密了;在知道登录密码的情况下是可以解开报文的,所以我是使用了两个自己的QQ账号,因为只是实验嘛 忘了说了,关键就是在本地消息的加密密钥,这个东西没法(基本上没法)从本地得到,但可以从QQ登录报文得到。 我的意思够明白了吧,所以说我的替换工具其实就是个解包再封装的工具,没有两个msg2.0.db文件的消息加密密钥,啥也做不了。最后再说一句,我的替换工具借鉴了sethseth的解包工具,只不过没把文件解压出来,而是修改之后再放回去 |
|
[邀请码已发][原创]QQ2010本地聊天记录文件Msg2.0.db的进一步研究[申请邀请码]
呵呵,这个方法只能用于密文固定的加密算法(简单来说,就是加密单元之间相互独立,不会出现利用前文的加密输出作为后文的加密输入的情况),而且怎么个算法还是个疑问;如果不使用穷举法爆破,就得利用加密算法自身的漏洞来算。 而QQ使用的加密算法是一种前后相关的块加密算法,也就是说,即使是同样的明文,同样的密钥,每次加密后得到的密文几乎是不同的,所以理论上的破解方法只有穷举爆破,密钥空间是2的128次方。 如果既利用不了加密算法的漏洞也不想使用理论上的爆破,就只能从加密体系入手了。这个思路的入手点有两个:获取服务器私钥(且不说是否是公钥加密,就算是,难度也可想而知,但一劳永逸),分析密钥产生算法(加密密钥是本地生成的,如果密钥全部随机生成,也比较棘手,若非,或许能有效缩小暴力空间) |
|
[讨论]QQ2010本地聊天记录文件 Msg2.0.db 解密分析
私钥是拦截不到的,因为它不公开,也就不会在网络上传输 |
操作理由
RANk
{{ user_info.golds == '' ? 0 : user_info.golds }}
雪币
{{ experience }}
课程经验
{{ score }}
学习收益
{{study_duration_fmt}}
学习时长
基本信息
荣誉称号:
{{ honorary_title }}
能力排名:
No.{{ rank_num }}
等 级:
LV{{ rank_lv-100 }}
活跃值:
在线值:
浏览人数:{{ visits }}
最近活跃:{{ last_active_time }}
注册时间:{{ user_info.create_date_jsonfmt }}
勋章
兑换勋章
证书
证书查询 >
能力值