如果你現在想模擬登陸知乎，會發現 fromdata 是一串加密的字符串
看了之后是不是很痛苦？你是不是就想使用 selenium 來模擬登陸？不過好像知乎對 selenium 也進行了相應的反爬處理，哈哈。但是我不也想用 selenium，效率太慢了，直接破解 js 才是我最喜歡挑戰的。好，我現在教你如何用 js 硬擼破解,廢話不多說，直接進入正題。
1. 找出signature加密
加密位置這個相對來說是比較難找的，需要自己對那些混淆過的 js 進行一遍又一遍的搜尋，有時候你看到頭皮發麻也不一定找得到，再加上這個加密參數是一堆字符串，連個鍵都沒有，搜索的條件都沒有。這怎么辦呢？我們可以去百度或者谷歌看看前人是怎么搞的。
你直接搜索知乎模擬登陸的話，會發現以前的知乎的 fromdata 是鍵值形式的，有以下鍵值對
順便也可以看看之前的破解思路，看到了上面的 signature 是通過加密來的，猜測知乎應該也是對之前的鍵值加密的 fromdata 進行加密的，在控制臺搜搜 signature 看看有沒有線索
提示：按下 ctrl + shift + f 可出現搜索框
一搜，果然有，看了看，signature 的加密過程和以前的還是一樣的，證明我的猜想正確了，說明是通過之前的 fromdata 的鍵值對進行加密成的一堆字符串，現在就看看 signature 是如何加密的。
如果你對加密有點了解的話，還容易知道通過上面代碼知道，很容易知道是通過 hmac 加密，哈希算法是 sha1，密鑰為 d1b964811afb40118a12068ff74a12f4，加密數據有四個，為 clientId、grantType、timestamp 和 source，這些值都可以在上面通過調試出來的，就不多說了，如下
2. 找出fromdata的完整鍵值對
在知道 signature 是如何加密的之后，我們還需要找出完整的 fromdata 先，不過在上面的調試中，你會發現也有幾個 fromdata 值，但是不全。
這時候如果我們得繼續搜索 signature 的話，找了一整天你都會發現不到什么線索，這時候我們可以通過登陸的 url 進行突破，看看 url 是哪個路徑，然后一段搜。
身為老司機，還是得分享些干貨精品學習資料的，推薦下小編創建的Python學習交流群556370268，這里都是一群愛好Python的小伙伴，每天還會直播和大家交流分享經驗哦。
其登陸url是 https://www.zhihu.com/api/v3/oauth/sign_in。那我們可以直接搜 sign_in 試試。搜了發現和上面的 signature 是在同一個 js 文件上的，感覺應該有戲。
這個和登陸地址完全匹配，應該就是這個了，可以進行調試一波
這不出來了，經過多次調試，發現大多數值都是固定的，只有 signature 和 timestamp 不是，其他的就是賬號密碼之類的，還有個驗證碼 captcha 以及它的類型 lang，signature 上面的已經找出來了，timestamp 很明顯就是時間戳，其他的就不多說了。
現在的 fromdata 已經全部找出來了，我們離加密字符串又近了一步，如果你直接用這個表單進行模擬登陸，會給你返回下面錯誤
Missing argument grant_type
可見我們還得找出這個 fromdata 的加密方法。
3. 找出 fromdata 加密位置
如果你是第一次找這個，估計你得不斷地翻 js，也不一定能找得到，或者你可以根據下面這個調用函數過程來找
會發現很多，不過你懂套路的話都知道加密一般都用到 encrypt 名字之類的,可以直接根據這個名字搜
一搜果然有這個，通過查看你很容易就找到這個
這個一通過調試，你可以看到，我們的加密字符串出來了，是不是很激動，我當時找到了這個的時候激動不得了。
這個是加密的字符串
這個就是我們需要找的
歷盡千辛萬苦，終于找出了廬山真面目，激動不？先不要激動先，這只是加密的位置，后面的才是最難的！
4. 找出 fromdata 加密的所有方法
知道位置后，我們可以直接把這個加密的 js 方法都扣出來，放在一個 html 文件內執行就好。
在上面找出位置之后，很容易就可以看到這個完整的一個的加密方法
按這個半括號向上找，你就可以找到一個完整的加密方法，這個就是整個 fromdata 的加密方法，挺容易找的，如果覺得不方便找的，可以先將這個 js 文件里面的代碼復制下來，然后到 Sublime Text 軟件上找，這個可以折疊，也比較容易找，找出來是這樣子
格式化之后有 400 多行，而且全是混淆，難看得一批。
為了看看這個正確不正確，我們可以把函數里面的內容直接拿出來，就是去掉最外層的函數，然后調用下面的函數 Q，把我們的 fromdata 傳進去
最后將上面的 JavaScript 給弄成一個 html 文件，放在 script 標簽內即可
格式就和上面一樣，然后直接用瀏覽器上打開這個 html 文件，你會看到這個
這個就是我們一直努力在找的 fromdata 加密字符串。
弄完這個之后，我們繼續使用 python 來操作了，因為這個 加密的方法格式化之后有 400 多行，實在太多，也全都是混淆，如果想用 python 來實現的話也不是不可能，就是成本太大了，需要的時間太多了，我們還不如直接使用 python 的 execjs 來執行 JavaScript 代碼直接獲得就可以了，這個簡單方便。
(我們除了使用 execjs 來執行，還可以使用 selenium 運行這個html 文件也是可以的，但是我并不想用 selenium 這個工具，還是喜歡折騰，所以忽略了，想用的可以試試。)
但是這里又會有一個問題，我們用瀏覽器打開的是為它提供了一個瀏覽器的運行環境，我們在 python 使用的 execjs 提供的是 node 環境，兩個環境的不一樣，就會產生不同的效果，下面我們可以選擇使用 webstorm 編輯器來提供 nodejs 環境來進行嘗試以下。
5. 在 node 環境調試加密代碼
你可以拿上面的 JavaScript 代碼在 webstorm 運行，你就會看到
TypeError: __g._encrypt is not a function
所以我們需要調試，需要把那些在瀏覽器上只有的對象，比如 window、navigator 之類的對象給弄掉，從而在 node 上用不用的代碼代替相同的效果即可。
要調試我們先要找到代碼運行的開端，可以很容易找到
可以看到，這里它會先去判斷有沒有 window 這個對象來判斷是不是在瀏覽器上面運行的，所以我們可以直接把它修改成 true 或者其他表示成 true 的值都可以
再次運行，可以看到這個錯誤
ReferenceError: atob is not defined
這個 atob 是將 base64 加密的字符串給解密，在 node 環境下是沒有這個方法的，我們需要使用 Buffer.toString()替代即可。
運行之后，還是報這個錯誤
TypeError: __g._encrypt is not a function
注意：這個是大坑，估計一般人每個一兩天還搞不定，這個是因為上面的解密的，但是上面的并不一樣，你可以在上面的兩個函數加斷點，分別在瀏覽器和 node 環境下運行，可以看到解密的數據是不一樣的，是因為在瀏覽器上的 base64 加密的是 binary 編碼，解密之后也就同樣需要使用 binary 編碼，這個是我在知乎的資源文件上搜索 atob 這個方法，然后慢慢查找看到的，當時也差不多心態崩了，還好堅持下來了。而我在 node 環境下解密之后使用了默認的編碼，所以解密的數據出錯了。當我們加上 binary 編碼之后，再運行
這時，錯誤不再是上面那個了，變成了另一個，證明解密正確了，再來看看下面這個錯誤
execption at 11: ReferenceError: window is not defined
原來是 window 對象惹的禍，這個時候就需要我們偽造 window 對象了，至于怎樣偽造呢，我們可以調試出錯的地方，看看它使用了什么方法，就直接使用適合 node 運行的相同效果的代碼代替就可以了，經過多次調試，需要我們偽造 window 和 navigator 這兩個對象，下面就是偽造之后的代碼
這個時候再運行看看。
可以看到成功了，上面的紅色字是一個提示，關于 Buffer 的，這個我們忽略就行，接下來就可以使用 python 環境進行測試了。
果然，都出來了，哈哈，注意需要先安裝 PyExecJS 庫，自行安裝，然后在測試的時候記得導入 execjs 即可。現在這個 fromdata 算是大功告成了，接下來就是登陸驗證下我們搞得這個加密對不對了。
6. 模擬登陸知乎
這個知乎的登陸也是坑滿滿，我也給踩了幾個，這個就直接說坑吧，其他的就不多說了。
我只是用手機號來登陸的，也可以用郵箱登陸，過程都差不多的。
1. 請求登陸的網址的請求頭需要帶上這幾個
不帶 content-type 的話，會給你返回這個錯誤
Missing argument grant_type
不帶 x-zse-83 的話，會給你返回這個錯誤
請求參數異常，請升級客戶端后重試
至于 agent-user 那就更不需要說了。
2. 請求順序
知乎這個登陸是首先請求驗證碼地址，看需要不需要填寫驗證碼，如果需要填就再請求一次，而且還需要再再請求一次查看是否輸入驗證碼正確，不正確就重復上面步驟，當不需要填寫驗證碼的時候就可以直接請求登陸網址了。
還有上面的三次請求的驗證碼地址的請求方法都是不一樣的，哪種方法自行調試即可。
3. 驗證驗證碼
在驗證驗證碼的時候請求頭的 content-type 不要填寫 值為 multipart/form-data，如果填了請求驗證碼的時候會給你返回這個錯誤：
{"error":{"message":"Missing argument input_text","code":400}}
它的意思是說沒有帶上驗證碼驗證，當我們去掉的這個字段的時候，就可以驗證了。
驗證驗證碼的時候請求頭只需要有一個** user-agent **就可以了
4. 請求的所有階段帶上 cookie
知乎這個有個 cookie 值是驗證碼票據，是從第一次請求驗證碼地址來的，就是下面這個
如果不帶 cookie請求或者請求順序不一樣都有可能給你返回這個錯誤。
{"error":{"message":"缺少驗證碼票據","code":120002,"name":"ERR_CAPSION_TICKET_NOT_FOUND"}}
5.你還想要？沒有了，坑暫時只有這么多，最后給你們看下登陸成功的結果
7. 寫在最后
身為老司機，還是得分享些干貨精品學習資料的，推薦下小編創建的Python學習交流群556370268，送給每一位小伙伴，這里是小白聚集地，每天還會直播和大家交流分享經驗哦，歡迎初學和進階中的小伙伴。
這個登陸折騰了差不多一周了，實際來說可能是三周，因為從剛開始看不懂 js 代碼，就跑去學了兩周 js，現在總得來說 js 也可以說上手了，以后或許也會使用 nodejs 搞點爬蟲，挺好玩的。
