前端加密参数分析实战：JS混淆、动态Cookie与5秒盾解密

接手这个“js--5”项目的时候，我一开始也以为是某个流程的第五个版本，结果打开代码一看，整个JavaScript文件被压成几行长字符串，变量名全是_0x开头，函数逻辑绕来绕去。这种项目在热搜词里能关联到“js反爬实战”、“js混淆动态cookie”、“5秒盾返回的js怎么解密”这些词，本质上就是一件事：前端加密参数分析。这篇文章我就把整个处理过程从头到尾梳理一遍，包括怎么建调试环境、怎么定位入口、怎么在断点里还原真实逻辑、以及遇到混淆和反调试时最实用的应对套路。内容偏实战，适合已经会写基础JavaScript、但没怎么碰过混淆代码的人。

1. 接手“js--5”项目的第一件事：把调试环境搭到顺手

先别急着看代码。拿到一个加密参数分析的“js--5”项目，我通常先做三件事：准备好Chromium内核的浏览器、装好切换JavaScript环境的插件（比如Tampermonkey用来跑Hook脚本）、再开一个本地代理抓包工具确认请求参数是在哪个阶段被加进去的。环境不顺，后面每一步都会卡壳。

1.1 确认入口URL和加密参数出现的时机

不管项目代号是“js--5”还是别的什么，第一步永远是打开浏览器开发者工具的Network面板，找到那个带着加密参数的请求。通常一个正常的用户操作（比如提交登录表单）会发出好几个请求，加密参数往往只出现在其中某个请求的Query String或请求体里。

我的习惯是先看这个请求的“Initiator”列。Chrome的DevTools会在这里显示这个请求是由哪个函数的哪一行代码触发的。点击跳转到Sources面板，你就站在了“加密参数被使用的现场”。如果Initiator里全都是(anonymous)或者被压缩成一行的大字符串，说明脚本被压缩或者混淆过，后面就要靠搜索和断点来定位。

确认完请求入口之后，我会给这个请求的关键参数记一个清单，比如参数名是sign、token还是nonce，以及它在Payload里的位置。这个清单在后续全局搜索的时候会非常有用。

1.2 动态脚本和静态脚本的区别：先分清对手

打开Sources面板左侧的文件夹树，“js--5”项目里的脚本通常分成两类：一类是写在HTML里直接加载的静态JS文件，另一类是页面运行到某个时机之后通过appendChild、document.createElement('script')动态注入的脚本，或者直接用eval、Function构造器执行的字符串代码。

动态脚本是新手最容易卡住的地方，因为你在Sources面板里根本看不到这些文件，除非在Network面板勾选“JS”过滤条件找到它们。我的经验是：遇到找不到目标代码的情况，先在Console里执行performance.getEntriesByType('resource')，这里面会列出页面加载期间所有被请求的资源，包括通过脚本动态创建的那些。再配合document.scripts遍历当前页面所有脚本元素，能大概率定位到动态脚本的URL。

动态脚本和静态脚本的处理策略是截然不同的。静态脚本可以直接在文件里搜索关键词，动态脚本则要在执行到注入那一步时用断点截住，然后在Console里解析它的代码内容。我把这些信息整理成一张表贴在自己项目的文档里：

2. 从界面到代码：怎么在几十个JS文件里找到加密函数

环境搭好之后，最考验耐心的环节来了：在几十个甚至上百个JS文件里找到那个真正生成加密参数的函数。这一步没有捷径，但有让搜索范围大幅缩小的技巧。

2.1 精准搜索关键词：先搜参数名，再搜特征变量

“js--5”这个项目里，加密参数名是sign，那我的第一动作就是在Sources面板里按Ctrl+Shift+F全局搜索sign。搜索结果会非常多，所以我会叠加关键词，比如sign:、sign =、sign=、"sign"，一层层过滤。

这里有个很实用的技巧：不要只搜参数名本身，还要搜索参数名被“加工”后的形态。如果全局搜索后结果还是太多，先定位到请求发出去的源头，比如XMLHttpRequest.prototype.send或者fetch的调用位置，在那边打一个条件断点，等请求真正发出时看调用栈。调用栈里自下而上每一层函数名，就等于给你画好了一张“从用户操作到加密参数生成”的地图。

