崙?zhàn)：請求頭簽名與動(dòng)態(tài)字體反爬疊加解析)
抓一個(gè)企業(yè)信息類站點(diǎn)的公開數(shù)據(jù)最讓人頭疼的往往不是登錄環(huán)節(jié)而是請求頭里那串看不出規(guī)律的十六進(jìn)制字符串以及頁面上一堆方框或者牛頭不對(duì)馬嘴的漢字。前者是 JavaScript 逆向里最典型的 header 加密后者是字體反爬的標(biāo)準(zhǔn)套路。這兩套機(jī)制單獨(dú)出現(xiàn)都不算難一旦疊在一起新手很容易在第一步就卡死簽名對(duì)不上直接被拒簽名對(duì)上了又拿到一堆亂碼數(shù)字兩輪折騰下來人都麻了。這篇內(nèi)容按我自己的排查順序把這兩塊拆開講清楚。簽名參數(shù)是怎么在混淆代碼里被生成的、斷點(diǎn)該下在哪里、加密函數(shù)怎么從一團(tuán)亂麻里摳出來本地跑字體反爬的映射關(guān)系到底藏在文件哪個(gè)位置、用字形輪廓怎么做特征比對(duì)、遇到每次刷新都換一套的動(dòng)態(tài)字體怎么保持長期穩(wěn)定。內(nèi)容適合有一定前端基礎(chǔ)、正在學(xué) JavaScript 逆向、或者被這兩類反爬卡過項(xiàng)目的讀者。文中所有代碼和字段名都做了脫敏處理域名、參數(shù)名一律用示例代替思路可以直接遷移。需要提前說清楚一點(diǎn)這類技術(shù)的正當(dāng)用途是學(xué)習(xí)前端保護(hù)機(jī)制、做自己有權(quán)訪問的數(shù)據(jù)采集、以及評(píng)估自家站點(diǎn)的防護(hù)強(qiáng)度。對(duì)外的數(shù)據(jù)抓取請務(wù)必遵守目標(biāo)站點(diǎn)的服務(wù)條款與 robots 協(xié)議控制請求頻率別把別人的服務(wù)器當(dāng)成自己的壓測環(huán)境。技術(shù)是中性的用在哪、怎么用取決于寫代碼的人。1. 請求頭里那串簽名才是真正的門1.1 一次抓包看到的三個(gè)異常字段打開開發(fā)者工具的 Network 面板隨便點(diǎn)一個(gè)返回?cái)?shù)據(jù)的接口把請求頭展開通常能看到幾個(gè)和普通瀏覽器請求不一樣的字段。它們不會(huì)有標(biāo)準(zhǔn)的Accept、User-Agent那種熟悉感而是帶著業(yè)務(wù)前綴比如X-Auth、X-Sign、X-Timestamp、X-Nonce這類命名。cookie 里往往也埋著一個(gè)類似的令牌跟著一起發(fā)出去。判斷哪個(gè)字段真正參與服務(wù)端校驗(yàn)最直接的辦法是本地重放。把請求復(fù)制成 cURL先原樣發(fā)一次確認(rèn)能通然后逐個(gè)刪掉可疑字段再發(fā)看返回結(jié)果。有的字段刪了沒影響說明只是埋點(diǎn)或者灰度標(biāo)識(shí)有的字段刪了立刻返回鑒權(quán)失敗或者空數(shù)據(jù)那它就是關(guān)鍵參數(shù)。這個(gè)方法笨但極其有效比對(duì)著代碼猜半天強(qiáng)得多。我第一次做這類分析時(shí)光靠刪字段就排除了三個(gè)干擾項(xiàng)省了大量讀混淆代碼的時(shí)間。字段名典型取值形態(tài)猜測作用驗(yàn)證方式X-Auth32 位小寫十六進(jìn)制可能是令牌或簽名刪掉重放看是否 401X-Timestamp13 位毫秒時(shí)間戳防重放窗口校驗(yàn)改成很久以前的值重放X-Nonce8 到 16 位隨機(jī)串防重復(fù)請求兩次請求用同一個(gè)值對(duì)比X-Sign大寫十六進(jìn)制或 Base64參數(shù)摘要簽名改任一業(yè)務(wù)參數(shù)后觀察是否變化表格里最后一行值得多說兩句。簽名類字段有個(gè)很明顯的特征你把業(yè)務(wù)參數(shù)改一個(gè)字符它的值就會(huì)整體變化而且是雪崩式的變化不是局部變。這基本可以斷定它是摘要算法常見的是 MD5、SHA1、SHA256偶爾也有 HMAC 變種。反過來如果你改了參數(shù)它紋絲不動(dòng)那它更可能是和時(shí)間戳綁定的令牌而不是對(duì)參數(shù)的摘要。1.2 簽名參數(shù)通常掛在哪一層簽名放在請求頭、URL 查詢串還是請求體里背后其實(shí)有工程上的考量不是隨便選的。放請求頭是最常見的做法原因有三一是不會(huì)污染 URL避免被 CDN 日志、瀏覽器歷史、Referer 無意中記錄二是跨域場景下配合自定義頭能觸發(fā)預(yù)檢服務(wù)端多一層控制三是和業(yè)務(wù)參數(shù)解耦前端攔截器可以統(tǒng)一注入業(yè)務(wù)代碼完全無感。放 URL 查詢串的情況多見于一些老接口或者需要被緩存層識(shí)別的場景這種情況下簽名往往是對(duì)整個(gè)查詢串排序后做的摘要。放請求體的通常是表單提交類接口簽名會(huì)作為 body 的一個(gè)隱藏字段一起提交。還有一類比較隱蔽的簽名藏在 cookie 里通過響應(yīng)頭的Set-Cookie下發(fā)每次請求自動(dòng)帶上這種反而最省事因?yàn)闉g覽器幫你處理了。真正麻煩的不是位置而是簽名內(nèi)容到底包了什么。常見的組合是業(yè)務(wù)參數(shù)按字典序拼接 → 加時(shí)間戳 → 加隨機(jī)串 → 加一個(gè)硬編碼在 JS 里的鹽 → 做摘要。這里任何一環(huán)的順序錯(cuò)了算出來的值都對(duì)不上。所以逆向的第一步不是急著讀代碼而是先把輸入確定下來也就是搞清楚簽名函數(shù)的入?yún)⒔Y(jié)構(gòu)。這個(gè)下文會(huì)詳細(xì)講。2. 順著調(diào)用棧往回走把簽名函數(shù)從混淆里挖出來2.1 斷點(diǎn)不是隨便下的從網(wǎng)絡(luò)面板倒推很多人一上來就去全局搜索字段名搜到一堆\x58\x2d\x53\x69\x67\x6e這樣的東西就懵了。其實(shí)更高效的路徑是從結(jié)果倒推過程。在 Network 面板找到那個(gè)請求右鍵選擇Replay XHR請求會(huì)重新發(fā)一次在 Sources 面板里對(duì)XMLHttpRequest.prototype.send或者fetch下斷點(diǎn)勾上Pause on any XHR/fetch讓請求在發(fā)出前停下來。停下來的那一刻調(diào)用棧就是你最好的地圖。棧頂通常是框架內(nèi)部的攔截器往下翻幾層會(huì)看到一個(gè)業(yè)務(wù)函數(shù)它的作用域里大概率能看到headers或者config對(duì)象里面就有那個(gè)簽名值。這時(shí)候別急著單步先在棧幀里點(diǎn)開各個(gè)作用域看看有沒有sign、token、timestamp這些變量名。如果變量名被混淆成了_0x1a2b就看它的值值和請求頭里那個(gè)簽名對(duì)得上的那個(gè)變量就是你要找的。我個(gè)人的習(xí)慣是找到值之后右鍵那個(gè)變量選Store as global variable控制臺(tái)里就能用temp1直接訪問然后寫幾行代碼調(diào)一調(diào)看看把它換成別的值請求還能不能通。這一步能確認(rèn)它到底是簽名還是別的什么避免走了半天冤枉路。2.2 字符串?dāng)?shù)組與控制流平坦化的處理手法混淆工具產(chǎn)出的代碼有幾個(gè)經(jīng)典特征認(rèn)出來之后還原思路就比較清晰了。第一個(gè)是字符串?dāng)?shù)組文件開頭有一大坨var _0x4f2c [\x73\x69\x67\x6e, getTime, ...]后面所有字符串都通過_0x4f2c[0x1]這種方式引用。第二個(gè)是解碼函數(shù)數(shù)組里的字符串常常還是加密的需要一個(gè)立即執(zhí)行函數(shù)在啟動(dòng)時(shí)解密一遍。第三個(gè)是控制流平坦化一段簡單的 if-else 被改寫成while(true){ switch(_0xabc--) { case 0: ... } }的形式看得人腦殼疼。處理字符串?dāng)?shù)組最有效的辦法不是手動(dòng)替換而是讓瀏覽器自己跑出來。在解碼函數(shù)執(zhí)行完之后的那一行下斷點(diǎn)控制臺(tái)里直接打印那個(gè)數(shù)組變量整個(gè)明文數(shù)組就出來了。如果在源碼里定位不到解碼完成的位置可以在文件末尾加一行console.log(_0x4f2c)或者用調(diào)試器的Logpoint功能不用改源碼也能看到?？刂屏髌教够鄬?duì)麻煩但也不用全部還原。大多數(shù)情況下你只需要跑通一個(gè)函數(shù)而不是讀懂整個(gè)文件。把switch里的case順序用腳本重新排一下按照_0xabc的初始值反推出執(zhí)行順序再把代碼塊按順序重排可讀性就能恢復(fù)七八成。如果懶得動(dòng)手直接讓虛擬機(jī)執(zhí)行原始混淆代碼也是可行的只是調(diào)試體驗(yàn)差一些。下面是我常用的字符串?dāng)?shù)組還原腳本思路是把數(shù)組和解碼函數(shù)一起在 Node 里跑一遍把結(jié)果 dump 出來const fs require(fs); const vm require(vm); const source fs.readFileSync(./obfuscated.js, utf-8); // 用一個(gè)最簡單的樁環(huán)境防止解碼函數(shù)里引用 window 報(bào)錯(cuò) const sandbox { window: {}, document: { createElement: () ({}) }, navigator: { userAgent: Mozilla/5.0 }, console: console, atob: (s) Buffer.from(s, base64).toString(binary), }; vm.createContext(sandbox); // 只取文件開頭的數(shù)組聲明和解碼 IIFE避免執(zhí)行后續(xù)業(yè)務(wù)邏輯 const head source.slice(0, source.indexOf(function _0x)); try { vm.runInContext(head, sandbox, { timeout: 3000 }); } catch (e) { console.warn(部分解碼失敗可分段執(zhí)行, e.message); } // 通常解碼后的數(shù)組會(huì)被掛回原變量名直接打印 const names Object.keys(sandbox).filter(k /^_0x/.test(k)); names.forEach(n console.log(n, sandbox[n]));這段代碼的價(jià)值不在于多高明而在于它體現(xiàn)了一個(gè)原則能交給引擎執(zhí)行的就別用手算?；煜谋举|(zhì)是機(jī)器能讀懂、人讀不懂那就讓機(jī)器去讀。2.3 摳出來的代碼怎么在本地跑起來定位到加密函數(shù)之后下一步是把它從整個(gè)文件里剝離出來讓它在本地 Node 環(huán)境里獨(dú)立運(yùn)行。這個(gè)過程俗稱摳代碼或者補(bǔ)環(huán)境聽起來玄乎其實(shí)就是缺什么補(bǔ)什么。第一輪直接把函數(shù)體連同它依賴的變量、工具函數(shù)一起復(fù)制出來扔到一個(gè)新文件里跑一下看報(bào)什么錯(cuò)。報(bào)window is not defined就補(bǔ)一個(gè)global.window {}報(bào)document is not defined就補(bǔ)一個(gè)最簡對(duì)象報(bào)navigator、location、localStorage同理。關(guān)鍵是別一次補(bǔ)全按報(bào)錯(cuò)驅(qū)動(dòng)補(bǔ)一個(gè)跑一次這樣才知道哪些是真正用到的哪些是冗余的。// env.js —— 最小可用環(huán)境樁 global.window global; global.navigator { userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64), platform: Win32, language: zh-CN, }; global.location { href: https://example.com/list, protocol: https: }; global.document { cookie: , referrer: https://example.com/, createElement: () ({ getContext: () null, style: {}, }), getElementsByTagName: () [], }; global.localStorage { _s: {}, getItem(k) { return this._s[k] || null; }, setItem(k, v) { this._s[k] String(v); }, }; // 加載并調(diào)用摳出來的簽名函數(shù) require(./sign.js); const result global.__sign({ page: 1, keyword: demo, ts: Date.now() }); console.log(sign , result);這里有幾個(gè)坑要提前說。一是Date和Math.random可能被頁面重寫過如果原代碼里有Date.prototype.getTime的改寫本地行為會(huì)和瀏覽器不一致需要把這個(gè)改寫也一起扣出來。二是有些簽名函數(shù)依賴document.cookie里的某個(gè)值本地是空的算出來的結(jié)果自然對(duì)不上這時(shí)候要把真實(shí) cookie 塞進(jìn)去。三是時(shí)區(qū)問題如果簽名里用到了new Date().toString()本地環(huán)境和服務(wù)器時(shí)區(qū)不一致會(huì)直接導(dǎo)致簽名失敗最好統(tǒng)一成時(shí)間戳運(yùn)算。我踩過最深的一個(gè)坑是某個(gè)函數(shù)內(nèi)部用了window.performance.now()本地補(bǔ)了window但沒補(bǔ)performance報(bào)錯(cuò)信息被 try-catch 吃掉了返回undefined最后是逐行打斷點(diǎn)才發(fā)現(xiàn)的。所以補(bǔ)環(huán)境的時(shí)候盡量把 try-catch 先注釋掉讓錯(cuò)誤暴露出來別讓靜默失敗浪費(fèi)時(shí)間。3. 字體反爬不是障眼法是另一套編碼3.1 頁面上的亂碼其實(shí)是私有區(qū)碼點(diǎn)第一次遇到字體反爬的人最常見的反應(yīng)是這頁面怎么全是方塊。其實(shí)仔細(xì)看方塊里是有東西的只是字形被替換過。打開 Elements 面板選中一個(gè)數(shù)字看到的文本內(nèi)容是#xe123;這樣的私有區(qū)碼點(diǎn)范圍通常在 UE000 到 UF8FF 之間。瀏覽器用頁面引入的自定義字體去渲染這個(gè)碼點(diǎn)字體文件里把 UE123 這個(gè)位置畫成了8的樣子所以你看到的是8但復(fù)制出來是\ue123。整個(gè)鏈路是這樣的font-face聲明了一個(gè).woff或.ttf文件font-family指向它頁面元素的文本用私有區(qū)碼點(diǎn)瀏覽器加載字體后按 cmap 表把碼點(diǎn)映射到字形索引再從glyf表里取出輪廓數(shù)據(jù)渲染出來。反爬的核心就在 cmap 這張表上——它等于一張碼點(diǎn) → 字形的字典只要把這張字典讀出來再搞清楚每個(gè)字形長什么樣映射關(guān)系就破了。用 Python 的fontTools解析是最省事的路徑幾行代碼就能把 cmap 打印出來from fontTools.ttLib import TTFont font TTFont(target.woff) cmap font.getBestCmap() # {碼點(diǎn): 字形名} glyf font[glyf] for code, name in sorted(cmap.items()): glyph glyf[name] if glyph.numberOfContours 0: continue # 空字形或復(fù)合字形跳過 coords glyph.coordinates print(hex(code), name, 點(diǎn)數(shù), len(coords), x范圍, (min(p[0] for p in coords), max(p[0] for p in coords)))getBestCmap()返回的是 Unicode cmap 子表一般就是你要的那張。字形名通常是uniE123這種命名但不絕對(duì)有的字體商會(huì)用glyph001之類的無意義名字所以別依賴名字依賴碼點(diǎn)和輪廓數(shù)據(jù)。復(fù)合字形composite glyph的numberOfContours是負(fù)數(shù)需要先glyf[name].getCoordinates(glyf)展開再處理直接讀coordinates會(huì)報(bào)錯(cuò)這一點(diǎn)在文檔里寫得不太明顯。3.2 用字形輪廓做特征比對(duì)拿到 cmap 只是第一步你還需要知道每個(gè)字形到底對(duì)應(yīng)哪個(gè)真實(shí)字符。如果反爬做得比較敷衍字形名會(huì)直接叫uniE123.1或者干脆就是eight一眼就能看出來。但稍微認(rèn)真一點(diǎn)的名字都是隨機(jī)生成的這時(shí)候就得從輪廓特征反推。輪廓特征可以從幾個(gè)維度提取控制點(diǎn)數(shù)量、輪廓的包圍盒寬高、各點(diǎn)坐標(biāo)的哈希、輪廓數(shù)量。真實(shí)場景下同一個(gè)字符在不同字體文件里的輪廓可能被輕微擾動(dòng)比如點(diǎn)坐標(biāo)整體偏移 1 到 2 個(gè)單位或者增加幾個(gè)冗余點(diǎn)所以不能做精確哈希得做相似度匹配。我一般用點(diǎn)數(shù) 寬高比 坐標(biāo)歸一化后的歐氏距離這三項(xiàng)加權(quán)效果比較穩(wěn)。def glyph_feature(font, name): glyph font[glyf][name] coords, _, _ glyph.getCoordinates(font[glyf]) xs [p[0] for p in coords] ys [p[1] for p in coords] w max(xs) - min(xs) or 1 h max(ys) - min(ys) or 1 # 歸一化到 0-1消除字號(hào)差異 norm [((x - min(xs)) / w, (y - min(ys)) / h) for x, y in coords] return { count: len(coords), ratio: round(w / h, 3), points: norm, } def similarity(a, b): if abs(a[count] - b[count]) a[count] * 0.2: return 0.0 if abs(a[ratio] - b[ratio]) 0.1: return 0.0 n min(len(a[points]), len(b[points])) dist sum(((a[points][i][0] - b[points][i][0]) ** 2 (a[points][i][1] - b[points][i][1]) ** 2) ** 0.5 for i in range(n)) / n return max(0.0, 1 - dist * 3)這套方法的前提是你手里有一份標(biāo)準(zhǔn)字形庫。做法很簡單找一個(gè)頁面上能看到真實(shí)字符的對(duì)照位置比如詳情頁里同時(shí)用普通字體展示的數(shù)字把字體文件按碼點(diǎn)解析后人工或者半自動(dòng)地把字形和真實(shí)字符綁定一次存成 JSON。之后每次遇到新字體拿新字形去和標(biāo)準(zhǔn)庫做相似度匹配取最高分即可。0 到 9 這十個(gè)數(shù)字加上小數(shù)點(diǎn)、冒號(hào)、百分號(hào)一共也就十幾個(gè)字符人工標(biāo)一次十分鐘的事一勞永逸。3.3 動(dòng)態(tài)字體每次刷新都是一張新表靜態(tài)字體反爬是入門級(jí)真正讓人抓狂的是動(dòng)態(tài)字體每次刷新頁面服務(wù)端重新生成一個(gè)字體文件碼點(diǎn)和字形的對(duì)應(yīng)關(guān)系整體打亂。今天 UE001 是8明天可能就是3。這時(shí)候只解析一次 cmap 是沒用的必須每次請求都重新拉字體、重新解析、重新匹配。判斷是不是動(dòng)態(tài)字體最粗暴的方法是連續(xù)刷新兩次對(duì)比兩次拿到的字體文件 MD5。如果不一樣再看 cmap 里的碼點(diǎn)集合是否變化碼點(diǎn)集合變了說明是全新字體碼點(diǎn)集合沒變但字形位置變了說明是重排。兩種情況處理思路一樣都是每次都以當(dāng)前字體文件為準(zhǔn)重新走一遍特征匹配。工程上要做的是把解析 → 匹配 → 緩存這條鏈路做成冪等的。緩存鍵用字體文件的 MD5 而不是 URL因?yàn)?URL 里常常帶隨機(jī)參數(shù)同一個(gè)文件可能會(huì)有多個(gè) URL。匹配結(jié)果存成{字體MD5: {碼點(diǎn): 真實(shí)字符}}的字典同一個(gè)字體再次出現(xiàn)時(shí)直接查緩存省掉重復(fù)的輪廓計(jì)算。這套機(jī)制搭好之后單次頁面解析的額外耗時(shí)能壓到幾十毫秒基本不影響整體抓取效率。還有個(gè)經(jīng)驗(yàn)有些字體文件會(huì)把部分字形做成空殼輪廓點(diǎn)數(shù)極少甚至為零用來干擾基于點(diǎn)數(shù)的識(shí)別。遇到這種情況特征匹配會(huì)自動(dòng)失敗這時(shí)候退一步用渲染截圖做像素比對(duì)也能兜底雖然慢但準(zhǔn)確率更高。別在一種方法上死磕多準(zhǔn)備一條后路。4. 兩套機(jī)制疊在一起時(shí)的穩(wěn)定性問題4.1 時(shí)間戳、隨機(jī)數(shù)與簽名有效期簽名里帶時(shí)間戳的接口服務(wù)端一定會(huì)做時(shí)間窗口校驗(yàn)常見的是允許 ±300 秒或 ±600 秒的偏差。這意味著你算出來的簽名不是永久有效的隔一段時(shí)間就得重算。本地調(diào)試時(shí)如果反復(fù)用同一個(gè)簽名發(fā)請求過一會(huì)兒突然開始報(bào)錯(cuò)十有八九不是代碼壞了是時(shí)間戳過期了。正確的處理方式是把簽名計(jì)算做成每次請求前調(diào)用而不是啟動(dòng)時(shí)算一次緩存起來。函數(shù)簽名大致是sign(params)內(nèi)部自己取當(dāng)前時(shí)間戳外部只管傳業(yè)務(wù)參數(shù)。隨機(jī)串同理nonce必須每次重新生成如果復(fù)用會(huì)被服務(wù)端的防重放機(jī)制攔下來。還有一種更隱蔽的情況服務(wù)端不僅校驗(yàn)時(shí)間窗口還校驗(yàn)時(shí)間戳的單調(diào)遞增也就是后一次請求的時(shí)間戳不能小于前一次。如果本地時(shí)間因?yàn)?NTP 同步往回跳了一下就會(huì)出現(xiàn)莫名其妙的失敗。穩(wěn)妥的做法是維護(hù)一個(gè)本地遞增計(jì)數(shù)器取max(當(dāng)前時(shí)間, 上次時(shí)間 1)作為實(shí)際使用的時(shí)間戳能規(guī)避絕大多數(shù)抖動(dòng)。4.2 字體映射緩存的失效判斷字體緩存失效的判斷不能只看時(shí)間得看內(nèi)容。我見過有人設(shè)置緩存 10 分鐘過期結(jié)果服務(wù)端是每 5 分鐘換一次字體中間 5 分鐘一直在用錯(cuò)誤的映射解析數(shù)據(jù)全錯(cuò)還找不到原因。更可靠的做法是每次請求響應(yīng)里檢查字體 URL 或者響應(yīng)頭里的文件哈希變了就重新拉。有些站點(diǎn)更狠字體文件路徑完全不變但內(nèi)容每次請求都不同靠 CDN 緩存控制頭來區(qū)分。這種情況就得在下載后立刻算一次 SHA1和上次的比對(duì)。多一次幾百 KB 文件的哈希計(jì)算代價(jià)可以接受換來的是映射絕對(duì)不會(huì)錯(cuò)位。失效情形判斷依據(jù)處理策略字體 URL 變化響應(yīng) HTML 里的font-face地址直接重新下載解析URL 不變但內(nèi)容變下載后計(jì)算文件 SHA1比對(duì)哈希不同則重建映射碼點(diǎn)集合變化cmap 的 key 集合視為全新字體全量匹配字形輪廓輕微擾動(dòng)特征相似度低于閾值用標(biāo)準(zhǔn)庫做模糊匹配兜底表格里最后一行是最容易被忽略的。有的站點(diǎn)不做整體重排只是在原有基礎(chǔ)上給每個(gè)字形加一點(diǎn)隨機(jī)偏移肉眼完全看不出區(qū)別但精確哈希會(huì)全部失效。這時(shí)候如果你的匹配邏輯是哈希相等才算命中就會(huì)全軍覆沒。所以特征匹配一定要留模糊空間閾值設(shè)得松一點(diǎn)寧可多匹配幾次也別直接判失敗。5. 工程化與邊界能跑和能長期跑是兩回事5.1 請求節(jié)奏與失敗重試的設(shè)計(jì)腳本能跑通第一版的時(shí)候人是最容易上頭的恨不得立刻把并發(fā)拉到 50 去刷全量數(shù)據(jù)。這么干的結(jié)果通常是被限流、被封 IP、或者觸發(fā)更嚴(yán)格的風(fēng)控然后前面的工作全白費(fèi)。正確的節(jié)奏是把并發(fā)壓到個(gè)位數(shù)請求之間加隨機(jī)間隔比如 800 到 2000 毫秒之間浮動(dòng)。這個(gè)數(shù)字不是拍腦袋是根據(jù)大多數(shù)站點(diǎn)默認(rèn)的限流策略估算的低于這個(gè)值觸發(fā)概率會(huì)明顯上升。重試策略也要講究。遇到 403、429 這類狀態(tài)碼不要立刻重試先退避等 5 秒、15 秒、60 秒指數(shù)增長最多重試三次。遇到簽名錯(cuò)誤類的業(yè)務(wù)返回碼別重試因?yàn)橹卦囈彩清e(cuò)的應(yīng)該重新走一遍簽名計(jì)算流程再發(fā)。遇到字體解析失敗也別重試請求重試的是字體下載和匹配環(huán)節(jié)。把不同錯(cuò)誤類型分開處理比無腦while(retry 3)靠譜得多。判斷是不是被限流了除了看狀態(tài)碼還可以看響應(yīng)時(shí)間。正常情況下 200 毫秒的接口突然變成 3 秒哪怕返回的仍是 200也說明服務(wù)端在給你降速這時(shí)候主動(dòng)停下來歇幾分鐘比硬剛更明智。5.2 把逆向結(jié)果封裝成可替換的模塊逆向代碼最大的問題是脆弱。對(duì)方前端一改版你摳出來的函數(shù)可能整個(gè)失效。所以從一開始就要把它當(dāng)成一個(gè)可替換的適配器來設(shè)計(jì)而不是散落在主流程里的幾十行腳本。具體做法是定義一個(gè)穩(wěn)定的接口比如signRequest(params) - headers內(nèi)部實(shí)現(xiàn)隨便怎么變外部調(diào)用方不感知。字體解析同理定義decodeText(text, fontBuffer) - plainText換了解析算法也不影響調(diào)用方。這樣改版的時(shí)候你只需要重寫適配器內(nèi)部主流程一行不用動(dòng)。配置項(xiàng)也要抽出來。鹽值、字段名、簽名算法、字體匹配閾值全部放到配置文件里別硬編碼在函數(shù)中間。我見過太多人把鹽值寫在代碼第 300 行改版之后找了半天才想起來在哪兒。集中管理之后改版排查的時(shí)間能省一大半。最后一條經(jīng)驗(yàn)是關(guān)于日志的。逆向類腳本一定要打詳細(xì)日志但要分級(jí)。請求級(jí)別的日志記錄 URL、耗時(shí)、狀態(tài)碼簽名級(jí)別的日志記錄入?yún)⒑统鰠⒌恼獎(jiǎng)e打完整值太長字體級(jí)別的日志記錄文件哈希和匹配成功率。出問題的時(shí)候看一眼日志就知道是哪一環(huán)崩的比重新斷點(diǎn)調(diào)試快十倍。日志文件記得輪轉(zhuǎn)別跑一天把磁盤寫滿。真正把這類項(xiàng)目做久了我才明白逆向能力只占三成剩下七成是工程穩(wěn)健性和對(duì)邊界的管理。代碼寫得再巧妙如果三天兩頭因?yàn)閷?duì)方改版就全線崩那這個(gè)項(xiàng)目就沒法交付。反過來拆得足夠清晰、切得足夠細(xì)、日志足夠全就算核心算法失效了也能在半小時(shí)內(nèi)定位并替換掉。這才是能長期跑下去的狀態(tài)。 JS逆向?qū)崙?zhàn)：請求頭簽名與動(dòng)態(tài)字體反爬疊加解析
抓一個(gè)企業(yè)信息類站點(diǎn)的公開數(shù)據(jù)最讓人頭疼的往往不是登錄環(huán)節(jié)而是請求頭里那串看不出規(guī)律的十六進(jìn)制字符串以及頁面上一堆方框或者牛頭不對(duì)馬嘴的漢字。前者是 JavaScript 逆向里最典型的 header 加密后者是字體反爬的標(biāo)準(zhǔn)套路。這兩套機(jī)制單獨(dú)出現(xiàn)都不算難一旦疊在一起新手很容易在第一步就卡死簽名對(duì)不上直接被拒簽名對(duì)上了又拿到一堆亂碼數(shù)字兩輪折騰下來人都麻了。這篇內(nèi)容按我自己的排查順序把這兩塊拆開講清楚。簽名參數(shù)是怎么在混淆代碼里被生成的、斷點(diǎn)該下在哪里、加密函數(shù)怎么從一團(tuán)亂麻里摳出來本地跑字體反爬的映射關(guān)系到底藏在文件哪個(gè)位置、用字形輪廓怎么做特征比對(duì)、遇到每次刷新都換一套的動(dòng)態(tài)字體怎么保持長期穩(wěn)定。內(nèi)容適合有一定前端基礎(chǔ)、正在學(xué) JavaScript 逆向、或者被這兩類反爬卡過項(xiàng)目的讀者。文中所有代碼和字段名都做了脫敏處理域名、參數(shù)名一律用示例代替思路可以直接遷移。需要提前說清楚一點(diǎn)這類技術(shù)的正當(dāng)用途是學(xué)習(xí)前端保護(hù)機(jī)制、做自己有權(quán)訪問的數(shù)據(jù)采集、以及評(píng)估自家站點(diǎn)的防護(hù)強(qiáng)度。對(duì)外的數(shù)據(jù)抓取請務(wù)必遵守目標(biāo)站點(diǎn)的服務(wù)條款與 robots 協(xié)議控制請求頻率別把別人的服務(wù)器當(dāng)成自己的壓測環(huán)境。技術(shù)是中性的用在哪、怎么用取決于寫代碼的人。1. 請求頭里那串簽名才是真正的門1.1 一次抓包看到的三個(gè)異常字段打開開發(fā)者工具的 Network 面板隨便點(diǎn)一個(gè)返回?cái)?shù)據(jù)的接口把請求頭展開通常能看到幾個(gè)和普通瀏覽器請求不一樣的字段。它們不會(huì)有標(biāo)準(zhǔn)的Accept、User-Agent那種熟悉感而是帶著業(yè)務(wù)前綴比如X-Auth、X-Sign、X-Timestamp、X-Nonce這類命名。cookie 里往往也埋著一個(gè)類似的令牌跟著一起發(fā)出去。判斷哪個(gè)字段真正參與服務(wù)端校驗(yàn)最直接的辦法是本地重放。把請求復(fù)制成 cURL先原樣發(fā)一次確認(rèn)能通然后逐個(gè)刪掉可疑字段再發(fā)看返回結(jié)果。有的字段刪了沒影響說明只是埋點(diǎn)或者灰度標(biāo)識(shí)有的字段刪了立刻返回鑒權(quán)失敗或者空數(shù)據(jù)那它就是關(guān)鍵參數(shù)。這個(gè)方法笨但極其有效比對(duì)著代碼猜半天強(qiáng)得多。我第一次做這類分析時(shí)光靠刪字段就排除了三個(gè)干擾項(xiàng)省了大量讀混淆代碼的時(shí)間。字段名典型取值形態(tài)猜測作用驗(yàn)證方式X-Auth32 位小寫十六進(jìn)制可能是令牌或簽名刪掉重放看是否 401X-Timestamp13 位毫秒時(shí)間戳防重放窗口校驗(yàn)改成很久以前的值重放X-Nonce8 到 16 位隨機(jī)串防重復(fù)請求兩次請求用同一個(gè)值對(duì)比X-Sign大寫十六進(jìn)制或 Base64參數(shù)摘要簽名改任一業(yè)務(wù)參數(shù)后觀察是否變化表格里最后一行值得多說兩句。簽名類字段有個(gè)很明顯的特征你把業(yè)務(wù)參數(shù)改一個(gè)字符它的值就會(huì)整體變化而且是雪崩式的變化不是局部變。這基本可以斷定它是摘要算法常見的是 MD5、SHA1、SHA256偶爾也有 HMAC 變種。反過來如果你改了參數(shù)它紋絲不動(dòng)那它更可能是和時(shí)間戳綁定的令牌而不是對(duì)參數(shù)的摘要。1.2 簽名參數(shù)通常掛在哪一層簽名放在請求頭、URL 查詢串還是請求體里背后其實(shí)有工程上的考量不是隨便選的。放請求頭是最常見的做法原因有三一是不會(huì)污染 URL避免被 CDN 日志、瀏覽器歷史、Referer 無意中記錄二是跨域場景下配合自定義頭能觸發(fā)預(yù)檢服務(wù)端多一層控制三是和業(yè)務(wù)參數(shù)解耦前端攔截器可以統(tǒng)一注入業(yè)務(wù)代碼完全無感。放 URL 查詢串的情況多見于一些老接口或者需要被緩存層識(shí)別的場景這種情況下簽名往往是對(duì)整個(gè)查詢串排序后做的摘要。放請求體的通常是表單提交類接口簽名會(huì)作為 body 的一個(gè)隱藏字段一起提交。還有一類比較隱蔽的簽名藏在 cookie 里通過響應(yīng)頭的Set-Cookie下發(fā)每次請求自動(dòng)帶上這種反而最省事因?yàn)闉g覽器幫你處理了。真正麻煩的不是位置而是簽名內(nèi)容到底包了什么。常見的組合是業(yè)務(wù)參數(shù)按字典序拼接 → 加時(shí)間戳 → 加隨機(jī)串 → 加一個(gè)硬編碼在 JS 里的鹽 → 做摘要。這里任何一環(huán)的順序錯(cuò)了算出來的值都對(duì)不上。所以逆向的第一步不是急著讀代碼而是先把輸入確定下來也就是搞清楚簽名函數(shù)的入?yún)⒔Y(jié)構(gòu)。這個(gè)下文會(huì)詳細(xì)講。2. 順著調(diào)用棧往回走把簽名函數(shù)從混淆里挖出來2.1 斷點(diǎn)不是隨便下的從網(wǎng)絡(luò)面板倒推很多人一上來就去全局搜索字段名搜到一堆\x58\x2d\x53\x69\x67\x6e這樣的東西就懵了。其實(shí)更高效的路徑是從結(jié)果倒推過程。在 Network 面板找到那個(gè)請求右鍵選擇Replay XHR請求會(huì)重新發(fā)一次在 Sources 面板里對(duì)XMLHttpRequest.prototype.send或者fetch下斷點(diǎn)勾上Pause on any XHR/fetch讓請求在發(fā)出前停下來。停下來的那一刻調(diào)用棧就是你最好的地圖。棧頂通常是框架內(nèi)部的攔截器往下翻幾層會(huì)看到一個(gè)業(yè)務(wù)函數(shù)它的作用域里大概率能看到headers或者config對(duì)象里面就有那個(gè)簽名值。這時(shí)候別急著單步先在棧幀里點(diǎn)開各個(gè)作用域看看有沒有sign、token、timestamp這些變量名。如果變量名被混淆成了_0x1a2b就看它的值值和請求頭里那個(gè)簽名對(duì)得上的那個(gè)變量就是你要找的。我個(gè)人的習(xí)慣是找到值之后右鍵那個(gè)變量選Store as global variable控制臺(tái)里就能用temp1直接訪問然后寫幾行代碼調(diào)一調(diào)看看把它換成別的值請求還能不能通。這一步能確認(rèn)它到底是簽名還是別的什么避免走了半天冤枉路。2.2 字符串?dāng)?shù)組與控制流平坦化的處理手法混淆工具產(chǎn)出的代碼有幾個(gè)經(jīng)典特征認(rèn)出來之后還原思路就比較清晰了。第一個(gè)是字符串?dāng)?shù)組文件開頭有一大坨var _0x4f2c [\x73\x69\x67\x6e, getTime, ...]后面所有字符串都通過_0x4f2c[0x1]這種方式引用。第二個(gè)是解碼函數(shù)數(shù)組里的字符串常常還是加密的需要一個(gè)立即執(zhí)行函數(shù)在啟動(dòng)時(shí)解密一遍。第三個(gè)是控制流平坦化一段簡單的 if-else 被改寫成while(true){ switch(_0xabc--) { case 0: ... } }的形式看得人腦殼疼。處理字符串?dāng)?shù)組最有效的辦法不是手動(dòng)替換而是讓瀏覽器自己跑出來。在解碼函數(shù)執(zhí)行完之后的那一行下斷點(diǎn)控制臺(tái)里直接打印那個(gè)數(shù)組變量整個(gè)明文數(shù)組就出來了。如果在源碼里定位不到解碼完成的位置可以在文件末尾加一行console.log(_0x4f2c)或者用調(diào)試器的Logpoint功能不用改源碼也能看到?？刂屏髌教够鄬?duì)麻煩但也不用全部還原。大多數(shù)情況下你只需要跑通一個(gè)函數(shù)而不是讀懂整個(gè)文件。把switch里的case順序用腳本重新排一下按照_0xabc的初始值反推出執(zhí)行順序再把代碼塊按順序重排可讀性就能恢復(fù)七八成。如果懶得動(dòng)手直接讓虛擬機(jī)執(zhí)行原始混淆代碼也是可行的只是調(diào)試體驗(yàn)差一些。下面是我常用的字符串?dāng)?shù)組還原腳本思路是把數(shù)組和解碼函數(shù)一起在 Node 里跑一遍把結(jié)果 dump 出來const fs require(fs); const vm require(vm); const source fs.readFileSync(./obfuscated.js, utf-8); // 用一個(gè)最簡單的樁環(huán)境防止解碼函數(shù)里引用 window 報(bào)錯(cuò) const sandbox { window: {}, document: { createElement: () ({}) }, navigator: { userAgent: Mozilla/5.0 }, console: console, atob: (s) Buffer.from(s, base64).toString(binary), }; vm.createContext(sandbox); // 只取文件開頭的數(shù)組聲明和解碼 IIFE避免執(zhí)行后續(xù)業(yè)務(wù)邏輯 const head source.slice(0, source.indexOf(function _0x)); try { vm.runInContext(head, sandbox, { timeout: 3000 }); } catch (e) { console.warn(部分解碼失敗可分段執(zhí)行, e.message); } // 通常解碼后的數(shù)組會(huì)被掛回原變量名直接打印 const names Object.keys(sandbox).filter(k /^_0x/.test(k)); names.forEach(n console.log(n, sandbox[n]));這段代碼的價(jià)值不在于多高明而在于它體現(xiàn)了一個(gè)原則能交給引擎執(zhí)行的就別用手算?；煜谋举|(zhì)是機(jī)器能讀懂、人讀不懂那就讓機(jī)器去讀。2.3 摳出來的代碼怎么在本地跑起來定位到加密函數(shù)之后下一步是把它從整個(gè)文件里剝離出來讓它在本地 Node 環(huán)境里獨(dú)立運(yùn)行。這個(gè)過程俗稱摳代碼或者補(bǔ)環(huán)境聽起來玄乎其實(shí)就是缺什么補(bǔ)什么。第一輪直接把函數(shù)體連同它依賴的變量、工具函數(shù)一起復(fù)制出來扔到一個(gè)新文件里跑一下看報(bào)什么錯(cuò)。報(bào)window is not defined就補(bǔ)一個(gè)global.window {}報(bào)document is not defined就補(bǔ)一個(gè)最簡對(duì)象報(bào)navigator、location、localStorage同理。關(guān)鍵是別一次補(bǔ)全按報(bào)錯(cuò)驅(qū)動(dòng)補(bǔ)一個(gè)跑一次這樣才知道哪些是真正用到的哪些是冗余的。// env.js —— 最小可用環(huán)境樁 global.window global; global.navigator { userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64), platform: Win32, language: zh-CN, }; global.location { href: https://example.com/list, protocol: https: }; global.document { cookie: , referrer: https://example.com/, createElement: () ({ getContext: () null, style: {}, }), getElementsByTagName: () [], }; global.localStorage { _s: {}, getItem(k) { return this._s[k] || null; }, setItem(k, v) { this._s[k] String(v); }, }; // 加載并調(diào)用摳出來的簽名函數(shù) require(./sign.js); const result global.__sign({ page: 1, keyword: demo, ts: Date.now() }); console.log(sign , result);這里有幾個(gè)坑要提前說。一是Date和Math.random可能被頁面重寫過如果原代碼里有Date.prototype.getTime的改寫本地行為會(huì)和瀏覽器不一致需要把這個(gè)改寫也一起扣出來。二是有些簽名函數(shù)依賴document.cookie里的某個(gè)值本地是空的算出來的結(jié)果自然對(duì)不上這時(shí)候要把真實(shí) cookie 塞進(jìn)去。三是時(shí)區(qū)問題如果簽名里用到了new Date().toString()本地環(huán)境和服務(wù)器時(shí)區(qū)不一致會(huì)直接導(dǎo)致簽名失敗最好統(tǒng)一成時(shí)間戳運(yùn)算。我踩過最深的一個(gè)坑是某個(gè)函數(shù)內(nèi)部用了window.performance.now()本地補(bǔ)了window但沒補(bǔ)performance報(bào)錯(cuò)信息被 try-catch 吃掉了返回undefined最后是逐行打斷點(diǎn)才發(fā)現(xiàn)的。所以補(bǔ)環(huán)境的時(shí)候盡量把 try-catch 先注釋掉讓錯(cuò)誤暴露出來別讓靜默失敗浪費(fèi)時(shí)間。3. 字體反爬不是障眼法是另一套編碼3.1 頁面上的亂碼其實(shí)是私有區(qū)碼點(diǎn)第一次遇到字體反爬的人最常見的反應(yīng)是這頁面怎么全是方塊。其實(shí)仔細(xì)看方塊里是有東西的只是字形被替換過。打開 Elements 面板選中一個(gè)數(shù)字看到的文本內(nèi)容是#xe123;這樣的私有區(qū)碼點(diǎn)范圍通常在 UE000 到 UF8FF 之間。瀏覽器用頁面引入的自定義字體去渲染這個(gè)碼點(diǎn)字體文件里把 UE123 這個(gè)位置畫成了8的樣子所以你看到的是8但復(fù)制出來是\ue123。整個(gè)鏈路是這樣的font-face聲明了一個(gè).woff或.ttf文件font-family指向它頁面元素的文本用私有區(qū)碼點(diǎn)瀏覽器加載字體后按 cmap 表把碼點(diǎn)映射到字形索引再從glyf表里取出輪廓數(shù)據(jù)渲染出來。反爬的核心就在 cmap 這張表上——它等于一張碼點(diǎn) → 字形的字典只要把這張字典讀出來再搞清楚每個(gè)字形長什么樣映射關(guān)系就破了。用 Python 的fontTools解析是最省事的路徑幾行代碼就能把 cmap 打印出來from fontTools.ttLib import TTFont font TTFont(target.woff) cmap font.getBestCmap() # {碼點(diǎn): 字形名} glyf font[glyf] for code, name in sorted(cmap.items()): glyph glyf[name] if glyph.numberOfContours 0: continue # 空字形或復(fù)合字形跳過 coords glyph.coordinates print(hex(code), name, 點(diǎn)數(shù), len(coords), x范圍, (min(p[0] for p in coords), max(p[0] for p in coords)))getBestCmap()返回的是 Unicode cmap 子表一般就是你要的那張。字形名通常是uniE123這種命名但不絕對(duì)有的字體商會(huì)用glyph001之類的無意義名字所以別依賴名字依賴碼點(diǎn)和輪廓數(shù)據(jù)。復(fù)合字形composite glyph的numberOfContours是負(fù)數(shù)需要先glyf[name].getCoordinates(glyf)展開再處理直接讀coordinates會(huì)報(bào)錯(cuò)這一點(diǎn)在文檔里寫得不太明顯。3.2 用字形輪廓做特征比對(duì)拿到 cmap 只是第一步你還需要知道每個(gè)字形到底對(duì)應(yīng)哪個(gè)真實(shí)字符。如果反爬做得比較敷衍字形名會(huì)直接叫uniE123.1或者干脆就是eight一眼就能看出來。但稍微認(rèn)真一點(diǎn)的名字都是隨機(jī)生成的這時(shí)候就得從輪廓特征反推。輪廓特征可以從幾個(gè)維度提取控制點(diǎn)數(shù)量、輪廓的包圍盒寬高、各點(diǎn)坐標(biāo)的哈希、輪廓數(shù)量。真實(shí)場景下同一個(gè)字符在不同字體文件里的輪廓可能被輕微擾動(dòng)比如點(diǎn)坐標(biāo)整體偏移 1 到 2 個(gè)單位或者增加幾個(gè)冗余點(diǎn)所以不能做精確哈希得做相似度匹配。我一般用點(diǎn)數(shù) 寬高比 坐標(biāo)歸一化后的歐氏距離這三項(xiàng)加權(quán)效果比較穩(wěn)。def glyph_feature(font, name): glyph font[glyf][name] coords, _, _ glyph.getCoordinates(font[glyf]) xs [p[0] for p in coords] ys [p[1] for p in coords] w max(xs) - min(xs) or 1 h max(ys) - min(ys) or 1 # 歸一化到 0-1消除字號(hào)差異 norm [((x - min(xs)) / w, (y - min(ys)) / h) for x, y in coords] return { count: len(coords), ratio: round(w / h, 3), points: norm, } def similarity(a, b): if abs(a[count] - b[count]) a[count] * 0.2: return 0.0 if abs(a[ratio] - b[ratio]) 0.1: return 0.0 n min(len(a[points]), len(b[points])) dist sum(((a[points][i][0] - b[points][i][0]) ** 2 (a[points][i][1] - b[points][i][1]) ** 2) ** 0.5 for i in range(n)) / n return max(0.0, 1 - dist * 3)這套方法的前提是你手里有一份標(biāo)準(zhǔn)字形庫。做法很簡單找一個(gè)頁面上能看到真實(shí)字符的對(duì)照位置比如詳情頁里同時(shí)用普通字體展示的數(shù)字把字體文件按碼點(diǎn)解析后人工或者半自動(dòng)地把字形和真實(shí)字符綁定一次存成 JSON。之后每次遇到新字體拿新字形去和標(biāo)準(zhǔn)庫做相似度匹配取最高分即可。0 到 9 這十個(gè)數(shù)字加上小數(shù)點(diǎn)、冒號(hào)、百分號(hào)一共也就十幾個(gè)字符人工標(biāo)一次十分鐘的事一勞永逸。3.3 動(dòng)態(tài)字體每次刷新都是一張新表靜態(tài)字體反爬是入門級(jí)真正讓人抓狂的是動(dòng)態(tài)字體每次刷新頁面服務(wù)端重新生成一個(gè)字體文件碼點(diǎn)和字形的對(duì)應(yīng)關(guān)系整體打亂。今天 UE001 是8明天可能就是3。這時(shí)候只解析一次 cmap 是沒用的必須每次請求都重新拉字體、重新解析、重新匹配。判斷是不是動(dòng)態(tài)字體最粗暴的方法是連續(xù)刷新兩次對(duì)比兩次拿到的字體文件 MD5。如果不一樣再看 cmap 里的碼點(diǎn)集合是否變化碼點(diǎn)集合變了說明是全新字體碼點(diǎn)集合沒變但字形位置變了說明是重排。兩種情況處理思路一樣都是每次都以當(dāng)前字體文件為準(zhǔn)重新走一遍特征匹配。工程上要做的是把解析 → 匹配 → 緩存這條鏈路做成冪等的。緩存鍵用字體文件的 MD5 而不是 URL因?yàn)?URL 里常常帶隨機(jī)參數(shù)同一個(gè)文件可能會(huì)有多個(gè) URL。匹配結(jié)果存成{字體MD5: {碼點(diǎn): 真實(shí)字符}}的字典同一個(gè)字體再次出現(xiàn)時(shí)直接查緩存省掉重復(fù)的輪廓計(jì)算。這套機(jī)制搭好之后單次頁面解析的額外耗時(shí)能壓到幾十毫秒基本不影響整體抓取效率。還有個(gè)經(jīng)驗(yàn)有些字體文件會(huì)把部分字形做成空殼輪廓點(diǎn)數(shù)極少甚至為零用來干擾基于點(diǎn)數(shù)的識(shí)別。遇到這種情況特征匹配會(huì)自動(dòng)失敗這時(shí)候退一步用渲染截圖做像素比對(duì)也能兜底雖然慢但準(zhǔn)確率更高。別在一種方法上死磕多準(zhǔn)備一條后路。4. 兩套機(jī)制疊在一起時(shí)的穩(wěn)定性問題4.1 時(shí)間戳、隨機(jī)數(shù)與簽名有效期簽名里帶時(shí)間戳的接口服務(wù)端一定會(huì)做時(shí)間窗口校驗(yàn)常見的是允許 ±300 秒或 ±600 秒的偏差。這意味著你算出來的簽名不是永久有效的隔一段時(shí)間就得重算。本地調(diào)試時(shí)如果反復(fù)用同一個(gè)簽名發(fā)請求過一會(huì)兒突然開始報(bào)錯(cuò)十有八九不是代碼壞了是時(shí)間戳過期了。正確的處理方式是把簽名計(jì)算做成每次請求前調(diào)用而不是啟動(dòng)時(shí)算一次緩存起來。函數(shù)簽名大致是sign(params)內(nèi)部自己取當(dāng)前時(shí)間戳外部只管傳業(yè)務(wù)參數(shù)。隨機(jī)串同理nonce必須每次重新生成如果復(fù)用會(huì)被服務(wù)端的防重放機(jī)制攔下來。還有一種更隱蔽的情況服務(wù)端不僅校驗(yàn)時(shí)間窗口還校驗(yàn)時(shí)間戳的單調(diào)遞增也就是后一次請求的時(shí)間戳不能小于前一次。如果本地時(shí)間因?yàn)?NTP 同步往回跳了一下就會(huì)出現(xiàn)莫名其妙的失敗。穩(wěn)妥的做法是維護(hù)一個(gè)本地遞增計(jì)數(shù)器取max(當(dāng)前時(shí)間, 上次時(shí)間 1)作為實(shí)際使用的時(shí)間戳能規(guī)避絕大多數(shù)抖動(dòng)。4.2 字體映射緩存的失效判斷字體緩存失效的判斷不能只看時(shí)間得看內(nèi)容。我見過有人設(shè)置緩存 10 分鐘過期結(jié)果服務(wù)端是每 5 分鐘換一次字體中間 5 分鐘一直在用錯(cuò)誤的映射解析數(shù)據(jù)全錯(cuò)還找不到原因。更可靠的做法是每次請求響應(yīng)里檢查字體 URL 或者響應(yīng)頭里的文件哈希變了就重新拉。有些站點(diǎn)更狠字體文件路徑完全不變但內(nèi)容每次請求都不同靠 CDN 緩存控制頭來區(qū)分。這種情況就得在下載后立刻算一次 SHA1和上次的比對(duì)。多一次幾百 KB 文件的哈希計(jì)算代價(jià)可以接受換來的是映射絕對(duì)不會(huì)錯(cuò)位。失效情形判斷依據(jù)處理策略字體 URL 變化響應(yīng) HTML 里的font-face地址直接重新下載解析URL 不變但內(nèi)容變下載后計(jì)算文件 SHA1比對(duì)哈希不同則重建映射碼點(diǎn)集合變化cmap 的 key 集合視為全新字體全量匹配字形輪廓輕微擾動(dòng)特征相似度低于閾值用標(biāo)準(zhǔn)庫做模糊匹配兜底表格里最后一行是最容易被忽略的。有的站點(diǎn)不做整體重排只是在原有基礎(chǔ)上給每個(gè)字形加一點(diǎn)隨機(jī)偏移肉眼完全看不出區(qū)別但精確哈希會(huì)全部失效。這時(shí)候如果你的匹配邏輯是哈希相等才算命中就會(huì)全軍覆沒。所以特征匹配一定要留模糊空間閾值設(shè)得松一點(diǎn)寧可多匹配幾次也別直接判失敗。5. 工程化與邊界能跑和能長期跑是兩回事5.1 請求節(jié)奏與失敗重試的設(shè)計(jì)腳本能跑通第一版的時(shí)候人是最容易上頭的恨不得立刻把并發(fā)拉到 50 去刷全量數(shù)據(jù)。這么干的結(jié)果通常是被限流、被封 IP、或者觸發(fā)更嚴(yán)格的風(fēng)控然后前面的工作全白費(fèi)。正確的節(jié)奏是把并發(fā)壓到個(gè)位數(shù)請求之間加隨機(jī)間隔比如 800 到 2000 毫秒之間浮動(dòng)。這個(gè)數(shù)字不是拍腦袋是根據(jù)大多數(shù)站點(diǎn)默認(rèn)的限流策略估算的低于這個(gè)值觸發(fā)概率會(huì)明顯上升。重試策略也要講究。遇到 403、429 這類狀態(tài)碼不要立刻重試先退避等 5 秒、15 秒、60 秒指數(shù)增長最多重試三次。遇到簽名錯(cuò)誤類的業(yè)務(wù)返回碼別重試因?yàn)橹卦囈彩清e(cuò)的應(yīng)該重新走一遍簽名計(jì)算流程再發(fā)。遇到字體解析失敗也別重試請求重試的是字體下載和匹配環(huán)節(jié)。把不同錯(cuò)誤類型分開處理比無腦while(retry 3)靠譜得多。判斷是不是被限流了除了看狀態(tài)碼還可以看響應(yīng)時(shí)間。正常情況下 200 毫秒的接口突然變成 3 秒哪怕返回的仍是 200也說明服務(wù)端在給你降速這時(shí)候主動(dòng)停下來歇幾分鐘比硬剛更明智。5.2 把逆向結(jié)果封裝成可替換的模塊逆向代碼最大的問題是脆弱。對(duì)方前端一改版你摳出來的函數(shù)可能整個(gè)失效。所以從一開始就要把它當(dāng)成一個(gè)可替換的適配器來設(shè)計(jì)而不是散落在主流程里的幾十行腳本。具體做法是定義一個(gè)穩(wěn)定的接口比如signRequest(params) - headers內(nèi)部實(shí)現(xiàn)隨便怎么變外部調(diào)用方不感知。字體解析同理定義decodeText(text, fontBuffer) - plainText換了解析算法也不影響調(diào)用方。這樣改版的時(shí)候你只需要重寫適配器內(nèi)部主流程一行不用動(dòng)。配置項(xiàng)也要抽出來。鹽值、字段名、簽名算法、字體匹配閾值全部放到配置文件里別硬編碼在函數(shù)中間。我見過太多人把鹽值寫在代碼第 300 行改版之后找了半天才想起來在哪兒。集中管理之后改版排查的時(shí)間能省一大半。最后一條經(jīng)驗(yàn)是關(guān)于日志的。逆向類腳本一定要打詳細(xì)日志但要分級(jí)。請求級(jí)別的日志記錄 URL、耗時(shí)、狀態(tài)碼簽名級(jí)別的日志記錄入?yún)⒑统鰠⒌恼獎(jiǎng)e打完整值太長字體級(jí)別的日志記錄文件哈希和匹配成功率。出問題的時(shí)候看一眼日志就知道是哪一環(huán)崩的比重新斷點(diǎn)調(diào)試快十倍。日志文件記得輪轉(zhuǎn)別跑一天把磁盤寫滿。真正把這類項(xiàng)目做久了我才明白逆向能力只占三成剩下七成是工程穩(wěn)健性和對(duì)邊界的管理。代碼寫得再巧妙如果三天兩頭因?yàn)閷?duì)方改版就全線崩那這個(gè)項(xiàng)目就沒法交付。反過來拆得足夠清晰、切得足夠細(xì)、日志足夠全就算核心算法失效了也能在半小時(shí)內(nèi)定位并替換掉。這才是能長期跑下去的狀態(tài)。