gsxt滑動驗證碼
最後,談談滑動驗證碼。
目前,工商網站已經全面改版,全部采用了滑動驗證碼,上面絕大多數思路都失效了。對於滑動驗證碼,網上能搜到的解決方案基本都是下載圖片,還原圖片,算出滑動距離,然後模擬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滑動驗證碼