2.2 事件监听器定位法：从“点击按钮”倒推入口函数

如果加密参数是在点击登录按钮之后才生成的，那通过Event Listener来找入口就是最快的方式。在Elements面板里选中那个登录按钮，右侧切到“Event Listeners”页签，展开click事件，里面会列出所有绑定在这个按钮上的处理函数。

勾选“Framework listeners”和“Ancestors”这两个选项可以看到更完整的信息。点击函数名可以直接跳到对应的JavaScript代码行。这里我想特别说明一下：很多项目的加密逻辑并不直接写在按钮的click事件里，而是click事件调用了某个公共函数，再由公共函数去拼接参数。所以从Event Listener定位到的可能只是“入口的第一站”，后面还要继续顺着函数调用关系往深处走。

2.3 一个不算冷门的经验：先搜URL参数名再搜加密函数

搜索参数名有时候会因为名字太常见而失效，比如sign这种字符串，全局搜索能出来几百个结果。我现在的习惯是交换一下顺序：先在Network面板里抓到请求的完整URL，用URL里的路径片段去全局搜索。

比如URL是https://example.com/api/login?sign=xxx，那我在Sources里搜/api/login，而不是搜sign。命中的位置就是构建这个请求URL的代码，紧接着的几行，通常就是加密参数的赋值逻辑。这个搜索策略尤其在压缩代码里面管用，因为URL字符串没法被混淆，而变量名可以随便改。

3. 断点调试实战：从参数生成到参数发送的完整链路

找到疑似代码之后，真正的“手术”才刚刚开始。生成加密参数的过程通常不是一个函数单独完成的，而是一串函数层层调用、相互传参之后的结果。断点调试就是把这条链路的每一步都看清楚。

3.1 在参数赋值的位置打条件断点

明确了加密参数是在哪个函数里被赋值的之后，我在赋值那一行打断点，但不会打普通断点，而是打条件断点。比如变量名是sign，条件可以写成typeof sign !== 'undefined'。这是为了避免断点被脚本初始化阶段那些无关的赋值操作反复命中，直接等“真正有价值的赋值出现”时再停。

停下来之后，我要做三件事：看Scope面板里的局部变量、看Call Stack面板里的调用层级、看Watch面板里自己加的关键变量。很多时候加密参数的生成依赖几个前置变量，这几个前置变量的值从哪来，才是真正要弄清的。

3.2 “读写器断点”在JavaScript调试里的用法

如果赋值语句是a.b.c = d这种属性写入，我会对c这个属性打一个Break on properties modifications类型的断点。Chrome DevTools里叫“Break on”，在Sources面板的Scope变量上右键就能看到。这样只要这个属性被读取或者被修改，脚本就会停下来，能帮我精准定位是哪段代码在“碰”这个属性。

我在实际处理“js--5”项目时经常遇到：加密参数不是一次算完的，而是先赋值到一个对象属性上，后续再被某个加密函数读取。如果只盯着赋值语句，永远看不到“读取”这个环节。属性断点能同时覆盖读和写两种情况，是还原完整数据流的利器。

3.3 关键时机的处理：断点被清掉怎么办

有时候断点刚设置好，重新刷新页面就失效了。这不一定是你操作失误，而是页面有可能在运行时动态修改了脚本内容。此时我通常使用debugger;语句代替DevTools断点，在目标代码附近手动插入一行debugger;。页面执行到这行时会自动暂停，哪怕脚本被动态执行也能截住。

还有一类情况是页面里内置了debugger;检测，一旦检测到开发者工具打开，就用无限debugger死循环卡住页面。“js--5”项目正好也遇到了这类代码。处理思路有两种：一是把debugger;语句替换成空语句或者一段空白函数，二是用“Never pause here”功能右键点击那个断点位置告诉调试器不要在这里暂停。具体操作是在DevTools里右键点击出现黄色高亮的行号，选择“Never pause here”即可。

4. 解密“5秒盾返回的JS”：从混淆代码里还原真实逻辑

