企业官网建设流程全解析

简介：这份面向爬虫与前端安全学习者的实战代码包，围绕某东 Webpack 方式下的 h5st 逆向展开，提供从模块定位、加载逻辑分析到参数生成调用的一套可运行示例，适合已具备 JavaScript 基础、希望理解 h5st 加密流程与请求参数构造的中级学习者参考。压缩包共 2 个文件，包含 1 个 Python 脚本与 1 个 JavaScript 文件，体量约 159KB；前者便于串联请求与参数调用，后者承载 Webpack 模块及逆向分析代码，结构精简、便于对照调试。目前已有 860 人学习，说明该案例在爬虫参数逆向场景中具有一定参考价值。读者可从中获得 h5st 相关逻辑的完整代码、Webpack 打包模块的定位与调用思路，以及 Python 与 JS 协同验证的排错方向，用于理解目标接口参数生成机制并提升逆向分析能力。

1. 一次 403 的排查现场：h5st 为什么不能“抄”只能“复刻”

请求头里那串带分号的值一变，接口立刻从 200 掉到 403——这是我在一个 webpack 打包的移动端页面里第一次碰到 h5st 类签名参数时的现场。它不像 cookie 那样躺在document.cookie里可以直接复制，而是每次请求前由一段压在 chunk 里的 JS 现算出来，函数名是单字母，依赖全挂在闭包里。做爬虫的同学最容易在这里走偏：以为找到“加密函数”就赢了，实际上真正要复刻的是 webpack 的模块运行时加它依赖的浏览器环境。

这篇笔记写给两类人：一类是已经会抓包、会写基础请求、卡在签名参数怎么落地这一步的爬虫从业者；另一类是想搞清楚 webpack 产物结构、想看看别人怎么拆包的前端同学。下面按“定位 — 抠模块 — 补环境 — 对参数 — 排错 — 回归”的顺序走一遍，代码都能直接跑，坑也都会点出来。文中所有站点、目录、版本号均为脱敏示意，方法用于自建靶场与授权范围内的安全研究。

2. 拆 webpack 运行时：三种产物形态与模块表的落盘方式

逆向这类签名的第一步不是看算法，是看“东西装在哪”。webpack 的产物有个固定套路：一个运行时（runtime）负责模块注册和加载，若干个 chunk 负责业务代码，业务代码被打成模块id -> 工厂函数的键值对。签名函数只是其中某个工厂函数里的一段逻辑，你拿不到运行时，就拿不到它。

我一般先把页面所有 JS 落盘，再坐回来看结构。下面这几条命令能在一分钟内判断产物形态：如果匹配到webpackChunk前缀，基本是 webpack 5；匹配到webpackJsonp，是 webpack 4 及更早；两个都没有且文件是 ESM 直出的，多半是 vite/rollup，那这套方法要换思路。

2.1 先判断是哪一代 webpack 产物

# 把页面所有 js 落到 ./js 目录后，先做形态判断 grep -ro "webpackChunk[a-zA-Z0-9_]*" ./js | sort -u # webpack 5 grep -ro "webpackJsonp[a-zA-Z0-9_]*" ./js | sort -u # webpack 4 及以下 grep -rl "__webpack_require__" ./js # 运行时所在文件

-r递归目录，-o只输出命中片段而不是整行（压缩后的 JS 一行几万字符，不加-o会把整行刷屏），sort -u去重。命中的那个名字就是挂载在window/self上的全局数组名，后面 hook 要用到它。

需要提醒的是，同一个站点可能同时存在多个全局名——主站一个、活动页一个、第三方 SDK 一个。别只 hook 第一个命中的，把所有命中的名字都列出来，逐个挂，再对比哪个里面有签名相关模块。我在一个项目里就因为只挂了主站那个，白找了两天，签名其实在活动页那个独立 chunk 里。

2.2 拦截 chunk 注册，把模块表完整落盘

webpack 5 的 chunk 加载是往全局数组push一个三段式参数：[[chunkId...], {模块id: 工厂函数}, 运行时回调]。直接在页面里覆盖push经常失效，因为 webpack 内部缓存了数组引用的原始方法；用Proxy代理get更稳。

