JS逆向实战：对称加密算法识别、定位与Python复现全解析

1. 项目概述：对称加密在JS逆向中的核心地位

在JS逆向的实战世界里，加密算法是绕不开的一道坎。如果说非对称加密（如RSA）是负责安全“握手”和传递“钥匙”的“外交官”，那么对称加密就是后续所有数据高速、高效传输的“主力军”。当你成功逆向了一个登录接口，发现密码被RSA公钥加密后，往往只是第一步。后续大量的业务数据、接口参数、甚至会话令牌的加解密，大概率会由对称加密算法接管。因此，深入理解并掌握对称加密的逆向分析，是从“入门”迈向“精通”的关键一步。

对称加密，顾名思义，就是加密和解密使用同一把密钥。它的核心优势在于速度快，适合对海量数据进行实时加解密，这正是现代Web应用和移动端App广泛采用它的原因。在JS逆向中，你遇到的AES、DES、3DES、RC4、Rabbit，甚至国密的SM4，都属于对称加密的范畴。我们的目标，就是当你在浏览器的开发者工具中，看到一串CryptoJS.AES.encrypt(...)或者一个神秘的encrypt函数调用时，能够迅速定位密钥、识别模式、补全环境，最终在Python/Node.js中完美复现其加密逻辑，从而成功构造出服务端认可的请求参数。

这篇文章，我将结合多年爬虫与逆向经验，抛开教科书式的理论堆砌，直接聚焦于实战中对称加密算法的识别、定位、分析与复现全流程。我会带你拆解几个经典案例，分享那些调试工具里不会写的“骚操作”和“坑点”，让你在面对加密参数时，不再是一头雾水地盲目搜索，而是有章法、有思路地层层剥开它的外壳。

2. 对称加密算法核心原理与JS实现特征

在动手逆向之前，我们必须先搞清楚对手是谁。对称加密算法虽然家族庞大，但在前端JavaScript中，其实现和调用通常有非常明显的特征。理解这些特征，能让你在浩瀚的混淆代码中快速定位到目标。

2.1 主流算法速览与JS常见库

前端最常用的对称加密库非CryptoJS莫属。它是一个强大的加密算法JavaScript实现集合，代码结构清晰，是许多网站的首选。此外，原生的Web Crypto API也逐渐普及，但多用于更底层的安全场景。一些公司也会使用自研或经过特定混淆的加密模块。

1. AES (Advanced Encryption Standard)这是目前最安全、最通用的对称加密算法，没有之一。在CryptoJS中，它的调用特征非常明显：

• 搜索关键词：CryptoJS.AES、mode、padding、iv（初始化向量）。
• 常见模式：CBC（最常用，需要IV）、ECB（不推荐，不需要IV）、CFB、OFB等。
• 填充方式：Pkcs7（在CryptoJS中常表现为Pkcs7填充，但内部处理与PKCS#5等价）、ZeroPadding等。
• 代码特征：你可能会看到类似CryptoJS.AES.encrypt(message, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 })的代码块。

2. DES / 3DES (Data Encryption Standard)这是一种较老的算法，因密钥长度短（DES仅56位）已不再安全，但在一些遗留系统中仍能见到。3DES是DES的加强版。

• 特征：密钥长度是重要线索（DES 8字节，3DES 16或24字节）。在代码中可能搜索到CryptoJS.DES或CryptoJS.TripleDES。

3. 国密算法 (SM4)在国内的一些政务、金融类网站中，你可能会遇到国家密码管理局认定的标准算法SM4。它的块大小、密钥长度与AES相同（128位），但算法结构不同。

• 特征：可能会引入特定的SM4库，如sm4.js。搜索SM4、国密等关键词可能会有发现。其调用方式与AES类似，但算法对象不同。

4. 流加密 (RC4, Rabbit)这类算法将密钥转换为伪随机密钥流，然后与明文进行异或操作。它们通常不需要填充和复杂的模式。

• 特征：代码中可能出现CryptoJS.RC4或CryptoJS.Rabbit。加密过程往往很简单，形如CryptoJS.RC4.encrypt(plaintext, key)。

注意：很多网站会对CryptoJS等库进行定制化修改或重度混淆。你可能看不到完整的CryptoJS.AES.encrypt，而是看到a.b.c(d, e, {f: g})这样的形式。这时，关键就在于通过调试，追踪这些变量最终指向的函数和对象。