“js--5”项目里有一段让我印象深刻的代码，类似热搜词里提到的“5秒盾返回的js”。这种代码的特点是：服务器返回的不是数据，而是一段JavaScript，这段JS动态计算出一个cookie或者token，然后通过document.cookie写入浏览器，下次请求才会被放行。

4.1 认识三类常见的混淆手段

“js--5”项目里的混淆不算特别复杂，但已经是典型的商业级混淆了。我拆开来看，常见的套路无非三大类。

“js--5”项目里这三种都齐了。变量名全是_0x3f2a这种十六进制乱码；字符串被存进一个大数组，用偏移量去取；执行逻辑被包进一个巨大的while加switch循环，每执行一个case就切换state。面对这种代码，单纯靠人眼逐行读是不现实的。

4.2 用工具做初步还原，再用断点验证

我处理这种代码的流程分为三步。第一步，把混淆后的JS整体复制到本地文件，用格式化工具把压缩的一行代码展开成多行，让函数边界和语句块边界清晰可见。第二步，用替换脚本把_0x开头的变量名批量替换成v1、v2这类可读名字，这一步不需要特别智能，只是让代码在调试器里看起来不那么费眼。第三步，也是最关键的，不要试图在静态文本里“读懂”整个算法，而是直接在浏览器里跑起来，在关键取值语句上打断点看实际值。

以“5秒盾返回的JS”为例，它的最终目的是设置一个cookie。那我就在document.cookie的赋值语句上打断点，停住之后看右侧的表达式值，确认它到底是基于什么算出来的，然后继续往上追它的输入。这样做的好处是：即使你不完全明白整个状态机的每个case，也能把“输入-输出”关系摸出来。

4.3 逐步还原一个常见的动态Cookie生成过程

这里我用“js--5”项目里遇到过的一个简化案例来说明怎么操作。假设返回的JS里有这么一段：

javascript复制var _0x4b2c = ['\x64\x6f\x6d\x61\x69\x6e', '\x63\x6f\x6f\x6b\x69\x65'];
var _0x2f1a = function(_0x3a2b) {
    return _0x4b2c[_0x3a2b];
};
var _0x5e7c = _0x2f1a(0) + '=' + _0x3a2b;
document[_0x2f1a(1)] = _0x5e7c;

这里_0x4b2c是个字符串数组，_0x2f1a(0)取的是domain，_0x2f1a(1)取的是cookie。但静态看容易被_0x前缀唬住。我的做法是直接在Console里手动模拟执行：

javascript复制var _0x4b2c = ['\x64\x6f\x6d\x61\x69\x6e', '\x63\x6f\x6f\x6b\x69\x65'];
var _0x2f1a = function(_0x3a2b) {
    return _0x4b2c[_0x3a2b];
};
console.log(_0x2f1a(0)); // domain
console.log(_0x2f1a(1)); // cookie

一跑就明白了：所谓“解密”根本不是密码学里的解密，而是把字符串从数组中取出来。这也就是为什么我一直强调“跑起来比静态读快”的原因。很多混淆只是制造了阅读障碍，并没有真正改变算法。

5. 绕过“debugger无限循环”和“检测篡改”的反调试手段

处理到这一步，“js--5”项目的核心加密逻辑已经能看明白了。但还剩下两道坎：第一道是反调试代码，第二道是如果我想在脚本里插入Hook代码，怎么绕过完整性校验。

5.1 两种最常见的反调试写法及绕过方案

第一种是无限debugger。代码里写一个递归或不含条件的debugger;语句，在开发者工具打开时就会不断触发断点暂停。绕过办法是在DevTools的Sources面板里右键点击那个断点位置，从菜单里选择“Never pause here”，这样即使代码执行到debugger;也会被跳过。

第二种是检测代码是否被修改。比如代码里有一段函数：

javascript复制function check() {
    var _0x1234 = arguments.callee.toString();
    if (_0x1234.indexOf('hook') !== -1) {
        throw new Error('tampered');
    }
}

这段代码检查函数自身被序列化后的字符串里是否包含了某个关键字。如果你在Hook脚本里重写了这个函数，它一运行就抛异常。绕过办法是在重写前先把原函数的源码取出来分析，调整Hook方式，让检测函数看到的源码和原来的一致。