// 注入到目标页面控制台：拦截模块注册，把工厂函数收集起来 (function () { const NAME = 'webpackChunk_shop'; // 换成上一步 grep 出来的全局名 const raw = window[NAME] || []; window.__modTable = {}; // 模块id -> 工厂函数源码 window[NAME] = new Proxy(raw, { get(target, prop) { if (prop === 'push') { // 参数结构：[ [chunkIds], { id: factory }, runtimeCallback? ] return function (arg) { const mods = arg[1] || {}; for (const id of Object.keys(mods)) { window.__modTable[id] = mods[id].toString(); // 存源码，别存函数 } console.log('[capture] chunk', arg[0], '模块数', Object.keys(mods).length); return Array.prototype.push.apply(target, arg); }; } return Reflect.get(target, prop); } }); })();

这里有个关键选择：存mods[id].toString()而不是函数对象。因为函数对象绑死在页面上下文里，你没法直接搬到 Node 里；源码才是可搬运的资产。另外 webpack 5 的模块 id 可能是数字也可能是字符串（"src/utils/sign.js"这种），不要做Number(id)强转，强转会让一部分模块查不到，报错信息还特别误导，后面避坑章节会细说。

触发方式很简单：在页面上正常点几下、翻两页、触发一次带签名的请求，__modTable就会攒满。然后copy(JSON.stringify(window.__modTable))导出成文件。

2.3 定位签名入口：从请求头往回追调用栈

模块表有了，但哪个模块是签名模块？两个办法，我一般同时用。

第一个是 DevTools 的 XHR/fetch 断点：Sources 面板里加一个 URL 关键字断点，命中后看 Call Stack，从send往上翻，业务层一般在 3 到 6 层之内，那一层的函数名往往就是sign、getH5st、_sign之类被保留或半混淆的名字。

第二个更快，直接 hook 请求头写入，把调用栈打出来：

// hook setRequestHeader，谁写的签名头就打谁 const rawSet = XMLHttpRequest.prototype.setRequestHeader; XMLHttpRequest.prototype.setRequestHeader = function (k, v) { if (/h5st|sign|token|auth/i.test(k)) { console.log('[header]', k, String(v).slice(0, 60)); console.log(new Error('trace').stack); // 压缩代码里是行列号，需 pretty print } return rawSet.apply(this, arguments); };

Error.stack在压缩后的代码里只有行列号，看着像天书，所以要先在 Sources 里点一下{}（Pretty print）把文件格式化，再用 Ctrl+Shift+F 全局搜签名参数的分隔符（比如;）或版本号字符串，通常能直接跳到拼装位置。这一步不要省，很多人失败就失败在“猜错了入口模块”，后面补环境补半天，全补在无关模块上。

2.4 手写一个最小__webpack_require__

__webpack_require__是运行时闭包里的私有函数，外部拿不到。既然已经拿到了模块表，索性自己写一个加载器，逻辑很短，但要补齐 webpack 的辅助函数，否则 ES Module 互操作会直接崩。

// runner.js：最小 webpack 模块加载器 const modules = require('./modTable.json'); // id -> 工厂函数源码字符串 const cache = {}; function __webpack_require__(id) { if (cache[id]) return cache[id].exports; const module = (cache[id] = { id: id, exports: {}, loaded: false }); const src = modules[id]; if (!src) throw new Error('module not found: ' + id); // 用 Function 把源码还原成工厂函数，注意参数顺序固定 const factory = new Function('module', 'exports', '__webpack_require__', 'return (' + src + ')'); factory(module, module.exports, __webpack_require__).call( module.exports, module, module.exports, __webpack_require__ ); module.loaded = true; return module.exports; } // webpack 5 的四个辅助函数，缺一个就可能报 "is not a function" __webpack_require__.d = (exports, name, getter) => { if (!Object.prototype.hasOwnProperty.call(exports, name)) { Object.defineProperty(exports, name, { enumerable: true, get: getter }); } }; __webpack_require__.r = (exports) => { if (typeof Symbol !== 'undefined' && Symbol.toStringTag) { Object.defineProperty(exports, Symbol.toStringTag, { value: 'Module' }); } Object.defineProperty(exports, '__esModule', { value: true }); }; __webpack_require__.n = (m) => (m && m.__esModule ? () => m.default : () => m); __webpack_require__.o = (obj, key) => Object.prototype.hasOwnProperty.call(obj, key); module.exports = __webpack_require__;

