qiyesafe.com

百度登录加密协议分析(上)

　　本周又和大家见面了，没什么特殊情况，一般是一周一篇原创。发布的时间基本上是在周末，平时还是比较忙碌的。最近在开发自己的博客，过段时间可以和大家分享开发博客中的技术点。如果大家想及时的和我交流的话，可以关注文章最后的微信公众号，这样我可以比较及时的知道大家的想法。（我的新书《Python爬虫开发与项目实战》出版了，大家可以看一下样章）

　　好了，废话不多说，咱们进入今天的主题，讲解一下前段时间做的百度登录加密协议分析，由于写的比较详细，篇幅有点多，所以就分为上下两篇来写。由于百度登录使用的是同一套加密规则，所以这次就以百度云盘的登录为例进行分析。

 

　第一部分：
　　首先打开firebug，访问http://yun.baidu.com/，监听网络数据。
　　
　　　　流程:
　　　　　　1.输入账号和密码，点击登录。
　　　　　　2.点击登录。(第一次post,这时候会出现验证码)
　　　　　　3.会出现验证码，输入验证码，
　　　　　　4.最后点击登录成功上线。(第二次post登录成功)
 
 
　　  根据以往的分析经验，一般需要进行两次登录，来比较post请求出去的数据，哪些字段是不变的，哪些字段是动态改变的。同样上述的流程，这次也会重复一次。将两次登录过程中产生的post请求保存下来。
 
　　
　　  在一次成功的登录过程中，我们需要点击两次登录按钮，也就出现了两次post请求。
 
　　
　　
　　咱们先关注最后一次post的请求内容。
　　
　　
　　这个时候从账号登出，清除cookie信息，再进行一次登录过程，再把post出去的数据，记录下来,进行比较哪些是变化的。
　　
　　通过两次的比较，我们可以发现:
 
　　 apiver=v3
　　callback=parent.bd__pcbs__yqrows
　　charset=utf-8
　　codestring=jxGa206f4ef6540e2a5023014affd01abcc160fde066101382d
　　countrycode=
　　crypttype=12
　　detect=1
　　foreignusername=
　　gid=58DDBCC-672F-423D-9A02-688ACB9EB252
　　idc=
　　isPhone=
　　logLoginType=pc_loginBasic
　　loginmerge=true
　　logintype=basicLogin
　　mem_pass=on
　   password
　　quick_user=0
　　rsakey=kvcQRN4WQS1varzZxXKnebLGKgZD5UcV
　　safeflg=0
　　staticpage=http://yun.baidu.com/res/static/thirdparty/pass_v3_jump.html
　　subpro=netdisk_web
　　token=69a056f475fc955dc16215ab66a985af
　　tpl=netdisk
　　tt=1469844379327
　　u=http://yun.baidu.com/
　　username
　　verifycode=1112
　　
　其中标有绿色的字段都是不变化的，其他都是变化的。
 
 
　　接着看一下变化的字段：
 
　　　　callback 不清楚是什么
　　　　codestring 不清楚是什么
　　　　gid 一个生成的ID号
　　　　password 加密后的密码
　　　　ppui_logintime 时间，不知道有没有用
　　　　rsakey RSA加密的密钥(可以推断出密码肯定是经过了RSA加密)
　　　　token 访问令牌
　　　　tt 时间戳
　　　　verifycode 验证码
 
　　　　上面标为绿色的部分，都是可以简单获取的，所以先不用考虑。
 
第二部分：
 
　　(1) 采取倒序的分析方式，上面说了一下第二次post的值，接着咱们分析一下，第一次post的数据内容。
 
 
　　通过两次post比较，可以发现一下字段的变化:
 
　　　　callback 第一次post已经产生，第二次post内容发生变化
　　　　codestring 第一次post时没有数据,第二次post产生数据
　　　　gid 第一次post已经产生，第二次post内容没有发生变化
　　　　password 第一次post已经产生，第二次post内容发生变化
　　　　ppui_logintime 第一次post已经产生，第二次post内容发生变化
　　　　rsakey 第一次post已经产生，第二次post内容没有发生变化
　　　　token 第一次post已经产生，第二次post内容没有发生变化
 
　　从上面可以看到出现明显变化的是codestring ,从无到有。
　  可以基本上确定 codestring 是在第一次post之后产生的，所以codestring 这个字段应该是在第一次post之后的响应中找到。
　  果然不出所料:
 
 
　　codestring 这个字段的获取位置已经确定。
　　————————————————————————————————————————————————————————————————————————
 
　　(2) 接下来 分析第一次post已经产生，第二次post内容没有发生变化的字段
　　　　gid
　　　　rsakey
　　　　token
 
　　根据网络响应的顺序，从下到上，看看能不能发现一些敏感命名的链接(这是之前的经验)
 
　　从第一次post的往上看，一个敏感的链接就出现了。
 
 
 
 
 
 
 
　　通过查看响应我们找到rsakey，虽然在响应中变成了key,可是值是一样的。
　  通过之前的信息，我们知道密码是通过RSA加密的，所以响应中的publickey可能是公钥，所以这个要重点注意。
 
 
　　咱们还可以发现callback 字段，参数中出现callback字段，之后响应中也出现 了 callback字段的值将响应包裹取来，由此可以推断
　　callback字段可能只是进行标识作用。不参与实际的参数校验。
 
　　通过这个get链接的参数，我们可以得出结论:
 
　　　　gid和token可以得到rsakey参数:
　　　　gid token ------->>>>>rsakey
 
 
 
　　分析 gid和token字段
 
　　为了加快速度，咱们直接在firebug的搜索框中输入token:
　　搜索两三次就发现了token的出处。
 
 
 
 
 
　　通过get请求的参数可以得出这样的结论:
　　　　通过gid可以得出来Token
　　　　gid----------->>>>>>>>token
 
 
　　最后咱们分析一下gid：
　　　　依然是搜索gid ,搜索几次就在这个脚本中发现了gid的存在:
 
 
　　
　　　　　 格式化脚本之后，咱们看一下这个gid是怎么产生的
　　　　　　通过gid:e.guideRandom ,我们可以知道gid是由guideRandom这个函数产生的，接着在脚本中搜索这个函数;
 
 
 
　　最后找个了这个函数的原型，但是通过代码可以看到，这个是随机生成的一个字符串，这就好办了(百度。。。其实当时我是无语的)。
　　　　gid = this.guideRandom = function () {
　　　　　　return 'xxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function (e) {
　　　　　　var t = 16 * Math.random() | 0,
　　　　　　n = 'x' == e ? t : 3 & t | 8;
　　　　　　return n.toString(16)
　　　　　　}).toUpperCase()
　　　　}()
 
总结一下:
 
　　codestring:从第一次post之后的响应中提取出来
　　
　　gid: 有一个已知函数guideRandom 随机产生，可以通过调用函数获取
 
 
 
 
今天的分享就到这里，下一篇继续分析。如果大家觉得还可以呀，记得推荐呦。



 欢迎大家支持我公众号:   



本文章属于原创作品,欢迎大家转载分享。尊重原创,转载请注明来自:七夜的故事 http://www.cnblogs.com/qiyeboy/
 
 
 
 

 

 
posted @ 2016-07-31 10:13  七夜的故事  阅读(15212)  评论(17)  编辑  收藏  举报
qiyesafe.com