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


      本周又和大家见面了,没什么特殊情况,一般是一周一篇原创。发布的时间基本上是在周末,平时还是比较忙碌的。最近在开发自己的博客,过段时间可以和大家分享开发博客中的技术点。如果大家想及时的和我交流的话,可以关注文章最后的微信公众号,这样我可以比较及时的知道大家的想法。(我的新书《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/
     
     
     
     
     
  • 相关阅读:
    poj 2312 Battle City
    poj 2002 Squares
    poj 3641 Pseudoprime numbers
    poj 3580 SuperMemo
    poj 3281 Dining
    poj 3259 Wormholes
    poj 3080 Blue Jeans
    poj 3070 Fibonacci
    poj 2887 Big String
    poj 2631 Roads in the North
  • 原文地址:https://www.cnblogs.com/qiyeboy/p/5722424.html
Copyright © 2020-2023  润新知