2.2 密钥、IV与模式的“铁三角”

对称加密，尤其是分组加密（如AES），有三个核心概念必须厘清，它们共同决定了加密的结果：

1. 密钥 (Key)：加密和解密的根本。长度取决于算法（AES-128/192/256对应16/24/32字节）。密钥的获取是逆向的核心目标。它可能硬编码在JS里，可能通过接口动态获取，也可能是由用户密码通过某种算法（如PBKDF2）派生而来。

2. 初始化向量 (IV, Initialization Vector)：用于CBC、CFB等模式，目的是使相同的明文在不同次加密中产生不同的密文，增强安全性。IV不需要保密，但通常需要和密文一起传输。IV的缺失或错误是导致复现失败的最常见原因之一。它可能是固定的、随机的、或由某个参数计算得出。

3. 工作模式 (Mode) 与填充 (Padding)：

   • 模式：定义了算法如何应用在数据块上。ECB模式每个块独立加密，不安全；CBC模式每个块依赖于前一个块，最常用。
   • 填充：因为分组加密需要处理固定长度的数据块（如AES是16字节），当明文不是块大小的整数倍时，就需要填充。Pkcs7是最常见的填充方式。

在逆向时，你必须完整地确定这四要素：算法、密钥、IV、模式与填充。缺一不可。

2.3 前端代码中的常见“藏匿”手法

开发者不会把密钥明晃晃写在var key = "123456"里。以下是一些常见的隐蔽方式：

• 字符串混淆：密钥可能被拆分成多个片段，通过数组操作、位运算或字符串函数拼接起来。例如：key = atob("MTIzNDU2") + String.fromCharCode(55, 56, 57)，实际是"123456789"。
• 动态生成：密钥可能由页面中的某个固定值（如window.xxx）、用户ID、时间戳等参数，经过一个自定义的哈希或编码函数生成。
• 网络请求获取：密钥或加密所需的盐值(Salt)、IV可能通过一个前置的API接口获得，这个接口可能还需要特定的令牌才能访问。
• Webpack模块化：加密函数可能被包裹在Webpack模块中，导出为一个看似随意的变量名，需要你找到模块的入口和导出映射关系。

面对这些情况，单纯的关键字搜索可能失效。你需要结合断点调试、堆栈跟踪、Hook技术和对代码执行流的耐心分析来捕捉密钥的生成瞬间。

3. 逆向实战：定位与分析对称加密逻辑

理论说再多，不如一次实战。我们假设一个场景：在分析某电商网站的商品列表接口时，发现其请求体中的一个params参数是一长串看似随机的Base64字符串，疑似被加密。我们的任务就是破解它。

3.1 第一步：初步侦察与关键词搜索

打开Chrome开发者工具，切换到Network（网络）选项卡，清空记录，然后触发一次商品列表的请求（比如翻页）。找到目标XHR/Fetch请求，查看其Headers和Payload。

1. 观察请求参数：如果params或data是一个长字符串，且字符集符合Base64（A-Za-z0-9+/=）或Hex，加密的可能性很大。复制一段密文，尝试用Base64解码，如果结果是乱码，那基本就是加密后的二进制数据了。
2. 全局搜索关键词：
   • 直接搜索密文的前几个字符或后几个字符。有时加密函数的结果会直接被赋值给某个变量，通过搜索密文可以反向定位到加密位置。
   • 搜索通用加密函数名：encrypt、encode、CryptoJS、AES、DES、mode、iv、pad。
   • 搜索可能包含密钥的常量字符串：如果你怀疑密钥是固定的，可以尝试搜索一些可能的密钥格式或长度（如16、24、32位的字符串片段）。

3.2 第二步：XHR/Fetch断点与调用栈分析

如果关键词搜索无果，或者结果太多难以筛选，断点法是最高效的。

1. 设置XHR/Fetch断点：
   • 在开发者工具的Sources（源代码）面板，找到右侧的XHR/fetch Breakpoints。
   • 点击+，输入目标请求URL的一部分（如包含/api/list），添加断点。