几个参数的用意说明白：.d处理export { x }的 getter 定义，.r打 ES Module 标记，.n处理import * as的兼容包装，.o是hasOwnProperty的别名。这四个函数在压缩后的运行时里名字是乱的，但用法固定，照抄即可。new Function里那个return (...)的括号不能少，工厂函数源码本身是function(...){...}形式，包一层括号才能被正确求值。

写到这一步，模块能加载了，但一执行大概率会报window is not defined——因为签名逻辑天生依赖浏览器环境。这正是下一章要处理的事。

3. 抠出签名模块：vm 沙箱补环境与依赖递归收集

直接把整个模块表丢进 Node 里跑，通常活不过三秒。原因有两层：一是模块之间的依赖需要从入口递归拉齐，二是模块内部大量访问window、document、navigator这类只有浏览器才有的对象。补环境不是把浏览器整个搬过来，而是“缺什么补什么、补的每一块都要有依据”。

3.1 从入口模块递归收集依赖

签名函数不会孤立存在，它可能依赖工具函数模块、MD5 实现模块、时间格式化模块。webpack 的依赖调用在源码里表现为__webpack_require__(123)这样的字面量，扫一遍就能拿到依赖图。

// 从入口 id 出发，把可达模块全部收集出来 function collect(entryId, modules) { const seen = new Set(); const stack = [entryId]; while (stack.length) { const id = stack.pop(); if (seen.has(id)) continue; seen.add(id); const src = modules[id] || ''; // 匹配 __webpack_require__(123) 或 __webpack_require__("src/a.js") const re = /__webpack_require__\(\s*(?:"([^"]+)"|'([^']+)'|(\d+))\s*\)/g; let m; while ((m = re.exec(src))) { const dep = m[1] || m[2] || m[3]; if (dep !== undefined) stack.push(dep); } } return Array.from(seen); }

注意正则里同时兼容了字符串 id 和数字 id，并且取到的是原始字符串而不是转成数字——原因前面提过，webpack 5 的模块 id 可能是路径字符串。收集完之后把结果和modTable.json做交集，交集之外的模块就是“不需要搬”的，能显著缩小沙箱的攻击面，也少补一堆没用的 DOM API。

还有个细节：有些模块是通过__webpack_require__.e(chunkId)做异步加载的，这种静态扫描扫不到。遇到e调用，要么手动把对应 chunk 的模块表合并进来，要么在沙箱里把__webpack_require__.e打桩成返回已 resolve 的 Promise。后者更快，但前提是被异步加载的那个模块确实不影响签名结果——这一点要靠输出比对来验证，不能凭感觉。

3.2 用 vm 搭一个最小可执行沙箱

Node 内置的vm模块是最省事的选择：能隔离全局污染，又能自由控制上下文里有什么。关键在于window必须指向沙箱自身（很多库会写window.xxx = ...，然后从window上读回来）。

const vm = require('vm'); const crypto = require('crypto'); const sandbox = {}; sandbox.window = sandbox; sandbox.self = sandbox; sandbox.globalThis = sandbox; sandbox.top = sandbox; sandbox.parent = sandbox; // UA 必须从真实请求头里抄，别用默认值，很多分支靠它判断平台 sandbox.navigator = { userAgent: 'Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148', platform: 'iPhone', language: 'zh-CN', languages: ['zh-CN'], cookieEnabled: true, webdriver: false }; sandbox.location = { href: 'https://example.com/m/index.html', protocol: 'https:', host: 'example.com', hostname: 'example.com', search: '', hash: '' }; sandbox.document = { cookie: '', // 有需要就整串贴进来 referrer: 'https://example.com/', createElement: () => ({ getContext: () => null, style: {}, setAttribute() {} }), getElementsByTagName: () => [], querySelector: () => null, addEventListener: () => {} }; sandbox.localStorage = { _d: {}, getItem(k) { return this._d[k] ?? null; }, setItem(k, v) { this._d[k] = String(v); }, removeItem(k) { delete this._d[k]; } }; sandbox.crypto = crypto.webcrypto; sandbox.setTimeout = setTimeout; sandbox.clearTimeout = clearTimeout; sandbox.console = console; vm.createContext(sandbox); // 之后所有模块都在这个上下文里跑

