前端: 從零破解一款輕量級滑動驗證碼

今天在這篇文章裏給大家介紹一下怎樣使用代碼破解滑塊驗證碼。文章末尾有源碼鏈接，需要的朋友可以自取，不過拿走之前記得三連哇！

思路講解

打開頁面

滑塊驗證碼是滑動驗證碼的一種，生成步驟至少有三步：

根據用戶標識，從後臺獲得驗證碼圖片
監聽鼠標事件並回傳後臺
後臺判斷事件的真僞，回傳驗證結果

無論生成機制的細節如何，滑塊都是要展示在頁面上的。直接用 HTTP Request 把頁面請求下來肯定不行，這裏我們需要使用 Puppeteer 打開頁面。測試頁面就以 react-slider-vertify[1] 的官網爲例。

Puppeteer[2] 是一個通過 DevTools 協議來控制瀏覽器行爲的庫，只需編寫不多的代碼，就可以操作真實的瀏覽器搞定諸如爬蟲、自動化測試、網頁性能分析、瀏覽器擴展測試等功能。使用起來比較方便，它文檔挺全的，根據文檔，打開頁面前需要啓動一個瀏覽器實例，然後調用 newPage 方法創建一個新頁面。核心代碼如下。

const puppeteer = require('puppeteer')

puppeteer.launch().then(async browser => {
  const page = await browser.newPage()
  await page.goto('http://h5.dooring.cn/slider-vertify/vertify')
})

正常瀏覽網頁時，很少會碰到滑塊驗證，因爲它的路徑非常長，會需要浪費用戶好一會兒時間。雖然文案上給你顯示 “恭喜 0.9s 打敗了 99% 的用戶”，但從前置腳本請求，到加載圖片，用戶滑動滑塊，到回傳驗證... 前前後後的步驟加起來可能花了你 9s 不止。本質上它是防禦性的手段，一般當服務器限流，或者服務器已經懷疑你是爬蟲的時候，纔會讓它跳出來要求做進一步驗證。所以一般來說，爬蟲代碼可以默認忽略滑塊驗證的，不過本文代碼我們就假定默認驗證碼一定存在吧。

接下來，分析一下用戶行爲。解決滑塊驗證，無非就是先判斷一下缺口的位置，然後移動鼠標。這裏進一步可以細分爲鼠標的點擊事件和鼠標移動事件兩種。代碼邏輯大致如下。

等待驗證碼圖片加載完畢
移動鼠標到滑塊位置
按下鼠標
移動鼠標到缺口位置
鬆開鼠標
等待結果返回

啊，流程我都知道，可問題就在，怎麼判斷要把鼠標移動到哪裏？服務器端返回的是一張帶缺口的圖片，缺口位置指定是不通過接口傳遞的。

可能還有些同學會問，怎麼移動鼠標呢？如果我一次性就把滑塊給移到指定位置了，那服務器不是會立馬把我標記爲爬蟲嘛... 這兩個問題我逐一解答。

判斷位置

要分析缺口的位置，我們必須先知道這個缺口是怎麼畫上去的。打開控制檯初步檢查可以發現，頁面從服務器先拿到了一張完整的圖片，然後缺口位置是通過 JS 隨機生成的。啊這... 這... 這是因爲我們用的測試頁面是文檔頁，大家不必在意這些安全方面的小細節。

找到請求

接着剛纔的思路繼續，既然缺口是從原圖中挖的一個洞，那麼我們只需要識別一下圖片中洞的位置就好了。比較簡單的方案是使用第三方的圖像識別技術（或相關技術），把圖片上傳至第三方，就直接拿到缺口位置的相對座標。下圖給大家展示一下阿里雲的圖像分割的效果 alimagic[3]。

阿里雲圖像分割

如果想做一個效果穩定一點的驗證碼破解工具，我建議大家還是用自己的模型，或者自己寫算法。一來是第三方要的錢錢不少哇~ 再就是這種圖像識別並不是專門爲驗證碼訓練的，所以放到爬蟲中還不太成熟，一旦背景圖片複雜，識別率下降得老快了。

百度雲圖像主體識別

