文章目錄

• 前文回顧
• 提出問題
• 問題1：Cookie從何而來？
• • 問題描述
  • hook查看`GW1gelwM5YZuT`何時生成
• 問題2：搜索頁面不匹配
• • 問題描述
  • 抓包分析
  • 如何獲取“頁面Cookie”
  • 頁面Cookie的自動化獲取
• 總結

前文回顧

在【瑞數】維普期刊JS逆向詳細流程及4000字爬蟲總結(1)一文中，成功拿到了搜索接口的簽名。

本文主要探究cookie的獲取。

接口簽名的生成與獲取

cookie的生成與獲取

基于瀏覽器環境的爬蟲如何部署？

關于本次瑞數解密的總結

提出問題

一提到cookie的獲取，第一想法就是簡單。通常的流程就是請求一下網頁，然后在響應中提取cookie即可。

但是在維普期刊這個例子里，并不是這樣。先來了解在調試中我所遇到的實際問題。

然后在后文中，我們一一來解決這些問題。

問題1：Cookie從何而來？

問題描述

在上文中，我們是從瀏覽器中直接復制的cookie

那么這個cookie從哪來？

通過抓包可以知道cookie中name為GW1gelwM5YZuS的值是服務端給的（在第二個問題中有解釋）。

在返回的所有響應頭中，沒有發現設置GW1gelwM5YZuT的值，那么可以斷定這是在本地生成的。

hook查看GW1gelwM5YZuT何時生成

使用hook函數在設置cookie時進入debugger狀態

(function(){var org = document.cookie.__lookupSetter__('cookie');document.__defineSetter__("cookie",function(cookie){if(cookie.indexOf('GW1gelwM5YZuT')>-1){debugger;}org = cookie;return cookie;});document.__defineGetter__("cookie",function(){return org;}); })();

hook流程

找到第一次加載的JS代碼或JS文件，在第一行代碼上斷點；

調式進入暫停后，在console鍵入hook函數；

放行

加載的第一個js文件是leE4DklasHMb.f22c526.js，在第一行打下斷點，然后刷新頁面

進入斷點后，在console鍵入hook代碼，按F8放行

GW1gelwM5YZuT被設置，成功暫停

查看調用棧，這里的_$bs就是GW1gelwM5YZuT的值，是從調用方傳過來的，繼續向上回溯查看。

然后找到這行代碼xx(773, 1)，如果繼續向上找，這是在首次允許整個簽名代碼時執行的，且只會調用一次。

換句話說，這行代碼是在搜索頁面加載時執行的。

Tips：如果上面的調試過程，超過了40秒左右，這次放行又會立即暫停到我們的hook函數內。

繼續往上回溯，可以看到這次是_$VD(733, 10)，這和剛才的xx(773, 1)有所不同。

繼續向上向上查看調用棧，可以看到類似代碼，這是設置了定時器。作用就是每隔50秒，調用一次_$XR方法，即設置一次GW1gelwM5YZuT的值。

以上是比較容易發現的觸發方式，另外還有事件可以觸發GW1gelwM5YZuT的生成，有興趣可以多調試看看。

頁面加載事件；

定時器事件；

鼠標點擊事件；

問題2：搜索頁面不匹配

問題描述

在上文中，需要拿到搜索頁面的源代碼才能進行代碼注入。

之前是通過手動復制的方式獲取，現在則是需要通過Python發送請求拿到搜索頁面。

當我直接請求搜索頁面，返回的代碼如下：

返回的結果明顯和之前手動復制的不同。

第一狀態碼不對，正常請求應該是返回 200

第二內容不對，這次請求返回的html，雖然也有一段混淆的JS，但是，body標簽內幾乎沒有什么代碼。

抓包分析

打開抓包工具（本文使用的是Fiddler），并在瀏覽器匿名窗口訪問搜索主頁。

第一次請求，狀態碼確實是412。

請求搜索頁面的流程：

請求搜索頁面，返回html頁面，狀態碼為412；

html中引入了JS文件，則請求這個JS文件；

再次請求搜索頁面，請求成功；

---

接下來，我們分析如何才能獲取到正確的搜索頁面。

