1. 先搞清楚X-Bogus到底是个什么东西聊抖音 X-Bogus 加密解析之前得先把一个误会掰正很多人一上来就问用什么解密好像它是某种和 AES、RSA 同一类的加密算法拿到密钥就能还原明文。实际做过一轮的人都知道它压根不是拿来加密内容的它是一段挂在请求参数上的签名串。也就是说它对原始数据不做任何保密处理它的作用只有一个——让服务端相信这个请求确实是从正常客户端发出来的中间没有被篡改。我最早接触这块是因为一个很朴素的场景手上有一批自己账号下的作品要备份一个个点下载太反人类就想着写个脚本批量拉一下列表。结果第一次跑就发现URL 参数、cookie、header 全都对得上返回依然是空的或者提示参数错误。把浏览器里成功的那条请求原封不动复制出来重放又能通。唯一的差别就是 URL 尾巴上多了个X-BogusDFSzswV...这样的 28 位字符串。这个字符串就是关卡。它的生成有几个特点值得先建立认知。第一它是一次性的跟时间戳强绑定你五分钟前算出来的那串五分钟后再发大概率就废了。第二它是跟请求内容绑定的URL、query 参数、可能还包括 UA 和前端的某些环境值改动任何一个字符签名就对不上。第三它是前端本地算出来的服务端只做校验不做下发所以你没有接口拿签名这种偷懒路径只能把生成逻辑搬到自己的环境里。这三个特点决定了后面所有工作的方向。你要做的不是破解一个加密而是把一段跑在浏览器里的 JS 逻辑完整地、稳定地移植到 Node 里并且保证每次输入输出都跟浏览器一致。本质上这是一次代码移植 环境模拟的活儿跟密码学关系不大。注意本文讨论的是前端签名机制的技术原理与通用逆向方法论目标是理解前端工程中的请求校验设计思路。任何涉及他人隐私数据、账号数据批量获取的行为都不在讨论范围内实操请严格限定在自己有权限的数据上进行。1.1 为什么它被叫做加密而不是签名命名这事在圈子里一直挺乱。因为前端那坨代码是被混淆过的变量名全是_0x1a2b这种字符串被塞进数组里读起来像是加密。再加上参数值本身是一串看不出规律的字符外行一看就觉得是密文。于是抖音 X-Bogus 加密解析这个说法就传开了。但从工程角度看标准的签名流程是把参与校验的若干字段按约定顺序拼成一个字符串过一个哈希或摘要函数最后做一次编码。这个过程没有密钥交换没有可逆性要求输出长度固定输入稍微一变输出就雪崩。X-Bogus 完全符合这个特征。它更像 HMAC 那套思路的简化变体。理解这一点很重要因为它直接决定了你的调试方式。如果真是加密你需要找密钥、找算法、找填充模式而如果是签名你只需要做到一件事同样的输入在你的环境里算出来的字符串跟浏览器里算出来的一模一样。这就把问题从逆向密码学降维成了对齐计算过程难度和可验证性都友好得多。1.2 参数在整条链路里的位置从请求结构上看一个典型的列表请求大致是这样组织的路径带上device_platform、aid、version_code这类固定参数业务参数里带分页游标、数量限制等然后才是X-Bogus和另一个常被一起提到的参数。服务端拿到请求后会用自己的那份逻辑重算一遍比对通过才继续走业务。这里有个很关键的推论参与签名的字段是有限的、确定的。不会把整个 body 都塞进去也不会引入随机因子否则服务端没法复现。所以只要你能把参与计算的输入项找全算法本身反而是最容易复现的部分。绝大多数人卡住不是因为算法看不懂而是因为漏了一两个隐藏输入项——比如某个从 cookie 里读的值、某个从window上取的属性、某个被缓存在闭包里的时间偏移量。我自己的经验是逆向的八成时间花在找全输入项两成时间花在还原计算逻辑。新手往往反过来盯着那坨混淆代码死磕结果算法抄完了跑出来还是不对因为少喂了一个参数。2. 动手前把环境和工具备齐工欲善其事这话虽然老套但在 JS 逆向里格外真实。工具没配好你会发现自己在重复做很多机械劳动效率低到怀疑人生。这一节把我常用的配置列一遍顺便说说每个工具到底解决什么问题。2.1 浏览器侧的准备工作首选还是基于 Chromium 内核的浏览器开发者工具的功能最全Sources 面板的调试体验也最成熟。装好之后有几件事一定要先做。第一打开 DevTools 的Settings把Sources里的Enable JavaScript source maps关掉同时把Ignore list里那些第三方库的过滤规则清一清。很多混淆代码会被误判为库文件在调用栈里直接折叠成一行(anonymous)找入口的时候非常难受。第二装一个代码美化插件或者直接用 DevTools 自带的{}格式化按钮。注意格式化只影响你看到的排版不影响实际执行断点位置会跟着映射不用担心打错地方。但对于那种把整个文件压成一行、几万字符的脚本格式化是必须的第一步。第三打开Network面板勾上Preserve log然后把请求过滤设成Fetch/XHR。接下来刷新页面触发一次目标请求右键那条记录选Copy as cURL先存一份原始样本。这份样本后面是你的标准答案每次改完代码都拿它对比能省下大量猜测时间。2.2 断点与调用栈回溯的分工DevTools 的断点有好几种用途差别很大混着用容易乱。我把常用的几类列在下面断点类型触发条件典型用途行断点执行到指定行已知算法位置逐步跟进XHR/Fetch 断点匹配 URL 片段时中断从请求发起点反查调用栈事件监听断点指定 DOM 事件触发找按钮点击后的处理链条件断点表达式为真时中断在循环里精确定位某次调用全局断点任意脚本执行前中断处理动态加载、脚本注入场景最常用的是 XHR 断点配合调用栈。你在 Network 里看到请求地址的固定片段比如/aweme/v1/web/就在Sources面板右侧的XHR/fetch Breakpoints里加上这个片段。刷新页面请求发出前会停下来此时右侧Call Stack里那一串就是你需要的路径。从最内层往外点找到第一个看起来像是业务代码的帧。2.3 Node 侧的依赖清单Node 版本建议用 LTS不要贪新。有些混淆代码里用了较新的语法特性跑在过老的版本上会直接语法报错而报错信息又指向被混淆的位置很难读。我一般固定在 LTS 的偶数版本上。需要的包不多通常这几样就够# 基础的 HTTP 客户端用于验证签名后的请求 npm i axios # 一个轻量的 JS 沙箱用来跑扣出来的代码 npm i vm2 # 如果需要模拟 DOM 环境 npm i jsdom # 本地起个代理观察流量仅用于调试自己的请求 npm i http-proxyvm2这个包要注意它本身的安全模型有过多次讨论用在自己的调试环境里没问题但别拿它去跑来路不明的代码。我在本地习惯直接用 Node 原生的vm模块虽然隔离能力弱一些但调试体验更直接报错栈更清晰。提示不要一上来就想着全自动。先把浏览器里那条能通的请求手工跑通一遍把每个参数的来源标清楚再动手写代码。跳过这一步的人后面会在到底是算法错了还是参数漏了这个问题上耗掉好几天。3. 找到签名入口的三条路定位入口是整个流程里最关键的一步。入口找对了后面是体力活入口找错了后面是玄学。我常用的有三条路径各有适用场景实际做的时候往往是三条配合着走。3.1 全局搜索与关键词变形最直接的办法是在Sources面板里全局搜X-Bogus。但混淆代码里这个字符串往往不会以明文出现它可能被拆成X-Bog us也可能被塞进一个字符串数组运行时通过下标索引取出来。所以搜的时候要多试几种变体单独搜Bogus、搜X-Bog、搜a_bogus、搜拼接后的常量片段。更有效的一招是搜赋值动作。签名最终要挂到请求参数上那么代码里一定存在类似xxx[X-Bogus] yyy或者params.push(X-Bogus n)的写法。如果混淆器把属性名也处理了那就换个思路搜那些大概率不会被混淆的东西device_platform、aid、msToken这类参数名。找到拼接逻辑往上游追一两层签名变量就浮出来了。3.2 XHR 断点回溯调用栈这条路我觉得最稳。设好断点后请求中断看调用栈。关键技巧是逐层往上看找到第一个非混淆的边界。具体怎么判断混淆代码的调用栈通常表现为帧名是(anonymous)或者是一串无意义的短标识符位置都在同一个文件里行号挨得很近。而正常的业务代码或者框架代码帧名会有意义位置分散在不同文件中。当你发现某一帧的路径指向一个体积很大、命名像是 SDK 的文件时那基本就是签名的生成位置了。在那一帧上点一下Sources 会跳到对应代码。这时候先别急着读先在函数入口打个断点重新触发请求然后单步跟一遍观察参数是怎么一步步被加工成最终那串字符的。跟着走一遍比读十遍代码有用。3.3 脚本注入与 Hook 打法有些场景下断点不好用比如代码是被动态注入的或者签名函数在一个 worker 里跑。这时候可以从数据流下手做函数 Hook。// 拦截 JSON.stringify观察哪些对象在被序列化进签名 (function () { const raw JSON.stringify; JSON.stringify function (value, ...rest) { const out raw.call(this, value, ...rest); if (out out.length 50) { console.log([stringify], out.slice(0, 200)); console.trace(); } return out; }; })();上面这段是通用的改一改就能用来 HookencodeURIComponent、String.prototype.slice、Array.prototype.join。Hook 的价值在于它不挑代码位置只要数据经过这个通用方法你就能看到。签名算法里几乎必然要用到字符串拼接和编码Hook 这几个点能快速圈定计算区间。定位方式上手难度适用场景主要坑点全局关键词搜索低混淆程度一般、字符串未完全打散关键词变形导致搜不到XHR 断点回溯中绝大多数常规请求调用栈被 ignore list 折叠函数 Hook中高动态注入、worker 场景Hook 过多导致日志爆炸三条路我一般按这个顺序走先搜关键词搜不到就设 XHR 断点还不行才上 Hook。因为前两条路对代码的侵入性最低不容易把原本能跑的页面搞崩。4. 把混淆代码拆成能读的逻辑找到入口之后眼前通常是一坨让人头皮发麻的东西。别慌混淆再花哨套路就那么几种认出来之后就是按图索骥。4.1 混淆的三种常见形态字符串数组化是最常见的一种。所有字面量字符串被抽出来放在一个大数组里代码里原来的X-Bogus变成了_0x4f2a(0x1c3)而_0x4f2a是个取数组元素的函数参数是下标。更进一步的做法是把这个数组做一次轮转——用一个偏移量函数把数组顺序打乱运行时先自执行一次还原。对付这种最省事的办法不是人肉还原而是在运行时把还原后的结果 dump 出来。你在取字符串的函数上下个断点或者直接 Hook 它把所有调用过的返回值打印一遍映射表就出来了。控制流平坦化是第二种也是让人最头疼的。正常的if/else被改成了一个大的switch加一个状态变量代码执行顺序跟你从上往下读的顺序完全不一样。识别特征是函数体开头有个var _0x3b2c 1然后一个while(true)里套着巨大的switch(_0x3b2c)。破解思路是先不管顺序把每个case分支单独拎出来看搞清楚每个分支在做什么最后再根据状态变量的赋值关系把流程图拼回去。这个过程可以借助一些反混淆工具做辅助但最终还是要自己核对一遍。死代码与不透明谓词是第三种。作者会插入大量永远不会执行的分支条件写成if (_0x1a 0x3f7) {...}这种而_0x1a的实际取值范围根本到不了。还有垃圾函数、无用变量互相引用。处理办法是先把明显用不到的部分整块删掉跑一遍报错就说明删多了再加回来。这种减法调试比逐行读快得多。4.2 关键运算链的还原签名算法的核心计算部分通常可以拆成这么几个阶段输入收集把 URL 路径、query 字符串、时间戳、UA 等拼成一个原始串。预处理可能做一些字符替换、大小写处理、截断。摘要计算过一套自定义的位运算或者哈希产出一个中间值。编码输出把字节序列映射成可见字符集得到最终的 28 位字符串。第 3 步是看不懂的重灾区。里面会有一堆、、^、的组合还有查表操作。我的建议是不要试图理解它的数学含义那没意义。你要做的是原样搬运。位运算在这个场景下是确定性计算同样的输入永远得到同样的输出你只要保证运算符优先级、类型转换特别是 0这种无符号转换都搬对了就行。搬运的时候有个细节特别容易出错JS 里和对超范围数字的处理跟直觉不一样。混淆器经常用 0来做无符号转换如果你手抄的时候漏了一个结果就全错。我的做法是抄完一段就立刻做单元测试——在浏览器里给这段函数喂一组固定输入记下输出然后在 Node 里跑同样的输入比对结果。逐段验证别攒到最后一起测。4.3 环境依赖项识别这是最隐蔽的一环。签名函数里往往藏着几个从运行环境取值的地方比如navigator.userAgent—— 很可能参与计算而且不同浏览器值不同。window.performance.now()或者Date.now()—— 时间因子必参与。document.cookie里的某个值 —— 有时会作为附加输入。screen.width/screen.height—— 有些实现会用到。某个被缓存的全局对象属性 —— 首次计算后写回后续复用。识别办法很土但有效在断点停住的时候把右侧Scope面板展开一级一级看闭包和外层作用域里都有什么变量。重点看那些值为字符串或数字、且在算法里被读取过的。另外控制台里直接敲window.xxx试探也很快。我在实际项目里踩过一个坑算法里用了一个从 canvas 指纹派生的值。当时我以为是随机数怎么复现都对不上。后来发现那个值在同一台设备上是稳定的本质是环境指纹。这类依赖项你没法猜出来只能在断点里逐个看作用域变量把取值范围确认清楚。5. Node.js 复现与补环境实战代码看懂了接下来是把浏览器里的逻辑搬到 Node 里跑。这一步的核心矛盾是浏览器有现成的window、document、navigatorNode 什么都没有。5.1 扣代码的粒度选择搬运粒度有两种极端。一种是整文件搬把那个几万行的 SDK 文件整个复制到 Node 里然后在外面模拟一个完整的浏览器环境。另一种是只扣关键函数精确定位到生成签名的那个函数把它和它依赖的几个辅助函数摘出来。我现在的做法是先粗后细。第一轮用整文件搬先跑通确认逻辑无误第二轮再逐步裁剪把用不到的部分删掉。理由很简单一开始就精细裁剪很容易漏掉某个间接依赖而且报错信息被混淆过排查成本极高。整文件搬虽然丑但它能跑通跑通之后你就有了一个可靠的参照物。裁剪的时候删一段跑一次保持每次只删一小块。当代码从几万行瘦到几百行冷启动时间会明显下降这对后面的性能优化很重要。5.2 常见环境缺失与补齐套路跑起来之后你会遇到一连串的ReferenceError和类型错误。下面是几个必补项// 最小化的环境模拟按需增减 const sandbox { navigator: { userAgent: 固定的 UA 字符串, platform: Win32, languages: [zh-CN, zh], }, location: { href: https://目标页面地址/, protocol: https:, host: 目标域名, }, document: { cookie: , referrer: , createElement() { // 有些实现会用到 canvas 指纹需要给一个可用对象 return { getContext: () null }; }, }, screen: { width: 1920, height: 1080 }, Date, Math, JSON, parseInt, parseFloat, decodeURIComponent, encodeURIComponent, atob: (s) Buffer.from(s, base64).toString(binary), btoa: (s) Buffer.from(s, binary).toString(base64), }; sandbox.window sandbox; sandbox.self sandbox; sandbox.globalThis sandbox;几个要点。window、self、globalThis三者要指向同一个对象很多混淆代码会同时用这三个引用来判断环境。atob和btoa在 Node 里没有全局版本较新版本有了但行为细节可能不同最好自己实现一份保证与浏览器一致。document.createElement经常在指纹采集里被调用如果直接给undefined会在某个深层调用里报错报错位置还很难定位索性先给个桩。注意不要为了让代码不报错就无脑 return null 或者 return 空对象。有些依赖项如果返回了不合理值代码不会报错但会走进另一条分支算出来的签名是错的。表现为跑得通但验证不过这比直接报错更难查。正确做法是先在浏览器断点里看清真实的取值再照着填。5.3 一致性校验怎么做才靠谱校验只有一个标准同一组输入Node 输出的字符串必须和浏览器输出的逐字符相同。具体操作上我习惯在浏览器里把签名函数的输入和输出都打印出来用一组固定输入固定时间戳、固定 URL记录下来。然后 Node 里跑同样的输入比对输出。不一致就二分查找把算法从中间切开上半段单独测看中间值是否一致逐步缩小范围。有个小技巧如果中间值的比对结果总是差一点点比如前几位一样后面不一样那多半是某个输入项的长度或者编码方式不同比如多了个空格、少了次 URL 编码。如果完全不一样那可能是漏了某个关键输入或者某个位运算写错了。这两种症状的排查方向完全不同先判断症状再动手。