以下介紹一種新思路。反正我們已經有一張完整的圖片了，那就只要不斷地滑動滑塊，把結果和原圖比對就行。理論上，只要滑倒差不多 “那個點”，肉眼看起來不會有很大的違和感時，就搞定了。比如下面這張圖。

和原圖進行比對

截圖嘛可以直接用 Pupeteer 的截圖功能，它提供了對應的 API，可以精準的截出特定元素。

至於圖片比對，其實就是給圖片初步處理後，兩張圖一個像素一個像素的去比較。兩個像素如果顏色差異超過閾值，就認爲這是兩個不相同的像素。簡便起見，我們直接用開源庫 rembrandt[4]，它會給我們返回兩張圖片間的差異。

最後是滑動滑塊，既然要模擬人肉操作，那麼操作 CSS，用絕對定位，把滑塊一個像素一個像素的向右移；每移動一次，把圖像比對的結果記錄下來。

以上三個流程的核心代碼非常簡單，只需要以下幾行：

while (left <= maxOffset) {

  /* 使用 CSS left 屬性控制懸浮的滑塊的偏移量 */

  await page.evaluate(async ($sliderFloat, left) => {
    $sliderFloat.setAttribute('style', `left: ${left}px`)
  }, $sliderFloat, left)

  /* 截圖並和原圖進行比對，把結果存到 results 數組裏 */

  const $panel = await page.$('#Vertify-demo-4 .canvasArea')
  const panelImgBase64 = await $panel.screenshot({
    type: 'jpeg'
  })
  const compareRes = await rembrandt({
    imageA: panelImgBase64,
    imageB: rawImage
  })
  results.push({
    left,
    diff: compareRes.differences
  })

  left += 1
}

通過 CSS 控制位移

最後，把 results 扔到裏面展示一下（這裏給個 ECharts 折線圖示例網址 [5]），不出意外能得到這樣一張圖表。看到那個尖尖的 “V” 型山谷了嘛，呼哈哈哈，答案很明顯，當我們把滑塊從左往右移動時，滑塊約接近缺口，那截出來的圖片就越像原圖，它兩之間像素差異越小；一直往右移動，滑塊會逐漸遠離缺口，截出來的圖片和原圖相比像素差異又逐漸開始增大。我們只需要把差異最小的那個點找到，然後滑動滑塊到對應的 left 偏移量就闊以了。

圖像比對結果

題外話，爲什麼最大的差異在 3000 左右呢？我們簡單估算一下。

滑塊的大小爲 45*45，再加上外面的圓形，約莫佔了 2100 像素；也就是說缺口加滑塊，理論上最大會有 4200 個像素和原圖不同。不過滑塊可能和遮住的地方像素有重合，假設重合了 350 像素，再加上我們的最低點的圖片差異都有 351，減去這些誤差，得 3499。嗚呼，3499 約等於 3000，估算成功（手動狗頭）。

不過還沒完，你要是把代碼跑起來就會發現，臥草，太慢了這玩意兒！正常人劃一下驗證碼頂多兩秒鐘的事兒，我們一幀一幀截圖得花個 40s 的時間才能截完圖算出山谷谷底的值來。

這裏提供幾種思路優化效率：

把元素縮小，複製多份，平鋪開來展示；這樣只要截一次，然後再裁剪、比對就好。
放大步長，比方說先每次平移 15px，找到局部最優解，然後在局部最優解附近再回到平移 1px 的方案找最優解。
因爲圖片比對的結果類似 “V” 字，“V”字右半邊其實是可以不用再計算的。

使用 1+2+3 我覺得可以在 3s 內搞定最優解，不過代碼複雜度會變得很高，文中簡單起見暫只實現一下方案 2。

首先是每次移動 15px 找局部最優解。

// 圖片缺口是不會給挖在初始附近的，
// 所以 left 從 45 像素開始計算可以節約不少計算量，
let left = 45;
const max15Offset = 265;
const res15px = [];
while (left <= max15Offset) {
  await setLeft(left);
  const compareRes = await compare();
  res15px.push({
    left,
    diff: compareRes.differences,
  });
  left += 15;
}

