聲明

本文章中所有內容僅供學習交流，抓包內容、敏感網址、數據接口均已做脫敏處理，嚴禁用于商業(yè)用途和非法用途，否則由此產生的一切后果均與作者無關，若有侵權，請聯系我立即刪除！

本文首發(fā)鏈接為: https://mp.weixin.qq.com/s/o5UCJFhBg-4JFdS0aEwDuw

前言

在此前。我們先來了解下什么是webscoket？什么是wss？什么是ws？

WebSocket協議是html5的一種通信協議，該協議兼容我們常用的瀏覽器。例如Chrome、 Firefox、IE等。它可以使客戶端和服務端雙向數據傳輸更加簡單快捷，并且在TCP連接進行一次握手后，就可以持久性連接，同時允許服務端對客戶端推送數據。外加傳統(tǒng)模式的協議一般HTTP請求可能會包含較長的頭部，但真正有效的可能只有小部分，從而就占用了很多資源和帶寬。因此WebSocket協議不僅可以實時通訊，支持擴展；也可以壓縮節(jié)省服務器資源和帶寬。

WS協議和WSS協議兩個均是WebSocket協議的SCHEM，兩者一個是非安全的，一個是安全的。也是統(tǒng)一的資源標志符。就好比HTTP協議和HTTPS協議的差別。非安全的沒有證書，安全的需要SSL證書。（SSL是Netscape所研發(fā)，用來保障網絡中數據傳輸的安全性，主要是運用數據加密的技術，能夠避免數據在傳輸過程被不被竊取或者監(jiān)聽。）其中WSS表示在TLS之上的WebSocket。WS一般默認是80端口，而WSS默認是443端口，大多數網站用的就是80和433端口。（在高防防護過程中，80和433端口的網站是需要備案才可以接入國內的。）當然網站也會有別的端口，這種如果做高防是方案是可以用海外高防的。WS和WSS的體現形式分別是TCP+WS AS WS ，TCP+TLS+WS AS WS。服務器網址就是 URL。

目標網站

aHR0cDovL3d3dy5sdXhpLmdvdi5jbi9jb2wvY29sNDQ0NC9pbmRleC5odG1s

抓包分析

我們掏出我們的抓包工具看看。我們這里選擇charles去抓包。

這里吐出了兩個數據包，一個是https協議的，一個是wss協議的。

https協議：

每個都看了 其他的請求都沒用。只有這個v1 這個請求不確定。

這里我們簡單分析一下：

1. 返回給我們的cookie的 dGg2aCfMMK97Ro270mqBFu5qjC8TQbL2opnHvbEpM 這個的value的值 對應的就是wssURL pr 的后綴
2. v1/sessions這個請求返回給我們的值是一段加密的值。
3. 其他的頁面均無數據來源。

這里我們大膽猜測一下：這個v1session這個請求返回給我們的值。我們需要解密，解密出來的值，大概率就是這個 dGg2aCfMMK97Ro270mqBFu5qjC8TQbL2opnHvbEpM cookie的值。然后我們提取出來。完成對wss這個URL的拼接。從而請求。當然這些都是猜測。我們再來看看wss請求。

wss協議：

這里只有一個請求。就不搞那些彎彎繞繞了。話不多說 直接看contents里的內容。

從這張圖我們可以知道很多

1. 通過wss傳輸數據
2. 數據很亂 肯定也是通過js進行的一些打亂和拼接。
3. 這個WSS的連接的某個值是通過v1/session的請求的cookie來獲得的。

其他的東西。我們還是需要一步一步來。首先需要把v1/sessions 這個請求請求且解密。

目的

1. 獲取wss連接（偽造并且獲取v1/sessions請求中的cookies）
2. wss 數據的解碼

數據接口分析

v1/session 接口分析

我們直接去網頁上找這個sessions棧。

根據我們的經驗之談。前兩個請求不是。后面這個anonymous匿名函數值也不是。所以大概率就是這個t.startSession。

追棧進去。

這個位置大概率就是加密點。并且還做了一層Json序列化。但這個是v1/session 傳值的參數。那就很簡單了。這個重點不就是把P的值搞出來。然后調用這個encryptSessions這個方法就行了嗎。

首先打斷點追進去看看是什么。

可以看到 加密了一組名為P的值。這個P我們繼續(xù)往上看。

可以看到 有些是瀏覽器的一些值。有一些則是自己封裝的值。都在上面連在一起。到時候扣下來就行。但其實經過多次測試。只有這個 tabId：c 這組值 需要封裝，其他的值寫死即可。

其實可以發(fā)現這個文件是個webpack打包的文件。這個tabId賦值給了加載器函數，調用了其他的函數。那我們直接搜索這個tabId就好啦

我們找到了生成的這個值。可是這個值其實是找不到生成的位置的。但其實縱觀全局。這個tabId是有很多相等的值。所以我們改寫一下

function get_tabID() {

    return Math.random().toString(36).slice(-10)

}

這樣 tabId的值就出來了。

當然這只是第一步。后續(xù)把encryptSessions這個函數扣出來了。

當然 分析到這里還不算難。后續(xù)就是把如何把這個東西扣代碼扣出來

wss接口請求分析

其實我們最主要的目的還是獲取這個wss的連接。那我們就簡單來看看這個wss連接是如何生成的。我們剛剛通過抓包軟件已經簡單分析了一下。可以通過偽造v1/sessions這個請求來獲取cookie 從而填充wss鏈接。