5.2 在正确时机注入Hook：从启动时机说起

Hook的本质是在目标函数执行之前或之后，插入一段自己的逻辑。但“js--5”项目里，很多函数是从混淆代码里动态生成的，启动时机不好掌控。我常用的方案是借助Object.defineProperty来Hook对象属性，或者修改原型链上的方法。

比如我想监控所有cookie赋值操作，可以在document的cookie属性上做文章，用Object.defineProperty重写setter：

javascript复制Object.defineProperty(document, 'cookie', {
    get: function() {
        return document.cookie;
    },
    set: function(val) {
        console.log('[Hook] cookie set:', val);
        // 这里可以加自己的逻辑
    }
});

这个Hook代码要放在页面脚本执行之前。可以用一个小书签脚本，也可以直接用Tampermonkey等在页面加载早期执行的插件。Hook完之后，再次触发那个5秒盾流程，就能在Console里看到每次cookie被写入的值，以及触发写入时的调用栈。

5.3 用“非入侵式”思路代替修改原文件

我最早做这类分析时，习惯直接改原文件里的代码，结果经常因为完整性校验而卡住。后来换了个思路：不修改原文件，而是用代理替换脚本文件的方式，在文件层面做重定向，这样原文件代码不受影响，校验的是原文件的话就能通过。

更稳妥的做法是，在代码中寻找明确的“扩展点”。比如项目里经常会有全局配置对象，里面有回调函数、随机数生成器之类的接口。我不修改主流程，只是在回调里追加日志输出。这种非入侵式方式虽然不能覆盖所有场景，但能覆盖大部分需要“看数据流”的场景，而且风险低很多。

6. 当代码里出现“chameleon”这类加密函数时，怎么拆解

前面说到的内容还比较通用，实际处理“js--5”项目时，我遇到了热搜词里提到的chameleon这个函数名。这类函数名一看就是自研的加密函数，很多情况下它不是一个单纯的加密，而是把参数拼接、加密、编码几个步骤混在了一起。遇到这种函数，我会单独为它写一个“拆解文档”。

6.1 拆分输入和输出，画出数据流而不是流程图

拆解自研函数最忌讳一上来就逐行翻译代码，因为很容易陷入细节无法自拔。我的做法是先确定输入有哪些，输出是什么，然后在console.log里把每个关键步骤的输出打出来。

chameleon这个函数在“js--5”项目里接收三个参数：一个字符串、一个时间戳、一个随机数。输出是一个64位长度的字符串。那我就先确认：三个参数中，哪些参与了字符串拼接，哪些参与加密运算，哪些只是用来增加随机性。把输入参数的值和对应的输出值记录下来，多记录几组，用对比的方式找出规律，比任何静态分析都高效。

6.2 二进制转十六进制、Base64、变种Base64这些高频编码

自研加密函数里最常见的处理是编码转换。你可能在代码里看到charCodeAt、toString(16)、fromCharCode，或者看到某个字符串被转成Base64。识别这些编码的目的不是“解密”，而是“还原数据组织形式”。

“js--5”项目里的chameleon就有一段逻辑：把字符串转成UTF-8字节数组，再逐字节做异或运算，最后用Base64编码输出。我识别出来之后，直接在本地写一个等价的JavaScript函数来复现这个过程。这样做的意义在于：即使原网站的加密逻辑变了，我也能通过对比新旧输出的差异快速定位变化点。

6.3 还原算法时的“最小复现”困境

直接把一个上百行、嵌套多层调用的函数搬到本地跑，通常不会一次成功。我的做法是先做最小复现：只把涉及输出的关键几行搬出来，用一个样例输入测试输出，和原网站的正式输出对比。如果结果一致，再把其他细节慢慢补回去。

如果最小复现的输出一直对不上，常见原因有三个：一是输入参数没有取全，比如漏了一个环境变量；二是输入顺序错了，比如参数A和B在传参时交换了位置；三是编码格式不一致，比如源字符串是UTF-8编码，你在本地还原时用了charCodeAt直接取码位，结果不同。逐个排查这三个原因，能解决九成以上的对不上问题。