然後再嘗試每次移動 2px 找最優解，搜尋的範圍是 15px 步長最優解的 left 偏移量的左右共 20 個像素。

const min15pxDiff = Math.min(...res15px.map((x) => x.diff));
const min15pxLeft = res15px.find((x) => x.diff === min15pxDiff).left;

left = min15pxLeft - 12;
const max2Offset = min15pxLeft + 8;
const res2px = [];
while (left <= max2Offset) {
  await setLeft(left);
  const compareRes = await compare();
  res2px.push({
    left,
    diff: compareRes.differences,
  });
  left += 2;
}

此時得到的解可以約等於最優解了。當然，如果你覺得不穩的話，還可以使用 1px 步長去找。

估算一下，原先需要截 245 次圖片，現在直接降到 1/10，23 次。不過，也別太高興，因爲測試發現只做優化 2，解驗證碼的時候還是要 7s...

移動鼠標

缺口位置都搞定了，那移動鼠標還不簡單嘛~

Puppeteer 已經提供了鼠標相關的接口 [6]，一共四個：mouse.click、mouse.down、mouse.move、mouse.up，分別是點擊、按下、移動和鬆開。使用 mouse.move 可以直接把鼠標位置移動到一個特定的座標上。假設我們現在從座標（100,100）花大約 1s 把鼠標移動到（200,200），可以使用循環實現。

const now = {
  x: 100,
  y: 100
}
const target = {
  time: 1000,
  x: 200,
  y: 200, 
}
const steps = 10
const step = {
  x: Math.floor((target.x - now.x) / steps),
  y: Math.floor((target.y - now.y) / steps),
  time: target.time / steps
}
while (now.x < target.x) {
  await sleep(step.time)
  now.x += step.x
  now.y += step.y
  await page.mouse.move(now)
}

害，要是打遊戲的時候也像這段代碼一樣，我想我的手點到哪兒它就點到哪兒就好了~

機器是不會手抖的，這段代碼和真實世界的滑動效果相差太遠了！我們看一張我用手滑的效果，尤其是要仔細觀察滑動過程中鼠標的位置。

鼠標軌跡不穩定

鼠標 Y 軸位置總是在變
鼠標 X 軸位置會滑過頭

這裏做一波小優化，把這兩個細節整合進去。

// 獲得一個隨機的偏移量
const getRandOffset = (enableNegative = true, max = 3) => {
  const negative = enableNegative
    ? (Math.random() < 0.5) ? -1 : 1
    : 1
  return Math.floor(Math.random() * max) * negative
}

// 先滑過頭十幾像素，然後再花 100 毫秒的時間往回滑到正確位置
const targets = [
  {
    time: 1000,
    x: 200 + getRandOffset(false, 15),
    y: 200 + getRandOffset(false, 15),
    steps: 10
  },
  {
    time: 100,
    x: 200,
    y: 200,
    steps: 3
  }
]

// 注意這裏用 for await 循環把 targets 串起來執行
for await (const target of targets) {
  const step = {
    x: Math.floor((target.x - now.x) / target.steps),
    y: Math.floor((target.y - now.y) / target.steps),
    time: target.time / target.steps,
  }
  let gap
  while (gap = Math.abs((target.x - now.x)), gap > 0) {
    await sleep(step.time)
    // 最後一步就直接滑動到位，不需要隨機數了
    const inOneStep = Math.abs(target.x - now.x) <= Math.abs(step.x);
    if (inOneStep) {
      now.x = target.x;
      now.y = target.y;
    } else {
      now.x += step.x + getRandOffset();
      now.y += step.y + getRandOffset();
    }
    moveMouseTo(now)
  }
}

如何移動鼠標到這裏就解決了，如果要考慮加速度、用戶習慣等因素，代碼會更加複雜，暫時就不深入討論啦，有興趣的同學可以自己研究。

最終效果如下（這張 GIF 忘記設置循環播放了，可能要在新頁面打開它才能看到效果）。

最終效果（加速）

源碼地址：Crack-the-Slider[7]

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ZWadv7Ntrc3bA9UvNdpITA

思路講解

打開頁面

判斷位置

移動鼠標

猜你喜歡