简介：小红书x-s参数逆向分析资源包，面向逆向工程、安全研究和爬虫开发人员，旨在剖析x-s参数的动态生成机制与补环境源码，帮助读者理解客户端如何利用该参数完成与服务器的安全通信，适合具备编程、加密算法和网络协议基础的中高级学习者。压缩包共1511个文件，以js、ts脚本及map映射文件为主，辅以json配置、md说明、license许可、yml配置等类型，整体约3.34MB，目录结构较为清晰，便于按脚本类型检索分析。已有402人学习下载，适用性与参考价值得到初步验证。内容涵盖反编译代码分析、签名机制解读、网络数据包解析等关键环节，并涉及HTTP/HTTPS协议与加密逻辑的还原思路，以及用户认证、内容分发等相关参数的关联分析，可为后续安全研究、漏洞挖掘或第三方插件开发提供直接参考。
1. x-s参数逆向分析：它到底在给谁签名
抓小红书Web端接口时，第一个绕不过去的字段就是x-s。一串几十上百位的十六进制字符串，每次请求都不一样，不带它直接返回-1，带了但算错同样返回-1。很多人第一反应是这玩意有黑匣子，其实x-s没那么玄学，它本质上是客户端对请求上下文算出来的一次签名。逆向分析x-s参数，核心不是去破解某个加密算法，而是把「哪些内容参与了签名、按什么顺序拼接、最后做了什么摘要」这一套规则还原出来，然后在本地用代码重新算一遍。这篇文章写给正在做接口调试、数据采集或爬虫稳定性优化的人，目标是让你从抓包开始，一步步把x-s复现出来，并知道哪些环节最容易翻车。
2. 从抓包到定位：x-s的构成与生成逻辑
2.1 先看长什么样：抓包锁定x-s的特征
开始逆向之前，先得确认目标长什么样。打开浏览器开发者工具，切到小红书Web站点，随便触发一个需要登录态的接口，在请求头里能看到x-s、x-t、x-s-common这一组参数。x-s通常是一串十六进制字符串，x-t是一串毫秒级时间戳，x-s-common是另一段更长的签名内容。这三个字段往往同时出现，x-s是短签名，x-s-common是重签名，服务端先验x-s，再验x-s-common，任何一个不对都拿不到数据。
我的习惯是先抓十条同接口的请求，把x-s、x-t、请求路径、请求体放在一张表里对比。你会发现几个规律：x-s每次都不同，但长度几乎一样；x-t和请求发出时间强相关；同一接口带同一请求体，重放老请求时x-s不会变，但x-t太旧会被拒。这说明x-s的生成输入里至少包含x-t时间戳，时间戳一变，x-s就变。如果换一个接口路径，哪怕请求体相同，x-s也完全不同，说明path参与了签名。这两条规律是后续逆向的锚点。
用抓包工具确认请求头之后，把请求复制成cURL格式保存下来，后面写验证脚本会频繁用到。同时留意请求头里有没有自定义的User-Agent、Cookie、x-b3-traceid之类的字段，它们很可能也在签名范围内。判断方法很简单：手动改其中一个字段看x-s是否校验失败，但这要在后面本地复现签名之后才能做，现在先记录。
2.2 顺着JS找签名入口：用关键词和调用栈定位
Web端的签名逻辑一定在前端JavaScript里。打开开发者工具的资源面板，找到加载的主JS文件。因为代码做过混淆和压缩，直接搜「x-s」可能什么都搜不到，更常见的是字段名被拆成变量拼接，或者藏在某个对象里动态生成。我一般换一个思路：不是去找x-s这个字符串，而是去找x-t的赋值位置，因为x-t是一个明文时间戳，搜索难度低很多。在JS里搜x-t或者"x-t"，找到之后往上看几步，通常能看到同一个对象在同时设置x-s、x-s-common，签名函数就在附近。
定位到赋值语句之后，打断点或者直接看调用栈，就能找到真正的签名函数。小红书Web端的x-s生成逻辑，我观察到的常见结构是：取method、path、query、body、x-t、salt六类输入，做一次字符串归一化拼接，再走MD5或HMAC摘要。下面用一段简化的Node伪代码说明这个结构，不是某个真实版本，但能帮你理解后续要分析什么。
// sign.js - 示意性结构，非线上代码 const crypto = require('crypto'); function normalize(method, path, query, body, ts) { return [method, path, query || '', body || '', ts].join('&'); } function buildXSign(config) { const { method, path, query, body, ts, salt } = config; const raw = normalize(method, path, query, body, ts); const digest = crypto.createHash('md5').update(raw + salt).digest('hex'); return digest; // 实际可能再拼接长度或二次编码 }这段代码的逻辑说明：normalize函数把请求的五个要素用&连接，顺序是method、path、query、body、ts，顺序不能乱，因为服务端用同样的顺序做校验。buildXSign在归一化字符串末尾追加一个salt，再做MD5摘要。salt是写死在JS里的常量或者动态生成的变量，这是逆向的关键点——算法好分析，salt难找。参数说明：method是POST或GET，path是接口路径不含域名，query和body必须保持和实际请求完全一致，ts来自x-t字段。实际线上的x-s比这个复杂，可能包含长度前缀、多维数组参与、自定义编码，但整体思路就是「归一化 + 摘要」。
如果你在JS里找不到明显的crypto调用，别急着怀疑方向。签名逻辑可能不在主包里，而是通过动态加载的chunk文件拉下来的，或者干脆在WebWorker里跑的。用开发者工具的Network面板按JS类型筛选，看哪个文件是在发送请求前一刻才加载的，重点跟进。另一个可靠做法是直接hook浏览器内置函数，把btoa、Array.from、字符串拼接处的调用栈打出来，看签名前的原始串长什么样。
3. 用Frida到运行时里拿现场：hook sign函数与参数
3.1 为什么不用静态分析硬啃：混淆与动态加载
Web端的JS分析到sign函数入口，后面硬啃会遇到瓶颈。线上JS做过分片混淆，函数名全部重命名，字符串常量拆散再拼接，你要是靠肉眼在压缩代码里找salt，会浪费大量时间。这时候更高效的做法是让代码自己把答案说出来——用Frida到运行时里hook。
Frida是跨平台的动态插桩工具，能在进程运行时注入JavaScript脚本，拦截函数调用、读取参数和返回值。对于小红书Web端，hook点在浏览器或WebView的JavaScript引擎里，对于App端，hook点在Java层或Native层。无论哪一层，思路是一样的：找到签名函数在内存里的位置，hook它的入口和出口。静态分析告诉你「大概在哪里」，Frida告诉你「准确在哪里、传了什么值、返回了什么」。
很多人第一反应是Frida只适合App逆向，其实浏览器同样可以。你可以用Frida attach到Chromium进程，hook JavaScript引擎的导出接口，然后拦截crypto.subtle.digest、createHash这类底层调用，看到所有摘要操作的输入输出。签名前的原始字符串一旦被打出来，salt和拼接规则就彻底暴露了。这个方法对Web端和App端都适用，一次学会，两条路都能走。
3.2 一个能跑的Frida脚本：hook签名函数、打印入参与调用栈
下面给一个Frida脚本框架，用于App场景下的签名函数hook。脚本先枚举当前进程已加载的模块，再对目标so导出表里的候选符号做hook。具体符号名需要你根据自己逆向到的真实函数来替换，脚本的价值在于完整演示了「找到函数、打印参数、打印返回值、打印调用栈」四步。
// hook_sign.js - Frida脚本，按实际目标函数名替换 'use strict'; function hookExport(moduleName, exportName) { const mod = Process.findModuleByName(moduleName); if (!mod) { console.log(`[-] module not found: ${moduleName}`); return; } const addr = mod.findExportByName(exportName); if (!addr) { console.log(`[-] export not found: ${exportName}`); return; } Interceptor.attach(addr, { onEnter(args) { this.start = Date.now(); console.log(`[→] ${exportName} onEnter`); // 打印前3个参数的内存内容，具体按函数原型调整 for (let i = 0; i < Math.min(3, args.length); i++) { try { console.log(` arg[${i}] = ${args[i].readUtf8String() || args[i].toString()}`); } catch (e) { console.log(` arg[${i}] = ${args[i].toString()}`); } } }, onLeave(retval) { const cost = Date.now() - this.start; console.log(`[←] ${exportName} onLeave, cost=${cost}ms`); try { console.log(` ret = ${retval.readUtf8String() || retval.toString()}`); } catch (e) { console.log(` ret = ${retval.toString()}`); } // 打印调用栈，用于定位上层调用点 console.log(` stack = ${Thread.backtrace(this.context, Backtracer.ACCURATE) .slice(0, 8) .map(addr => addr.toString()) .join(' <- ')}`); } }); } // 替换成你实际定位到的模块名和导出函数名 hookExport('libxxsign.so', 'sign_xs');逻辑说明：Process.findModuleByName按模块名拿到动态库基址，findExportByName找到导出函数的地址，Interceptor.attach在这个地址上挂了两个回调。onEnter在函数被调用前触发，把前三个参数的原始内容打印出来，如果是字符串就显示字符串内容，不是字符串就显示指针地址。onLeave在函数返回后触发，打印返回值和本次调用的耗时。调用栈用Thread.backtrace抓取，能找到是谁调用了这个签名函数，顺着调用栈反向查就能定位到上层Java或JS逻辑。
参数说明：moduleName和exportName是你要替换的两个变量，实际逆向时先用Process.enumerateModules()把所有已加载模块列出来，再对可疑的so文件逐个findExportByName试探。如果目标函数不是导出函数而是内部函数，findExportByName会找不到，这时需要用Module.enumerateSymbols()看所有符号，或者用内存特征码搜索找到函数地址。不管哪种方式，找到了函数地址，剩下的hook逻辑都一样。
跑这个脚本的时候，注意一个小细节：args.length在onEnter里拿的是系统调用约定的参数个数，不是C函数声明里的参数个数。实际打印时按函数原型调整循环上限，别盲目全打。另一个细节是readUtf8String()只对指向合法字符串的指针有效，读到非字符串内存会抛异常，所以外面套了try-catch，失败就退回打印指针值。这样脚本不会因为一个参数解析失败就崩掉。
4. 把x-s搬进Node.js：本地复现签名的最小实现
4.1 算法判断与参数表：先确认摘要类型和参与字段
Frida拿到签名函数的输入输出之后，下一步是判断摘要算法。判断方法很简单：你手里有一组输入和一个输出。把输入按各种可能的方式拼接，分别尝试MD5、SHA1、SHA256、HMAC-MD5、HMAC-SHA256，看哪个算出来的结果和线上x-s一致。不需要猜，写个小脚本穷举就行。
参与字段的判断同样靠穷举法。先把候选字段列表列出来：method、path、query、body、x-t、user-agent、cookie、x-s-common的前半段。然后逐个尝试组合，用已知的x-s做对照，比对一致就说明这个字段确实参与了签名。字段顺序的确认方法是固定其他字段，只交换两个字段的位置看摘要是否变化，摘要变了就说明顺序有影响。这套方法比起读混淆代码要快得多，也是我推荐所有做签名逆向的人优先采用的路径。
把确认结果整理成一张参数表，方便后续写代码时对照：
| 参数字段 | 是否参与签名 | 取值来源 | 注意点 |
|---|---|---|---|
| method | 是 | 请求方法大写 | 转小写会导致签名不一致 |
| path | 是 | 不含域名的接口路径 | 带不带query要实测确认 |
| query | 视接口而定 | URL问号后的参数 | 字段顺序变化会影响签名 |
| body | 视接口而定 | 原始请求体字符串 | JSON字段顺序必须稳定 |
| x-t | 是 | 毫秒级时间戳 | 与请求头x-t取值必须一致 |
| salt | 是 | 常量或动态生成 | 通常藏在JS或so的只读数据区 |
参数说明：method和path几乎必然参与签名，这是最容易验证的，换一个接口路径x-s就变。query和body是否参与要看具体子系统，有的接口GET请求签名不含query，有的包含。x-t一定要和请求头发出的值完全相同，差一个毫秒都不行，本地复现时先固定一个x-t值再验证，别用当前时间反复试。salt是唯一的未知常量，找到它整个签名就破了。
4.2 本地签名实现：直接可跑的Node模块
确认算法是MD5还是HMAC之后，就能写本地实现。下面是一个完整可跑的Node模块，用配置文件管理算法和字段组合。这份代码按「可配置」思路写，你确认完自己的签名规则后，只改config对象就能用。
// local_sign.js - 本地复现x-s签名 const crypto = require('crypto'); // 算法和参与字段按实际逆向结果配置 const config = { algorithm: 'md5', // md5 / sha1 / sha256 / hmac-md5 / hmac-sha256 secretKey: 'your_salt', // 从JS或so中提取的salt fields: ['method', 'path', 'query', 'body', 'ts'], // 参与签名的字段及顺序 joinChar: '&', // 拼接分隔符 }; function buildRawString(request) { const parts = []; const fieldMap = { method: request.method, path: request.path, query: request.query || '', body: request.body || '', ts: request.ts, }; for (const f of config.fields) { if (!(f in fieldMap)) { throw new Error(`unknown field: ${f}`); } parts.push(fieldMap[f]); } return parts.join(config.joinChar); } function sign(request) { const raw = buildRawString(request); const data = raw + (config.secretKey || ''); let result; if (config.algorithm.startsWith('hmac-')) { const hashAlgo = config.algorithm.replace('hmac-', ''); result = crypto.createHmac(hashAlgo, config.secretKey).update(data).digest('hex'); } else { result = crypto.createHash(config.algorithm).update(data).digest('hex'); } return { raw, x_s: result }; } // 用一组抓包得到的真实请求做对照验证 const sampleRequest = { method: 'GET', path: '/api/notes/feed', query: '', body: '', ts: '1735000000000', }; const output = sign(sampleRequest); console.log('raw string:', output.raw); console.log('local x-s :', output.x_s); console.log('expected : 目标x-s值（替换成线上抓到的）'); console.log('match :', output.x_s === '目标x-s值');逻辑说明：buildRawString按配置的fields数组顺序取出请求字段，拼接成原始字符串。sign函数在原始串末尾追加salt，再按配置的算法做摘要。Hmac系列走createHmac，普通摘要走createHash，两种路径都覆盖。最后一段是验证样例，把线上抓到的x-s填进expected位置，跑一次就知道本地实现对不对。
参数说明：fields数组的顺序必须和实际签名顺序完全一致，第一次验证时先固定这个数组，不要频繁调整。joinChar常见是&，也可能遇到空字符或逗号，用已知样本盲测确认。secretKey就是salt，如果摘要算法是md5且salt为空字符串，则data等于raw本身。跑验证时用固定的ts值，不要用Date.now()，否则每次输出都不同，没法对照。
验证通过之后，sign()函数就成为本地签名引擎。后续接入自己的请求逻辑时，注意每次都重新计算x-s，不要缓存复用。x-t取当前毫秒时间戳，x-s用同一时刻的ts计算，两者保持同步。如果你在一个循环里发很多请求，每次循环都要重新取时间、重新签名，不能把第一次的结果拿来重复用。
5. 逆向x-s的五个常见坑：现象、原因与解决办法
5.1 本地签名对不上：原始字符串拼接顺序错了
现象：算法、salt、字段都确认无误，但本地算出的x-s和线上抓到的值完全对不上。
原因：字段拼接顺序有误。你以为的顺序是method、path、body、ts，实际上线里的顺序可能是path、method、ts、body。拼接顺序只要错一位，摘要值就完全不同，而且没有任何提示告诉你错在哪。
解决：把线上抓到的那组请求入参和x-s输出固定下来，写一个排列组合脚本，对fields数组做全排列，逐个比对摘要结果。字段数量在5个左右时全排列有120种，瞬间能跑完。如果所有排列都对不上，再检查拼接分隔符是否错误，把joinChar也加入穷举范围。
5.2 本地算出x-s，提交后返回-1：时间戳被服务端复验
现象：本地签名算法没问题，用固定ts验证能对上，但真正发请求时还是被拒，返回码带-1或者提示签名过期。
原因：服务端除了验x-s的值，还会验x-t的时效性。你本地用固定时间戳算签名，请求发出时用的是另一个时间戳，两个x-t不一致。或者你用了同一个x-t和对应的x-s重放请求，但服务端只允许某个时间窗口内的签名，窗口过期后直接拒绝。
解决：请求发出前一刻再取ts值，用这个ts同时生成x-t和x-s。x-t放进请求头，x-s用同一个ts计算，保证两者指向同一时刻。重放旧请求时，除了改x-s也要同步更新x-t，否则会被时效校验打回。这个坑是所有做采集的人踩得最多的，回头检查一下自己的代码是不是把ts写成了常量。
5.3 换了个接口就签名失败：path参与了签名但你没带上
现象：同一个签名引擎，访问A接口稳定通过，访问B接口必失败，且B接口的path和A接口结构差别很大。
原因：path是签名输入的一部分。你如果只在本地实现里写死了第一个接口的path，换接口时path没更新，算出来的x-s自然对不上。这在用代码模板做多接口采集时特别容易犯。
解决：把path作为sign()函数的入参，而不是写死在函数内部。每次发请求前，从当前请求对象里取真实的path传入签名计算。同时确认path是否包含问号后的参数，有的接口把query也拼在path后面，有的分开传，实际测试确定你那个接口属于哪种。
5.4 body字段顺序抖动导致签名不稳定：JSON.stringify的字段排序陷阱
现象：本地签名偶尔成功偶尔失败，抓包看请求体都一样，但x-s值每次都变，服务端时好时坏。
原因：请求体是JSON对象时，JSON.stringify会按对象键的插入顺序输出，不同语言、不同运行环境对字段顺序的处理可能不同。同一个body，字段顺序调整后字符串变了，签名自然变了。如果服务端按你的body重建签名时字段顺序和你不同，就会校验失败。
解决：先把body解析成对象，再按ASCII码顺序或固定顺序重新序列化。比如在Node里写一个稳定序列化函数，递归处理嵌套对象，确保每次输出字段顺序一致。种做法同样适用于query参数，URLSearchParams的拼接顺序在两端不同也会导致类似问题。
5.5 静态搜索找不到salt：字符串被拆分或加密存放
现象：签名函数逻辑都分析清楚了，唯独salt找不到。在JS里搜索salt相关的英文关键词没有结果，在二进制里搜hex字符串也搜不到。
原因：salt不是明文写死的，可能被拆成多个字符串片段在运行时拼接，或者经过一层编码后存放，甚至可能在首次启动时从服务端下发再缓存在本地。静态搜索当然找不到。
解决：用Frida hook摘要函数，直接在运行时看原始字符串。crypto.subtle.digest、md5、createHash这些函数的入参就是最终参与摘要的字符串，salt已经拼在里面了。从输出逆推，把已知字段部分去掉，剩下的就是salt。这个方法能绕开所有混淆，因为无论salt怎么藏，它最终都要落到呼摘要函数的内存里。
6. 用AB对照脚本验证签名闭环：一个收尾的硬通货
整个逆向过程做完，最后一步是建立可重复的验证闭环。我习惯把「线上抓到的x-s」和「本地算出的x-s」放进同一个脚本里做AB对照，这一步能确认所有参数配置正确，也能在后续代码改动后快速回归。下面是一个简单的验证脚本，把第4章的sign函数复用进来，从文件读入样本数据，批量比对。
node verify_xsign.js samples.json// verify_xsign.js - 批量AB对照 const fs = require('fs'); const { sign } = require('./local_sign'); const samples = JSON.parse(fs.readFileSync(process.argv[2], 'utf8')); let pass = 0; let fail = 0; for (const s of samples) { const result = sign(s.request); const ok = result.x_s === s.expected_x_s; console.log(`${ok ? 'PASS' : 'FAIL'} path=${s.request.path}`); if (!ok) { console.log(' raw :', result.raw); console.log(' expected:', s.expected_x_s); console.log(' actual :', result.x_s); } ok ? pass++ : fail++; } console.log(`total=${samples.length} pass=${pass} fail=${fail}`); process.exit(fail === 0 ? 0 : 1);逻辑说明：从samples.json读取样本列表，每个样本包含一组模拟请求和线上抓到的预期x-s。逐条调用本地sign函数计算x-s，再和期望值比对。输出PASS或FAIL，FAIL时打印原始拼接串和两个x-s值，便于定位差异。样例数据建议准备10条以上，覆盖GET、POST、带query、带body四种组合。参数说明：samples.json的结构是[{"request": {...}, "expected_x_s": "..."}]，request对象必须包含method、path、query、body、ts五个字段，ts要用线上抓包时的时间戳，不能替换成当前时间。
这个闭环脚本跑通了，x-s逆向就算真正完成。往后改代码、调参数，先跑一遍批量对照，省去线上试错的成本。我的习惯是每次调整字段配置后，把回归脚本连同样本一起提交到代码仓库，样本文件里保留抓包时的原始请求头和x-t值。这样做还有个好处：换电脑、换环境后能快速确认签名引擎是否仍然可用。x-s逆向的最后一个教训是：不要贪多，先锁一组样本，跑通一个接口再扩展，样本越杂，排错越难。希望这篇笔记帮你在x-s参数这条路上少踩几个坑。
本文还有配套的精品资源，点击获取
