前端加密PDF密码逆向分析：从网络抓包到Python算法复现实战

1. 项目概述与核心价值

最近在分析一个在线文档平台的加密PDF下载流程时，遇到了一个挺有意思的挑战。这个平台为了保护文档内容，对用户下载的PDF文件进行了前端加密，你需要输入一个由平台动态生成的密码才能打开。对于普通用户来说，这只是一个额外的安全步骤，但对于我们这些喜欢研究技术实现、或者在某些特定场景下（比如合法合规的文档批量处理、自动化归档）需要绕过这个交互环节的人来说，就产生了一个需求：我们能否逆向分析出这个加密密码的生成逻辑，从而实现无需人工干预的自动化解密？

这听起来有点像在“破解”什么，但实际上，我们探讨的是一种基于前端代码分析的逻辑还原。平台在前端（用户的浏览器里）完成密码的生成和加密套用，那么理论上，只要我们能够理清浏览器中JavaScript代码的执行逻辑，就能在本地环境复现这一过程。整个过程不涉及对服务器端未授权数据的获取，核心在于对公开的前端资源进行静态分析与动态调试。这次实战，我们就来一步步拆解这个“黑盒”，看看如何从一次普通的PDF下载请求中，定位到关键的加密函数，并最终理解其密码生成机制。无论你是前端安全研究员、自动化脚本开发者，还是单纯对Web逆向感兴趣的朋友，这个过程都能让你对现代Web应用的安全边界和实现细节有更深刻的认识。

2. 逆向分析的整体思路与准备工作

2.1 核心思路拆解：从前端到密码

面对一个加密的PDF，最直接的思路是找到加密发生的位置。既然密码是在下载时由前端生成的，那么我们的突破口必然在浏览器。整个逆向流程可以概括为“由外及内，动静结合”：

1. 网络行为观察：首先，通过浏览器开发者工具的网络面板（Network），捕获整个PDF下载过程中的所有HTTP请求。关键目标是找到那个最终触发PDF下载、或者携带了加密相关参数的请求。
2. 关键逻辑定位：分析捕获到的请求，特别是那些含有疑似密码参数（可能是password、key、encryptKey等命名）的请求。然后，通过“发起程序”功能回溯到生成这个请求的JavaScript代码。
3. 代码分析与还原：找到的JavaScript代码往往是经过混淆和压缩的，可读性极差。我们需要运用调试技巧，结合静态分析和动态执行，一步步理清代码逻辑，定位到核心的密码生成函数。
4. 算法复现与验证：将核心算法逻辑用清晰的代码（如Python）重新实现，并用已知的案例进行测试，验证生成的密码能否成功解密对应的PDF。

这个思路的核心在于，我们承认并利用了一个事实：为了能让用户的浏览器正常工作，所有用于生成密码的逻辑和（非对称加密中的）公钥等必要信息，都必须以某种形式暴露给前端。我们的任务就是找到并理解这些信息。

2.2 环境与工具准备

工欲善其事，必先利其器。进行前端逆向分析，一套顺手的工具链至关重要。

2.2.1 浏览器与开发者工具

• 主浏览器：推荐使用Google Chrome或基于Chromium的Microsoft Edge。它们的开发者工具功能强大且统一，是我们分析的主力。
• 核心面板：
  • Network（网络）：用于捕获所有网络请求，这是所有分析的起点。务必勾选“Preserve log”（保留日志）并禁用缓存。
  • Sources（源代码）：用于查看、调试JavaScript代码。可以设置断点、单步执行、查看调用栈。
  • Console（控制台）：用于执行JavaScript代码片段，测试我们的猜想，打印变量值。
  • Application（应用）或Storage（存储）：有时密钥或种子会存储在LocalStorage、SessionStorage或IndexedDB中，需要在这里检查。

2.2.2 辅助分析工具