每一块都有理由：navigator.userAgent决定走 PC 分支还是 H5 分支，签名算法在不同分支下可能完全不同；document.cookie里通常有会话标识，签名函数会读它参与摘要计算；localStorage里常存设备指纹或上一次的令牌；location参与某些拼接。这些值都不能拍脑袋编，最好的来源是抓包时那条真实请求对应的页面状态——打开 DevTools 控制台，把navigator.userAgent、document.cookie、localStorage逐条打印出来复制过去。

注意：crypto.webcrypto的subtle接口全是 Promise，而不少站点签名用的是自研的同步 MD5/SHA256。沙箱里挂了 webcrypto 之后，如果原逻辑走的是subtle.digest，返回值会变成[object Promise]被拼进字符串，结果看着像乱码，实际是类型错了。

3.3 用 Proxy 打桩，把“缺什么”变成日志

补环境最耗时的不是写实现，是找“还缺什么”。硬跑只会拿到第一个报错，改完再跑又报下一个，来回几十轮。我的做法是先挂一个万能桩：任何未定义的属性访问、函数调用都记录下来并返回桩本身，跑一遍就能拿到完整缺失清单。

const missing = new Set(); function stub(path) { const fn = function () {}; return new Proxy(fn, { get(t, p) { if (p === Symbol.toPrimitive) return () => 0; // 参与运算时不炸 if (p === 'toString') return () => ''; missing.add(path + '.' + String(p)); return stub(path + '.' + String(p)); }, apply() { missing.add(path + '()'); return stub(path + '()'); }, construct() { missing.add('new ' + path); return stub('new ' + path); } }); } // 遍历沙箱里没有的全局名时用它兜底 sandbox.__stub = stub; process.on('exit', () => { console.log('缺失清单：\n' + Array.from(missing).sort().join('\n')); });

跑一遍之后按清单逐条补真实实现，补完再跑，直到清单不再增长。这套流程看起来笨，但比一轮轮试错快得多，而且留下的清单本身就是文档——下次版本更新再挂一次，差异一目了然。

签名算法里常见的摘要函数如果是自研的，直接在沙箱里挂一个同步实现即可，不用去动crypto：

// 同步 md5 挂载示例（用现成库，别自己手写） const md5 = require('crypto-js/md5'); sandbox.__md5 = (s) => md5(String(s)).toString();

把模块源码里的crypto.subtle调用替换成__md5属于侵入式改造，能做但不推荐长期用——每次版本更新都要改一遍。更稳的是在沙箱里伪造一个同步版的crypto.subtle.digest，让原逻辑无感通过，改造点集中在一处。这个取舍在长期维护时差别很大，后面第 6 章还会说到。

4. 拼装参数与冻结变量：六个分段字段各管什么

签名函数能跑通，只完成了一半。真正让请求通过的是“参数拼装得对不对”，而这里最容易翻车的地方不是算法，是那几个看起来无关紧要的字段。

4.1 分段字段的业务含义

h5st 这类参数通常是分号分隔的多段结构，不同站点段数和顺序不同，但语义高度相似：

这张表的价值在于：当你拿到 403 时，可以按段位逐段排查，而不是把整个字符串当成黑匣子。我的习惯是先固定第 2、4、5 段，只让第 1、6 段变化，跑通之后再放开。哪一段一放开就 403，问题就锁定在哪一段。

第 4 段要特别留意。它是版本号，服务端升级后会改，而你的脚本里如果写死了旧版本，表现是“算法算对了但服务端不认”。稳妥做法是从页面 HTML 里的某个 config 变量或一个独立的配置接口动态取，而不是硬编码。

4.2 时间戳与随机数：让结果可复现的两个开关

调试期最痛苦的是“同一个输入，两次结果不一样，不知道哪次对”。这时候要主动冻结随机源：

// 调试期冻结 Math.random，让签名可复现；上线前务必还原 const originalRandom = Math.random; let seed = 20240521; Math.random = function () { seed = (seed * 1103515245 + 12345) & 0x7fffffff; return seed / 0x7fffffff; }; // 时间戳同理，可以先把 Date.now 钉死，比对通过后再放开 const originalNow = Date.now; Date.now = () => 1716300000000;

这两个替换必须放在模块加载之前执行，因为有些模块在初始化阶段就把Date.now或Math.random存进了闭包变量，事后替换无效。这一点很反直觉，我最早就是因为替换太晚，冻了半天没效果。

时间戳还有两个隐蔽问题：一是精度，JS 的Date.now()是毫秒，但有些实现要求秒级，多三位数直接导致摘要对不上；二是时区，new Date().getHours()之类的方法受TZ环境变量影响，本地跑出来和浏览器跑出来可能差 8 小时。稳妥做法是启动脚本时显式设process.env.TZ = 'Asia/Shanghai'，别依赖机器默认值。

4.3 把签名能力包成 CLI 和服务

调试通了之后，别让它停在控制台里。包成一个函数，再包成 HTTP 服务，后续接入爬虫框架就是一行请求的事。

// sign-server.js：把签名能力暴露成本地 HTTP 接口 const http = require('http'); const { sign } = require('./signer'); // 内部完成沙箱创建 + 模块加载 const server = http.createServer((req, res) => { const u = new URL(req.url, 'http://localhost'); const body = u.searchParams.get('body') || ''; // 参与签名的请求体 const t0 = Date.now(); try { const h5st = sign(body); res.setHeader('content-type', 'application/json'); res.end(JSON.stringify({ h5st, cost: Date.now() - t0 })); } catch (e) { res.statusCode = 500; res.end(JSON.stringify({ error: String(e && e.message) })); } }); server.listen(8787, () => console.log('sign server on 8787'));

参数说明：body是参与摘要计算的请求体原文，必须和实际发出的一模一样——多一个空格、字段顺序换一下，摘要就变了，这是最常见的 403 来源。返回里带cost方便观察性能，签名一次通常几毫秒，如果超过 100ms，多半是沙箱里某个桩函数在空转。

并发要注意：签名模块内部常带闭包缓存（比如缓存了设备指纹），多个请求同时进来可能互相污染。稳妥做法是每个请求新建一个 vm context，或者用 worker 池跑。前者简单但慢，后者快但要处理进程间通信，量不大时没必要上。

Python 侧调用就这么简单：

import requests def get_sign(body: str) -> str: r = requests.get("http://127.0.0.1:8787/", params={"body": body}, timeout=5) r.raise_for_status() return r.json()["h5st"] print(get_sign('{"page":1,"size":20}'))

把签名服务和业务请求拆成两个进程的好处是：签名服务崩了不影响采集任务重试，且签名服务可以单独重启、单独挂日志。生产上我会给它加一个健康检查接口，业务侧拿到 500 就熔断，别让它把整个任务拖死。

5. 避坑与排查：五条让签名结果对不上的血泪记录

下面这五条都是我在不同项目里真实踩过的，按“现象 → 原因 → 解决”写。遇到 403 的时候先按这个顺序过一遍，比漫无目的地补环境快得多。

5.1 执行环境类的三个坑

坑一：Cannot read properties of undefined (reading 'call')

现象：模块加载到一半直接抛这个错，堆栈指向__webpack_require__内部，看不出哪个模块缺了。

原因：模块 id 类型不匹配。webpack 5 里模块 id 可能是数字123，也可能是字符串"src/utils/a.js"，我在写加载器时习惯性写了Number(id)，结果字符串 id 被转成NaN，查表查不到。

解决：加载器里所有键一律保持原始值，不做类型转换；modTable.json导出时也保留原样。另外顺手加上if (!(id in modules)) throw new Error('missing ' + id)，报错信息要能一眼看出缺哪个模块，别让undefined.call这种错误浪费半小时。

坑二：签名函数返回空串或undefined

现象：不报错，但拿到的签名值是空的，或者明显是兜底值。

原因：模块内部有平台判断，比如if (/iPhone/.test(navigator.userAgent))，沙箱里navigator是默认值或者压根没挂，走了 else 分支，直接返回空。

解决：把真实请求头里的User-Agent完整复制到navigator.userAgent，同时补齐platform、language、vendor等字段。判断依据不能靠猜，去页面控制台把整个navigator的属性打印出来对比。这一步做完，很多“算出来是空”的问题自动消失。

坑三：异常被 try/catch 吞掉，只看到一个兜底值

现象：没有任何报错，但结果就是不对。

原因：签名函数外层包了try { ... } catch (e) { return fallback }，异常被吃掉，返回了预先准备的默认串。

解决：沙箱里注入一个会打日志的console，并且在vm.createContext之前把Error的prepareStackTrace挂上；更直接的办法是临时把抓到的模块源码里的catch分支改掉，让它throw出来。这个操作只用于调试，别带进最终脚本。改完立刻就能看到真实异常。

5.2 参数与时间类的两个坑

坑四：本地跑得好好的，一上线就 403

现象：同一份代码，本地连续跑几十次都通，部署到服务器后成功率暴跌。

原因：两个可能，一是服务器时区不是东八区，new Date()相关逻辑偏了 8 小时；二是服务器时间本身有漂移，与服务端的时间窗对不上。第二点更隐蔽，容器里 NTP 没同步的情况很常见。

解决：启动脚本强制process.env.TZ = 'Asia/Shanghai'；再在签名前后打印本地Date.now()与服务端响应头的Date，算个差值，超过一两分钟就先校时。我现在的习惯是每次部署完先跑一个十次的连通性小脚本，通过率不是 100% 就不继续。

坑五：第一次调用正常，第二次结果就变了

现象：单独调用没问题，连续调用时偶发失败。

原因：模块闭包里缓存了可变状态。常见的是缓存了设备指纹、自增计数器、上一次的随机种子。第一次初始化之后，后续调用复用了旧状态，导致与服务端期望的不一致。

解决：要么每次签名新建 vm context 重新走一遍模块初始化，要么把缓存对象在每次调用前重置。前者的代价是性能，后者的代价是容易漏字段。我一般先用前者保证正确性，压测发现性能不够再逐个优化。判断是不是这个原因很简单：连续调两次，把两次的中间变量打出来对比，哪里不一样就是哪里被缓存了。

提示：排查时先做“可复现”，再做“定位”。把时间戳和随机数冻结住，让同样的输入产生同样的输出，后面的二分排查才有意义；否则你连两次失败是不是同一个原因都说不清。

6. 回归与维护：把还原脚本变成能长期跑的资产

签名逻辑是会变的，这一点必须提前接受。所以真正决定这套东西能活多久的，不是算法还原得多漂亮，而是你有没有一套能快速发现“变了”和快速定位“变在哪”的机制。

我一般会维护一张对照表，每次版本更新后先跑回归：

这张表不需要多复杂，一个 json 文件加几十行脚本就够。关键是把它挂在定时任务上，别等业务报错了才去看。

回归脚本的核心思路是“冻结输入 + 比对结构”，而不是比对最终字符串——因为时间戳每次都变，字符串永远对不上。有效做法是：固定时间戳和随机数，只校验摘要段长度、字符集、分段数量，再配合一次真实请求的成功率做最终判断。

// 回归检查：结构校验 + 连通性抽检 const assert = require('assert'); const { sign } = require('./signer'); // 冻结时间后，同一输入的结构必须稳定 const s = sign('{"page":1,"size":20}'); const parts = s.split(';'); assert.ok(parts.length >= 5, '分段数量变了，可能服务端升级'); assert.ok(/^[0-9a-f]{32,64}$/i.test(parts[parts.length - 1]), '摘要段格式变了'); console.log('结构校验通过，段数', parts.length);

结构校验能抓到大部分“发版了”的场景，而且误报率低。真正的玄学在成功率上：有时候结构没变、算法没变，就是过不了，多半是环境指纹或风控策略调整，这种只能靠成功率监控兜底，靠肉眼是看不出来的。

最后说个我自己的教训。早期我图省事，把补环境的代码和业务请求写在一个文件里，结果版本一更新，改一处带动三处，排查半天。后来强制自己拆成三层：env/只放环境桩，runtime/只放模块加载，signer.js对外只暴露一个sign(body)。从那以后我每次更新签名逻辑，都强制走一遍“抓新 JS → 生成 modTable → 跑结构校验 → 抽检十次成功率”这四步，不再凭感觉改代码。这套流程笨，但它让我少熬了很多夜。希望帮到你。

本文还有配套的精品资源，点击获取