7. 处理“js--5”项目时的几个常见误区和我的应对习惯

这块内容不是教科书上的知识点，而是我在反复处理这类加密参数项目时总结出来的实操经验。很多东西看起来简单，实际踩坑之后才明白原因。

7.1 误区一：试图完全读懂每一行混淆代码

新手常有的想法是：只要我把代码逐行弄懂，就一定能还原整个算法。但混淆代码本身就是用来增加阅读成本的，逐行读会让人心态崩溃。我现在的原则是“以目标为导向”：如果目标是拿到加密参数，那就只需要知道哪个输入对应哪个输出，不需要理解中间每个状态机的case的完整转义逻辑。

7.2 误区二：忽略浏览器环境与Node.js环境差异

有时候在浏览器里跑通的还原代码，搬到Node.js就出错。常见原因包括：浏览器里有window、document等全局对象，Node.js里没有；或者某些随机数生成依赖浏览器的crypto.getRandomValues，Node.js用的是crypto.randomBytes。

我处理“js--5”项目时遇到过一次极其隐蔽的问题：代码里用Date.now()作为种子生成随机数，但浏览器和服务器的系统时间有偏差，导致本地复现时随机数对不上。排查了半天才发现是这个原因。后来我在还原代码时，会尽量保留原始运行环境，比如直接在浏览器Console里执行还原脚本，而不是急着把代码搬到Node.js。

7.3 误区三：只想解密，忽略了“复现”才是核心目标

看到“解密”这个词，很多人会联想到破解甚至逆向整个系统。但从技术工作角度看，我们的核心目标应该是“复现”对方的前端计算流程，而不是攻击、破解任何后台服务。正确、合法、合规的做法，是把你分析出来的算法用于自己的学习、测试、性能分析，或者在自己拥有授权的项目中参考设计。了解前端加密的常见套路，可以帮助你更好地设计自己的应用，而不是去突破别人的防线。

7.4 我的几个固定操作习惯

第一，每次全局搜索前，先明确搜索词的精准度。搜sign不如搜/api/login，搜/api/login不如搜请求URL里那段不易重复的路径。搜索词越具体，结果越少，越省时间。

第二，每到一个关键断点，先在Console里执行一遍Object.keys(globalThis)和Object.getOwnPropertyNames(window)，看看页面上挂载了哪些全局对象和自定义变量。有些加密函数会挂载在全局对象上，直接找到它们能省下大量找代码的时间。

第三，本地建一个“样本库”文件夹。每处理一个加密参数，就把请求的URL、加密参数名、加密算法的特征、以及最终还原出的关键代码记录到一个独立的Markdown文件里。日积月累，你会发现很多所谓的“新算法”无非是旧算法的组合变体，有样本库在手，处理速度会快很多。

8. 一个完整的“js--5”项目实操记录：从抓包到复现

前面讲了这么多方法和技巧，最后我用一个简化版的实际案例，把整个流程串起来。这个案例的流程我在多个“js--5”类似项目里反复走，已经形成了肌肉记忆。

8.1 场景：带“js--5”代号的页面，登录时要提交加密参数

我给这个案例命名为“js--5”，因为它确实来自我处理过的一个内部编号为5的JavaScript逆向项目。它的页面是一个普通的登录框，输入用户名和密码后点登录，Network面板里能看到一个POST /api/auth/login的请求，Payload里除了username和password，还有一个_sign参数，看起来是一串32位长度的十六进制字符串。

我随手在Console里看了一下Object.keys(window)，发现一个可疑的全局对象_0x5f3a。展开看，里面有一堆函数，其中一个叫generateSign，名字太直白了。我直接在Console里调用_0x5f3a.generateSign('test', '123456')，居然真的返回了一串32位十六进制，正好是_sign的长度。

8.2 断点定位：找到generateSign内部的步骤

虽然我直接调通了，但为了确认它是不是真的被请求调用，我在generateSign函数内部加了一行debugger;，然后在页面上重新登录。断点触发后，我看Call Stack，发现调用链路是：onClick → _0x5f3a.buildRequest → _0x5f3a.generateSign。这证实了_sign确实是由这个函数生成的。