• 代码美化工具：面对压缩成一行的代码，首先需要格式化。Chrome开发者工具的Sources面板自带“Pretty Print”按钮（{}图标）。对于更复杂的混淆，可以尝试在线工具或VS Code插件。
• 请求重放工具：如Postman或Hoppscotch。当我们分析出请求参数构造逻辑后，需要用这些工具模拟请求，验证我们的逆向结果是否正确，避免频繁在浏览器中操作。
• 编程环境：用于复现算法。Python是首选，因其拥有丰富的加解密库（如pycryptodome、cryptography）和网络请求库（如requests）。准备一个Jupyter Notebook或简单的Python脚本环境会很方便。
• 系统剪切板增强工具：如Ditto（Windows）或Alfred（Mac）。在反复复制代码片段、请求头、参数时，能极大提升效率。

注意：整个分析过程应在你拥有合法权限的文档或个人测试文档上进行。未经授权对他人的加密文档进行此类分析可能违反服务条款甚至法律法规。请务必用于学习目的和合规场景。

3. 实战第一步：网络抓包与请求分析

一切分析始于观察。我们首先需要完整地捕获一次加密PDF的下载过程。

3.1 捕获下载请求流

1. 打开Chrome开发者工具（F12），切换到Network面板。
2. 确保录制按钮是红色开启状态，并勾选Preserve log。清空现有的请求列表。
3. 在目标在线文档平台中，找到你想要分析的加密PDF，点击“下载”或类似按钮。此时，可能会弹出密码输入框，也可能直接开始下载一个加密的PDF文件。我们假设是后者，即平台自动生成密码并加密后下载。
4. 观察Network面板中瞬间涌现的请求。重点关注：
   • 文档内容请求：通常是一个对PDF文件本身的请求，URL可能包含文档ID，状态码为200。但此时响应体（Response）可能是乱码，因为文件已加密。
   • XHR/Fetch请求：在下载动作前后，很可能有异步JavaScript请求发出，用于获取加密密钥、初始化向量或其他必要参数。这些请求的Initiator列会显示是哪个JS文件发起的。
   • 可能携带参数的请求：仔细查看每个请求的Payload（负载）或Query String Parameters（查询参数）。寻找像key、token、encryption、password、cipher这样的字段名。

3.2 定位关键请求与参数

经过筛选，你可能会发现一个特殊的请求，它不像直接请求PDF资源，而是一个API调用。例如，它可能是一个向/api/getDownloadInfo或/file/encrypt/key发起的POST或GET请求。

点击这个请求，查看其详细信息：

