简介：围绕某东webpack方式h5st逆向的实战代码包，面向具备一定前端与爬虫基础、希望理解h5st参数生成与加密链路的开发者，也可作为安全测试与逆向分析的学习案例。资源共2个文件，包含1个Python脚本和1个JavaScript脚本，压缩包约159KB；前者便于串联请求与结果验证，后者侧重前端逻辑复现与webpack模块定位，两者可配合对照阅读。已有860人学习。读者可借助完整代码分析h5st模板的加载方式、模块组织与关键参数生成过程，梳理从页面调试、网络请求分析到Python侧复现的排错思路，并理解webpack打包代码的阅读与拆解方法，对定位签名参数、还原调用链和验证请求结果有参考价值。内容强调技术研究与合规边界，适合用于学习逆向工程基本方法、提升前端代码分析能力，不建议用于非法用途。
1. 为什么这类 webpack 签名参数值得单独拆一遍
前阵子帮朋友看一个抓取任务，页面数据在浏览器里一切正常，把请求原样搬到 Node 里跑，服务端回的内容却是空的——问题就出在请求头里那个几十位长的签名字段。这个项目是围绕某商城 H5 页面做的签名参数逆向分析实践，用 webpack 打包产物作为切入点，把混淆过的 JS 还原成可以在本地调用的函数。它适合两类人：一类是把爬虫当正经工程做、迟早要面对参数签名问题的开发者；另一类是前端同学，想搞清楚自己每天打包出来的 bundle 到底能被人看到什么。这篇笔记按「产物长什么样 → 怎么定位 → 怎么补环境跑起来 → 怎么防止下次改版翻车」的顺序，把这套流程完整走一遍。所有代码只针对学习场景和自有系统的调试分析。
2. 打包产物解剖：从__webpack_require__里找到签名入口
打开页面加载的那个几百 KB 的 JS 文件，第一反应通常是懵的：一层套一层的立即执行函数，变量名全是a、b、c，字符串散落成数组。但只要确认它是 webpack 打的，结构其实是固定的，认出来之后剩下的就是体力活。
2.1 runtime 那几十行到底在干什么
webpack 打包后的文件头部通常是一小段「运行时」，它的作用是定义模块注册和加载机制。压缩之后长这样：
// webpack 5 生产环境 runtime 的典型形态（已简化） (() => { "use strict"; var e = {}; // 模块缓存，key 是模块 id function r(t) { // 这就是 __webpack_require__ var n = e[t]; if (void 0 !== n) return n.exports; var o = e[t] = { exports: {} }; // 先占位，防止循环依赖死递归 return modules[t].call(o.exports, o, o.exports, r), o.exports; } r.m = modules; // 模块定义表，通常是数组或对象 r.d = (t, n) => { // 定义 getter 形式的导出 for (var o in n) r.o(n, o) && !r.o(t, o) && Object.defineProperty(t, o, { enumerable: !0, get: n[o] }); }; r.o = (t, n) => Object.prototype.hasOwnProperty.call(t, n); r(r.s = 0); // 从入口模块 id 开始执行 })();这段代码里只有三个东西需要记住。r就是__webpack_require__，负责按 id 取模块；e是缓存对象，同一个模块只会被执行一次；r.m是模块定义表，里面每一项都是一个函数，参数是(module, exports, require)，跟 Node 的 CommonJS 包装函数一个思路。参数t是模块 id，压缩后一般是数字，未压缩可能是"./src/utils/sign.js"这样的路径。
认结构的意义在于：你不需要读懂全部业务代码，只要拿到r这个引用，就能像调库一样把任意模块的导出取出来。这是后面所有工作的地基。
2.2 模块 id 与依赖链：顺着 require 往上爬
知道了r的作用，下一步是找到「哪个模块负责算签名」。压缩后的文件里搜不到函数名，但模块之间的调用关系还在。常见的做法是从某个已知的入口往下追，比如页面初始化时调用的主模块r(r.s = 0)，或者从 XHR 断点拿到调用栈，看栈顶函数属于哪个模块。
模块 id 有两种常见形态。数字 id 下，模块表是个数组，r.m[12]就是第 12 个模块；字符串 id 下，模块表是对象，键名通常保留了一点路径信息，像"./src/request/index.js"。后者对分析友好得多，很多团队为了排查线上问题会开启optimization.moduleIds: 'named'，这算是个意外之喜。
依赖链的读法是：模块 A 的包装函数体里出现r(12)，说明 A 依赖 12 号模块。你可以写个小脚本扫描整个文件，用正则抓出所有r(\d+)或者r("...")的调用，建一张依赖图，然后看哪几个模块被 HTTP 请求模块依赖、同时又依赖了加密相关的模块。我一般会先把「被请求模块依赖的模块」列出来，范围一下就能缩到个位数。
提示：不要指望一次就定位准。签名逻辑经常被拆成三四个模块——参数排序一个、时间戳一个、加密一个、拼装一个，追的时候要有耐心。
2.3 用 hook 抓模块导出，比肉眼找快十倍
肉眼读代码容易漏，更省事的办法是在运行时劫持r，把所有模块的导出记录下来。因为r在 runtime 闭包里，外部拿不到，所以要在文件加载前动手：把 JS 文件下载到本地，在 runtime 末尾（r(r.s = 0)之前）插入一段代码，把r挂到全局上。
// 插入到 runtime 中 r(r.s=0) 之前，把 require 暴露到全局 window.__wp_require__ = r; // 再包一层，记录每个模块的导出情况 const rawRequire = window.__wp_require__; const cacheLog = new Map(); window.__wp_require__ = function (id) { const exported = rawRequire(id); if (!cacheLog.has(id)) { cacheLog.set(id, exported); // 只打有函数导出的模块，减少噪音 const keys = Object.keys(exported || {}); const fnKeys = keys.filter(k => typeof exported[k] === "function"); if (fnKeys.length) { console.log(`[module ${id}]`, fnKeys.join(", ")); } } return exported; };这段代码做了两件事：先把原始r存到全局变量，再用一个包装函数替换它。包装函数调用原始r拿到导出结果，首次遇到某个模块时打印它的函数型属性名——Object.keys会把r.d定义的 getter 也列出来，所以能直接看到sign、encrypt、getToken这类语义化的名字。参数id就是模块 id，cacheLog用来去重，避免同一个模块刷屏。
实际跑起来之后，控制台会哗哗输出一串模块名。这时候再去触发一次页面上的数据请求，看最后几行输出，大概率就能锁定目标模块。拿到模块 id 之后，window.__wp_require__(目标id)就能直接把签名函数取出来调用，不需要再管它内部怎么组织的。
注意：hook 要放在业务代码执行之前。如果你的页面用了懒加载分包，还要考虑在 chunk 加载时重复这个动作，否则会漏掉后加载的模块。
3. 定位与还原：关键字、AST 与断点三条路
拿到模块只是开始，里面的代码往往还被字符串数组、控制流平坦化包了几层。这一步的目标是把「人能读的代码」还原出来，方便确认输入输出格式。
3.1 关键字定位法与 XHR 断点
最快的路子是搜关键字。签名参数最终要拼进请求头或 URL，所以搜请求头的字段名、搜setRequestHeader、搜sign、搜时间戳格式化函数的名字，都能命中。压缩代码里字符串常常被抽到数组里，直接搜可能搜不到明文，这时候改搜 Unicode 转义或者数组下标也行，但更靠谱的还是断点。
XHR 断点的操作是：开发者工具 Source 面板里勾上XHR/fetch Breakpoints，填上请求 URL 的一个片段，页面发请求时就会停在send那一行。然后看 Call Stack，从send往上翻两三层，一般就能看到签名函数被调用的位置。如果栈里全是压缩后的短名字，点开每一层看它引用了哪些模块 id，再回模块表里对，就能定位。
我习惯两条路一起走：先搜关键字缩小范围，再用断点确认。关键字负责「猜」，断点负责「验」，单靠哪一条都容易走偏。
3.2 字符串数组还原：一个能直接抄的 babel 脚本
webpack 本身不会做字符串混淆，但很多项目会叠加一层javascript-obfuscator之类的工具，把所有字符串抽到一个大数组里，通过一个偏移函数取值：
// 混淆后的典型形态 var _0x1a2b = ["sign", "timestamp", "abcdef", "getTime"]; function _0x3c4d(i) { i = i - 0x0; // 偏移量，混淆器随机生成 return _0x1a2b[i]; } // 业务代码里变成 _0x3c4d(0x0) + _0x3c4d(0x1)还原思路是：找到那个数组和取值函数，用 Babel 遍历 AST，把所有_0x3c4d(数字)形式的调用替换成字符串字面量。脚本大概长这样：
// deobfuscate.js —— 基于 @babel/parser 和 @babel/traverse const fs = require("fs"); const parser = require("@babel/parser"); const traverse = require("@babel/traverse").default; const generate = require("@babel/generator").default; const code = fs.readFileSync("./bundle.js", "utf-8"); const ast = parser.parse(code, { sourceType: "script" }); // 第一遍：收集字符串数组和取值函数名 const stringArrays = new Map(); let decoderName = null; traverse(ast, { VariableDeclarator(path) { const { id, init } = path.node; // 匹配 var _0x1a2b = ["...", "..."]; if ( init && init.type === "ArrayExpression" && init.elements.length > 10 && init.elements.every(e => e.type === "StringLiteral") ) { stringArrays.set(id.name, init.elements.map(e => e.value)); } }, FunctionDeclaration(path) { const name = path.node.id && path.node.id.name; const body = path.node.body.body; // 匹配 return _0x1a2b[i - 0x0] 这种单语句返回 if ( name && body.length === 1 && body[0].type === "ReturnStatement" && body[0].argument.type === "MemberExpression" ) { decoderName = name; } } }); // 第二遍：把解码函数调用替换成字面量 if (decoderName && stringArrays.size) { const arr = [...stringArrays.values()][0]; traverse(ast, { CallExpression(path) { if (path.node.callee.name !== decoderName) return; const arg = path.node.arguments[0]; if (arg.type !== "NumericLiteral") return; const value = arr[arg.value]; // 偏移量需要按实际情况修正 if (typeof value === "string") { path.replaceWith({ type: "StringLiteral", value }); } } }); } fs.writeFileSync("./bundle.decoded.js", generate(ast).code);脚本分两遍遍历：第一遍扫变量声明收集字符串数组，同时找「函数体只有一条 return 语句」的解码函数；第二遍把所有对解码函数的调用替换成对应的字符串字面量。参数上，sourceType: "script"是因为打包产物是普通脚本，不是 ES module；arr[arg.value]里的下标需要根据实际的偏移表达式调整，如果原代码是i - 0x10，就要改成arr[arg.value - 16]。
跑完之后代码可读性会明显上一个台阶，至少函数名和字段名都能看见了。控制流平坦化那层更麻烦，常见做法是用 Babel 把switch-case的分发逻辑展开成顺序语句，但这一块每个混淆器生成的结构都不一样，没有通用脚本，只能看情况手写规则。
3.3 控制流平坦化：先跑通再还原
面对平坦化的代码，我的建议是别急着还原。平坦化的目的是让你读不懂，但不影响执行——只要环境补对了，这段代码在 Node 里一样能跑。所以顺序应该是：先让它跑起来，验证输入输出正确；如果需要长期维护，再回头做 AST 还原。
判断要不要还原的标准很实际：如果签名逻辑只有百来行，还原后维护成本低于每次改版重新分析的成本，那就值得做；如果代码量上千行、还依赖大量浏览器 API，那不如直接保留原始 bundle，用补环境的方式调用，改版时只重新定位入口即可。
4. 补环境：让签名函数在 Node 里跑起来
把 bundle 拿到 Node 里执行，第一件事通常是报错：window is not defined、document is not defined、navigator is not defined。签名函数里多多少少会读一些浏览器环境信息，这一步要做的事就是把这些空补上。
4.1 最小环境清单与执行顺序
先给一个最小可用的骨架，把常见的全局对象挂上去：
// env.js —— 在 require bundle 之前执行 const vm = require("vm"); const fs = require("fs"); // 1. 造一个沙箱上下文 const sandbox = { console, setTimeout, setInterval, clearTimeout, Math, Date, JSON, parseInt, parseFloat, encodeURIComponent, decodeURIComponent, atob: s => Buffer.from(s, "base64").toString("binary"), btoa: s => Buffer.from(s, "binary").toString("base64"), }; // 2. 浏览器对象 sandbox.window = sandbox; sandbox.self = sandbox; sandbox.globalThis = sandbox; sandbox.navigator = { userAgent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", platform: "Win32", language: "zh-CN", languages: ["zh-CN", "zh"], hardwareConcurrency: 8, }; sandbox.location = { href: "https://example.com/list", protocol: "https:", host: "example.com", hostname: "example.com", pathname: "/list", search: "", }; sandbox.document = { cookie: "", referrer: "https://example.com/", createElement: () => ({ getContext: () => null, style: {} }), documentElement: { style: {} }, }; sandbox.screen = { width: 1920, height: 1080, availWidth: 1920, availHeight: 1040 }; sandbox.localStorage = { getItem: () => null, setItem: () => {}, removeItem: () => {} }; sandbox.sessionStorage = sandbox.localStorage; // 3. 执行 bundle const code = fs.readFileSync("./bundle.js", "utf-8"); const context = vm.createContext(sandbox); vm.runInContext(code, context); // 4. 从上下文里取签名函数 const sign = context.window.__sign_entry__; console.log(sign({ a: 1, b: 2 }));这段代码的重点在顺序：所有全局对象必须在runInContext之前挂到sandbox上，因为 bundle 顶层的立即执行函数一进来就会读环境；sandbox.window = sandbox是为了让window.xxx和直接xxx指向同一个对象，很多代码两种写法混用；globalThis也要指过去，否则用globalThis判断运行时的库会走错分支。
参数说明：vm.createContext创建的上下文与主进程隔离，bundle 里的var声明不会污染 Node 全局；atob/btoa在 Node 16 之后虽然内置了，但行为细节和浏览器有差异，手动包一层 Buffer 更可控。真实场景里navigator.userAgent不能随便填，很多签名会把 UA 参与计算，必须和服务端校验时用的一致。
4.2 用 Proxy 拦截，把没补的变量揪出来
手写环境最常见的失败是「漏了一个变量，跑到某一行才报错」。用 Proxy 包一层window，能在访问未定义属性时立即报警，比等运行时报错快得多：
// strict-env.js —— 用 Proxy 拦截未定义属性访问 const realWindow = sandbox.window; const handler = { get(target, prop) { // 内置符号和已知属性直接放行 if (typeof prop === "symbol") return target[prop]; if (prop in target) return target[prop]; // 未定义属性：打印调用栈，方便定位是哪一行读的 console.warn(`[env miss] window.${String(prop)}`); console.trace(); return undefined; }, set(target, prop, value) { target[prop] = value; return true; } }; sandbox.window = new Proxy(realWindow, handler); sandbox.self = sandbox.window;拦截器只做了两件事：访问已知属性原样返回，访问未知属性先打一条[env miss]警告再返回undefined。typeof prop === "symbol"的判断不能省，因为有些库会遍历Symbol.iterator，不排除会触发大量误报。console.trace()会打出完整调用栈，直接告诉你这个属性是在 bundle 的哪个位置被读的，对着栈去补对应的对象就行。
这个办法在补document、navigator时同样适用。拦截器本身会拖慢执行，但它只在分析阶段启用，定位完成之后关掉即可。
提示：如果你发现某个属性被访问了几百次还是未定义，先别急着补。有可能是它在检测环境真实性，比如读
navigator.webdriver，硬补反而会露馅，这种情况要看业务上是否真的需要。
4.3 crypto 与时间：两个最容易被忽略的依赖点
签名函数里有两类调用最容易出问题。一类是加密，浏览器里走window.crypto.subtle（异步）或者CryptoJS（纯 JS 实现）；另一类是时间，Date.now()返回毫秒，有些算法还要拼上时区偏移。
window.crypto.subtle在 Node 里可以用require("crypto").webcrypto顶替，但它是异步的，签名函数如果写成了同步调用就会崩。判断方式是看源码里有没有await或 Promise 链，没有的话八成用的是纯 JS 实现，环境里不需要补crypto，直接把 bundle 里那个加密库模块取出来用就行。
时间这块，签名往往包含一个有效期，服务端会校验请求时间和服务端时间的差值。本地复现时如果时间不准，签名是对的也会被拒。解决办法是在沙箱里把Date换成一个受控版本：
// 用真实时间，但允许手动偏移 const RealDate = Date; let offset = 0; sandbox.Date = class extends RealDate { constructor(...args) { if (args.length === 0) super(RealDate.now() + offset); else super(...args); } static now() { return RealDate.now() + offset; } }; // 需要校准时调 sandbox.__setOffset(-2000) sandbox.__setOffset = ms => { offset = ms; };继承原生Date而不是完全重写，是为了保留getTimezoneOffset、toISOString这些方法，很多签名会用到它们。offset允许你在发现本地时间与服务端有偏差时手动补偿，补偿值通过__setOffset传入，单位是毫秒。
补完这一层，签名函数基本就能在 Node 里返回正常结果了。剩下的工作是把调用封装起来，接到自己的请求流程里。
5. 避坑与排查：几段让人加班的真实记录
5.1 症状：签名能算出来，但服务端一直说无效
原因通常是参数顺序或编码不一致。签名算法对参数的排序和序列化方式极其敏感——你用JSON.stringify拼的字符串，和页面用&拼的字符串，算出来完全是两个值。
解决办法是把页面发出的原始请求参数抓下来，打印你本地参与签名的字符串，逐字符对比。重点看三处：空值参数是保留还是丢弃、中文是否做了encodeURIComponent、数字类型的1和字符串"1"有没有被区别对待。我遇到过一次是 URL 参数里的空格页面编成了%20，我这边编成了+，差一个字符全盘皆输。
5.2 症状：代码在浏览器里跑得好好的，Node 里报xxx is not a function
原因一般是环境判断走了不同分支。很多库会检测typeof window !== "undefined"来选择浏览器实现还是 Node 实现，你在沙箱里塞了window，它走了浏览器分支，但对应的 API 你只补了个空对象。
解决方式是顺着报错往上找那个xxx是在哪赋值的，看它所在的函数有没有环境判断。如果确实是分支走错，要么补齐对应的 API，要么把判断条件改掉——但改代码会让后续版本更新时的 diff 变大，我的习惯是优先补环境，实在补不了再动代码，动过的地方单独记一份 patch。
5.3 症状：签名有效期只有几十秒，批量请求中途全挂
原因是签名里带了时间戳，且服务端做了窗口校验。页面本身是一次请求算一次签名，你如果把签名缓存下来复用，很快就过期。
解决办法是在每次请求前重新调用签名函数，不做缓存；如果一次任务要发几百个请求，控制并发数，别让后面的请求排队排到过期。另外注意本地时钟——机器时间漂移几分钟，签名的有效期窗口就永远对不上，定期校时是必须的。
5.4 症状：hook 打出来的模块导出是空的
原因是模块用了r.d定义的 getter，属性是懒执行的，Object.keys虽然能列出键名，但值只有在真正访问时才会计算。如果你的记录代码只存了引用，后面模块被回收或者状态变化，值就对不上了。
解决办法是在 hook 里直接读一次值并深拷贝，或者至少把键名和类型记下来。另一种可能是目标模块还没执行——依赖它的模块没被加载，r(id)会惰性执行，这时候要主动调一次r(目标id)触发初始化。
5.5 症状：版本更新后，所有定位全部失效
原因是打包配置变了，模块 id 从数字变成了带哈希的字符串，或者字符串数组的取值函数改成了带三元判断的版本。
解决办法是把「定位」这一步脚本化。与其每次手动翻文件，不如写一个扫描脚本：正则抓模块表、抓请求头字段名、抓加密库的特征字符串（比如某个常量表的开头几位），输出候选模块 id 列表。这样改版后跑一遍脚本，几分钟就能重新定位，比重新读一遍 bundle 强太多。
6. 二次开发：把一次性分析变成能维护的工具
一次分析结束之后，真正的成本在「下次改版」。我的经验是把整个流程拆成四层，每层独立，一层坏了不影响其他层。
| 层级 | 职责 | 改版影响 |
|---|---|---|
| 抓取层 | 下载 bundle、比对 hash | 必变 |
| 定位层 | 找模块 id、找导出名 | 大概率变 |
| 环境层 | 补 window/navigator/Date | 偶尔变 |
| 调用层 | 封装签名函数、拼请求 | 基本不变 |
分离之后，改版时只需要处理前两层。定位层我会写成一个配置文件驱动的扫描器：
// locate.js —— 配置驱动的模块定位 const fs = require("fs"); const rules = [ // 特征字符串 → 用于在模块表里找候选模块 { name: "sign_module", patterns: ["setRequestHeader", "timestamp"] }, { name: "crypto_module", patterns: ["ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef", "0123456789+/"] }, ]; const code = fs.readFileSync("./bundle.js", "utf-8"); const report = {}; for (const rule of rules) { const hit = rule.patterns.filter(p => code.includes(p)); report[rule.name] = { matched: hit.length, // 记录命中的位置，方便人工二次确认 positions: hit.map(p => code.indexOf(p)) }; } console.log(JSON.stringify(report, null, 2));配置文件里每条规则包含一个名字和一组特征字符串，脚本统计每组命中数量并记录位置。改版之后跑一遍，如果sign_module的命中数从 2 变成 0，说明请求头字段名或者某个关键字变了，对着位置附近翻一翻就能重新锁定。这套东西看起来土，但比每次凭记忆翻代码可靠得多。
调用层要防的是「签名对了但请求还是失败」。我的习惯是在封装里加两道校验：第一道是格式校验，检查签名长度、字符集是否符合预期，不符合直接抛错而不是发出去；第二道是失败重试，服务端返回无效签名时重新算一次再发，最多重试两次，避免死循环。这两道加起来不到二十行，能省掉大量「到底是网络问题还是签名问题」的排查时间。
还有一点值得做：把每次签名时的输入参数、输出结果、本地时间写进日志，按天切分。签名失效这类问题，事后复盘时最需要的就是当时的输入输出，没有日志基本靠猜。日志里别存敏感字段，参数做个摘要就行。
最后说个习惯。我早期做这类分析，定位到函数就直接跑，跑通就完事，从来不记录环境补了哪些项。结果某次改版后环境层报错，我花了整整一下午才想起来当初navigator里还塞过hardwareConcurrency，漏了它就走进另一个分支。从那以后我每次补环境都强制写一份env.md，列清楚补了哪些对象、每个字段的值、从哪来的，改版时先对着清单过一遍。这套看起来笨的办法，反而让我在几个项目的版本迭代里省下了最多时间。希望帮到你。
本文还有配套的精品资源，点击获取
