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

  本周又和你们见面了,没什么特殊状况,通常是一周一篇原创。发布的时间基本上是在周末,平时仍是比较忙碌的。最近在开发本身的博客,过段时间能够和你们分享开发博客中的技术点。若是你们想及时的和我交流的话,能够关注文章最后的微信公众号,这样我能够比较及时的知道你们的想法。(个人新书《Python爬虫开发与项目实战》出版了,你们能够看一下样章html

  好了,废话很少说,我们进入今天的主题,讲解一下前段时间作的百度登陆加密协议分析,因为写的比较详细,篇幅有点多,因此就分为上下两篇来写。因为百度登陆使用的是同一套加密规则,因此此次就以百度云盘的登陆为例进行分析。web

 

 第一部分:
  首先打开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/
相关文章
相关标签/搜索