2. 触发请求：回到页面，再次触发请求。此时执行流会在发起网络请求的瞬间暂停。
3. 分析调用栈 (Call Stack)：这是最关键的一步！在Sources面板右侧，你会看到Call Stack区域，里面显示了当前暂停位置是如何被一层层函数调用过来的。加密操作一定发生在发送请求之前。
   • 忽略最顶层的send或fetch相关内部函数。
   • 从下往上（或从上往下逐个点击）查看调用栈中的每一个函数，特别是那些属于网站自身域名下的脚本（如main.chunk.js，vendor.js）。
   • 点击某个栈帧，代码会定位到该函数的执行位置。仔细查看附近的代码，寻找是否有对请求参数（如payload、data）进行赋值或处理的代码，这里很可能就是加密发生的地方。

实操心得：我习惯在调用栈里寻找那些函数名包含submit、request、ajax、sendData或者变量名包含params、encrypted的栈帧。找到后，不要只看当前行，要阅读这个函数及其上层函数的完整逻辑，理解参数是如何被传递和加工的。

3.3 第三步：Hook技术精准拦截

对于复杂的、动态加载的加密逻辑，或者加密函数被深深隐藏的情况，我们可以使用更主动的Hook技术。Hook的本质是在某个函数或属性被调用/访问时，插入我们自己的调试代码。

HookJSON.stringify：很多请求在发送前，会将对象参数通过JSON.stringify序列化成字符串。如果加密是在序列化之后进行的，Hook这个函数可能抓不到。但如果加密是对整个字符串进行的，或者加密后形成了一个新的对象，那么HookJSON.stringify可以让我们看到加密前的原始对象。

// 在Console中执行 (function() { var stringify = JSON.stringify; JSON.stringify = function(...args) { console.trace("JSON.stringify被调用，参数:", args); debugger; // 自动断点 return stringify.apply(this, args); }; })();

HookCryptoJS.AES.encrypt：如果我们已经怀疑是AES，可以直接Hook其加密方法。这需要加密逻辑已经加载到页面中。

// 在Console中执行，假设CryptoJS已全局可用 if (CryptoJS && CryptoJS.AES && CryptoJS.AES.encrypt) { var _encrypt = CryptoJS.AES.encrypt; CryptoJS.AES.encrypt = function(message, key, cfg) { console.log("AES加密被调用！"); console.log("明文:", typeof message === 'object' ? message.toString() : message); console.log("密钥:", key); console.log("配置:", cfg); debugger; return _encrypt.call(this, message, key, cfg); }; console.log("Hook CryptoJS.AES.encrypt 成功！"); }

执行Hook脚本后，再触发请求。一旦加密函数被调用，就会自动断点，并打印出关键的明文、密钥和配置信息。这是获取加密参数最直接、最暴力也最有效的方法之一。

3.4 第四步：深入加密函数内部

通过断点或Hook，我们成功定位到了加密函数，比如一个名为encryptData的函数。接下来需要深入分析：

1. 单步调试 (F10/F11)：在加密函数入口处打上断点，然后一步步执行（F10是跳过函数调用，F11是进入函数调用）。观察每一步中，密钥key、初始化向量iv是如何被计算或赋值的。
2. 查看作用域变量：在调试器右侧的Scope面板，可以查看当前作用域下的所有局部变量、闭包变量和全局变量。这里常常藏着计算好的密钥和IV。
3. 复制关键代码段：将包含加密核心逻辑的代码段（从密钥生成到调用加密库函数）复制出来。注意，如果代码被混淆（变量名是a,b,c,d），你需要根据执行流程，理清每个变量的实际含义。有时，直接复制整个函数及其依赖的辅助函数是更稳妥的做法。

4. 案例拆解：从JS到Python的完整复现

假设我们通过上述方法，在一个名为encryptParams的函数中找到了如下AES加密逻辑：

