Spider Proxy内置20多款加解密工具，缩短抓包到解密链路

Spider Proxy 内置 20 多款常用加解密辅助工具，这个功能点听起来像是"顺手加的"，但真正在接口调试、数据清洗、安全自查这些场景里滚过几年的同行都清楚，抓包和看懂抓到的内容之间，往往隔着一段非常磨人的手工活。你抓到一串U2FsdGVkX1+...开头的字符串，或者一段a=3f8c9...&sign=...的请求体，工具能帮你把报文原样展示出来，但报文里的参数到底是 Base64、Hex、还是 AES 密文，密钥藏在哪个字段，签名怎么算出来的，这些都得靠人一点点试。Spider Proxy 把 20 多款加解密辅助工具直接嵌进了代理工作台，本质上是想把"抓包"到"读懂"这段距离压缩到最短。这篇内容适合几类人看：做接口联调的后端和前端、写采集脚本的数据工程师、做自有系统安全自查的运维和测试，以及刚接触编码转换、还没建立起"参数直觉"的新手。接下来的内容不讲空话，按工具家族拆解、按还原链路推演、按踩坑清单收口，尽量把每一步的"为什么这么做"说透。

1. 为什么加解密工具要内置在抓包代理里

1.1 抓包到解密之间那段被忽略的手工断层

大多数人第一次接触抓包，关注点都在"能不能抓到"上：证书装没装、请求走没走代理、有没有被压缩。等这一关过了，真正的困难才浮现——抓到的报文看不懂。一个典型场景是某接口的请求体长这样：

{ "bizData": "eyJvcmRlcklkIjoiMjAyNTA5MTIzNCIsImFtdCI6MTk5LjAwfQ==", "sign": "9f2c1e7a4b8d3f6e0a5c2b9d1e8f3a7c", "ts": 1757589123 }

表面看是三个字段，实际上套了三层：bizData是 Base64，里面还藏着一个 JSON；sign是 32 位十六进制，大概率是 MD5 或者 SHA-1 截断；ts是秒级时间戳。要把它彻底读懂，你得先 Base64 解码，再把解码后的 JSON 格式化，接着反推sign的拼接规则，最后验证时间戳是不是参与签名。

这些动作单独看都不难，难在它们要在三四个工具之间来回切换：浏览器开一个在线 Base64 解码页、再开一个时间戳转换页、本地再跑个 Python 脚本算 MD5。每切一次窗口，上下文就断一次，思路被打断的成本远高于操作本身的成本。尤其在参数多、字段嵌套深的接口里，一次调试可能要来回切几十次，效率损失非常可观。

把加解密工具内置进代理工作台，解决的就是这个断层。选中一段文本，右键直接解码，结果原地展开，不用跳出去，不用复制粘贴到别的页面。这个体验差异，用过的人基本回不去了。

1.2 外挂式工具箱的三个现实问题

在线工具站不是不能用，但在真实工作流里有三个绕不开的麻烦。

第一个是数据外泄风险。很多接口的请求体里带着用户标识、手机号掩码、订单号、内部业务字段，把这些内容整段贴到第三方在线解码站点，本质上是把业务数据交给了不受你控制的服务器。有些站点还会把输入内容写进日志甚至用于训练，这在合规要求严格的团队里是不能接受的。本地跑脚本虽然安全，但每次都要开终端、改参数、跑命令，繁琐程度又劝退。

第二个是环境依赖。本地脚本依赖 Python 版本、pycryptodome之类的三方库、编码环境变量，换台机器就可能报错。团队协作时，你写好的脚本同事跑不起来，是极常见的事。

第三个是结果不可复现。在线工具站今天能用明天可能就改版、加广告、限速，甚至直接关停。你昨天验证过的解码路径，今天打不开了，排查链路就断在那里。

内置工具箱的价值就在于：数据不出本机、不依赖外部环境、路径和结果稳定可复现。这三点听起来朴素，但恰好是日常调试中最容易被忽略、又最容易在关键时刻掉链子的地方。