老規(guī)矩 進堆棧>>>>>>>>

搜索this.channelURL

獲取到this.channelURL的生成點。

經過大量測試可知

ws_url = 'ws://www.xxx.xxx/1ywuKELSO2ahQuWZ/pr/' + urlPrefixToken + '/b/ws/' + tabID

而這個urlPrefixToken的生成處如下圖

urlPrefixToken 也和我們一開始抓包分析的一樣。就是通過cookie來生成的。

加密v1/sessions的data

我們進棧點。發(fā)現是這個dynamicEncrypt 這個函數生成的加密值。

===? 繼續(xù)

那接下來我們只要封裝這個dynamicEncrypt 函數即可。

因為這個是在webpack里面。所以我們扣除加載器。然后缺啥補啥就可以了。

當然。其實全部摳出來 內容很多。而且很麻煩。所以本文使用扣代碼去解決。

這里就不講怎么扣代碼了

核心代碼請查看原文鏈接>>>> https://mp.weixin.qq.com/s/o5UCJFhBg-4JFdS0aEwDuw

當然 值得注意的是這個iv。也是需要摳出來的。

function get_iv() {

    var t = Math.random().toString(36).slice(-8) + "-" + Math.random().toString(36).slice(-8) + (new Date).getTime()

        , e = dynamicEncrypt(t, l, u).replace("_", "");

    return e.substring(1, 17)

}

上文提到的tabId 我們也重新封裝成一個函數

function get_tabID() {

    return Math.random().toString(36).slice(-10)

}

獲取cookie

當然。我們廢那么打力氣去偽造這個請求。不是獲取這里面的數據的。而是為了拿到請求v1/sessions中的cookie的。因為在第一段我們就分析了。wss的有一部分值是可以通過v1/sessions中的cookie拿到的。

我們帶入python中運行試試。

好。經過測試。我們發(fā)現請求返回給我們的狀態(tài)碼是500。這是咋回事？？？？

經過我們反復測試。我們發(fā)現我們還需要添加上請求頭。而請求頭里還有一個值

'etag'而這個值恰恰又等于剛剛 AES加密中的IV值。

我們把這個值再添加進去 請求看看。

這樣就能請求成功了。

在上文分析。我們可知。獲取內容不是我們所需要的。我們真正需要的>>>>>>>> 獲取cookie

我們獲取這個cookie的value。然后拼接URL。

核心代碼請查看原文鏈接>>>> https://mp.weixin.qq.com/s/o5UCJFhBg-4JFdS0aEwDuw

請求WSS連接

這里有兩種方式

1. 通過Python 模擬連接websocket 請求
   1. 缺點：后續(xù)需要手動解碼。兼容性不好
   2. 優(yōu)點：高效快速。
2. 通過JS 連接webscoket
   1. 缺點：不好調用。需要手動扣代碼
   2. 兼容性很好。得到的數據也比較完整。

這里我選擇用Python 模擬連接。因為 扣代碼的方式我試過。速度有點慢。而且好像也不太對的樣子。

這里貼下連接webscoket的代碼

ws = websocket.WebSocketApp(ws_url,on_message=on_message, )

ws.run_forever()

def on_message(ws, message):

    print(message)

結果>>>>>>

這得到的是啥呀？ 一堆亂碼。

但是這也很簡單判斷。wss一般傳輸的數據就兩種，文本和二進制數據

這個很明顯是二進制數據。而這個是通過Message pack的方式去壓縮的。再通過Message pack的方式去解包就行了。

這里簡單介紹下什么是Message pack：

MessagePack是一種有效的二進制序列化格式。它使您可以在多種語言（如JSON）之間交換數據。但是它更快，更小。小整數被編碼為一個字節(jié)，典型的短字符串除字符串本身外僅需要一個額外的字節(jié)。簡單來講，它的數據格式與json類似，但是在存儲時對數字、多字節(jié)字符、數組等都做了很多優(yōu)化，減少了無用的字符，二進制格式，也保證不用字符化帶來額外的存儲空間的增加。

官網: MessagePack: It's like JSON. but fast and small. (msgpack.org)

github:https://github.com/msgpack/

官網有示例代碼。直接使用即可。下面貼一個本人用的方式

import msgpack

def on_message(ws, message):

    import ormsgpack

    print(ormsgpack.unpackb(message))

然后我們去慢慢提取。

然后發(fā)現可以成功提取。

但是這個請求中。標題和時間倒還比較好獲取。

但是詳情頁的連接。好像還并沒有發(fā)給我們。

獲取詳情頁鏈接

我們繼續(xù)去看wss的這個連接。

發(fā)現我們每次點進詳情頁。我們會向服務器發(fā)送一個請求。

然后服務器會再吐一個連接給我們。

并且詳情頁內容也是wss傳給我們的。

說實話真的很麻煩>>>>>>>>>個人建議還是用其他方式去獲取吧。本文只做研究。

本文首發(fā)鏈接為: https://mp.weixin.qq.com/s/o5UCJFhBg-4JFdS0aEwDuw

總結

以上是生活随笔為你收集整理的JS逆向实战23 某市wss URL加密+请求头+ws收发的全部內容，希望文章能夠幫你解決所遇到的問題。

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