本周又和大家见面了，没什么特殊情况，一般是一周一篇原创。发布的时间基本上是在周末，平时还是比较忙碌的。最近在开发自己的博客，过段时间可以和大家分享开发博客中的技术点。如果大家想及时的和我交流的话，可以关注文章最后的微信公众号，这样我可以比较及时的知道大家的想法。（我的新书出版了，大家可以看一下）
好了，废话不多说，咱们进入今天的主题，讲解一下前段时间做的百度登录加密协议分析，由于写的比较详细，篇幅有点多，所以就分为上下两篇来写。由于百度登录使用的是同一套加密规则，所以这次就以百度云盘的登录为例进行分析。
第一部分：
首先打开firebug，访问，监听网络数据。
流程:
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 随机产生，可以通过调用函数获取
token:通过将gid带入这链接 获取响应中的token
rsakey:将获取的gid和token带入从响应中可以提取出来rsakey
今天的分享就到这里，下一篇继续分析。如果大家觉得还可以呀，记得推荐呦。 欢迎大家支持我公众号: 本文章属于原创作品,欢迎大家转载分享。尊重原创,转载请注明来自:七夜的故事 http://www.cnblogs.com/qiyeboy/