1.3 内置工具箱的边界：它不做什么

有一点必须说清楚：内置加解密工具是"辅助"，不是"万能钥匙"。它不会自动帮你猜出密钥，不会替你判断某个哈希用的是哪种盐值拼接方式，更不会把一段无密钥的强加密数据变成明文。

它能做的是把那些确定性的、机械的转换动作做到极致——给定输入和参数，立刻给出输出，并支持反向验证。至于密钥从哪来、签名规则怎么拼、加密模式是 CBC 还是 ECB，这些仍然依赖你对业务逻辑的理解和逐步试错。

所以正确的预期是：工具箱把"体力活"承包了，把"脑力活"留给你。理解这个边界之后，后面的内容才不会跑偏——我们讨论的是如何用工具加速判断，而不是指望工具替你完成判断。

提示：任何接口的加解密还原，都应限定在你拥有或已获得明确授权的系统范围内进行。对第三方系统的未授权分析，既不合规也不专业。

2. 二十多款工具的家族图谱：从编码到签名的完整覆盖

2.1 编码转换家族：Base64、URL、Hex、HTML 实体与 Unicode

编码类工具是使用频率最高的一档，因为绝大多数"看不懂"的字符串，第一层都是编码而不是加密。编码和加密有个本质区别：编码是可逆且无密钥的，任何人拿到字符串都能还原；加密是需要密钥的，没有密钥理论上无法还原。这个区别决定了排查顺序——永远先试编码，再考虑加密。