function encryptParams(plainText) { var key = CryptoJS.enc.Utf8.parse('1234567890123456'); // 16字节密钥 var iv = CryptoJS.enc.Utf8.parse('abcdefghijklmnop'); // 16字节IV var encrypted = CryptoJS.AES.encrypt(plainText, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return encrypted.ciphertext.toString(CryptoJS.enc.Base64); // 输出Base64 }

现在，我们需要在Python中复现这个加密过程，使得我们生成的密文与JS生成的一模一样。

4.1 环境准备与库选择

Python中进行AES加密，最常用的是pycryptodome库。它功能强大且持续维护。使用pip安装：

pip install pycryptodome

为什么是pycryptodome而不是pycrypto？pycrypto已年久失修，存在安全漏洞且安装麻烦。pycryptodome是其一个活跃的分支，API完全兼容，是当前事实上的标准。

4.2 复现过程详解

JS代码清晰地展示了所有要素：算法AES、密钥、IV、模式CBC、填充Pkcs7。我们的Python复现必须严格对应。

from Crypto.Cipher import AES from Crypto.Util.Padding import pad import base64 def encrypt_aes_cbc(plain_text: str, key: str, iv: str) -> str: """ 复现JS中CryptoJS.AES.encrypt的CBC模式+Pkcs7填充加密。 参数: plain_text: 待加密的明文字符串 key: 密钥字符串，UTF-8编码 iv: 初始化向量字符串，UTF-8编码 返回: Base64编码的密文字符串 """ # 1. 将字符串密钥和IV转换为字节，并确保长度正确 # CryptoJS.enc.Utf8.parse() 相当于将UTF-8字符串编码为字节 key_bytes = key.encode('utf-8') iv_bytes = iv.encode('utf-8') # AES-128 需要16字节密钥，192需要24字节，256需要32字节 # 这里假设是AES-128，我们可以简单检查一下 if len(key_bytes) not in [16, 24, 32]: # 如果长度不对，可能需要用MD5/SHA256等哈希一下，具体看JS逻辑 # 本例中JS直接parse，所以我们也直接使用 pass # 暂时不做处理，假设长度正确 # 2. 创建AES加密器，使用CBC模式和指定的IV cipher = AES.new(key_bytes, AES.MODE_CBC, iv_bytes) # 3. 处理明文：先转换为字节，然后进行PKCS7填充 # Pkcs7填充：需要填充到块大小(16字节)的整数倍，填充的值等于填充的字节数 plaintext_bytes = plain_text.encode('utf-8') padded_bytes = pad(plaintext_bytes, AES.block_size, style='pkcs7') # 使用pkcs7 # 4. 加密 encrypted_bytes = cipher.encrypt(padded_bytes) # 5. 将加密后的字节进行Base64编码 # JS中用的是 encrypted.ciphertext.toString(CryptoJS.enc.Base64) # ciphertext 是CryptoJS内部的WordArray对象，直接包含加密后的字节。 # 在Python中，我们加密得到的encrypted_bytes就是对应的字节。 ciphertext_b64 = base64.b64encode(encrypted_bytes).decode('utf-8') return ciphertext_b64 # 测试复现 if __name__ == '__main__': key = '1234567890123456' iv = 'abcdefghijklmnop' plaintext = '{"page":1,"size":20}' # 模拟请求参数 encrypted_result = encrypt_aes_cbc(plaintext, key, iv) print(f'Python加密结果: {encrypted_result}') # 为了验证，我们可以用同样的参数在Node.js环境或用CryptoJS在线工具运行JS代码，对比输出。 # 假设JS运行结果是：'Kk5v7p3aXpPZz3pNp8q9sLm2n4bVcXyZ==' # print(f'预期JS结果: Kk5v7p3aXpPZz3pNp8q9sLm2n4bVcXyZ==') # assert encrypted_result == 'Kk5v7p3aXpPZz3pNp8q9sLm2n4bVcXyZ=='

关键点解析与避坑指南：

1. 编码一致性：JS的CryptoJS.enc.Utf8.parse('...')是将UTF-8字符串转换成它内部的WordArray对象，本质上就是获取字符串的UTF-8编码字节。在Python中，我们直接用.encode('utf-8')即可对应。千万不能用.encode('ascii')或其他编码。
2. 填充 (Padding)：这是最容易出错的地方。CryptoJS.pad.Pkcs7和 PythonCrypto.Util.Padding中的pad(..., style='pkcs7')是等效的。必须确保使用相同的填充方式。有些旧的代码可能使用ZeroPadding，那在Python端就需要对应的实现。
3. 输出格式：JS代码中encrypted.ciphertext.toString(CryptoJS.enc.Base64)是直接将加密后的二进制数据（ciphertext）进行Base64编码。在Python中，cipher.encrypt()返回的就是字节数据，直接base64.b64encode()即可。注意，不要对encrypted_bytes先做.hex()或其他转换。
4. IV的处理：在CBC模式中，IV是必须的，且需要是16字节（对于AES）。在Python的AES.new中，IV作为参数传入。确保IV的字节长度正确。

4.3 处理更复杂的情况：动态密钥与自定义算法

实战中很少遇到如此清晰的硬编码密钥。更多情况是这样的：

情况一：密钥由固定字符串经过哈希得出

var keyStr = "fixed_salt_" + Date.now().toString().slice(0,8); var key = CryptoJS.MD5(keyStr).toString().substr(0, 16); // 取MD5的前16位作为AES-128密钥 var iv = CryptoJS.enc.Utf8.parse('1234567890123456');

复现策略：在Python中，你需要用hashlib.md5计算出相同的MD5值，然后截取前16个字符作为密钥字节。注意Date.now()在JS和Python中可能有时区差异，需要确认时间戳的生成逻辑是否可预测（比如是服务器下发的？还是本地生成的特定格式？）。

情况二：加密函数被深度混淆和封装你找到的加密调用可能是window._crypto.encrypt(plaintext)，而_crypto是一个复杂的自执行函数返回的对象。这时，不要试图去完全理解混淆后的代码逻辑。可以尝试：

1. 直接调用：在浏览器Console中，尝试直接调用window._crypto.encrypt('test')，看是否能得到结果。如果可以，说明这个函数是完整的。
2. 导出函数：将这个复杂的自执行函数整体（通常是一个几千行的IIFE）复制到一个单独的JS文件中，稍作修改（比如补全缺失的浏览器对象如window,document），然后在Node.js环境中用vm2等沙箱模块运行它，直接调用其暴露的加密函数。
3. 补环境大法：这是高阶技巧。如果加密函数依赖浏览器的某些特性（如navigator.userAgent,window.location），你需要在Node.js中模拟这些对象。通常，定义一个空的window = global; window.navigator = { userAgent: '...' }就能解决大部分问题。

5. 调试技巧、问题排查与安全边界

即使你成功复制了代码，复现过程也绝不会一帆风顺。下面是我总结的常见问题排查清单和一些高级技巧。

5.1 密文对不上？逐项检查清单

当你的Python加密结果与JS生成的密文不一致时，请按以下顺序排查：

一个非常实用的调试方法是：在JS端构造一个最简单的、固定的明文（如"test123"）进行加密，然后在Python端用同样的参数复现。排除业务数据的干扰，聚焦于算法本身是否复现正确。

5.2 高级Hook与代码提取技巧

对于反调试能力较强的网站（比如无限debugger、检测控制台），常规的断点可能失效。可以尝试以下方法：

• 油猴脚本注入Hook：将你的Hook脚本写成Tampermonkey或Violentmonkey脚本，在页面加载早期就执行，这样可以在网站的反调试代码生效前就完成Hook。
• Override本地文件：在开发者工具的Sources面板，找到加载的JS文件，右键选择Override content。你可以将文件保存到本地，删除其中的反调试代码（如setInterval(function(){debugger;}, 100)或(function() {var a = new Date(); Debugger; if(new Date() - a > 100) {alert('检测到调试')}})()），然后刷新页面，浏览器会加载你修改后的本地文件。
• 使用Proxy对象进行深度Hook：对于对象属性的访问也可以Hook。

  // Hook某个对象的特定属性获取 let realKey = window.someObject.secretKey; window.someObject = new Proxy(window.someObject, { get(target, property) { if (property === 'secretKey') { console.log('有人访问了secretKey！值是:', target[property]); debugger; } return target[property]; } });

5.3 安全、法律与道德边界

这是所有技术讨论都必须强调的底线。

• 仅用于学习与研究：本文所有技术仅限用于授权测试、学习密码学原理、分析公开接口的通信机制。绝对禁止用于攻击、窃取、破坏任何未经授权的系统。
• 尊重robots.txt与服务条款：在尝试分析任何网站前，请先查看其robots.txt文件和服务条款，明确对方是否允许爬虫或自动化访问。
• 避免对目标造成负担：在调试和分析过程中，尽量减少对目标服务器的高频请求，避免触发对方的反爬机制或造成不必要的负载。
• 数据脱敏：在分享案例分析时，应对密钥、特定接口地址、用户数据等敏感信息进行脱敏处理。

逆向工程是一把双刃剑，它极大地加深了我们对系统工作原理的理解，是安全研究员、爬虫工程师（在合法合规前提下）的必备技能。但时刻牢记，技术能力的提升，必须与法律意识和职业道德的加强同步。当你成功还原出一个复杂的加密流程时，那份成就感来自于对技术的征服，而非对规则的逾越。保持这份初心，你的路才能走得长远而稳健。