• Headers：查看请求头，特别是Authorization、Cookie等认证信息，以及Content-Type。
• Payload：如果是POST请求，查看Form Data或Request Payload。这里很可能包含了服务器生成并返回给前端的加密密钥（Encrypted Key）或用于生成密码的种子（Seed）。
• Response：这是重中之重！查看服务器返回的JSON数据。一个典型的响应可能长这样：

  { "code": 0, "data": { "fileId": "1234567890", "downloadUrl": "https://cdn.example.com/encrypted.pdf", "encryptionInfo": { "method": "AES-256-CBC", "key": "U2FsdGVkX1...（一长串Base64编码的字符串）", "iv": "abcdef1234567890", "password": "" // 注意，密码可能为空，需要前端计算 } } }

  或者，密码可能直接返回：

  { "data": { "password": "5f4dcc3b5aa765d61d8327deb882cf99" } }

关键点：如果password字段是空的，或者返回的是一个加密过的key，那么几乎可以肯定，密码是在前端通过JavaScript计算出来的。计算所需的原材料（加密的密钥、IV、文档ID等）已经包含在响应里了。我们的目标就从“找密码”变成了“找生成密码的JS函数”。

• Initiator：点击这个请求的Initiator标签页，它会显示调用栈，直接链接到发起这个请求的JavaScript代码行。这是通往核心逻辑的黄金通道。点击栈中最顶层的那个链接（通常是你的点击事件处理函数），它会带你跳转到Sources面板对应的代码位置。

4. 逆向核心：JavaScript代码分析与调试

找到入口只是开始，面对经过混淆压缩的代码才是真正的挑战。

4.1 处理混淆代码

点击Initiator跳转后，你看到的代码很可能面目全非：变量名都是a, b, c, _0x1a2b3c，没有空格和换行。第一步是点击Sources面板左下角的{}（Pretty Print）按钮格式化代码，使其具备基本的可读性。

即使格式化后，逻辑可能依然晦涩。常见的混淆手段包括：

• 变量名混淆：将有意义的名字改为短字母或十六进制字符串。
• 控制流平坦化：将顺序执行的代码拆散，用switch-case或数组跳转来打乱顺序。
• 字符串加密：将字符串常量加密存储，使用时动态解密。
• 死代码注入：插入大量永不执行的代码块。

我们的策略不是完全读懂每一行，而是动态跟踪。

4.2 动态调试定位密码生成点

假设我们从服务器响应中拿到了一个加密的key，并且知道前端需要解密它得到密码。那么密码生成点很可能发生在两个地方：

1. 在发送下载PDF的请求之前，密码已经计算好并作为参数附加。
2. 在接收到PDF二进制流之后，在内存中进行解密。

我们更关注第1种情况，因为它更常见。如何找到它？

1. 设置断点：在Initiator跳转到的代码行附近，仔细阅读。寻找与下载URL拼接、参数赋值相关的操作。例如，看到downloadUrl += "?password=" + someVariable这样的代码，就在这一行设置断点（点击行号）。
2. 搜索关键词：在格式化后的代码中（Ctrl+F），搜索可能的关键词，如password、decrypt、AES、CryptoJS（一个常用的前端加密库）、encrypt、key、iv。注意，混淆后这些词可能作为字符串常量被加密，但有时也会原样出现。
3. XHR/Fetch断点：在Sources面板的右侧，XHR/Fetch Breakpoints区域，可以添加一个包含部分URL的断点，例如*download*。当任何包含download的URL被请求时，浏览器会自动暂停，此时调用栈会显示完整的请求发起路径，方便我们向上回溯。
4. 事件监听器断点：在Sources面板右侧的Event Listener Breakpoints中，可以展开Mouse事件，勾选click。这样当点击下载按钮时，代码会立即在事件处理函数入口处暂停。

4.3 跟栈与变量监视

当代码在断点处暂停后：

• 查看调用栈（Call Stack）：右侧的Call Stack面板显示了当前暂停位置是如何被一步步调用过来的。从下往上读，最下面是入口（如事件触发），最上面是当前行。你可以点击调用栈中的任意一层，查看当时的代码和上下文。沿着调用栈向下（向更早的调用层）追溯，往往能找到密码计算发生的地方。
• 监视变量（Watch）：在右侧添加你想监视的变量名。如果看到像e、t、r这样的变量被赋值，可以将其添加到Watch中，观察其值的变化。当看到某个变量的值突然变成了一串像密码的字符串（如MD5哈希值或Base64串），那就接近目标了。
• 控制台交互：在Console中，你可以直接输入当前作用域内的变量名来查看其值。你甚至可以尝试执行一些代码片段，例如调用你怀疑是解密函数的那个方法，看看返回什么。

一个典型过程：通过Initiator找到请求发起函数 -> 在该函数中设置断点 -> 触发下载 -> 代码暂停 -> 查看调用栈，找到负责组装参数的函数 -> 在该函数中，发现一个类似var pwd = cryptoLib.decrypt(encryptedKey, someOtherParam)的调用 -> 将cryptoLib.decrypt这个函数作为重点分析对象。

5. 密码生成算法的解析与复现

找到了核心函数，比如一个名为_0xabc123的function，它接收加密的key和IV，返回密码。现在需要理解它的内部逻辑。

5.1 静态分析与动态执行结合

1. 复制函数：在Sources面板中，尝试将这个函数及其所有依赖的函数体复制到一个文本编辑器中。如果依赖很多，可以尝试使用“保存代码片段”功能，或者直接在该网站的上下文环境中进行测试。
2. 简化与重命名：在编辑器中，人工将一些明显的逻辑进行简化。例如，如果看到var a = 'password';，可以将其重命名为var prefix = 'password';。对于简单的操作如b = c + d，尽量理解其意图。这个过程非常耗时，需要耐心。
3. 在控制台测试：在浏览器Console中，确保你处于正确的页面上下文（通常就是当前标签页）。然后，将你整理后的函数定义粘贴进去并执行。接着，手动调用这个函数，传入你从网络请求中捕获到的真实参数（加密的key, iv等），观察输出。

   // 假设我们整理出的函数叫 calculatePassword function calculatePassword(encryptedKey, iv, fileId) { // ... 整理后的逻辑 return password; } // 从之前的Network响应中获取真实数据 var testEncryptedKey = "U2FsdGVkX1..."; var testIv = "abcdef1234567890"; var testFileId = "12345"; console.log(calculatePassword(testEncryptedKey, testIv, testFileId));

   如果控制台输出了一个字符串，并且你用这个字符串能手动打开之前下载的加密PDF，那么恭喜，算法还原成功了90%。

5.2 常见加密库识别与算法判断

前端常用的加密库有CryptoJS、Web Crypto API、forge等。在代码中搜索这些库的典型特征：

• CryptoJS：常见调用如CryptoJS.AES.decrypt(ciphertext, key, {iv: iv})；CryptoJS.MD5('message').toString()。
• Web Crypto API：使用window.crypto.subtle，方法名如decrypt、importKey，返回Promise。
• 自定义算法：有时平台会使用自定义的简单混淆，比如将字符串反转、与某个固定值进行异或、进行Base64编码解码组合等。

通过识别库和函数调用，可以判断出加密算法（如AES-256-CBC）、模式、填充方式等关键信息。这些信息对于后续用其他语言复现至关重要。

5.3 使用Python复现算法

一旦在浏览器控制台中验证成功，下一步就是用Python将逻辑重写，实现自动化。这里以最常见的CryptoJS AES解密为例。

假设我们在JS中分析出的逻辑是：密码等于用某个固定字符串作为密钥，对encryptedKey进行AES-256-CBC解密的结果。

Python复现示例：

import base64 from Crypto.Cipher import AES from Crypto.Util.Padding import unpad import hashlib def decrypt_password(encrypted_key_b64, iv_hex, secret): """ 模拟前端CryptoJS的AES解密逻辑 :param encrypted_key_b64: Base64编码的加密密钥串（可能带有'Salted__'前缀） :param iv_hex: 十六进制字符串表示的IV :param secret: 用于派生密钥的密码字符串 :return: 解密后的明文密码 """ # 1. 处理加密数据：CryptoJS的格式通常是 `Salted__` + salt + ciphertext encrypted_data = base64.b64decode(encrypted_key_b64) if encrypted_data.startswith(b'Salted__'): salt = encrypted_data[8:16] # 接下来的8字节是salt ciphertext = encrypted_data[16:] # 使用OpenSSL的EVP_BytesToKey方式派生密钥和IV（CryptoJS默认方式） key_iv = _evp_bytes_to_key(secret.encode('utf-8'), salt, key_len=32, iv_len=16) derived_key = key_iv[:32] derived_iv = key_iv[32:48] else: # 如果没有Salted头，可能直接使用提供的IV和密钥 derived_key = hashlib.md5(secret.encode()).digest() # 或其他简单派生方式，需根据JS代码确定 derived_iv = bytes.fromhex(iv_hex) ciphertext = encrypted_data # 2. 创建AES解密器 cipher = AES.new(derived_key, AES.MODE_CBC, derived_iv) # 3. 解密并去除PKCS#7填充 decrypted_padded = cipher.decrypt(ciphertext) decrypted = unpad(decrypted_padded, AES.block_size) return decrypted.decode('utf-8') def _evp_bytes_to_key(password, salt, key_len, iv_len): """模拟OpenSSL的EVP_BytesToKey函数""" from hashlib import md5 dtot = md5(password + salt).digest() d = [dtot] while len(b''.join(d)) < key_len + iv_len: d.append(md5(d[-1] + password + salt).digest()) return b''.join(d)[:key_len + iv_len] # 使用从网络请求中获取的真实数据进行测试 encrypted_key = "U2FsdGVkX19Y2q...（你的Base64数据）" iv = "abcdef1234567890" secret = "某个固定的前端密钥" # 这个需要从JS代码中分析得出 password = decrypt_password(encrypted_key, iv, secret) print(f"计算出的密码: {password}")

实操心得：CryptoJS.AES.encrypt在默认情况下会使用随机盐并进行一次EVP_BytesToKey派生，生成加密结果会自动包含Salted__前缀。这就是为什么我们经常在抓包数据中看到以U2FsdGVkX1（Base64编码的Salted__）开头的字符串。在Python端复现时，必须使用同样的密钥派生算法，否则解密会失败。如果JS代码中显式指定了key和iv对象（而不是字符串），则可能使用的是OpenSSL格式，需要按上述方式处理。

6. 完整流程串联与自动化脚本编写

理解了各部分原理后，我们可以将整个流程串联起来，写一个自动化的脚本。

6.1 流程步骤总结

1. 模拟登录/获取会话：使用requests.Session()维持登录状态，携带必要的cookies或token。
2. 请求文档加密信息：向平台的API接口发起请求，获取包含encryptedKey、iv、fileId等信息的JSON响应。
3. 执行密码生成算法：调用我们逆向并复现的Python解密函数，传入从响应中获取的参数，计算出明文密码。
4. 下载加密PDF：使用相同的会话，请求PDF文件的直接下载URL。
5. 在内存中解密PDF：如果平台是返回加密文件流，我们可以用计算出的密码和算法（如AES-256-CBC），在内存中直接解密PDF数据，然后保存为明文PDF文件。如果平台需要将密码作为参数传递给一个解密服务端，则可能需要调整步骤。

6.2 Python自动化脚本框架

import requests from your_crypto_module import decrypt_password # 导入之前写好的解密函数 class EncryptedPDFDownloader: def __init__(self, session_cookie): self.session = requests.Session() self.session.headers.update({ 'User-Agent': 'Mozilla/5.0 ...', }) # 设置登录cookie self.session.cookies.set('SESSION_ID', session_cookie) def fetch_encryption_info(self, file_url_or_id): """从平台API获取加密信息""" # 这里需要根据实际平台API构造请求 api_url = "https://platform.example.com/api/getFileEncryptionInfo" params = {'fileId': file_url_or_id} resp = self.session.get(api_url, params=params).json() # 解析响应，假设结构如下 data = resp['data'] return { 'encrypted_key': data['encryptionInfo']['key'], # Base64 'iv': data['encryptionInfo']['iv'], # Hex 'download_url': data['downloadUrl'] } def calculate_password(self, enc_info): """计算解密密码""" # 这里的SECRET需要根据逆向出的JS逻辑确定，可能是一个固定字符串，也可能是由其他参数计算得出 SECRET = "hardcoded_secret_from_js" password = decrypt_password(enc_info['encrypted_key'], enc_info['iv'], SECRET) return password def download_and_decrypt(self, file_url_or_id, save_path): """主流程：获取信息、计算密码、下载并解密""" print(f"[*] 获取文件加密信息...") enc_info = self.fetch_encryption_info(file_url_or_id) print(f"[*] 逆向计算解密密码...") password = self.calculate_password(enc_info) print(f"[+] 密码计算成功: {password}") print(f"[*] 下载加密PDF文件流...") pdf_resp = self.session.get(enc_info['download_url'], stream=True) encrypted_pdf_data = pdf_resp.content print(f"[*] 在内存中解密PDF...") # 假设是AES-256-CBC加密，且文件流就是密文 iv_bytes = bytes.fromhex(enc_info['iv']) key_bytes = hashlib.md5(password.encode()).digest() # 再次注意，密钥派生方式需与JS一致！ cipher = AES.new(key_bytes, AES.MODE_CBC, iv_bytes) decrypted_padded = cipher.decrypt(encrypted_pdf_data) # 去除PKCS#7填充 decrypted_data = unpad(decrypted_padded, AES.block_size) # 保存解密后的PDF with open(save_path, 'wb') as f: f.write(decrypted_data) print(f"[+] 文件已成功解密并保存至: {save_path}") return True if __name__ == '__main__': # 使用示例 cookie = "你的登录Cookie" downloader = EncryptedPDFDownloader(cookie) # 传入文档的ID或分享链接 downloader.download_and_decrypt("目标文档ID", "./decrypted_document.pdf")

7. 常见问题、排查技巧与法律伦理边界

7.1 逆向分析中的常见坑点

1. 密钥派生方式不一致：这是导致Python复现失败的最常见原因。CryptoJS的EVP_BytesToKey、直接使用MD5、SHA256哈希、或者PBKDF2派生，必须与前端完全一致。仔细对比JS代码中密钥和IV的生成过程。
2. 编码问题：JS中的字符串到字节的转换（如CryptoJS.enc.Utf8.parse）与Python中的str.encode('utf-8')要对应。同样，输出可能是Hex或Base64，需注意转换。
3. 混淆代码中的陷阱：混淆器可能会重写一些标准函数，或者添加无用的代码干扰分析。动态调试时，务必以实际执行的变量值为准，不要完全相信静态代码。
4. 异步操作：现代前端大量使用Promise和async/await。如果密码计算在异步回调中，需要确保你的断点设置在正确的时机，或者使用async调试技巧。

7.2 调试与排查技巧

• Console大法好：在怀疑的代码行前后插入console.log语句（在Sources面板中直接编辑代码，Ctrl+S保存），打印关键变量值。这是理解混淆代码最直接的方法。
• 重写并替换函数：在Console中，你可以重写某个函数。例如，如果你怀疑window.cryptoLib.decrypt是关键，可以将其替换为你的日志版本：

  var originalDecrypt = window.cryptoLib.decrypt; window.cryptoLib.decrypt = function(...args) { console.log('decrypt called with args:', args); var result = originalDecrypt.apply(this, args); console.log('decrypt result:', result); return result; };

• 使用debugger语句：在难以设置断点的代码位置（例如在eval执行的代码中），可以直接在代码里插入debugger;语句，浏览器执行到此处时会自动暂停。

7.3 法律与伦理考量

这是最重要的一部分。技术本身是中立的，但使用技术的行为有边界。

• 权限是前提：只对你拥有明确所有权或使用权的文档进行此类分析。未经授权分析他人的加密文档，涉嫌侵犯他人数据安全，违反《网络安全法》等相关法律法规及平台用户协议。
• 目的须正当：此类技术研究应仅限于学习密码学应用、Web安全、自动化流程等合法目的。不得用于破解他人密码、窃取商业机密、侵犯知识产权等非法活动。
• 尊重知识产权：逆向工程得到的算法逻辑，可能是平台的核心商业机密。即使你分析出来了，也不应公开披露其具体细节，尤其是用于非法目的的详细教程。分享技术思路和方法论是可行的，但应避免提供可直接攻击特定平台的“武器化”代码。
• 用于自动化与集成：一个合理的应用场景是，你公司购买了该平台的团队版，有大量内部文档需要定期自动备份到本地归档系统。手动下载并输入密码效率低下，因此你开发了这个自动化脚本，仅用于处理你们团队自身拥有权限的文档。这是提升效率的合理技术实践。

最后一点个人体会：前端加密更像是一种“防君子不防小人”的轻量级保护。它增加了直接获取明文内容的难度，但无法阻止拥有前端代码执行权限的用户。真正的敏感数据加密应该在后端完成，前端仅作为交互界面。这次实战与其说是一次“破解”，不如说是一次对Web应用安全架构的深度体检，它让我们更清楚地认识到数据在传输和客户端处理过程中的风险点。对于开发者而言，如果真想保护内容，关键逻辑和密钥绝不能下放到客户端；对于安全研究者而言，理解这些模式的局限性则是构建更全面安全观的基础。