在generateSign内部，我看到核心代码大概是：

javascript复制var _0x2f1a = Date.now();
var _0x3b2c = _0x5f3a.md5(username + password + _0x2f1a);
var _0x4d3e = _0x5f3a.hexEncode(_0x3b2c);

简单来说，它就是md5(用户名+密码+时间戳)，再转十六进制。这里完全没有复杂的AES、RSA，但加上全局对象名混淆和字符串数组取值的包装，看起来就像很厉害的样子。

8.3 本地复现：把关键逻辑搬到自己的脚本

我把这段逻辑搬到本地Node.js脚本里，用crypto模块的createHash('md5')复现：

javascript复制const crypto = require('crypto');

function generateSign(username, password, timestamp) {
    const raw = username + password + timestamp;
    const hash = crypto.createHash('md5').update(raw).digest('hex');
    return hash;
}

console.log(generateSign('test', '123456', Date.now()));

用浏览器里拿到的同一个输入输出对比，结果完全一致。到这里，“js--5”的加密参数分析就基本完成了。剩下的问题，比如不同账号、不同时间戳的生成规则，也顺着这个框架继续测了一遍，全部通过。

8.4 复现成功后，别忘了反向验证

我遇到很多人在本地跑通一次就认为万事大吉，结果过段时间发现算法变了。正确做法是：在本地脚本里留好输入输出的日志，定期和线上请求的参数值做对比。一旦发现不一致，说明对方前端逻辑有调整，此时再用同样的断点方案重新分析一次，更新脚本。

9. 我的几个固定防坑清单（处理加密参数项目必看）

做了这么多次JavaScript加密参数分析，我总结了一个防坑清单，每次开工前都会快速过一遍。

9.1 环境检测相关的坑

• 确认页面是否检测了webdriver属性，如果检测到了，很多自动化的手段会失效，需要在浏览器设置或启动参数上做对应修改。
• 确认代码是否依赖了languages、plugins等浏览器指纹信息，有些加密参数会把这些环境值当作盐值参与计算。
• 确认代码是否检测了debugger状态，检测方式包括无限debugger、日志输出异常、页面崩溃等，提前在DevTools里设置好“Never pause here”。

9.2 数据格式相关的坑

• 字符串拼接时要注意大小写。MD5和Base64的输出对大小写敏感，很多参数生成结果对不上，就是因为源字符串大小写不对。
• 时间戳有的是毫秒，有的是秒。Date.now()返回毫秒，Math.floor(Date.now() / 1000)才是秒。每次转换前先看原代码里对时间戳做了什么操作。
• 编码格式要统一。代码里如果做了encodeURIComponent，你在本地也要同样处理，否则中文字符和特殊字符会得到不同的字节序列。

9.3 流程复现相关的坑

• 调用栈里看到的函数名，可能和实际执行的函数名不一致，因为代码可能对函数名也做了映射。我们要以实际断点命中的位置为准。
• 加密参数可能依赖多个模块的输出，比如一个模块生成token，另一个模块把token做二次加密。不要只盯着最后一个加密函数，要把前面的模块输出都打印出来。
• 如果页面里有多个请求，别忽略请求的先后顺序。有些加密参数依赖前面的请求返回的某个值，比如上一个请求返回的sessionID会被当成参数加进来。这时候你需要先让前面的请求正常完成，才能复现后面的算法。

提示：处理“js--5”这类项目时，最关键的心态是“别怕”。混淆和反调试只是增加了阅读成本，算法的本质往往就是一个哈希、一个编码拼接、一个简单的数学运算。把环境搭好、入口找准、断点打好、数据流看清楚，大多数项目都能在两三个小时内读完核心逻辑。

最后再分享一个我处理这类项目的小习惯：每完成一个“js--5”类似项目，我会在项目文件夹里放一个README.md，记录这次用到的URL、参数名、混淆类型、反调试手段、核心算法摘要，以及本地复现脚本的路径。下次再遇到同类项目，直接翻开这个文件看，能节省至少一半的前期排查时间。这个习惯坚持了大半年，回头再看，真的帮我省下了无数重复踩坑的时间。