Base64 是出现最多的一种。它的原理是把每 3 个字节（24 位）重新切成 4 个 6 位单元，每个单元映射到 64 个可打印字符之一，末尾用=补齐。这个原理带来的几个实战特征值得记住：Base64 编码后的长度一定是 4 的倍数；常见字符集是A-Za-z0-9+/，URL 安全变体把+和/换成-和_并去掉填充符=；以eyJ开头的 Base64 解码后基本可以确定是 JSON，因为{"这两个字符的 Base64 就是ey。

URL 编码（百分号编码）常见于 GET 查询串和表单提交，中文在不同字符集下结果完全不同：UTF-8 下"中"是%E4%B8%AD，GBK 下是%D6%D0。这个差异是后文踩坑章节的重点之一。

Hex 编码把每个字节转成两位十六进制，长度是原始字节的两倍。哈希值、密钥、二进制摘要普遍用 Hex 表示。这里有个小细节：Hex 大小写不影响数值，但有些签名校验代码做字符串比较时会区分大小写，导致"明明算对了却验签失败"。

HTML 实体和 Unicode 转义（\u4e2d）则常见于被前端框架转义过的内容，尤其是富文本、模板渲染结果和某些老式接口的返回体。

2.2 摘要与签名家族：MD5、SHA 系列与 HMAC

摘要类工具的产出是哈希值，特点是单向不可逆、定长、输入微小变化导致输出雪崩式改变。常用成员包括 MD5（128 位，32 位十六进制）、SHA-1（160 位，40 位十六进制）、SHA-256（256 位，64 位十六进制）、SHA-512。

看到 32 位十六进制，MD5 是第一嫌疑；40 位是 SHA-1；64 位是 SHA-256。这个长度直觉能帮你快速缩小范围。

但真正的工作量不在选算法，而在还原拼接规则。大量接口的签名是这么算的：

# 常见的签名拼接方式示例 import hashlib params = {"bizId": "10086", "ts": "1757589123", "nonce": "a1b2c3"} raw = "&".join(f"{k}={v}" for k, v in sorted(params.items())) + "&key=YOUR_SECRET" sign = hashlib.md5(raw.encode("utf-8")).hexdigest() print(sign)

规则里藏着很多变量：参数是否按字典序排序、是否包含空值参数、是否带key后缀、拼接分隔符是&还是|、是否对结果再取大写、是否截取前 16 位。这些组合起来可能有几十种，逐一手工试很痛苦。工具箱的价值是让你能快速对同一个输入切换不同算法和大小写，把"试错"这件事的边际成本降到接近零。

HMAC 则是在哈希基础上加了一把密钥，HMAC-SHA256在开放平台接口里出现频率极高。它的输出同样是 Hex 或 Base64 两种表示，这个表示差异也会导致验签失败。

2.3 对称与非对称加密家族：AES、DES、RSA 的参数拆解

加密类工具是难度最高的一档，因为它的输出正确与否取决于一串参数的完全匹配，错一个就全是乱码。以 AES 为例，必须同时确定四件事：

• 算法模式：ECB、CBC、CTR、GCM 等
• 填充方式：PKCS7、PKCS5、ZeroPadding、NoPadding
• 密钥长度：16 字节（AES-128）、24 字节（AES-192）、32 字节（AES-256）
• 初始向量 IV：CBC 等模式必需，固定 16 字节，ECB 模式不需要

这四项只要有一项不对，输出就是一堆不可读的二进制。所以加密类排查的核心思路不是"猜"，而是"逐一固定变量"：先假设 CBC + PKCS7 + 16 字节密钥这个最常见组合，跑一次看结果是否是可打印字符；如果不是，再换模式。

DES 和 3DES 在老系统里还大量存在，密钥分别是 8 字节和 24 字节，安全性已经明显不足，但在存量系统里仍然绕不开。工具箱里保留这些算法，主要是为了兼容老接口，而不是推荐使用。

非对称加密以 RSA 为主，特点是公钥加密私钥解密、私钥签名公钥验签。RSA 的参数坑更多：密钥是 PEM 格式还是裸 Base64、填充是 PKCS1 还是 OAEP、输出是 Base64 还是 Hex、明文的编码是 UTF-8 还是 GBK。RSA 还有个特性需要注意——同样的明文用同一个公钥加密两次，结果可能不同（PKCS1 v1.5 和 OAEP 都带随机填充），所以不能用"输出是否一致"来判断加密是否正确，只能靠解密回验。

2.4 令牌与结构化数据家族：JWT、序列化串与时间戳

JWT 是近十年最常见的令牌格式，结构非常规整：三段 Base64URL 用.连接，分别是 header、payload、signature。header 里写着算法（HS256 或 RS256），payload 里是业务声明（用户 ID、过期时间、角色）。

解析 JWT 最大的价值不是看内容——内容本来就是 Base64，随便一个工具都能解——而是通过 header 里的alg字段快速判断签名算法是"对称密钥"还是"非对称密钥"。这个判断直接决定了你后面要不要去找密钥：HS256 意味着签名密钥是一个共享字符串，通常藏在客户端或服务端配置里；RS256 意味着签名用私钥、验签用公钥，公钥往往可以在某个接口公开获取。

时间戳转换也是高频需求。秒级时间戳是 10 位，毫秒级是 13 位，这个位数差异是最快的识别方式。时间戳在签名里出现时，还涉及一个隐蔽问题：服务端校验时间戳的有效窗口通常是 5 到 15 分钟，如果你复现请求时用了旧的时间戳，即使签名算对了也会被拒绝，报错信息却可能是"签名错误"，非常容易误导排查方向。

结构化数据这块主要涉及 JSON 压缩、gzip、deflate 以及 Cookie 的序列化格式。有些接口的请求体是把 JSON 压缩后再 Base64，解码出来是一堆乱码，只有再做一次解压才能看到明文。这个"多层嵌套"是新手最容易卡住的地方。

3. 一条加密接口的还原链路：从密文到可读参数

3.1 第一步：判定这段密文属于哪个家族

拿到一段陌生字符串，先做分类判断而不是急着解码。判断顺序建议固定下来：先看字符集，再看长度，最后看结构特征。

纯A-Za-z0-9+/=且长度为 4 的倍数，优先按 Base64 试。纯0-9a-f且长度为 32、40、64，优先按哈希试。包含%XX的按 URL 编码试。包含明显的{、}、:、,，直接当 JSON 解析。长度不规整、含大量不可打印字符，说明可能是原始二进制被某种方式转写过，需要先看它在报文里的表示形式是 Hex 还是 Base64。

这里有个很实用的技巧：很多密文虽然经过 AES 加密，但传输时会再套一层 Base64，因为原始密文是二进制，不能直接放进 JSON。所以你看到的是"Base64 的壳，AES 的芯"。判断方法是先 Base64 解码，如果得到的字节长度正好是 16 的倍数，且字节分布看起来随机，那基本可以确定里面是分组加密的结果。

另一个判断依据是上下文。如果这个字段名叫sign、signature、hash，它几乎一定是摘要类；叫data、bizData、payload、encrypt，更可能是加密类；叫token、jwt，按令牌处理。

3.2 第二步：定位密钥与 IV 的藏身之处

密钥不会凭空出现，它一定藏在某个你能拿到的地方。常见的藏身点有这么几类。

客户端代码里的硬编码常量。这在移动端和 Web 前端里最常见，字符串往往伪装成"配置项"，名字可能是appSecret、aesKey、salt。长度上，AES 密钥在硬编码时经常写成 16 位可读字符串，比如1234567890abcdef，或者是某个 MD5 值的前 16 位。

接口返回的其他字段。有些设计会把 IV 或随机因子作为一个独立字段随请求一起发送，比如iv、nonce、salt。这类设计的安全性依赖于 IV 随机且不重复，本身思路是对的，只是实现上经常出错，比如固定了 IV。

配置接口或初始化接口。部分客户端启动时会调一个配置接口，返回里带着加密参数。抓完整流程比只看单个请求更容易发现这类线索。

默认值。这一条最容易被忽略：不少实现的密钥就是1234567890123456这种测试值，或者全零的 IV。在自有系统自查时，用默认值试一轮经常一击命中。

定位密钥的实操建议是：把整个抓包会话按时间顺序排好，从登录/初始化请求开始顺读，把出现的所有字符串常量、看起来"没被使用"的字段都记下来，再逐一作为密钥候选去试。

3.3 第三步：填充模式与字符集的交叉验证

假设你已经确定了算法和密钥，接下来最容易出问题的是填充和字符集。

填充方面，AES 分组长度是 16 字节，明文必须补齐到 16 的整数倍，PKCS7 是最普遍的填充方式。如果你解密出来的明文尾部带着一串\x08\x08...或者\x0b\x0b...这样的字符，恭喜，说明密钥和模式都对了，只是填充处理没做干净——那些字节就是填充值。反过来，如果你用 NoPadding 解出来的结果是可读的但最后不完整，说明原本是有填充的，只是被截断了。

字符集方面，解密得到字节后，还需要决定用哪种编码解释成字符串。UTF-8 是默认选择，但老系统里 GBK 也很常见。判断方法很简单：UTF-8 解码失败（抛异常或出现替换字符）而 GBK 能正常解出中文，就说明是 GBK。

这三个变量——模式、填充、字符集——构成一个三维搜索空间。理论上组合数是 4×4×2 左右，实际用工具跑一轮也就几十次，几分钟能穷举完。这也是为什么要在工具箱里做而不是手工——手工穷举几十次会疯。

3.4 第四步：把结果回填进请求做闭环验证

解出来只完成了一半，闭环验证才是真正确认。闭环的意思是：你按照推测的规则，用工具重新生成一份合法的请求参数，发出去，服务端正常响应。

这个步骤经常能暴露前面所有步骤里隐藏的错误。比如你把 Base64 解出来了，JSON 也格式化好了，但重新拼回去的时候忘了加 padding 的=，服务端照样报错。再比如签名你算对了，但时间戳用的是解出来的旧值，超出校验窗口，依然失败。又或者参数排序规则你猜的是升序，实际是降序，只在参数数量大于 1 时才会暴露差异。

做闭环验证时，建议把变量一次只改一个。先固定所有参数用原始值，只替换其中一个，看服务端是否还接受。如果能接受，说明这个字段的校验不严格；如果不能，说明它确实参与校验。这个方法能快速画出"哪些字段参与签名"的全貌图，比一上来就改一堆参数高效得多。

4. 那些年踩过的坑：编码错位与参数误配的排查清单

4.1 Base64 变体与 URL 安全字符集的兼容问题

Base64 的坑集中在三个地方。

第一是填充符。标准 Base64 用=补齐到 4 的倍数，但很多场景会去掉=传输，因为=在 URL 和 Cookie 里需要转义。去掉填充后，长度可能不是 4 的倍数，某些严格的解码器会直接报错。遇到这种情况，自己在末尾补=到 4 的倍数即可，补 0 到 2 个。

第二是 URL 安全变体。标准字符集里的+和/在 URL 安全变体里是-和_。如果你把 URL 安全变体的字符串用标准解码器解，通常会解出错误的字节，而且不报错——这才是最坑的，因为错误是静默的。判断依据是字符串里有没有-或_。

第三是空白字符。从网页或日志里复制出来的 Base64 字符串，经常夹带换行符、空格、制表符。Base64 解码器对空白字符的处理不一致，有些自动忽略，有些报错。稳妥做法是解码前先去掉所有空白。

4.2 AES 模式、填充与密钥长度的三重匹配

AES 的坑比 Base64 深得多，因为它的错误表现形式不是报错，而是"输出一堆乱码"。

最常见的问题是密钥长度不对。AES 只接受 16、24、32 字节密钥，如果你拿到的密钥字符串是 20 位，直接塞进去会报错。这时有两种常见处理：截取前 16 位，或者用 MD5 计算后取 32 位十六进制字符串作为密钥。这两种做法在实际项目里都存在，需要分别试。

第二个问题是 IV 的处理。CBC 模式必须有 IV，如果代码里把 IV 固定成 16 个零字节，那你在工具里也要用全零 IV。有些实现会把密钥的前 16 字节直接当 IV 用，这也是一种常见做法。还有些实现把 IV 拼在密文的头部一起传输，解密时要先切出前 16 字节。

第三个问题是输出编码。加密后的字节用 Base64 表示还是 Hex 表示，这个差异会导致你拿到的"密文"形式完全不同。Hex 形式的密文长度是字节数的两倍，Base64 形式大约是字节数的 1.34 倍。看长度就能大致判断。

第四个问题是 ECB 和 CBC 的混淆。ECB 模式不需要 IV，且相同明文块会产生相同密文块。有个快速判断技巧：如果密文里出现了重复的 16 字节片段，很可能是 ECB；如果完全没有重复，更可能是 CBC。

4.3 时间戳、时区与随机数带来的"看似解错"

有一类问题非常具有欺骗性：所有参数都解对了，但请求就是不成功，而报错信息偏偏指向"签名错误"。

排查这类问题要优先看时间。服务端的时间戳校验窗口通常很短，5 到 15 分钟不等。你从抓包里拿到的请求，可能已经是半小时前的，直接复现必然失败。解决办法是用当前时间重新生成时间戳，再按规则重算签名。

时区也是隐蔽杀手。有些实现用的是本地时间（比如东八区），有些用 UTC。两者的差值恰好是 8 小时，时间戳数值上差 28800 秒。如果你算签名时用的时间基准不对，签名必然错，但报错信息不会告诉你原因。

随机数（nonce）的问题在于，有些服务端会记录已使用的 nonce，重复提交会被拒绝。这种情况下，你必须每次都生成新的 nonce。判断依据是：同样的请求第一次成功、第二次失败，就高度怀疑是 nonce 去重。

还有一个容易被误判的点是参数顺序。JSON 对象在大多数语言里是无序的，但签名往往要求按字典序拼接。如果你的代码遍历顺序和签名规则不一致，参数越多越容易出错。调试时建议打印出实际参与签名的原始字符串，肉眼比对，比反复试错快得多。

4.4 哈希不可逆时的误判与预计算表思路

新手最容易犯的错，是试图"解密"一个 MD5。哈希是不可逆的，不存在解密这回事。你能做的只有两种：猜原始输入，或者查预计算表。

预计算表的思路是把常见输入（比如短数字串、常见单词、常见组合）的哈希值提前算好存起来，拿到哈希后反查。

在实际工作里，预计算表更多用于自有系统的弱口令自查：批量把你负责的系统里的密码哈希和表比对，发现弱口令的账号，推动整改。这是很标准的运维自查动作，不涉及任何越界。

需要提醒的是，加盐（salt）会彻底破坏预计算表的有效性，因为同一个密码在不同盐值下哈希完全不同。这也是为什么现代密码存储一定要加盐。如果在自有系统里发现密码是"裸 MD5"存储的，那不只是弱口令问题，而是存储方案本身需要升级。

5. 把工具箱用成生产力：组合链路、批量处理与协作规范

5.1 组合链路：把多步转换串成一次点击

单步工具谁都有，真正的效率差异体现在"链路"上。前面提到的那个三层结构——Base64 外壳、AES 内核、内部 JSON——如果每次都手动走三步，一天下来光切窗口就能耗掉大量时间。

合理的做法是把高频链路固化下来。比如"Base64 解码 → 判断是否为密文 → 按预设参数 AES 解密 → UTF-8 解码 → JSON 格式化"，这五步如果能一键完成，调试节奏会完全不同。

要固化链路，前提是你已经确定了一组稳定的参数。参数不确定的时候不要急着固化，否则后面每改一次参数就要重配一次链路，反而更慢。建议的判断标准是：同一套参数连续成功还原三个以上不同请求，就可以固化。

固化的另一个好处是团队共享。你把链路参数导出给同事，他拿到后直接能用，不需要重新走一遍试错。这在多人协作排查同一个接口时特别有价值——一个人踩完坑，其他人不用重复踩。

5.2 批量处理与结果留痕

单个请求的调试做完之后，往往会面临一个更大的任务：这个接口有几百个参数组合，或者有几十个接口用了同一套加密规则，需要批量处理。

批量处理的关键是"输入输出的规范化"。把待处理的字符串整理成一行一条，批量解码后按行对应输出，这样便于后续比对。要特别注意批量处理时的异常隔离：某一行格式不对不应该导致整批中断，而应该单独标记出来，继续处理剩下的。

结果留痕这件事，很多人不重视，但在排查长链路问题时非常关键。建议每次还原都把"输入、参数组合、输出"三样记录下来，格式随意但结构要稳定。当你在第 20 次尝试时才成功时，前 19 次的记录能帮你快速判断规律——比如你会发现前 10 次失败都是因为没有补 Base64 填充，这个规律能直接指导后续的排查方向。

5.3 授权边界与数据合规的自查习惯

最后必须把这件事说清楚：加解密工具本身是中性的，它的合规性取决于你用在哪里。

给自己定几条硬规则会省掉很多麻烦。第一，只处理你有明确权限的系统——自有的、公司内部的、或者白纸黑字授权你测试的。第二，敏感数据不外传，包括不贴到公共在线工具站、不写进公开的复现脚本、不放进公开仓库。第三，调试用真实数据的脱敏版本，用假订单号、假用户 ID 走通链路的每一步，确认无误后再用真实数据验证。第四，排查记录也别随手丢，里面有接口路径、参数结构、密钥线索，属于需要管控的资料。

这几条规则不是为了应付流程，而是在实际操作中真的能降低风险。脱敏数据调试有个额外好处：假数据你能记住，真数据你记不住，用假数据走链路时判断"结果对不对"会容易很多。

我个人在做链路还原时有个习惯：先在工具里把完整链路走通，然后把每一步的参数和中间结果单独整理成一份可复现的笔记，最后只保留笔记，清掉临时数据。这份笔记在下一次遇到同类加密时，往往能省掉大半的排查时间——因为加密实现的套路就那么几种，你踩过的坑，下次大概率还会以稍有不同的形式出现。 another