简介：一套可运行源码包，聚焦JS逆向分析小红书X-s/X-T参数生成过程，主要面向具备前端调试基础、希望深入理解网络应用加密机制的开发者。资源将抓包分析、Hook JSON.stringify断点、调用栈跟踪、补环境/RPC等技术思路落地为可直接执行的项目，并配有HTML演示页面，方便边运行边观察生成逻辑。包内插桩日志明确揭示了MD5魔法值与Base64编码细节，包括URL、环境检测值、cookie中的a1、时间戳等关键字段，直观展示从URL加参数进行MD5、拼接x1-x4、Base64编码到最终生成payload的完整链路，能够帮助读者快速建立逆向分析的整体框架，避免从零摸索的弯路。资源共3个文件，包含inscode环境配置、HTML页面和gitignore文件，压缩包仅6KB，结构精简、轻量易用，无需复杂依赖即可在浏览器或集成环境中直接运行调试。目前已有120人学习/下载，对于想掌握小红书加密参数逆向方法，或希望将这套思路迁移到同类JS加密场景的开发者，都是一份值得动手实验的起点资料。
1. JS逆向分析小红书X-s/X-T：签名与时间戳的双重校验逻辑
在处理小红书Web端数据采集时，X-s与X-T这两个请求头参数几乎是一道绕不开的门槛。X-s是一段由前端JS动态生成的签名值，X-T则是与请求时间绑定的时间戳，两者联合构成了服务端校验的核心防线。很多开发者尝试直接复制请求头重放请求，结果通常是被风控系统秒拒——原因很简单：签名里既包含了路径、查询参数、请求体等信息，还混入了时间种子，哪怕URL只差一个字符，签名都会完全不同。为了讲透这套机制，我拆解了一个可运行的小红书X-s/X-T逆向源码包，它把签名生成流程、补环境方案和请求示例都封装好了，适合需要稳定请求接口的开发者直接复用。
这个源码包适合两类人：一类是正在研究小红书Web端反爬体系、想弄明白X-s签名生成逻辑的JS逆向初学者，另一类是已经在写采集脚本、但经常被签名校验拦截的从业者。接下来我会从签名入口定位、算法还原、源码结构、参数校验以及高频踩坑这几个角度逐层展开，最后落到一个能直接照做的请求签名示例上。整个拆解过程以可运行源码为主线，不会只停留在抓包截图上。
2. 定位签名入口：从启动器到断点下探的完整链路
2.1 先从搜索请求里找到X-s的生成起点
实际调试过程中，我一般会先打开开发者工具的网络面板，过滤出Search接口，然后从请求标头里复制X-s的值，切到Sources面板做全局搜索。这一步实操上有个小技巧：不要直接搜完整的X-s值，因为前端代码可能对字符串做了切分或拼接，直接搜整串往往会扑空。更稳妥的做法是搜X-s值的前八位或后八位，命中后再通过调用栈往上追溯。
一旦命中，基本会落在某个webpack模块内部。小红书的前端资源做过多层压缩和混淆，直接读代码会非常痛苦，所以我习惯借助启动器（Call Stack）看调用关系。断点命中后，从当前执行栈往回找，通常会经过封装好的请求库，然后进入一个带有加密逻辑的模块文件。到了这一步，核心工作就变成了识别这个模块里到底拼接了什么、使用什么哈希算法、最终怎么输出十六进制字符串。
// 示例：定位X-s生成的入口函数 function getXSign(params) { // 此处为实际签名函数入口，断点命中后会停留在类似行 var baseString = buildBaseString(params); // 拼接待签名内容 var timestamp = Date.now(); // X-T时间戳 return calcSign(baseString, timestamp); // 返回最终的X-s }这段伪代码说明了入口函数的基本职责：先把请求参数拼成固定格式的待签名串，然后取当前毫秒时间戳，最后把两者传入calcSign计算签名。参数说明上，buildBaseString的输出格式直接决定了签名是否能通过校验，需要在后续断点中观察它的实际拼接顺序，不能凭猜测去还原。
2.2 断点下探时如何区分有用的加密段和无用噪音
实际代码里会有大量与签名无关的辅助逻辑，比如日志上报、埋点初始化、错误捕获等。如果每个调用栈都逐行跟读，会很快迷失方向。我通常先在Network面板把请求锁定，然后在Sources里给搜索结果的唯一关键字添加条件断点，等请求发起前用鼠标悬浮查看b、e、t这类压缩变量名对应的真实内容，再顺着执行流找到真正的哈希处理段。
一个比较实用的观察点：X-s的值通常是定长的十六进制字符串。用断点停到签名生成函数return语句时，可以先在控制台执行arguments.callee.toString().slice(0, 200)，粗略判断当前位置是不是真正的签名函数，如果是，再往里看初始种子、盐值以及哈希次数。以我的经验来说，小红书的X-s和X-T常常会走一次类似于双MD5摘要的流程：先对请求体做摘要，再连同时间戳做第二次摘要，最终输出32位小写十六进制字符串。
// 断点附近常用验证代码 (function () { var sign = arguments.callee.toString(); if (sign.indexOf("md5") > -1 || sign.indexOf("hex") > -1) { console.log("当前函数疑似包含哈希逻辑"); } })();这段代码是在浏览器控制台直接执行的，作用是快速判断当前断点处的函数体里是否引用了hash库或十六进制输出逻辑。需要注意的是，arguments.callee在严格模式下会被禁用，所以这种验证手段仅在非严格模式的压缩代码段里有效。如果控制台没有任何输出，说明这个函数只是外层包装，需要继续往下走。
3. 签名算法还原：把压缩混淆的代码翻译成可读逻辑
3.1 从浏览器插桩到捕获真实参数
还原算法的第一步，是把浏览器环境里的参数完整捞出来。很多情况下，直接从调用栈里读参数会漏掉对象属性，尤其是签名函数内部自己构造的临时对象。更可靠的办法是给关键函数做插桩，在进入函数和return前分别打印入参与出路。
插桩的实现方式有两种：一种是在Sources里手工改源码，再保存成本地覆盖文件；另一种是用油猴脚本在页面加载前注入钩子。我一般选择后者，因为不用改动页面原始文件，刷新也不会丢失。插桩时要重点记录buildBaseString的输入输出、时间戳的具体取值、以及calcSign是否还接收了其他隐藏参数。
// 插桩示例：在页面加载前注入，捕获签名函数入参与返回值 (function () { var oldFetch = window.fetch; window.fetch = function () { var request = arguments[0]; var headers = request.headers || {}; if (headers["x-s"]) { console.log("捕获到X-s:", headers["x-s"], "X-T:", headers["x-t"]); console.log("请求URL:", request.url, "请求体:", request.body); } return oldFetch.apply(this, arguments); }; })();这段代码是在页面加载前执行的，核心作用是重写fetch方法，在每次请求发出去之前拦截标头信息。通过对比实际请求里的X-s与插桩捕获到的X-s，可以确认自己后续生成的签名值是否与前端一致。参数说明上，request.headers在小红书的请求中一般都能拿到X-s和X-T，如果拿不到，说明请求没有走标准fetch，需要改为钩住XMLHttpRequest。
3.2 双MD5摘要策略与时间戳绑定方式
抓取足够样本后，签名算法的全貌会逐渐清晰。在小红书的Web端签名逻辑里，X-s的生成顺序通常遵循这样一个链路：先把请求Path、部分Query参数、请求体做一次MD5，拿到中间的哈希值；再把这个哈希值拼上与X-T相同的时间戳，做第二次MD5，最终输出X-s。整个过程不涉及复杂的非对称加密，整体难度属于中等偏下。
这里需要特别说明时间戳的绑定方式。X-T的值取的通常是签名生成时刻的毫秒时间戳，但它不只是作为一个独立请求头返回，还会参与第二次MD5的输入。这就意味着如果客户端时间与服务器时间偏差过大，即使签名计算正确，服务端依然可能因为时间窗口超限而拒绝请求。常见做法是先从任意接口拿到服务器时间，再计算本地时间与服务器时间的偏移量，签名时统一使用校正后的时间。
// 还原后的签名计算参考实现 function md5(text) { // 这里使用项目源码里内置的MD5实现 return md5Hex(text); } function buildXSign(path, queryString, body, timestamp) { var firstRound = md5(path + queryString + body); var secondRound = md5(firstRound + timestamp); return secondRound; }这段代码算是核心签名的粗略还原。参数说明上，path需要去掉域名部分，queryString需要保持键值对的原始顺序，body则是请求体的字符串形式。如果请求体为空，则使用空字符串参与拼接。我把这版代码整理到源码包的sign.js模块里之后，只要把入参格式对齐，就能稳定生成合法签名。
4. 可运行源码包：从初始化到实际签名请求的完整闭环
4.1 源码包的核心目录与模块职责
拆解这个源码包时，我注意到它的目录结构很干净，核心模块都集中在src路径下，入口文件直接挂在根目录。它把环境校验、签名算法、请求示例分成了独立模块，这对想快速接入的人来说非常友好。拿到压缩包后，直接执行初始化命令即可安装运行时依赖。
cd xhs-sign-demo npm install安装完成后，运行目录下的start脚本就能拉起一个本地示例服务。这个示例服务会附带一个测试接口，里面内置了一组固定的请求参数，可以直接看到X-s与X-T的生成结果。需要说明的是，这组内置参数是为了演示签名流程而准备的，实际使用时需要替换成自己的真实请求数据。
源码包里最直观的是sign.js模块，它承担了签名计算的完整逻辑。该模块内封装了字符串拼接规则、时间戳生成方法和MD5哈希工具，并且对外暴露了一个签名生成函数。另外一个比较关键的模块是request.js，它会在请求发送前自动读取配置项，把生成的签名值写入请求头，避免手动拼接标头的繁琐过程。
4.2 签名生成与请求联调的正确顺序
在整个源码包的使用流程中，签名生成与请求联调是最容易出错的环节。常见做法是先生成X-T时间戳，再基于它计算X-s，最后同时写入请求头。如果反过来，先算X-s再补X-T，那么签名里的时间戳与请求头里显示的时间戳对不上，服务端校验大概率会失败。
// 参考request.js核心请求逻辑 const { generateXSign } = require("./sign"); const axios = require("axios"); async function searchRequest(params) { const timestamp = Date.now(); const path = "/api/search"; const query = buildQuery(params); const body = ""; const xSign = generateXSign(path, query, body, timestamp); const response = await axios.post("https://www.example.com" + path, params, { headers: { "X-T": timestamp, "X-S": xSign, "Content-Type": "application/json" } }); return response.data; }这段代码的逻辑是先用当前时间戳生成签名，再把时间戳和签名一起放进请求头。参数说明上，buildQuery需要按照前端实际的序列化规则生成查询字符串，不能直接用JSON.stringify替代；body字段在POST场景下如果为空字符串，签名拼接时同样使用空字符串。这样联调后，只要入参顺序一致，签名就能够通过服务端校验。
4.3 签名结果校验：先本地比对再发真实请求
很多新人拿到源码包后，第一件事就是直接向真实接口发请求，这样一旦被风控拦截，很难判断是签名问题还是IP问题。正确的做法是先跑一遍源码自带的校验脚本，它能模拟一组请求参数并生成签名值，然后与抓包拿到的签名值做比对。如果两者完全一致，说明环境与算法都已对齐；如果不一致，则需要逐个排查参数拼接顺序。
// 校验脚本sketch：本地比对输出 const rightResult = "32位十六进制签名"; const computedResult = generateXSign("/api/search", "keyword=%E7%83%AD%E9%97%A8", "", 1700000000000); console.log("本地计算结果:", computedResult); console.log("与目标结果比对:", computedResult === rightResult);在跑这段代码时，会输出本地计算的签名值，然后再与目标值做布尔比对。参数说明上，为了稳定复现，测试参数都是写死的：路径、查询字符串、时间戳都固定，这样结果才可重复。如果比对结果是false，优先检查query字符串的编码方式，其次检查body是否真的为空，这两处是最容易忽略的地方。
5. 避坑指南与常见排查方法：从X-s 400到风控封禁的实战排错
5.1 请求体格式错位导致签名值合法但接口返回400
现象：签名计算过程没有报错，生成的X-s也是32位十六进制，但实际请求发出去后接口直接返回400参数错误。整体来看签名好像生效了，但服务端并不买账。
原因：请求体格式与签名拼接时使用的格式不一致。比如签名时用的是JSON字符串{"keyword":"美食"}，但实际请求发送时axios默认序列化成了keyword=美食，两种格式参与签名后的MD5结果完全不同。前端签名的都是用请求体的原始字符串，因此发送时也必须用相同字符串。
解决：先在插桩代码里打印出actual request body，然后将请求体字符串原封不动地传入签名函数。如果前端使用的是JSON格式，axios里需要设置JSON.stringify后的字符串作为data，并确保Content-Type为application/json，这样参与签名与发送的体保持一致。
5.2 时间戳偏移超过服务端窗口导致偶发签名失效
现象：签名流程在本地验证完全没有问题，但每隔一段时间会有一批请求被拒绝，且报错信息提示签名过期或时间校验不通过。重新本地计算又恢复正常，看起来像是随机问题。
原因：本地设备时间与服务器时间存在偏差。签名用的X-T是基于本机时间生成的，如果本机时间比服务器时间慢或快了几十秒，超出了服务端允许的时间偏移窗口，即使签名内容完全正确，也会被判为过期请求。
解决：在项目中维护一个时间偏移量。启动时请求任意一个公开接口，从响应头里读取服务器时间，然后计算offset = serverTime - localTime。后续生成签名时，把Date.now()替换为Date.now() + offset，就能保证X-T始终落在服务端允许的窗口内。我一般每十分钟重新校准一次偏移量。
5.3 环境检测导致签名函数执行时报错
现象：在浏览器里打断点调试时签名函数正常运行，但把算法搬到Node.js环境后，执行签名函数直接抛异常，报错信息通常与window或document对象有关。
原因：压缩混淆代码里头可能暗含了环境检测逻辑，比如读取window.navigator.userAgent或document.cookie，Node.js里没有这些对象，运行时自然报错。这个检测不一定是为了安全防护，很多时候只是前端框架的通用逻辑在作祟。
解决：在Node.js里做轻量级环境补齐，定义global.window、global.navigator、global.document等必要对象，再尝试运行签名函数。补齐的原则是“用到什么补什么”，不要一次性引入jsdom之类的重型依赖，否则还会引发新的执行性能问题。源码包里带的env.js就是做这件事的，直接require即可。
5.4 Cookie缺失引起的风控策略升级
现象：请求签名明明符合校验，但连续请求几十次后突然所有请求都被重定向到验证页，且返回的HTML里包含验证组件。
原因：这通常不是签名算法本身被破解，而是请求缺少必要的Cookie上下文。小红书Web端风控会记录请求会话内的Cookie变化，如果一个会话里完全没有初始Cookie，或者Cookie值与签名请求头不匹配，就会触发验证机制。
解决：在请求流程中先访问一次首页或任意页面，获取初始Cookie并保存到会话中，后续每次请求都携带这套Cookie。同时保证请求头里的User-Agent、Accept等字段保持稳定，避免高频变化触发风控。观察下来，只要Cookie链路完整、请求频率控制在合理区间，被验证页拦截的概率会明显下降。
6. 签名指纹在落地中的高效用法：用时间窗口与重放特征做自检
实际把这一整套方案跑通之后，我觉得真正值钱的不是生成一个合法签名，而是用签名特征反推自己的请求链路是否健康。比如，把一段时间内所有请求的X-s与X-T组合保存下来，观察同一路径下X-s值的变化规律——如果连续多次请求的X-s完全一致，说明签名里的时间种子没有生效，大概率是时间戳传错了；如果X-s分布完全随机且每次都不相同，则说明拼接逻辑里包含了请求参数，这是期望中的状态。
另一个高效用法是把重放特征当成事后排查工具。当服务端开始有限流或拒绝动作时，我会回头拉取请求日志，筛选出签名值为同一串的请求数量。正常工作状态下一个签名只应该出现一次，如果大量请求共用了同一个X-s，说明本地做了请求缓存，或者签名生成处的随机种子没有被正确刷新。这种问题在错误日志里往往没有明确报错，但不解决就会造成越来越多的校验失败。
我自己习惯在签名生成模块里埋一个轻量统计计数器，记录每次签名的入参长度与生成耗时。入参长度异常时能快速定位是哪一类请求参数被截断，耗时陡然升高则可能是环境补齐对象干扰了执行逻辑。这样每次风控策略变动时，不需要重新抓包分析，直接看计数器数据就能缩小范围。
从那次之后，我每次在项目里接类似的签名校验逻辑，都会强制走一遍完整校验脚本：先静态比对签名结果，再发少量测试请求验证服务端接受度，最后观察一段时间内的签名分布曲线，这三步确认完毕后才敢放量跑。后续迭代签名参数时也不再靠盲改碰运气，而是先把插桩日志和签名日志对齐，再动算法代码。希望这个拆解思路能帮你在处理X-s这类签名参数时少绕弯子，直接找到可控的落地路径。
本文还有配套的精品资源，点击获取
