1. 拆解“JS逆向解析”到底在解决什么问题1.1 从一次真实需求说起去年帮一个做数据聚合的朋友处理过一个需求他们需要定期从某个公开的行业信息平台上抓取一批商品价格数据用于内部比价分析。听起来很简单对吧但实际动手才发现对方页面上显示的价格数字在HTML源码里根本找不到——你右键查看源代码看到的是一堆加密过的字符串或者干脆就是一个空壳。打开浏览器开发者工具Elements面板里明明能看到价格但Network面板里返回的响应体却是乱码。这就是典型的前端JavaScript动态渲染参数加密场景。页面上的数据不是服务端直接吐出来的而是浏览器拿到一段加密数据后通过JavaScript在本地解密、拼接、再渲染到DOM上的。你想拿到数据要么模拟浏览器的完整执行流程要么把那段加密逻辑逆向出来自己用代码实现一遍。这就是“JS逆向解析”要解决的问题。它不是一个具体的工具或框架而是一类技术手段的统称通过分析前端JavaScript代码理解其加密、混淆、编码逻辑最终在非浏览器环境中复现数据获取或接口调用的过程。1.2 谁需要掌握这项技能我把接触过的人群大致分了三类第一类是数据采集方向的开发者。他们需要从公开网页获取结构化数据但目标站点有前端加密或动态渲染普通的HTTP请求库拿不到完整数据。这类人需要理解JS逆向的基本流程能定位关键函数并移植到Python或Node.js中。第二类是安全测试方向的从业者。他们在做授权范围内的安全评估时需要分析前端代码中是否存在敏感信息泄露、加密逻辑缺陷、或者可被绕过的验证机制。JS逆向是他们日常工作的一部分。第三类是前端开发方向的工程师。他们可能出于技术好奇心想了解自己写的代码在别人眼里长什么样或者想学习常见的混淆手段来保护自己的业务逻辑。不管你是哪一类核心能力要求是一样的能看懂JavaScript代码能用开发者工具定位关键逻辑能把浏览器里的执行过程在本地复现出来。1.3 技术栈与工具选型工欲善其事必先利其器。我把自己常用的工具列一下都是免费且跨平台的工具用途推荐理由Chrome DevTools代码调试、断点追踪、调用栈分析功能最全Sources面板的断点功能无可替代Node.js本地复现JS逻辑语法一致可以直接跑浏览器里的代码Python requests最终的数据请求与处理生态成熟配合execjs可以调用JSFiddler / Charles抓包分析请求响应看请求头、Cookie、参数结构VS Code代码编辑与整理轻量插件丰富调试Node.js方便提示不要一上来就想着用自动化工具去“一键解密”。绝大多数有价值的逆向工作都需要你手动分析代码逻辑。工具只是辅助核心还是你的分析能力。选Node.js作为本地复现环境理由很简单浏览器里跑的JS放到Node.js里基本能直接跑语法层面没有障碍。Python虽然也能通过execjs调用JS但调试体验差很多适合最终集成阶段用。分析阶段我强烈建议在Node.js里跑通逻辑再移植到Python。2. 核心细节解析从混淆代码到可读逻辑2.1 定位关键代码的三种手段拿到一个目标站点第一步永远是找到那段负责加密或解密的代码在哪里。我常用的方法有三种按效率从高到低排列方法一XHR断点法。打开DevTools的Sources面板在右侧找到XHR/Fetch Breakpoints添加目标接口的URL关键词。刷新页面当浏览器发起该请求时代码会自动断在发起请求的位置。然后看Call Stack调用栈一层层往上翻就能找到参数是在哪里被加密的。这是最精准的方法适合接口参数加密的场景。方法二事件监听断点法。如果数据是通过点击按钮触发的可以在Elements面板找到那个按钮右键选择“Break on” - “Attribute modifications”或者“Subtree modifications”。当按钮被点击、DOM发生变化时代码会断下来。然后同样看调用栈往上追溯加密逻辑。方法三全局搜索法。在Sources面板按CtrlShiftF全局搜索关键词比如encrypt、sign、token、password、md5、aes等。如果代码没有经过太严重的混淆这些关键词能直接帮你定位到关键函数。如果搜不到就搜一些更通用的词比如function、return然后人工筛选。实操心得我一般先用方法三快速扫一遍如果代码混淆不严重几分钟就能定位。如果搜不到再用方法一。方法二用得比较少因为很多站点的数据加载是自动触发的不需要点击。2.2 读懂混淆代码的四个切入点定位到关键函数后你看到的代码大概率长这样var _0x4f2a [\x70\x61\x72\x73\x65, \x6c\x65\x6e\x67\x74\x68, ...]; function _0x3b1c(_0x5a2d) { return _0x4f2a[_0x5a2d]; } var result _0x3b1c(0x0) _0x3b1c(0x1);这就是最基础的数组映射混淆。变量名被替换成无意义的十六进制字符串被拆成数组通过索引访问。面对这种代码不要一行行去读效率太低。我的做法是切入点一找入口和出口。不管代码怎么混淆它总要有输入和输出。输入通常是某个参数比如时间戳、用户ID、明文密码输出是加密后的字符串。找到函数的参数和返回值你就知道这段代码在干什么了。切入点二还原字符串数组。把那个大数组复制出来在Node.js里跑一遍看看每个索引对应的真实字符串是什么。很多混淆只是把字符串藏起来了逻辑本身没变。切入点三跟踪函数调用链。从入口函数开始看它调用了哪些函数每个函数又调用了谁。用DevTools的Step Into功能一步步跟把调用链画出来。通常核心加密逻辑就在这条链的某个节点上。切入点四识别标准算法特征。很多加密用的是标准算法比如MD5、AES、RSA、Base64。这些算法在代码里会有明显的特征比如MD5会有0123456789abcdef这样的常量AES会有S盒和轮常量。识别出算法类型后你甚至不需要完全读懂代码直接用现成的库实现即可。2.3 常见加密与编码方式的识别我把常见的加密编码方式及其特征整理成表方便你快速判断类型典型特征处理方式Base64字符串以结尾字符集为A-Za-z0-9/直接解码无需密钥MD532位十六进制字符串代码中有0123456789abcdef常量不可逆只能用于验证SHA系列40位或64位十六进制字符串不可逆用于签名AES代码中有S盒、轮常量密钥长度16/24/32字节需要密钥和IV可逆RSA代码中有大数运算公钥以-----BEGIN PUBLIC KEY-----开头需要公钥或私钥自定义编码字符映射表、异或运算、位移操作需要逐行分析逻辑注意遇到自定义编码不要慌。绝大多数自定义编码的逻辑都很简单无非是字符替换、异或、位移的组合。你只要找到映射关系用代码复现一遍就行。2.4 参数签名的常见套路很多接口会对请求参数做签名防止篡改。常见的签名逻辑是把所有参数按key排序拼接成字符串加上一个盐值然后做MD5或SHA1。比如function sign(params) { var keys Object.keys(params).sort(); var str ; for (var i 0; i keys.length; i) { str keys[i] params[keys[i]] ; } str salt SECRET; return md5(str); }这种逻辑在代码里通常表现为sort、join、、md5这几个操作的组合。你只要找到SECRET这个盐值就能在本地复现签名。有些站点会把盐值藏在代码深处或者动态生成。动态生成的盐值通常来自另一个接口或者由时间戳、随机数经过某种运算得到。遇到这种情况你需要把盐值的生成逻辑也逆向出来。3. 实操过程从零复现一个加密接口的完整流程3.1 目标分析与信息收集假设我们要处理一个模拟项目某公开信息平台有一个列表接口返回的数据是加密的请求参数中有一个sign字段。我们的目标是拿到解密后的数据。第一步打开DevTools的Network面板找到那个接口请求。记录以下信息请求URL和请求方法请求头中的关键字段Cookie、User-Agent、Referer等请求参数的结构特别是sign字段的值响应体的结构确认是否加密第二步在Sources面板全局搜索sign找到生成签名的函数。如果搜不到就在Network面板右键该请求选择“Replay XHR”然后在Sources面板的XHR断点中拦截。第三步断下来之后看Call Stack找到调用链。通常你会看到类似这样的结构(anonymous) - request - sign - md5点击sign函数查看它的源码。如果代码被混淆了按2.2节的方法还原。3.2 关键函数的提取与本地复现假设我们找到了签名函数代码经过简单混淆后长这样function _0x2a1b(_0x3c4d) { var _0x5e6f Object[keys](_0x3c4d)[sort](); var _0x7a8b ; for (var _0x9c0d 0; _0x9c0d _0x5e6f[length]; _0x9c0d) { _0x7a8b _0x5e6f[_0x9c0d] _0x3c4d[_0x5e6f[_0x9c0d]] ; } _0x7a8b key _0x1b2c3d; return _0x4e5f6a(_0x7a8b); }其中_0x1b2c3d是盐值_0x4e5f6a是MD5函数。我们需要做的是找到_0x1b2c3d的值。在DevTools的Console里直接输入_0x1b2c3d回车就能看到它的真实值。找到_0x4e5f6a的实现。如果它是标准MD5直接用Node.js的crypto模块替代。把整个函数复制到Node.js里替换掉混淆的变量名补上缺失的依赖。整理后的代码const crypto require(crypto); function md5(str) { return crypto.createHash(md5).update(str).digest(hex); } function sign(params) { const keys Object.keys(params).sort(); let str ; for (let i 0; i keys.length; i) { str keys[i] params[keys[i]] ; } str key SECRET; return md5(str); }在Node.js里跑一遍对比浏览器里生成的sign值如果一致说明复现成功。3.3 响应解密的处理请求参数搞定后接下来处理响应解密。假设响应体是这样的{ data: U2FsdGVkX1abc123..., status: 200 }data字段是加密的。我们需要找到解密函数。同样用全局搜索搜decrypt、decode、AES等关键词。找到后把解密逻辑提取出来。假设解密逻辑是AESfunction decrypt(data) { const key CryptoJS.enc.Utf8.parse(1234567890abcdef); const iv CryptoJS.enc.Utf8.parse(abcdef1234567890); const decrypted CryptoJS.AES.decrypt(data, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return decrypted.toString(CryptoJS.enc.Utf8); }在Node.js里用crypto-js库复现npm install crypto-jsconst CryptoJS require(crypto-js); function decrypt(data) { const key CryptoJS.enc.Utf8.parse(1234567890abcdef); const iv CryptoJS.enc.Utf8.parse(abcdef1234567890); const decrypted CryptoJS.AES.decrypt(data, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return decrypted.toString(CryptoJS.enc.Utf8); }跑一遍看能否解出明文。如果报错检查key和iv的编码方式是否正确mode和padding是否匹配。3.4 完整请求链路的组装把签名和解密都跑通后就可以组装完整的请求链路了。用Python的requests库发起请求import requests import hashlib import time import json from Crypto.Cipher import AES from Crypto.Util.Padding import unpad import base64 SECRET your_secret_here def sign(params): keys sorted(params.keys()) str_to_sign for k in keys: str_to_sign f{k}{params[k]} str_to_sign fkey{SECRET} return hashlib.md5(str_to_sign.encode()).hexdigest() def decrypt(data): key b1234567890abcdef iv babcdef1234567890 cipher AES.new(key, AES.MODE_CBC, iv) decrypted cipher.decrypt(base64.b64decode(data)) return unpad(decrypted, AES.block_size).decode() params { page: 1, size: 20, timestamp: int(time.time() * 1000) } params[sign] sign(params) headers { User-Agent: Mozilla/5.0 ..., Referer: https://example.com/, Cookie: sessionid... } resp requests.get(https://example.com/api/list, paramsparams, headersheaders) result resp.json() if result[status] 200: data json.loads(decrypt(result[data])) print(data)实操心得时间戳参数要注意单位。有些站点用秒有些用毫秒。签名时用的时间戳和请求时传的时间戳必须一致否则签名验证会失败。我踩过这个坑排查了半天才发现是单位问题。3.5 验证与调试组装完成后不要急着跑大批量请求。先用单次请求验证对比本地生成的sign和浏览器里生成的sign是否一致。检查请求头是否完整特别是Cookie和Referer。看响应状态码和响应体确认解密是否成功。如果失败用DevTools的Console面板手动执行一遍签名函数对比结果。调试阶段最常见的错误是参数顺序不一致。签名时参数按key排序但请求时参数顺序可能不同。有些站点对参数顺序敏感有些则无所谓。如果签名验证失败先检查参数排序逻辑。4. 常见问题与排查技巧实录4.1 签名验证失败的排查思路签名验证失败是最常见的问题原因通常有以下几种问题现象可能原因排查方法返回403或签名错误盐值不对在Console里打印盐值变量确认是否动态变化签名值长度不对算法不匹配确认是MD5、SHA1还是其他算法签名值一致但请求失败参数编码问题检查参数是否经过URL编码空格是否转义时间戳相关错误时间戳单位或时区问题对比浏览器和本地的时间戳值Cookie失效会话过期重新获取Cookie检查是否有其他验证字段我遇到过一个比较坑的情况签名函数里用到了encodeURIComponent但我在Python里没有做同样的编码导致签名值不一致。后来在拼接字符串之前对每个参数值都做了urllib.parse.quote处理问题解决。4.2 代码混淆的应对策略如果代码混淆程度很高比如变量名全是随机字符串、控制流被扁平化、字符串被加密存储手动分析会非常耗时。这时候可以考虑以下策略策略一使用AST还原工具。比如babel配合自定义插件可以把混淆的代码还原成可读性较高的形式。但这需要一定的学习成本适合长期做逆向工作的人。策略二动态调试代替静态分析。不要试图读懂每一行代码而是在关键位置下断点观察变量的实际值。比如在加密函数的入口和出口下断点看输入和输出是什么中间过程可以忽略。策略三Hook关键函数。用DevTools的Console面板重写某些函数比如JSON.stringify、encodeURIComponent、XMLHttpRequest.prototype.send打印它们的调用参数。这样可以在不读代码的情况下知道数据经过了哪些处理。// Hook JSON.stringify var originalStringify JSON.stringify; JSON.stringify function(obj) { console.log(JSON.stringify called with:, obj); return originalStringify(obj); };策略四补环境。有些代码会检测运行环境比如检查window、document、navigator是否存在。在Node.js里跑的时候需要把这些全局对象补上。可以用jsdom库模拟浏览器环境或者手动定义缺失的变量。4.3 反调试机制的绕过有些站点会加入反调试机制比如检测开发者工具是否打开、检测代码是否被格式化、检测函数是否被Hook。常见的反调试手段和绕过方法手段一debugger死循环。代码里写一个setInterval(() { debugger; }, 100)让你无法正常调试。绕过方法在DevTools的Sources面板右键选择“Never pause here”或者在Console里重写setInterval。手段二检测console.log。重写console.log如果发现被调用就跳转到错误页面。绕过方法在页面加载前用DevTools的Console重写console.log为空函数。手段三检测函数toString。检查关键函数的toString结果是否包含native code判断是否被Hook。绕过方法重写Function.prototype.toString返回原始字符串。注意反调试机制的绕过涉及与目标站点的对抗仅限在授权范围内进行安全测试或学习研究。不要用于非法用途。4.4 性能优化与稳定性保障当逆向逻辑跑通后如果要做大批量请求还需要考虑性能和稳定性优化一复用Session。用requests.Session()保持会话避免每次请求都重新建立连接和协商Cookie。优化二控制请求频率。加time.sleep()随机延迟模拟人类操作节奏。频率过高容易触发风控。优化三异常重试。对网络超时、签名失败等情况做重试但不要无限重试设置最大重试次数。优化四日志记录。记录每次请求的参数、响应状态、耗时方便排查问题。import requests import time import random from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session requests.Session() retry Retry(total3, backoff_factor0.5, status_forcelist[500, 502, 503, 504]) session.mount(https://, HTTPAdapter(max_retriesretry)) for page in range(1, 101): try: params build_params(page) resp session.get(API_URL, paramsparams, headersheaders, timeout10) if resp.status_code 200: process(resp.json()) time.sleep(random.uniform(1, 3)) except Exception as e: print(fPage {page} failed: {e})4.5 常见问题速查表问题排查方向解决方案请求返回403请求头缺失或Cookie过期补全User-Agent、Referer、Cookie签名验证失败盐值、算法、参数顺序逐项对比浏览器和本地的签名过程响应解密乱码key、iv、mode、padding不匹配确认加密参数检查编码方式Node.js报错window is not defined缺少浏览器环境用jsdom补环境或手动定义全局变量代码混淆无法阅读混淆程度高用AST工具还原或动态调试代替静态分析反调试导致无法断点存在反调试机制重写关键函数绕过检测请求频率过高被封触发风控降低频率加随机延迟使用代理池提示代理池的选择要注意合规性仅使用合法合规的网络资源。5. 工具链与效率提升的实战建议5.1 本地调试环境的搭建我习惯在VS Code里建一个专门的逆向工作目录结构如下js-reverse/ ├── src/ │ ├── sign.js # 签名函数 │ ├── decrypt.js # 解密函数 │ └── utils.js # 工具函数 ├── test/ │ ├── test-sign.js # 签名测试 │ └── test-decrypt.js # 解密测试 ├── output/ │ └── data.json # 输出数据 ├── package.json └── README.md在package.json里配置调试脚本{ scripts: { test-sign: node test/test-sign.js, test-decrypt: node test/test-decrypt.js } }这样每次修改代码后直接npm run test-sign就能验证签名逻辑是否正确不用每次都去浏览器里对比。5.2 浏览器与Node.js的联调技巧有时候签名逻辑依赖浏览器的某些特性比如window.btoa、document.cookie等。在Node.js里跑的时候需要把这些补上。我的做法是写一个browser-env.js在测试文件开头引入// browser-env.js global.window global; global.document { cookie: sessionidabc123 }; global.navigator { userAgent: Mozilla/5.0 ... }; global.btoa function(str) { return Buffer.from(str, binary).toString(base64); }; global.atob function(str) { return Buffer.from(str, base64).toString(binary); };然后在测试文件里require(./browser-env); const { sign } require(../src/sign); console.log(sign({ page: 1, size: 20 }));这样就能在Node.js里模拟浏览器环境跑通依赖浏览器API的代码。5.3 代码版本管理与复用逆向出来的代码要妥善管理因为目标站点可能会更新加密逻辑。我的做法是每个站点建一个独立的目录目录名用站点域名或项目代号。代码里注明逆向日期和对应的站点版本。把关键的加密参数盐值、key、iv单独放在一个配置文件里方便更新。写一个简单的监控脚本定期检查签名是否仍然有效失效时发通知。// config.js module.exports { secret: abc123, aesKey: 1234567890abcdef, aesIv: abcdef1234567890, lastUpdated: 2025-01-15 };这样当站点更新时只需要修改配置文件不用动核心逻辑。5.4 学习路径与进阶方向如果你刚接触JS逆向我建议按以下路径学习第一阶段基础语法。确保你能读懂JavaScript的基本语法包括函数、对象、数组、闭包、原型链。推荐在MDN上过一遍核心概念。第二阶段DevTools熟练使用。重点掌握Sources面板的断点、调用栈、作用域查看功能。这是逆向工作的核心工具。第三阶段常见算法识别。把MD5、SHA、AES、RSA、Base64这几种算法的代码特征记住看到能认出来。第四阶段实战练习。找一些公开的、无风险的练习站点比如一些提供API测试的网站尝试逆向它们的签名逻辑。第五阶段进阶工具。学习AST操作、补环境框架、自动化Hook工具。这些能大幅提升效率但需要一定的编程基础。实操心得不要一开始就追求“万能工具”。我见过太多人花大量时间找自动化工具结果连最基本的断点调试都不熟练。工具是锦上添花核心能力还是手动分析。5.5 合规与风险提示最后必须强调一点JS逆向技术本身是中性的但使用场景有明确的边界。在授权范围内进行安全测试、学习研究、或者采集公开数据都是合理的。但以下行为绝对不要碰绕过付费墙获取本应付费的内容破解他人系统的身份验证机制大规模抓取非公开的个人隐私数据对目标站点造成服务压力或破坏我在实际操作中始终坚持一个原则只处理公开的、无需登录即可访问的数据且控制请求频率不影响目标站点的正常服务。如果目标站点有明确的反爬声明或服务条款禁止数据采集我会选择放弃寻找其他合规的数据来源。技术能力越强越要知道边界在哪里。这不是限制而是保护自己。6. 从逆向到防御理解前端安全的另一面6.1 常见前端防护手段的局限性做逆向久了自然会思考一个问题如果我是前端开发者怎么保护自己的接口不被轻易逆向我试过几种常见的防护手段说下实际效果。手段一代码混淆。把变量名替换成随机字符串把字符串拆成数组把控制流扁平化。这确实能提高逆向的门槛但无法从根本上阻止。有经验的逆向人员配合AST工具还原混淆代码只是时间问题。而且过度混淆会影响代码的可维护性和性能得不偿失。手段二动态密钥。每次请求前从服务端获取一个临时密钥用于签名或加密。这能增加逆向的难度因为密钥是动态的。但逆向人员可以通过Hook获取密钥的接口或者直接在内存中读取密钥值。防护效果有限。手段三环境检测。检测开发者工具是否打开、检测代码是否被格式化、检测函数是否被Hook。这些手段能挡住一部分新手但对有经验的人来说绕过只是多花几分钟的事。手段四WebAssembly。把核心逻辑编译成WASM增加逆向难度。这确实有效因为WASM是二进制格式反编译成本高。但WASM也有调试工具而且会增加包体积和加载时间。我的看法前端代码运行在用户的浏览器里用户拥有完全的控制权。任何前端防护都只能提高门槛无法做到绝对安全。真正的安全应该放在服务端接口鉴权、频率限制、行为分析、风控策略。前端防护只是第一道防线不是最后一道。6.2 服务端风控的常见策略从防御角度看服务端能做的前端做不了的事情很多请求频率限制同一IP或同一账号在单位时间内的请求次数超过阈值就拒绝。行为分析分析请求的时间间隔、参数规律、User-Agent一致性识别机器行为。参数校验服务端重新计算签名不信任前端传来的任何参数。Token机制每次请求携带一次性Token用完即废防止重放攻击。设备指纹收集浏览器指纹信息识别异常设备。这些策略的组合使用能大幅提高数据采集的成本。但也要注意平衡过于严格的风控会影响正常用户的体验。6.3 对开发者的实用建议如果你是一名前端开发者想保护自己的接口我的建议是不要把敏感逻辑放在前端。任何加密密钥、核心算法只要在前端出现就有可能被逆向出来。把这些逻辑放到服务端。使用标准的加密算法。不要自己发明加密算法标准算法的安全性经过了充分验证。做好服务端校验。前端传来的所有参数都要在服务端重新校验不要信任任何前端数据。合理使用混淆。适度混淆可以增加逆向成本但不要过度以免影响性能和可维护性。监控异常请求。记录请求日志分析异常模式及时发现和应对数据采集行为。如果你是一名逆向学习者我的建议是尊重目标站点的服务条款。如果站点明确禁止数据采集不要强行突破。控制请求频率。不要对目标站点造成服务压力。仅用于学习和研究。不要将逆向技术用于非法用途。持续学习。前端技术在不断演进逆向技术也需要不断更新。我在实际项目中最大的体会是逆向和防御是一体两面的。你越了解逆向的手段就越知道该怎么防御你越了解防御的策略就越知道逆向的突破口在哪里。这种双向的理解才是真正的核心竞争力。
1. 拆解“JS逆向解析”到底在解决什么问题1.1 从一次真实需求说起去年帮一个做数据聚合的朋友处理过一个需求他们需要定期从某个公开的行业信息平台上抓取一批商品价格数据用于内部比价分析。听起来很简单对吧但实际动手才发现对方页面上显示的价格数字在HTML源码里根本找不到——你右键查看源代码看到的是一堆加密过的字符串或者干脆就是一个空壳。打开浏览器开发者工具Elements面板里明明能看到价格但Network面板里返回的响应体却是乱码。这就是典型的前端JavaScript动态渲染参数加密场景。页面上的数据不是服务端直接吐出来的而是浏览器拿到一段加密数据后通过JavaScript在本地解密、拼接、再渲染到DOM上的。你想拿到数据要么模拟浏览器的完整执行流程要么把那段加密逻辑逆向出来自己用代码实现一遍。这就是“JS逆向解析”要解决的问题。它不是一个具体的工具或框架而是一类技术手段的统称通过分析前端JavaScript代码理解其加密、混淆、编码逻辑最终在非浏览器环境中复现数据获取或接口调用的过程。1.2 谁需要掌握这项技能我把接触过的人群大致分了三类第一类是数据采集方向的开发者。他们需要从公开网页获取结构化数据但目标站点有前端加密或动态渲染普通的HTTP请求库拿不到完整数据。这类人需要理解JS逆向的基本流程能定位关键函数并移植到Python或Node.js中。第二类是安全测试方向的从业者。他们在做授权范围内的安全评估时需要分析前端代码中是否存在敏感信息泄露、加密逻辑缺陷、或者可被绕过的验证机制。JS逆向是他们日常工作的一部分。第三类是前端开发方向的工程师。他们可能出于技术好奇心想了解自己写的代码在别人眼里长什么样或者想学习常见的混淆手段来保护自己的业务逻辑。不管你是哪一类核心能力要求是一样的能看懂JavaScript代码能用开发者工具定位关键逻辑能把浏览器里的执行过程在本地复现出来。1.3 技术栈与工具选型工欲善其事必先利其器。我把自己常用的工具列一下都是免费且跨平台的工具用途推荐理由Chrome DevTools代码调试、断点追踪、调用栈分析功能最全Sources面板的断点功能无可替代Node.js本地复现JS逻辑语法一致可以直接跑浏览器里的代码Python requests最终的数据请求与处理生态成熟配合execjs可以调用JSFiddler / Charles抓包分析请求响应看请求头、Cookie、参数结构VS Code代码编辑与整理轻量插件丰富调试Node.js方便提示不要一上来就想着用自动化工具去“一键解密”。绝大多数有价值的逆向工作都需要你手动分析代码逻辑。工具只是辅助核心还是你的分析能力。选Node.js作为本地复现环境理由很简单浏览器里跑的JS放到Node.js里基本能直接跑语法层面没有障碍。Python虽然也能通过execjs调用JS但调试体验差很多适合最终集成阶段用。分析阶段我强烈建议在Node.js里跑通逻辑再移植到Python。2. 核心细节解析从混淆代码到可读逻辑2.1 定位关键代码的三种手段拿到一个目标站点第一步永远是找到那段负责加密或解密的代码在哪里。我常用的方法有三种按效率从高到低排列方法一XHR断点法。打开DevTools的Sources面板在右侧找到XHR/Fetch Breakpoints添加目标接口的URL关键词。刷新页面当浏览器发起该请求时代码会自动断在发起请求的位置。然后看Call Stack调用栈一层层往上翻就能找到参数是在哪里被加密的。这是最精准的方法适合接口参数加密的场景。方法二事件监听断点法。如果数据是通过点击按钮触发的可以在Elements面板找到那个按钮右键选择“Break on” - “Attribute modifications”或者“Subtree modifications”。当按钮被点击、DOM发生变化时代码会断下来。然后同样看调用栈往上追溯加密逻辑。方法三全局搜索法。在Sources面板按CtrlShiftF全局搜索关键词比如encrypt、sign、token、password、md5、aes等。如果代码没有经过太严重的混淆这些关键词能直接帮你定位到关键函数。如果搜不到就搜一些更通用的词比如function、return然后人工筛选。实操心得我一般先用方法三快速扫一遍如果代码混淆不严重几分钟就能定位。如果搜不到再用方法一。方法二用得比较少因为很多站点的数据加载是自动触发的不需要点击。2.2 读懂混淆代码的四个切入点定位到关键函数后你看到的代码大概率长这样var _0x4f2a [\x70\x61\x72\x73\x65, \x6c\x65\x6e\x67\x74\x68, ...]; function _0x3b1c(_0x5a2d) { return _0x4f2a[_0x5a2d]; } var result _0x3b1c(0x0) _0x3b1c(0x1);这就是最基础的数组映射混淆。变量名被替换成无意义的十六进制字符串被拆成数组通过索引访问。面对这种代码不要一行行去读效率太低。我的做法是切入点一找入口和出口。不管代码怎么混淆它总要有输入和输出。输入通常是某个参数比如时间戳、用户ID、明文密码输出是加密后的字符串。找到函数的参数和返回值你就知道这段代码在干什么了。切入点二还原字符串数组。把那个大数组复制出来在Node.js里跑一遍看看每个索引对应的真实字符串是什么。很多混淆只是把字符串藏起来了逻辑本身没变。切入点三跟踪函数调用链。从入口函数开始看它调用了哪些函数每个函数又调用了谁。用DevTools的Step Into功能一步步跟把调用链画出来。通常核心加密逻辑就在这条链的某个节点上。切入点四识别标准算法特征。很多加密用的是标准算法比如MD5、AES、RSA、Base64。这些算法在代码里会有明显的特征比如MD5会有0123456789abcdef这样的常量AES会有S盒和轮常量。识别出算法类型后你甚至不需要完全读懂代码直接用现成的库实现即可。2.3 常见加密与编码方式的识别我把常见的加密编码方式及其特征整理成表方便你快速判断类型典型特征处理方式Base64字符串以结尾字符集为A-Za-z0-9/直接解码无需密钥MD532位十六进制字符串代码中有0123456789abcdef常量不可逆只能用于验证SHA系列40位或64位十六进制字符串不可逆用于签名AES代码中有S盒、轮常量密钥长度16/24/32字节需要密钥和IV可逆RSA代码中有大数运算公钥以-----BEGIN PUBLIC KEY-----开头需要公钥或私钥自定义编码字符映射表、异或运算、位移操作需要逐行分析逻辑注意遇到自定义编码不要慌。绝大多数自定义编码的逻辑都很简单无非是字符替换、异或、位移的组合。你只要找到映射关系用代码复现一遍就行。2.4 参数签名的常见套路很多接口会对请求参数做签名防止篡改。常见的签名逻辑是把所有参数按key排序拼接成字符串加上一个盐值然后做MD5或SHA1。比如function sign(params) { var keys Object.keys(params).sort(); var str ; for (var i 0; i keys.length; i) { str keys[i] params[keys[i]] ; } str salt SECRET; return md5(str); }这种逻辑在代码里通常表现为sort、join、、md5这几个操作的组合。你只要找到SECRET这个盐值就能在本地复现签名。有些站点会把盐值藏在代码深处或者动态生成。动态生成的盐值通常来自另一个接口或者由时间戳、随机数经过某种运算得到。遇到这种情况你需要把盐值的生成逻辑也逆向出来。3. 实操过程从零复现一个加密接口的完整流程3.1 目标分析与信息收集假设我们要处理一个模拟项目某公开信息平台有一个列表接口返回的数据是加密的请求参数中有一个sign字段。我们的目标是拿到解密后的数据。第一步打开DevTools的Network面板找到那个接口请求。记录以下信息请求URL和请求方法请求头中的关键字段Cookie、User-Agent、Referer等请求参数的结构特别是sign字段的值响应体的结构确认是否加密第二步在Sources面板全局搜索sign找到生成签名的函数。如果搜不到就在Network面板右键该请求选择“Replay XHR”然后在Sources面板的XHR断点中拦截。第三步断下来之后看Call Stack找到调用链。通常你会看到类似这样的结构(anonymous) - request - sign - md5点击sign函数查看它的源码。如果代码被混淆了按2.2节的方法还原。3.2 关键函数的提取与本地复现假设我们找到了签名函数代码经过简单混淆后长这样function _0x2a1b(_0x3c4d) { var _0x5e6f Object[keys](_0x3c4d)[sort](); var _0x7a8b ; for (var _0x9c0d 0; _0x9c0d _0x5e6f[length]; _0x9c0d) { _0x7a8b _0x5e6f[_0x9c0d] _0x3c4d[_0x5e6f[_0x9c0d]] ; } _0x7a8b key _0x1b2c3d; return _0x4e5f6a(_0x7a8b); }其中_0x1b2c3d是盐值_0x4e5f6a是MD5函数。我们需要做的是找到_0x1b2c3d的值。在DevTools的Console里直接输入_0x1b2c3d回车就能看到它的真实值。找到_0x4e5f6a的实现。如果它是标准MD5直接用Node.js的crypto模块替代。把整个函数复制到Node.js里替换掉混淆的变量名补上缺失的依赖。整理后的代码const crypto require(crypto); function md5(str) { return crypto.createHash(md5).update(str).digest(hex); } function sign(params) { const keys Object.keys(params).sort(); let str ; for (let i 0; i keys.length; i) { str keys[i] params[keys[i]] ; } str key SECRET; return md5(str); }在Node.js里跑一遍对比浏览器里生成的sign值如果一致说明复现成功。3.3 响应解密的处理请求参数搞定后接下来处理响应解密。假设响应体是这样的{ data: U2FsdGVkX1abc123..., status: 200 }data字段是加密的。我们需要找到解密函数。同样用全局搜索搜decrypt、decode、AES等关键词。找到后把解密逻辑提取出来。假设解密逻辑是AESfunction decrypt(data) { const key CryptoJS.enc.Utf8.parse(1234567890abcdef); const iv CryptoJS.enc.Utf8.parse(abcdef1234567890); const decrypted CryptoJS.AES.decrypt(data, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return decrypted.toString(CryptoJS.enc.Utf8); }在Node.js里用crypto-js库复现npm install crypto-jsconst CryptoJS require(crypto-js); function decrypt(data) { const key CryptoJS.enc.Utf8.parse(1234567890abcdef); const iv CryptoJS.enc.Utf8.parse(abcdef1234567890); const decrypted CryptoJS.AES.decrypt(data, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return decrypted.toString(CryptoJS.enc.Utf8); }跑一遍看能否解出明文。如果报错检查key和iv的编码方式是否正确mode和padding是否匹配。3.4 完整请求链路的组装把签名和解密都跑通后就可以组装完整的请求链路了。用Python的requests库发起请求import requests import hashlib import time import json from Crypto.Cipher import AES from Crypto.Util.Padding import unpad import base64 SECRET your_secret_here def sign(params): keys sorted(params.keys()) str_to_sign for k in keys: str_to_sign f{k}{params[k]} str_to_sign fkey{SECRET} return hashlib.md5(str_to_sign.encode()).hexdigest() def decrypt(data): key b1234567890abcdef iv babcdef1234567890 cipher AES.new(key, AES.MODE_CBC, iv) decrypted cipher.decrypt(base64.b64decode(data)) return unpad(decrypted, AES.block_size).decode() params { page: 1, size: 20, timestamp: int(time.time() * 1000) } params[sign] sign(params) headers { User-Agent: Mozilla/5.0 ..., Referer: https://example.com/, Cookie: sessionid... } resp requests.get(https://example.com/api/list, paramsparams, headersheaders) result resp.json() if result[status] 200: data json.loads(decrypt(result[data])) print(data)实操心得时间戳参数要注意单位。有些站点用秒有些用毫秒。签名时用的时间戳和请求时传的时间戳必须一致否则签名验证会失败。我踩过这个坑排查了半天才发现是单位问题。3.5 验证与调试组装完成后不要急着跑大批量请求。先用单次请求验证对比本地生成的sign和浏览器里生成的sign是否一致。检查请求头是否完整特别是Cookie和Referer。看响应状态码和响应体确认解密是否成功。如果失败用DevTools的Console面板手动执行一遍签名函数对比结果。调试阶段最常见的错误是参数顺序不一致。签名时参数按key排序但请求时参数顺序可能不同。有些站点对参数顺序敏感有些则无所谓。如果签名验证失败先检查参数排序逻辑。4. 常见问题与排查技巧实录4.1 签名验证失败的排查思路签名验证失败是最常见的问题原因通常有以下几种问题现象可能原因排查方法返回403或签名错误盐值不对在Console里打印盐值变量确认是否动态变化签名值长度不对算法不匹配确认是MD5、SHA1还是其他算法签名值一致但请求失败参数编码问题检查参数是否经过URL编码空格是否转义时间戳相关错误时间戳单位或时区问题对比浏览器和本地的时间戳值Cookie失效会话过期重新获取Cookie检查是否有其他验证字段我遇到过一个比较坑的情况签名函数里用到了encodeURIComponent但我在Python里没有做同样的编码导致签名值不一致。后来在拼接字符串之前对每个参数值都做了urllib.parse.quote处理问题解决。4.2 代码混淆的应对策略如果代码混淆程度很高比如变量名全是随机字符串、控制流被扁平化、字符串被加密存储手动分析会非常耗时。这时候可以考虑以下策略策略一使用AST还原工具。比如babel配合自定义插件可以把混淆的代码还原成可读性较高的形式。但这需要一定的学习成本适合长期做逆向工作的人。策略二动态调试代替静态分析。不要试图读懂每一行代码而是在关键位置下断点观察变量的实际值。比如在加密函数的入口和出口下断点看输入和输出是什么中间过程可以忽略。策略三Hook关键函数。用DevTools的Console面板重写某些函数比如JSON.stringify、encodeURIComponent、XMLHttpRequest.prototype.send打印它们的调用参数。这样可以在不读代码的情况下知道数据经过了哪些处理。// Hook JSON.stringify var originalStringify JSON.stringify; JSON.stringify function(obj) { console.log(JSON.stringify called with:, obj); return originalStringify(obj); };策略四补环境。有些代码会检测运行环境比如检查window、document、navigator是否存在。在Node.js里跑的时候需要把这些全局对象补上。可以用jsdom库模拟浏览器环境或者手动定义缺失的变量。4.3 反调试机制的绕过有些站点会加入反调试机制比如检测开发者工具是否打开、检测代码是否被格式化、检测函数是否被Hook。常见的反调试手段和绕过方法手段一debugger死循环。代码里写一个setInterval(() { debugger; }, 100)让你无法正常调试。绕过方法在DevTools的Sources面板右键选择“Never pause here”或者在Console里重写setInterval。手段二检测console.log。重写console.log如果发现被调用就跳转到错误页面。绕过方法在页面加载前用DevTools的Console重写console.log为空函数。手段三检测函数toString。检查关键函数的toString结果是否包含native code判断是否被Hook。绕过方法重写Function.prototype.toString返回原始字符串。注意反调试机制的绕过涉及与目标站点的对抗仅限在授权范围内进行安全测试或学习研究。不要用于非法用途。4.4 性能优化与稳定性保障当逆向逻辑跑通后如果要做大批量请求还需要考虑性能和稳定性优化一复用Session。用requests.Session()保持会话避免每次请求都重新建立连接和协商Cookie。优化二控制请求频率。加time.sleep()随机延迟模拟人类操作节奏。频率过高容易触发风控。优化三异常重试。对网络超时、签名失败等情况做重试但不要无限重试设置最大重试次数。优化四日志记录。记录每次请求的参数、响应状态、耗时方便排查问题。import requests import time import random from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session requests.Session() retry Retry(total3, backoff_factor0.5, status_forcelist[500, 502, 503, 504]) session.mount(https://, HTTPAdapter(max_retriesretry)) for page in range(1, 101): try: params build_params(page) resp session.get(API_URL, paramsparams, headersheaders, timeout10) if resp.status_code 200: process(resp.json()) time.sleep(random.uniform(1, 3)) except Exception as e: print(fPage {page} failed: {e})4.5 常见问题速查表问题排查方向解决方案请求返回403请求头缺失或Cookie过期补全User-Agent、Referer、Cookie签名验证失败盐值、算法、参数顺序逐项对比浏览器和本地的签名过程响应解密乱码key、iv、mode、padding不匹配确认加密参数检查编码方式Node.js报错window is not defined缺少浏览器环境用jsdom补环境或手动定义全局变量代码混淆无法阅读混淆程度高用AST工具还原或动态调试代替静态分析反调试导致无法断点存在反调试机制重写关键函数绕过检测请求频率过高被封触发风控降低频率加随机延迟使用代理池提示代理池的选择要注意合规性仅使用合法合规的网络资源。5. 工具链与效率提升的实战建议5.1 本地调试环境的搭建我习惯在VS Code里建一个专门的逆向工作目录结构如下js-reverse/ ├── src/ │ ├── sign.js # 签名函数 │ ├── decrypt.js # 解密函数 │ └── utils.js # 工具函数 ├── test/ │ ├── test-sign.js # 签名测试 │ └── test-decrypt.js # 解密测试 ├── output/ │ └── data.json # 输出数据 ├── package.json └── README.md在package.json里配置调试脚本{ scripts: { test-sign: node test/test-sign.js, test-decrypt: node test/test-decrypt.js } }这样每次修改代码后直接npm run test-sign就能验证签名逻辑是否正确不用每次都去浏览器里对比。5.2 浏览器与Node.js的联调技巧有时候签名逻辑依赖浏览器的某些特性比如window.btoa、document.cookie等。在Node.js里跑的时候需要把这些补上。我的做法是写一个browser-env.js在测试文件开头引入// browser-env.js global.window global; global.document { cookie: sessionidabc123 }; global.navigator { userAgent: Mozilla/5.0 ... }; global.btoa function(str) { return Buffer.from(str, binary).toString(base64); }; global.atob function(str) { return Buffer.from(str, base64).toString(binary); };然后在测试文件里require(./browser-env); const { sign } require(../src/sign); console.log(sign({ page: 1, size: 20 }));这样就能在Node.js里模拟浏览器环境跑通依赖浏览器API的代码。5.3 代码版本管理与复用逆向出来的代码要妥善管理因为目标站点可能会更新加密逻辑。我的做法是每个站点建一个独立的目录目录名用站点域名或项目代号。代码里注明逆向日期和对应的站点版本。把关键的加密参数盐值、key、iv单独放在一个配置文件里方便更新。写一个简单的监控脚本定期检查签名是否仍然有效失效时发通知。// config.js module.exports { secret: abc123, aesKey: 1234567890abcdef, aesIv: abcdef1234567890, lastUpdated: 2025-01-15 };这样当站点更新时只需要修改配置文件不用动核心逻辑。5.4 学习路径与进阶方向如果你刚接触JS逆向我建议按以下路径学习第一阶段基础语法。确保你能读懂JavaScript的基本语法包括函数、对象、数组、闭包、原型链。推荐在MDN上过一遍核心概念。第二阶段DevTools熟练使用。重点掌握Sources面板的断点、调用栈、作用域查看功能。这是逆向工作的核心工具。第三阶段常见算法识别。把MD5、SHA、AES、RSA、Base64这几种算法的代码特征记住看到能认出来。第四阶段实战练习。找一些公开的、无风险的练习站点比如一些提供API测试的网站尝试逆向它们的签名逻辑。第五阶段进阶工具。学习AST操作、补环境框架、自动化Hook工具。这些能大幅提升效率但需要一定的编程基础。实操心得不要一开始就追求“万能工具”。我见过太多人花大量时间找自动化工具结果连最基本的断点调试都不熟练。工具是锦上添花核心能力还是手动分析。5.5 合规与风险提示最后必须强调一点JS逆向技术本身是中性的但使用场景有明确的边界。在授权范围内进行安全测试、学习研究、或者采集公开数据都是合理的。但以下行为绝对不要碰绕过付费墙获取本应付费的内容破解他人系统的身份验证机制大规模抓取非公开的个人隐私数据对目标站点造成服务压力或破坏我在实际操作中始终坚持一个原则只处理公开的、无需登录即可访问的数据且控制请求频率不影响目标站点的正常服务。如果目标站点有明确的反爬声明或服务条款禁止数据采集我会选择放弃寻找其他合规的数据来源。技术能力越强越要知道边界在哪里。这不是限制而是保护自己。6. 从逆向到防御理解前端安全的另一面6.1 常见前端防护手段的局限性做逆向久了自然会思考一个问题如果我是前端开发者怎么保护自己的接口不被轻易逆向我试过几种常见的防护手段说下实际效果。手段一代码混淆。把变量名替换成随机字符串把字符串拆成数组把控制流扁平化。这确实能提高逆向的门槛但无法从根本上阻止。有经验的逆向人员配合AST工具还原混淆代码只是时间问题。而且过度混淆会影响代码的可维护性和性能得不偿失。手段二动态密钥。每次请求前从服务端获取一个临时密钥用于签名或加密。这能增加逆向的难度因为密钥是动态的。但逆向人员可以通过Hook获取密钥的接口或者直接在内存中读取密钥值。防护效果有限。手段三环境检测。检测开发者工具是否打开、检测代码是否被格式化、检测函数是否被Hook。这些手段能挡住一部分新手但对有经验的人来说绕过只是多花几分钟的事。手段四WebAssembly。把核心逻辑编译成WASM增加逆向难度。这确实有效因为WASM是二进制格式反编译成本高。但WASM也有调试工具而且会增加包体积和加载时间。我的看法前端代码运行在用户的浏览器里用户拥有完全的控制权。任何前端防护都只能提高门槛无法做到绝对安全。真正的安全应该放在服务端接口鉴权、频率限制、行为分析、风控策略。前端防护只是第一道防线不是最后一道。6.2 服务端风控的常见策略从防御角度看服务端能做的前端做不了的事情很多请求频率限制同一IP或同一账号在单位时间内的请求次数超过阈值就拒绝。行为分析分析请求的时间间隔、参数规律、User-Agent一致性识别机器行为。参数校验服务端重新计算签名不信任前端传来的任何参数。Token机制每次请求携带一次性Token用完即废防止重放攻击。设备指纹收集浏览器指纹信息识别异常设备。这些策略的组合使用能大幅提高数据采集的成本。但也要注意平衡过于严格的风控会影响正常用户的体验。6.3 对开发者的实用建议如果你是一名前端开发者想保护自己的接口我的建议是不要把敏感逻辑放在前端。任何加密密钥、核心算法只要在前端出现就有可能被逆向出来。把这些逻辑放到服务端。使用标准的加密算法。不要自己发明加密算法标准算法的安全性经过了充分验证。做好服务端校验。前端传来的所有参数都要在服务端重新校验不要信任任何前端数据。合理使用混淆。适度混淆可以增加逆向成本但不要过度以免影响性能和可维护性。监控异常请求。记录请求日志分析异常模式及时发现和应对数据采集行为。如果你是一名逆向学习者我的建议是尊重目标站点的服务条款。如果站点明确禁止数据采集不要强行突破。控制请求频率。不要对目标站点造成服务压力。仅用于学习和研究。不要将逆向技术用于非法用途。持续学习。前端技术在不断演进逆向技术也需要不断更新。我在实际项目中最大的体会是逆向和防御是一体两面的。你越了解逆向的手段就越知道该怎么防御你越了解防御的策略就越知道逆向的突破口在哪里。这种双向的理解才是真正的核心竞争力。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
