百度登陸加密協議分析(上)

  本週又和你們見面了,沒什麼特殊狀況,通常是一週一篇原創。發佈的時間基本上是在週末,平時仍是比較忙碌的。最近在開發本身的博客,過段時間能夠和你們分享開發博客中的技術點。若是你們想及時的和我交流的話,能夠關注文章最後的微信公衆號,這樣我能夠比較及時的知道你們的想法。(個人新書《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/
相關文章
相關標籤/搜索