第一次請求并不是一無是處，首先為瀏覽器設置了cookie，這個就是Gw1gelwM5YZuS的來源。

然后html頁面中引入了一個JS文件

這一點和上文搜索接口簽名一致，共同的特點就是引入JS文件賦值，通過html中的JS代碼還原字符串代碼，然后加載代碼并執行

這個JS文件暫時放下不管，先分析第二次搜索頁面請求。

可以看到，第二次請求搜索頁面時，cookie多了一個GW1gelwM5YZut，所以首次請求搜索頁面，其作用就是生成可訪問搜索頁面的cookie

自問自答環節

Q：既然cookie都已經生成了，那么帶上這個cookie在python中發送請求，可以嗎？

A：不行，經過多次調試，這個Cookie僅能用于訪問一次搜索頁面。

Q：訪問搜索頁面的cookie可以用于搜索接口嗎？

A：不行

關于上面問題與回答，是通過大量調試和踩坑"猜"出來。

如何獲取“頁面Cookie”

第一個問題中的Cookie是用于搜索接口，這次我們需要獲取的Cookie則是訪問搜索頁面的**“鑰匙”**。

為了區分，這個Cookie稱為頁面Cookie。

頁面Cookie關鍵值兩個：GW1gelwM5YZuS、GW1gelwM5YZuT

**Tips：**我稍稍看了下藥監局的瑞數，這個Cookie也是有特點的，會以xxxxS和 xxxxT命名。

改改稱呼，方便一點

以S結尾的，稱作s_cookie

以T結尾的，稱作t_cookie

ok，s_cookie在上一節的抓包分析中得知，這個值由服務端提供，除此之外s_cookie可用于搜索接口的請求，這個可以簡單調試看看，多次請求s_cooie一直是不變的，t_cookie則是頻繁變化。

接下來就讓我們一起來解密t_cookie，這也是本章的核心內容。

打開審查工具，刷新頁面，開始調試，發現第一個請求就是狀態碼200，但是我們需要的是狀態碼為412的請求。

這是因為跳轉導致（這就是故意為之）

我先講一講調試思路。

使用Fiddler攔截響應，并只允許通過第一次頁面的響應和JS文件響應。

這個時候打開審查工具，查看Application中的Cookies，可以看到“新鮮出爐”的Cookie。

拿出來測試看看，沒問題。

驗證頁面Cookie是否可用的代碼如下

# -*- coding: utf-8 -*- """ Created on 2021/5/25 15:25 --------- @summary: --------- @author: mkdir700 @email: mkdir700@gmail.com """ import requestssession = requests.session() s = input("請輸入GW1gelwM5YZuS的值:\r\n") value = input("請輸入GW1gelwM5YZuT的值:\r\n") session.headers = {"Host": "qikan.cqvip.com","Connection": "keep-alive","sec-ch-ua": '" Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"',"sec-ch-ua-mobile": "?0","Upgrade-Insecure-Requests": "1","User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36","Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9","Cookie": "GW1gelwM5YZuS={}; GW1gelwM5YZuT={}".format(s, value),"Sec-Fetch-Site": "none","Sec-Fetch-Mode": "navigate","Sec-Fetch-User": "?1","Sec-Fetch-Dest": "document","Accept-Encoding": "gzip, deflate, br","Accept-Language": "zh-CN,zh;q=0.9", } resp = session.get("http://qikan.cqvip.com/Qikan/Search/Advance?from=index") # print(resp.text) # print(resp.request.headers) print(resp.status_code)

如果用這個頁面Cookie再請求一次就會失敗

頁面Cookie的自動化獲取

我的思路如下：

依賴瀏覽器環境，將兩個Cookie生成

讀取Cookie即可

這當中存在一個問題，那就是我沒法控制請求的次數。

正常的流程是，瀏覽器打開頁面，會讓能加載的都加載，能運行的都運行。

而我們的要求是加載一個html頁面和一個JS文件，為了避免頁面Cookie被使用而導致失效，此時需要停止后續的所有請求。

手動獲取Cookie是借助了抓包工具攔截響應的功能。那么有沒有什么辦法達到同樣的效果呢？

