簡介一份以Webpack補(bǔ)環(huán)境為核心的拼多多anti_content參數(shù)逆向?qū)W習(xí)資料適合具備JavaScript基礎(chǔ)、希望進(jìn)階逆向工程的前端開發(fā)者或安全學(xué)習(xí)者。資料針對(duì)拼多多web端接口中的anti_content簽名機(jī)制梳理了利用Webpack配置與JavaScript環(huán)境補(bǔ)丁繞過校驗(yàn)的完整思路。壓縮包共含2個(gè)文件——一個(gè)Python腳本與一個(gè)JavaScript文件體積僅約40KB方便快速查看與復(fù)用。Python腳本主要負(fù)責(zé)啟動(dòng)輔助流程或與調(diào)試環(huán)境對(duì)接JavaScript文件則集中體現(xiàn)了Webpack模塊加載、補(bǔ)環(huán)境注入和逆向調(diào)用等關(guān)鍵代碼。目前已有431人學(xué)習(xí)下載對(duì)于想弄懂此類平臺(tái)復(fù)雜參數(shù)生成邏輯的讀者這份資料能提供從環(huán)境模擬、模塊分析方法到Python/JS協(xié)作的實(shí)操參考幫助縮短自行摸索的周期并加深對(duì)補(bǔ)環(huán)境技術(shù)的理解。1. webpack 拼多多 anti-content 補(bǔ)環(huán)境這是 js 逆向?qū)W習(xí)最典型的一條線爬蟲工程師打開拼多多 Web 端在開發(fā)者工具里隨便點(diǎn)開一個(gè)接口大概率會(huì)在請(qǐng)求參數(shù)里看到anti-content這個(gè)字段。想順著字符串搜索找到加密函數(shù)卻發(fā)現(xiàn)代碼是 webpack 打包產(chǎn)物模塊 ID、__webpack_require__、自執(zhí)行函數(shù)層層嵌套根本無從下手。把代碼拖到 Node 里跑又立刻被window is not defined、document is not defined拍在臉上。這三件事——定位 webpack 模塊、補(bǔ)環(huán)境、生成 anti-content 簽名——恰好是 js 逆向入門繞不開的一條主線。下面這套流程按最小可行方式拆開怎么把簽名模塊從產(chǎn)物里摳出來怎么在 Node 里把瀏覽器環(huán)境補(bǔ)起來以及補(bǔ)環(huán)境代理為什么經(jīng)常失效、翻車之后怎么定位。2. 從 webpack 產(chǎn)物中定位 anti-content模塊結(jié)構(gòu)與入口查找Webpack 打包產(chǎn)物不像手寫代碼那樣按文件目錄排列。它把所有模塊塞進(jìn)一個(gè)數(shù)組或?qū)ο笤儆媒y(tǒng)一的加載函數(shù)按 ID 取用。如果不先理解這個(gè)骨架拿到手幾百 KB 的壓縮 JS 就是一團(tuán)亂麻。這一章的落點(diǎn)是在產(chǎn)物里準(zhǔn)確找到 anti-content 相關(guān)代碼并搭出一個(gè)能獨(dú)立運(yùn)行的最小框架。后面的補(bǔ)環(huán)境工作全都建立在這個(gè)最小框架之上。2.1 webpack 產(chǎn)物骨架模塊數(shù)組與__webpack_require__的內(nèi)存尋址webpack 在生產(chǎn)模式下打包產(chǎn)物比開發(fā)模式簡潔得多可讀性也差得多。常見結(jié)構(gòu)是每個(gè)源文件被編譯成一個(gè)“模塊工廠函數(shù)”存放在以模塊 ID 為 key 的對(duì)象里另外提供一個(gè)__webpack_require__用來按 ID 加載模塊。如果站點(diǎn)還開啟了代碼壓縮和模塊合并scope hoisting / concatenateModules許多小模塊會(huì)被內(nèi)聯(lián)進(jìn)一個(gè)大函數(shù)模塊邊界被打散字符串搜索時(shí)上下文會(huì)更碎。這是 webpack 打包優(yōu)化配置對(duì)逆向分析最直接的影響優(yōu)化開得越狠產(chǎn)物越“平”可搜索的特征越少。先看一個(gè)刪掉業(yè)務(wù)代碼后的骨架真實(shí)產(chǎn)物再復(fù)雜核心也就是這幾行// webpack 產(chǎn)物最小骨架示意 var modules { 0: function (module, exports, __webpack_require__) { var signer __webpack_require__(12); exports.build function (obj) { return signer.sign(obj); }; }, 12: function (module, exports, __webpack_require__) { exports.sign function (obj) { // 真實(shí)產(chǎn)物里這里是一大段壓縮代碼 return step1: (obj.timestamp || ); }; }, }; var cache {}; function __webpack_require__(id) { if (cache[id]) return cache[id].exports; var module (cache[id] { exports: {} }); modules[id].call(module, module, module.exports, __webpack_require__); return module.exports; } // 入口加載模塊 0 并調(diào)用 console.log(__webpack_require__(0).build({ timestamp: Date.now() }));這個(gè)骨架說明三件事。第一模塊 ID 不一定是遞增數(shù)字production 模式壓縮后可能是短字符串反查時(shí)不要默認(rèn)從 1 開始數(shù)。第二__webpack_require__做了模塊緩存同一個(gè)模塊被多處依賴時(shí)不會(huì)重復(fù)執(zhí)行工廠函數(shù)這是“環(huán)境只補(bǔ)一次”能夠成立的前提。第三模塊間依賴是運(yùn)行時(shí)通過 require 按 ID 查找而不是直接引用全局變量所以摳出單個(gè)模塊時(shí)必須把整個(gè) modules 對(duì)象和__webpack_require__一起搬走否則模塊內(nèi)部依賴會(huì)全部斷掉。還有一種常見變體異步加載 chunk。主入口里只有webpackJsonpCallback和 chunk 加載函數(shù)業(yè)務(wù)模塊在獨(dú)立文件里。這種產(chǎn)物里直接搜 anti-content 往往命中在子 chunk 文件里需要先確定主入口調(diào)用了哪個(gè) chunk ID再單獨(dú)分析對(duì)應(yīng)文件分析思路跟處理單文件產(chǎn)物完全一樣。2.2 用字符串反查定位從 anti-content 到加密函數(shù)拿到產(chǎn)物后第一件事不是通讀而是搜字符串。anti-content大概率出現(xiàn)在兩個(gè)位置一是作為對(duì)象 key 被拼進(jìn)請(qǐng)求體二是被壓縮工具改名成短變量后真實(shí) key 寫在某個(gè)字符串常量里。我習(xí)慣先搜帶引號(hào)的完整字符串減少誤命中。import re js open(pdd.js, r, encodingutf-8, errorsignore).read() for m in re.finditer([\]anti-content[\], js): start max(0, m.start() - 300) end min(len(js), m.end() 300) print( match at %d % m.start()) print(js[start:end])命中處的上下文里通常能看到類似anti-content: n[XX]的賦值。n[XX]就是簽名函數(shù)被壓縮后的調(diào)用位置。接下去反查XX這個(gè) key 是在哪個(gè)模塊里定義回到 modules 對(duì)象里在這個(gè) key 所在的模塊工廠函數(shù)字符串里繼續(xù)搜。如果壓縮工具把屬性名也全部短化比如n[a1]就搜a(bǔ)1在模塊工廠函數(shù)里出現(xiàn)的位置順著賦值語句往上找函數(shù)入口。這一階段容易誤入歧途的地方是直接復(fù)制整個(gè)產(chǎn)物到本地運(yùn)行然后在海量 DOM 操作報(bào)錯(cuò)里打轉(zhuǎn)。正確做法是只保留“模塊表 入口調(diào)用”把無關(guān)模塊刪掉用最小腳本逐步加載?？吹揭粋€(gè)報(bào)錯(cuò)解決一個(gè)比一次性挑戰(zhàn)整個(gè)產(chǎn)物要快得多。2.3 把目標(biāo)模塊摳出來最小可運(yùn)行腳本的搭建假設(shè)通過 2.2 的反查已經(jīng)確定簽名入口模塊 ID 為 12這一步就把模塊表按原樣搬進(jìn)本地文件再寫一個(gè)精簡版 require 讓它能被調(diào)用。// 最小運(yùn)行腳本只加載需要的模塊 const modules { /* 從 pdd.js 里復(fù)制整個(gè) modules 對(duì)象 */ }; const cache {}; function __webpack_require__(id) { if (cache[id]) return cache[id].exports; const module (cache[id] { exports: {} }); modules[id].call(module, module, module.exports, __webpack_require__); return module.exports; } // 假設(shè)簽名入口是模塊 12 const signer __webpack_require__(12); console.log(signer.sign({ timestamp: 1700000000000 }));運(yùn)行這段腳本常見的報(bào)錯(cuò)有兩種。一是xxx is not defined說明模塊表漏了依賴模塊回到 2.1 步驟把缺失 ID 的模塊補(bǔ)進(jìn)來。二是window is not defined或document is not defined說明加密模塊在加載階段就引用了瀏覽器全局對(duì)象此時(shí)正式進(jìn)入補(bǔ)環(huán)境流程。注意報(bào)錯(cuò)位置通常不在你調(diào)用的入口函數(shù)里而在模塊工廠函數(shù)頂部——webpack 打包時(shí)很多模塊會(huì)在初始化階段執(zhí)行var doc window.document這類語句因此補(bǔ)環(huán)境必須在模塊加載前完成否則每次 require 都會(huì)掛掉。3. 補(bǔ)環(huán)境的原理與實(shí)操在 Node 里把瀏覽器環(huán)境“演”出來補(bǔ)環(huán)境是 js 逆向?qū)W習(xí)里的分水嶺概念。外行以為要把 window、document、navigator 整套實(shí)現(xiàn)一遍內(nèi)行知道只需要讓加密代碼“演”得不報(bào)錯(cuò)并且補(bǔ)出來的屬性值和類型能被服務(wù)端認(rèn)可。這一章按“先原理、再實(shí)操”的順序把補(bǔ)環(huán)境從零到能用的過程寫清楚。3.1 補(bǔ)環(huán)境的運(yùn)行邏輯不是抄瀏覽器是演到不報(bào)錯(cuò)先理解報(bào)錯(cuò)為什么會(huì)發(fā)生。Node.js 本身不提供 window、document 這類瀏覽器 API加密代碼卻習(xí)慣性地直接訪問它們。補(bǔ)環(huán)境就是在 Node 的全局對(duì)象上“種”出這些 API 的替身讓加密代碼在替身上正常走完邏輯。補(bǔ)環(huán)境的范圍怎么定我的習(xí)慣是三步先補(bǔ)最外層全局對(duì)象window、document、navigator、location讓腳本能跑起來再根據(jù)下一次報(bào)錯(cuò)補(bǔ)齊細(xì)節(jié)最后做一次瀏覽器環(huán)境對(duì)比把會(huì)參與簽名計(jì)算的屬性值校準(zhǔn)到和真實(shí)瀏覽器一致。這里有一條重要原則能少補(bǔ)就少補(bǔ)。補(bǔ)得越多偽造痕跡越多越容易被服務(wù)端從環(huán)境指紋上識(shí)別出腳本痕跡。常見做法是抓一個(gè)瀏覽器真實(shí)環(huán)境導(dǎo)出一份 JSON 配置來補(bǔ)而不是憑記憶手寫幾百行模仿代碼。反正服務(wù)端校驗(yàn)的是“像不像瀏覽器”不是“功能全不全”。3.2 第一輪補(bǔ)環(huán)境從報(bào)錯(cuò)驅(qū)動(dòng)把 window、document、navigator 補(bǔ)出來給出一個(gè)最基礎(chǔ)的骨架能覆蓋大多數(shù)模塊加載階段的全局引用。代碼在每個(gè)屬性后面標(biāo)注了為什么需要這個(gè)值避免新手照抄一堆用不上的屬性// 補(bǔ)環(huán)境骨架按需添加不要照抄一堆沒用的屬性 global.window global; global.navigator { userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, platform: Win32, language: zh-CN, languages: [zh-CN, zh], webdriver: false, }; global.document { cookie: , referrer: , addEventListener: function () {}, removeEventListener: function () {}, createElement: function (tag) { // 節(jié)點(diǎn)類型基礎(chǔ)屬性要帶上指紋計(jì)算常從節(jié)點(diǎn)上取值 return { nodeName: String(tag).toUpperCase(), style: {} }; }, documentElement: { style: {} }, body: { appendChild: function () {} }, }; global.location { protocol: https:, hostname: mobile.yangkeduo.com, href: https://mobile.yangkeduo.com/, pathname: /, };這段代碼里有三個(gè)參數(shù)需要重點(diǎn)校準(zhǔn)。navigator.userAgent必須和目標(biāo)瀏覽器保持一致它幾乎必然參與 UA 指紋計(jì)算填錯(cuò)直接導(dǎo)致簽名不一致。document.createElement返回的對(duì)象要帶nodeName、style這類基礎(chǔ)屬性因?yàn)榧用艽a可能從節(jié)點(diǎn)上取這些值拼進(jìn)指紋字符串。location.hostname要填實(shí)際請(qǐng)求的域名簽名校驗(yàn)偶爾會(huì)帶上 referrer 或 origin域名寫錯(cuò)也會(huì)被服務(wù)端識(shí)別出來。第一輪補(bǔ)完報(bào)錯(cuò)會(huì)向前推進(jìn)變成xxx is not a function或xxx is undefined這類具體問題。每修一處就回到報(bào)錯(cuò)現(xiàn)場(chǎng)看它到底要什么值不要提前補(bǔ)后面才可能用到的東西。3.3 原型鏈補(bǔ)環(huán)境從“補(bǔ)實(shí)例”升級(jí)到“補(bǔ)類”有些模塊不直接訪問document而是在代碼深處new Image()或new HTMLImageElement()。如果只補(bǔ)了空 documentnew Image()會(huì)直接拋Image is not defined。這類場(chǎng)景就要從“給實(shí)例補(bǔ)屬性”升級(jí)到“給類補(bǔ)原型”。// 原型鏈補(bǔ)環(huán)境先定義類再把類掛到全局 function HTMLImageElement() {} Object.defineProperty(HTMLImageElement.prototype, nodeName, { value: IMG, writable: true, configurable: true, }); HTMLImageElement.prototype.addEventListener function () {}; HTMLImageElement.prototype.setAttribute function (k, v) {}; global.HTMLImageElement HTMLImageElement; global.Image function (w, h) { const img new HTMLImageElement(); img.width w || 0; img.height h || 0; return img; };這里用Object.defineProperty而不是直接賦值HTMLImageElement.prototype.nodeName IMG原因是直接賦值會(huì)讓 nodeName 變成可枚舉屬性。真實(shí)瀏覽器里 nodeName 是原型上的不可枚舉屬性檢測(cè)代碼用Object.keys遍歷原型鏈時(shí)多出來的可枚舉項(xiàng)會(huì)直接暴露環(huán)境被改過。原型鏈補(bǔ)環(huán)境的核心不是“屬性多不多”而是“像不像”。另一個(gè)經(jīng)驗(yàn)補(bǔ)原型鏈時(shí)盡量往專用類上補(bǔ)比如只給HTMLImageElement補(bǔ)屬性不要順手在Object.prototype上掛一堆自定義字段。后者是排查災(zāi)難因?yàn)樗袑?duì)象都會(huì)被污染服務(wù)端一旦檢測(cè)某個(gè)對(duì)象的自有屬性數(shù)量整個(gè)環(huán)境都會(huì)翻車。3.4 用 Proxy 接管屬性讀取補(bǔ)環(huán)境代理失效的原因補(bǔ)環(huán)境補(bǔ)到最后總會(huì)有漏網(wǎng)屬性此時(shí)很多方案會(huì)寫一個(gè) Proxy把全局對(duì)象的屬性讀取統(tǒng)一接管沒命中的屬性返回一個(gè)函數(shù)或空對(duì)象避免代碼因取不到值直接拋錯(cuò)。// 用 Proxy 兜底而非完全替代顯式定義 const handler { get(target, prop, receiver) { if (prop in target) return Reflect.get(target, prop, receiver); if (typeof prop string) { const fallback function () {}; fallback.toString () function () { [native code] }; fallback.valueOf () undefined; return fallback; } return undefined; }, has(target, prop) { return true; // 讓prop in window同樣返回 true }, getOwnPropertyDescriptor(target, prop) { if (prop in target) { return Object.getOwnPropertyDescriptor(target, prop); } return { configurable: true, enumerable: false, writable: true, value: undefined, }; }, }; global.window new Proxy(globalThis, handler);這段代碼看起來能把所有兜底邏輯處理好但實(shí)際場(chǎng)景里“補(bǔ)環(huán)境代理失效”往往不是 get 沒生效而是另外三個(gè)原因。第一加密代碼判斷屬性是否存在時(shí)可能用prop in window這個(gè)操作走的是 has 陷阱而不是 get 陷阱漏掉 has 就會(huì)讓所有屬性都判定為不存在。第二Object.getOwnPropertyDescriptor(window, prop)直接拿屬性描述符既不經(jīng)過 get 也不經(jīng)過 has需要單獨(dú)實(shí)現(xiàn)。第三也是最隱蔽的一點(diǎn)兜底函數(shù)被當(dāng)作對(duì)象繼續(xù)訪問其上的方法時(shí)函數(shù)本身沒有這些方法調(diào)用鏈還是會(huì)斷。比如代碼里window.someApi.init()兜底返回的函數(shù)沒有init屬性執(zhí)行到window.someApi.init()依然報(bào)錯(cuò)。所以 Proxy 只適合兜底冷門屬性主力仍要靠顯式定義關(guān)鍵對(duì)象二者結(jié)合才能少踩坑。4. 補(bǔ)環(huán)境避坑代理失效、prototype 檢測(cè)與 source map 報(bào)錯(cuò)處理補(bǔ)環(huán)境方案能不能過最終取決于服務(wù)端認(rèn)不認(rèn)。這一章整理四個(gè)高頻翻車點(diǎn)每條按“現(xiàn)象、原因、解決”展開都是實(shí)際排查中反復(fù)遇到的場(chǎng)景。照著這個(gè)順序檢查能少走不少彎路。4.1 補(bǔ)環(huán)境代理失效get 返回了值代碼卻走了 undefined 分支現(xiàn)象日志里 get 陷阱被頻繁觸發(fā)說明代理在工作但簽名結(jié)果和瀏覽器里對(duì)不上甚至明顯走了“不支持”邏輯分支。原因多數(shù)代理只實(shí)現(xiàn)了 get漏掉 has 和 getOwnPropertyDescriptor。加密代碼判斷某個(gè) API 是否存在有三種常見寫法typeof window.xxx ! undefined、xxx in window、Object.getOwnPropertyDescriptor(window, xxx)。第一種會(huì)被 get 陷阱攔到后兩種完全繞過 get。尤其in表達(dá)式在 JS 里非常常見漏掉 has 陷阱等于讓所有屬性都是“不存在”代碼自然走進(jìn)錯(cuò)誤分支。解決把上一節(jié)給出的 handler 補(bǔ)全get、has、getOwnPropertyDescriptor 三個(gè)陷阱一起實(shí)現(xiàn)。接著做驗(yàn)證寫一段十行測(cè)試腳本分別用typeof、in、getOwnPropertyDescriptor訪問關(guān)鍵屬性三個(gè)結(jié)果必須和瀏覽器里一致否則繼續(xù)修。4.2 could not read source map for webpack://meai.web/node_modules/ 報(bào)錯(cuò)怎么處理現(xiàn)象把線上的 webpack JS 拉下來放到本地或分析工具里時(shí)控制臺(tái)拋出could not read source map for webpack://meai.web/node_modules/xxx.js這類報(bào)錯(cuò)。報(bào)錯(cuò)指向 node_modules 里的模塊路徑看起來像缺依賴容易誤導(dǎo)新手去補(bǔ) node_modules。原因webpack 產(chǎn)物末尾通常帶著//# sourceMappingURLxxx.js.map注釋生產(chǎn)環(huán)境不會(huì)把 map 文件隨包發(fā)布工具按注釋去找當(dāng)然找不到。這個(gè)報(bào)錯(cuò)跟簽名邏輯無關(guān)也不影響 JS 執(zhí)行純粹是注釋指向了一個(gè)不存在的文件。線上包里拿不到 map 文件想通過 source map 還原變量名的路是堵死的老老實(shí)實(shí)用字符串搜索和斷點(diǎn)定位更實(shí)際。解決本地分析時(shí)先把 sourceMappingURL 注釋整行刪掉或者用編輯器插件忽略 map 文件。不要花時(shí)間去找 map。這個(gè)經(jīng)驗(yàn)對(duì)任何 webpack 打包的站點(diǎn)產(chǎn)品都適用。4.3 原型鏈補(bǔ)環(huán)境被檢測(cè)toString 的破綻現(xiàn)象補(bǔ)完環(huán)境本地運(yùn)行一切正常anti-content 能算出來但提交到真實(shí)請(qǐng)求里服務(wù)端返回風(fēng)控提示。對(duì)比瀏覽器真實(shí)值后發(fā)現(xiàn)某些對(duì)象的方法實(shí)現(xiàn)特征異常。原因檢測(cè)腳本常執(zhí)行Function.prototype.toString.call(obj)來判斷某個(gè)方法是不是原生實(shí)現(xiàn)。補(bǔ)進(jìn)去的document.createElement、window.addEventListener是普通 JS 函數(shù)toString會(huì)輸出完整的函數(shù)源碼而瀏覽器原生方法輸出的是function () { [native code] }。一旦檢測(cè)發(fā)現(xiàn)字符串不是以[native code]結(jié)尾就判定環(huán)境被改過。解決所有補(bǔ)進(jìn)去的方法統(tǒng)一改寫 toString讓它返回function () { [native code] }并且要在函數(shù)定義后立即改寫const fakeAddListener function () {}; fakeAddListener.toString () function () { [native code] };另外能少重寫就少重寫。比如某個(gè) API 在簽名流程中根本不參與計(jì)算寧可不補(bǔ)也不給它一個(gè)假的實(shí)現(xiàn)因?yàn)槊總€(gè)假實(shí)現(xiàn)都多一個(gè)被檢測(cè)的破綻。4.4 navigator 和 UA補(bǔ)了但和服務(wù)端不匹配現(xiàn)象navigator.userAgent填了最新版 Chrome 的 UA其它常見屬性也都有但簽名一直不過。把瀏覽器里的 navigator 整個(gè)導(dǎo)出再補(bǔ)進(jìn)去結(jié)果還是一樣。原因不參與指紋的不只是 userAgent。screen.width、screen.height、devicePixelRatio、timezoneOffset、plugins、webdriver都在參與環(huán)境指紋計(jì)算。UA 對(duì)上了但其它值還是 Node 默認(rèn)狀態(tài)指紋就不一致。比如真實(shí)瀏覽器里navigator.webdriver是 undefined補(bǔ)環(huán)境腳本如果隨手給了個(gè) false檢測(cè)方一比對(duì)就發(fā)現(xiàn)問題。解決在真實(shí)瀏覽器控制臺(tái)執(zhí)行JSON.stringify(Object.entries(navigator))拿到完整鍵值對(duì)再按這份清單逐項(xiàng)補(bǔ)。補(bǔ)完后寫一個(gè)斷言腳本把 Node 里的 navigator 和運(yùn)行Object.entries(navigator)的結(jié)果做 diff改到除動(dòng)態(tài)字段外全量一致。這一步是補(bǔ)環(huán)境參數(shù)調(diào)試?yán)镒罨〞r(shí)間的部分也是能不能讓服務(wù)端認(rèn)你的分水嶺。5. 驗(yàn)證與邊界怎么確認(rèn)補(bǔ)出來的 anti-content 真的能用很多人在補(bǔ)環(huán)境上花了大量精力卻忽略了一個(gè)關(guān)鍵動(dòng)作驗(yàn)證。補(bǔ)環(huán)境跑通只是第一步跑出來的簽名和瀏覽器真實(shí)請(qǐng)求里的是否一致需要專門設(shè)計(jì)對(duì)比方法。這一章從驗(yàn)證方法、動(dòng)態(tài)因子識(shí)別、瀏覽器對(duì)比三個(gè)角度把這套流程的最后一段補(bǔ)完。5.1 雙端對(duì)比讓瀏覽器和 Node 各算一次逐字段對(duì)齊從瀏覽器抓一個(gè)真實(shí)請(qǐng)求把請(qǐng)求體里的動(dòng)態(tài)字段抽出來在 Node 里用同一份輸入去生成 anti-content然后對(duì)比。這是最直接的驗(yàn)證方式。// 用一份真實(shí)請(qǐng)求體驗(yàn)證補(bǔ)環(huán)境結(jié)果 const fs require(fs); const { getAntiContent } require(./pdd_env.js); // capture.json 來自瀏覽器復(fù)制{ url, data, anti-content } const capture JSON.parse(fs.readFileSync(capture.json, utf-8)); const params Object.assign({}, capture.data); const output getAntiContent(params); console.log(node :, output); console.log(browser:, capture[anti-content]); console.log(length :, output.length, capture[anti-content].length); console.log(match :, output capture[anti-content]);對(duì)比時(shí)看三個(gè)信息。長度不同大概率是環(huán)境指紋輸出不一致優(yōu)先回第 4 章排查 navigator 等屬性。前綴不同問題多半出在簽名參與字段的取值方式上。前綴一致但后段不一致重點(diǎn)檢查時(shí)間戳和隨機(jī)數(shù)是否同步更新。注意 anti-content 里通常含時(shí)間戳或隨機(jī)數(shù)直接要求全等不現(xiàn)實(shí)可以抓兩個(gè)間隔極短的請(qǐng)求觀察動(dòng)態(tài)部分的變化規(guī)律再做替換驗(yàn)證。5.2 動(dòng)態(tài)因子識(shí)別法哪些字段參與簽名哪些不參與如果雙端對(duì)比每次都不一樣先別急著懷疑環(huán)境用“單字段替換法”確認(rèn)哪些字段真正參與簽名。抓兩個(gè)真實(shí)請(qǐng)求 B1 和 B2把時(shí)間戳等可能變化的字段歸零逐個(gè)替換觀察 anti-content 是否變化。下面是一份示意記錄表操作anti-content 變化結(jié)論修改 timestamp變化參與簽名修改 pageSn變化參與簽名修改 pageSize不變不參與簽名修改擴(kuò)展字段 ext_a變化參與簽名識(shí)別過程中有兩個(gè)邊界坑要注意。第一時(shí)間戳精度有些實(shí)現(xiàn)取秒有些取毫秒比較時(shí)要把兩包的 timestamp 歸一化再測(cè)否則結(jié)論會(huì)誤判。第二部分字段不參與簽名計(jì)算但服務(wù)端會(huì)單獨(dú)校驗(yàn)改動(dòng)它們同樣會(huì)導(dǎo)致請(qǐng)求失敗。因此“簽名參與”和“服務(wù)端校驗(yàn)參與”是兩個(gè)維度不能混為一談。排錯(cuò)時(shí)先確認(rèn)哪一層在報(bào)錯(cuò)再?zèng)Q定改哪里的代碼。5.3 把瀏覽器當(dāng)黑匣子校準(zhǔn)補(bǔ)環(huán)境參數(shù)的三個(gè)技巧第一個(gè)技巧是從瀏覽器控制臺(tái)導(dǎo)出現(xiàn)有屬性而不是靠記憶補(bǔ)。navigator、screen、location、performance這些對(duì)象每一組都執(zhí)行一次Object.entries()導(dǎo)出再與 Node 里的對(duì)應(yīng)對(duì)象做按字段比對(duì)。補(bǔ)環(huán)境腳本與真實(shí)環(huán)境的差異會(huì)一目了然不需要反復(fù)試錯(cuò)。第二個(gè)技巧是使用“復(fù)制為 fetch”保留完整請(qǐng)求鏈路。瀏覽器里點(diǎn)一下頁面可能會(huì)同時(shí)觸發(fā)多個(gè)請(qǐng)求復(fù)制完整請(qǐng)求能幫你分辨當(dāng)前 anti-content 是哪個(gè)頁面動(dòng)作生成的。單獨(dú)復(fù)制一個(gè)請(qǐng)求體容易漏掉請(qǐng)求頭或 URL 參數(shù)導(dǎo)致補(bǔ)出來的環(huán)境在重放時(shí)整體錯(cuò)位。第三個(gè)技巧是動(dòng)態(tài)字段不要寫死。隨機(jī)數(shù)的長度、字符集、是否帶大寫都要以抓包觀察為準(zhǔn)。補(bǔ)環(huán)境腳本里生成隨機(jī)數(shù)時(shí)改成與抓包格式一致而不是隨便用Math.random().toString(36)湊數(shù)。格式對(duì)了簽名后續(xù)部分才能穩(wěn)定對(duì)齊。6. 用 vm 模塊給補(bǔ)環(huán)境加隔離避免環(huán)境串味與多開臟數(shù)據(jù)補(bǔ)環(huán)境代碼一直掛在 global 上短期跑通沒問題一旦并發(fā)請(qǐng)求或長期運(yùn)行就會(huì)栽跟頭。兩個(gè)任務(wù)同時(shí)執(zhí)行時(shí)A 任務(wù)改寫了 navigator.languageB 任務(wù)又改了一部分兩邊簽名全部亂套。我的做法是用 Node 的 vm 模塊把補(bǔ)環(huán)境代碼和簽名代碼一起丟進(jìn)沙箱每次調(diào)用創(chuàng)建全新 context跑完即棄。// 用 vm 隔離補(bǔ)環(huán)境避免全局污染 const vm require(vm); const fs require(fs); const envCode fs.readFileSync(./env.js, utf-8); // 補(bǔ)環(huán)境代碼 const signCode fs.readFileSync(./sign.js, utf-8); // 從 webpack 摳出的簽名模塊 function makeAntiContent(params) { const sandbox { params: { ...params }, result: }; vm.createContext(sandbox); vm.runInContext(envCode signCode, sandbox, { filename: sandbox.js }); return sandbox.result; } console.log(makeAntiContent({ timestamp: Date.now() }));這段代碼的核心是sandbox.params用了展開復(fù)制避免簽名代碼在沙箱里修改外部對(duì)象后下一輪調(diào)用還帶著上一輪的痕跡。每次 makeAntiContent 都從干凈狀態(tài)開始不存在全局串味問題。代價(jià)是createContext和runInContext有固定開銷高頻調(diào)用時(shí)可以用一個(gè) context 池預(yù)創(chuàng)建幾個(gè)沙箱輪流復(fù)用。我早期做 webpack 逆向時(shí)圖省事把所有補(bǔ)環(huán)境代碼掛在 global 下結(jié)果凌晨兩點(diǎn)排查一個(gè)“同一函數(shù)同一入?yún)?、兩次輸出不同”的玄學(xué)問題最后發(fā)現(xiàn)是上一個(gè)任務(wù)改了 navigator.language。從那以后我再不把補(bǔ)環(huán)境放進(jìn)共享全局作用域每次請(qǐng)求都用 vm 重新隔離。逆向這條路留退路比炫技重要。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取