最後，談談滑動驗證碼。

目前，工商網站已經全面改版，全部采用了滑動驗證碼，上面絕大多數思路都失效了。對於滑動驗證碼，網上能搜到的解決方案基本都是下載圖片，還原圖片，算出滑動距離，然後模擬js來進行拖動解決，我們來看下能否不模擬拖動來解決這個問題。

以雲南工商網站為例，首先抓包看過程。

1. http://yn.gsxt.gov.cn/notice/pc-geetest/register?t=147991678609，response：

2. 下載驗證碼圖片

3. http://yn.gsxt.gov.cn/notice/pc-geetest/validate， post如下數據：

4. http://yn.gsxt.gov.cn/notice/search/ent_info_list

仔細分析，我們發現兩處疑點：

1. 第一步並沒有返回需要下載的圖片地址，那麽前端怎麽知道要下載哪些圖片？

2. 第三步驗證時，並沒有告知後端下載了那些圖片，後端是怎麽驗證post過去的數據是有效性的？

仔細閱讀前端混淆的js代碼，我們發現前端數據處理過程是這樣的：

1. 從0到6（不含）中取隨機整數，賦值給d， d=5；

2. 從0到300（不含）中取隨機整數，賦值給e， e=293；

3. 將d轉化為字符串並作MD5加密，加密字符串取前9位賦值給f， f=’e4da3b7fb’；

4. 將e轉化為字符串並作MD5加密，加密字符串從第11位開始取9位賦值給g, g=’43be4f209’；

5. 取f的偶數位和g的奇數位組成新的9位字符串給h, h=’e3de3f70b’；

6. 取h的後4位與200做MOD運算，其結果小於40，則取40，否則取其本身賦值給x，x=51；

7. 取[x-3, x+3]以內隨機數賦值給c，c=51；

8. 分別取c,d,e跟challenge做t加密(t(c,challenge), t(d, challenge), t(e,challenge))並用（_）拼接即為geetest_validate, ‘9ccccc997288_999c9ccaa83_999cc9c9999990d’

這裏f, g參數決定了下載圖片地址：

而x為滑塊拖動的橫向偏移量，至此解答了疑問1中圖片下載地址怎麽來的問題。

前邊提到的t加密過程是這樣的：

t(a,b)，此處以a=51演示

1. challenge為34位16進制字符串，取前32位賦值給prefix，後2位賦值給suffix，prefix=’34173cb38f07f89ddbebc2ac9128303f’, suffix=’a8′

2. prefix去重並保持原順序，得到列表 [‘3’, ‘4’, ‘1’, ‘7’, ‘c’, ‘b’, ‘8’, ‘f’, ‘0’, ‘9’, ‘d’, ‘e’, ‘2’, ‘a’]

3. 將2中列表循環順序放入包含5個子列表的列表中，得到random_key_list： [[‘3’, ‘b’, ‘d’], [‘4’, ‘8’, ‘e’], [‘1’, ‘f’, ‘2’], [‘7’, ‘0’, ‘a’], [‘c’, ‘9’]]

4. 將suffix字符串（16進制）逐位轉化為10進制，得到[10, 8]

6. 將4中列表逐位與[36,0]做乘法和運算並與a的四舍五入結果相加， n= 51 + 36*10 + 0*8=419

7. q=[1,2,5,10,50], 用q對n做分解（n=50*13+10*0+5*1+2*1+1*1），將其因數倒序賦值給p，p=[0,2,1,1,8]

8. 從random_key_list右側開始隨機取值，次數為p中數值，拼成字符串sub_key，sub_key=’9ccccc997288′

至此，我們完成了整個分析過程，我們又有了新發現：

1. 按照前邊的抓包過程，其實不需要真的下載圖片，只需執行1、3、4步就可以得到目標數據了。步驟1也可以不要，只需3、4即可，但是少了步驟1， 我們還需要額外請求一次cookie，所以還是保留1, 這樣也偽裝的像一點嘛。

2. 相同的challenge，每次運算都可以得出不同的validate和seccode，那麽問題來了：到底服務端是怎麽根據challenge驗證其他數據是否有效呢？

總結一下，對於驗證碼，本文只是提供了一種新的思路，利用了網站開發過程中的一點小疏漏，而最後的滑動驗證碼也只是分析了offline模式的驗證方法。不要指望所有驗證碼都可以能繞過，沒有阿登高地，二戰德國就不打法國了麽？只要覺得有價值，即使正面面對驗證碼，作為爬蟲工程師建議也就一句話：不要慫，就是幹！

gsxt滑動驗證碼