我首先想到的是mitmproxy（中間人），作為中間人，我們可以修改內容，也有權決定請求與響應的去留。

使用mitmproxy應該是個比較快速的辦法，然后我嫌麻煩（其實沒有多麻煩， 哈哈哈），放棄了。

我選擇的方式是瀏覽器插件。

我將hook函數封裝為瀏覽器插件，只要檢測到t_cookie生成后，就將其賦值給全局變量。

然后使用window.stop停止整個網頁的加載，保證頁面Cookie不會被使用。

---

inject.jshook函數代碼

var code = function () {var org = document.cookie.__lookupSetter__('cookie');document.__defineSetter__("cookie", function (cookie) {if (cookie.indexOf('GW1gelwM5YZuT') > -1) {var t = cookie.split("=")[1].split(";")[0];window.t_cookie = t;console.log(t);window.stop();}return org;});document.__defineGetter__("cookie", function () {return org;}); } var script = document.createElement('script'); script.textContent = '(' + code + ')()'; (document.head || document.documentElement).appendChild(script); script.parentNode.removeChild(script);

manifest.json

{"name": "Injection","version": "2.0","description": "Cookie鉤子","manifest_version": 2,"content_scripts": [{"matches": ["<all_urls>"],"js": ["inject.js"],"all_frames": true,"permissions": ["tabs"],"run_at": "document_start"}] }

這兩個文件在同一目錄下，制作chrome插件的教程，網上搜一搜就行，非常簡單。

實現效果

獲取頁面Cookie代碼，插件inject文件夾與這個py文件在同一目錄

# -*- coding: utf-8 -*- """ Created on 2021/5/25 19:22 --------- @summary: --------- @author: mkdir700 @email: mkdir700@gmail.com """ import asyncio import os import timefrom pyppeteer import launch from pyppeteer_stealth import stealthasync def close_page(browser):await browser.close()async def start():# 插件文件夾路徑chrome_extension = os.path.join(os.path.abspath('./'), 'inject')browser = await launch({'headless': False,'userDataDir': './userDataDir','args': ['--no-sandbox','--load-extension={}'.format(chrome_extension),'--disable-extensions-except={}'.format(chrome_extension),'--window-size=0,0']})page = await browser.newPage()await page.setViewport(viewport={'width': 1000, 'height': 800})await stealth(page)await page.goto("http://qikan.cqvip.com/Qikan/Search/Advance?from=index")time.sleep(0.5)t = await page.evaluate("() => {return t_cookie;}")cookies = await page.cookies()s = Nonefor c in cookies:if "GW1gelwM5YZuS" == c['name']:s = c['value']data = {'s': s, 't': t}# print(data)await browser.close()return datadef get_cookies():data = asyncio.get_event_loop().run_until_complete(start())return dataif __name__ == '__main__':print(get_cookies())

參考文章：Pyppeteer如何加載chrome插件并測試

總結

cookie的獲取到這里就算結束了，cookie分為兩種類型，一種用于搜索頁面，另一種是用于搜索接口。

搜索接口的cookie可用于頁面，頁面的cookie不能用于搜索

cookie中的核心關鍵是這個t_cookie，這是在本機生成的。關于他詳細的生成邏輯，我沒有再分析。

我只知道，服務端返回的s_cookie影響著t_cookie的值，如果有大佬知道其中的生成邏輯，求告知。

這里在額外說下，搜索頁面與cookie存在某種綁定關系，比如，拿出A瀏覽器返回的搜索頁面源代碼，復制B瀏覽器中的cookie，這樣請求搜索接口將會失敗。

結合第一篇文章，重新梳理整個執行流程如下：

首次訪問搜索頁面（狀態碼412），被設置s_cookie;

加載搜索頁面及JS代碼，被設置t_cookie;

跳轉，再次請求搜索頁面（狀態碼200）；

加載頁面及JS代碼，重設t_cookie（可用于搜索接口）

根據接口地址生成簽名；

帶上s_cookie、t_cookie、簽名和請求參數，即可請求成功。

總結

以上是生活随笔為你收集整理的【瑞数】维普期刊搜索接口逆向总结_2_获取Cookie的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。