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