1. 为什么我要把二十多款加解密工具塞进同一个工作台1.1 从六个浏览器标签页说起做过接口联调和安全测试的人都懂那种感觉你抓到一个请求参数里躺着一个sign一个timestamp还有一个 Base64 一长串的data。接下来你的屏幕就变成了这样——左边开着抓包工具右边开着在线 MD5 计算站中间夹着一个 JWT 解析页再往后翻是时间戳转换、AES 在线解密、进制转换。每验证一个猜测就要复制一次、切换一次窗口、粘贴一次、比对一次。一个下午下来真正用在思考上的时间可能只有三分之一剩下的全耗在搬运数据上。Spider Proxy 这类工具的加解密辅助面板把这个过程压缩了。它内置了二十多款常用的加解密、编解码、摘要计算工具抓包抓到的内容可以直接丢进面板里处理不用出窗口、不用联网、不用担心把真实的业务数据粘到某个来路不明的在线网站上。标题里说的加解密辅助工具重点其实不在加密有多强而在辅助两个字——它是给分析者用的顺手小工具不是让你造密码系统的。我自己的感受是这类工具箱真正的价值是把验证一个猜想的成本从三十秒降到三秒。人的分析思路是连续的一旦被打断很多灵感就没了。工具切换本身就是一种打断。下面我就按实际使用顺序把这些工具的分类、参数细节、踩坑记录和典型场景捋一遍尽量写到能直接照着操作的程度。提示本文涉及的工具清单基于常见加解密工具集的通用分类整理不同版本的 Spider Proxy 在具体条目上会有增删重点是理解每一类工具的适用边界和参数含义而不是死记某个按钮的位置。1.2 二十多款工具的能力地图把工具箱里的项目按用途分一下大概是这么几类。这个分类不是随便切的它对应的是分析时先看什么、再看什么的顺序。分类代表工具典型使用时机编码转换Base64 / Base64URL、URL 编解码、Hex、Unicode 转义、HTML 实体、进制转换、ASCII 码表拿到一串看起来像乱码的字符串先判断它是不是只是换了种写法摘要哈希MD5、SHA-1、SHA-256、SHA-512、HMAC 系列、国密 SM3验证签名、校验参数完整性、比对文件指纹对称加密AES、DES、3DES、国密 SM4请求体/响应体整体加密密钥一般硬编码在前端非对称加密RSA 加解密、RSA 签名验签、密钥格式转换授权链路、支付回调、证书相关分析凭证解析JWT 三段拆解、Cookie 结构分析会话凭证分析、越权测试前的信息收集古典与趣味密码凯撒、栅栏、维吉尼亚、摩斯、培根、ROT13、键盘位移、JS 混淆还原CTF 题、隐写题、老式混淆脚本压缩与序列化Gzip、Deflate、zlib 解压、JSON 格式化与转义响应体解压后才发现是加密数据或者反过来这张表我建议你按从外到内的顺序去用先判断编码再判断摘要再判断加密。很多人一上手就直接冲 AES结果解了半天发现那串东西只是 Base64 套了一层 Gzip白白浪费时间。1.3 这套工具箱适合谁一句话说清楚适用人群所有需要看懂一串不认识的字符串的人。做接口联调的后端和前端、做安全测试的渗透人员、做爬虫和数据分析的工程师、打 CTF 的学生、甚至只是排查一个第三方回调为什么验签失败的人都会用到。它不要求你懂密码学的数学原理但要求你懂每个参数的含义——密钥多长、向量要不要、填充怎么选。这些才是真正卡人的地方也是我下面要重点讲的。2. 工具箱的整体设计思路拆解2.1 编码、摘要、加密为什么必须分成三层很多人第一次看到工具箱里同时有 Base64 和 AES会觉得这不都是加密吗。其实这是两个完全不同层面的东西混在一起判断会出大问题。编码不是加密它没有密钥。Base64、URL 编码、Hex、Unicode 转义这些只是换一种表示方式任何人拿到都能还原目的是让数据能安全地在文本协议里传输比如 URL 里不能直接放二进制。所以你看到一串aGVsbG8第一反应应该是这是编码直接解就行。摘要哈希是单向的理论上不可逆。MD5、SHA 系列都是把任意长度输入压成固定长度输出用来做完整性校验或签名。你不能解密一个 MD5只能去猜原文然后比对结果或者查彩虹表。实测中加盐salt的存在让彩虹表基本失效所以遇到 MD5 对不上通常不是算法错是拼接方式没猜对。加密是可逆的但它带了密钥和一堆参数。AES、RSA 这些密钥、模式、填充、初始向量少一个都解不出来。工具箱把这三层分开摆其实是逼着你在动手前先做一次判断。这个判断做对了后面就顺做错了会一直在错误的路上打转。2.2 工具面板和抓包流量之间的数据流转一个顺手的设计是工具面板和抓包列表之间的联动。常见的做法有两条路径正向在抓包详情里选中一段字符串右键直接送进某个工具省掉复制粘贴。这在处理超长参数时特别有用因为手工复制很容易漏掉首尾字符或者带上换行。反向在工具里处理完的结果可以回填到重放请求里直接验证我算出来的 sign 提交上去服务端认不认。这一步是闭环的关键很多在线工具做不到。我踩过的一个坑是从网页上复制 Base64 字符串时很容易带上看不见的换行或者全角空格。工具里解码失败你以为是算法不对其实只是多了个空格。所以能右键发送就别手工复制这个习惯能省下大量排查时间。2.3 为什么坚持不做一键自动解密有些工具会宣传自动识别加密方式并解密。听起来很美实际使用中我基本不用。原因有三个第一自动识别靠的是特征匹配比如看到 32 位十六进制就猜 MD5、看到 64 位就猜 SHA-256。但真实业务里一串 32 位十六进制可能是 MD5也可能是一个 ID、一个去掉横线的 UUID、一个自定义的 Base62 编码。猜错了还不如不猜。第二自动解密会掩盖参数细节。它帮你调好了模式和填充你确实拿到了明文但你不知道它用的是什么模式。等你需要自己写脚本复现的时候还是得从头试一遍。第三安全性上自动往往意味着上传到云端分析。业务数据不该离开本地。所以更合理的心态是把工具箱当成一个计算器你自己决定按哪些键它只负责算得快、算得准。3. 核心工具逐个拆解参数、边界与实操要点3.1 编码类Base64 家族的三种变体和它的坑Base64 是出现频率最高的编码。它的原理是把每 3 个字节24 位拆成 4 组 6 位每组映射到一个可打印字符码表是 A-Z、a-z、0-9、、/。因为 24 能被 6 整除所以长度天然是 4 的倍数不够的部分用补齐。这就是为什么你看到 Base64 结尾经常有一两个等号。实际使用中有三个变种必须分清标准 Base64字符集含和/。放到 URL 里会因为被解释成空格而出问题。Base64URL把换成-、/换成_常用于 JWT 和 URL 参数。去填充 Base64把结尾的删掉JWT 就是这种。判断方法很简单如果解码报错先看有没有-和_有就切 Base64URL如果长度不是 4 的倍数就补再试。工具面板一般有这几个选项切换一下就行不用手工改字符。URL 编码的重点是分清两种空格%20和。前者出现在路径和查询串里后者出现在表单提交的 body 里。还有一个容易被忽略的点中文在不同编码下转出来的%XX序列是不一样的。UTF-8 下一个汉字通常是三个字节GBK 下是两个字。所以解码出来的中文是乱码先怀疑编码集选错了而不是数据被加密了。十六进制要注意有没有前缀0x、有没有空格或冒号分隔。48656c6c6f和48 65 6c 6c 6f和0x48,0x65是同一个东西的三种写法。处理二进制数据比如 AES 的密文时十六进制和 Base64 是两个最常用的容器。3.2 摘要与哈希MD5、SHA、HMAC 和加盐的顺序问题摘要工具里最常被问的就是为什么我算出来的 MD5 跟服务端的不一样。这里基本可以按下面的顺序排查输出大小写MD5 是 32 位十六进制服务端可能用大写。工具里通常有大小写切换。拼接顺序是参数串 密钥还是密钥 参数串很多签名规则是前者但反过来的也有。分隔符参数之间用什么连、|、空字符串还是。空值参数参不参与这个最坑有的接口会把空值参数也排进去有的直接过滤掉。参数排序规则通常是按参数名字典序但大小写敏感与否会影响结果。是否对值做了 URL 编码再拼中文和特殊字符在编码前后哈希结果完全不同。HMAC和普通哈希的区别在于它把密钥当成一个正式的输入参与运算而不是简单地拼在末尾。HMAC-MD5、HMAC-SHA256 在 API 签名里非常常见。工具里选 HMAC 的时候一定要把密钥填到密钥字段不要填到内容里否则算出来的一定不对。国密 SM3现在在政务、金融类系统里出现得越来越多。它输出 256 位和 SHA-256 长度一样都是 64 位十六进制。光看长度分不出来需要结合业务背景判断。这类系统往往还配套 SM2非对称和 SM4对称遇到一套就基本是一整套。3.3 对称加密AES / DES / SM4 的模式、填充与密钥对称加密是整包里最容易出错的部分因为它有四个必须同时正确的参数。密钥长度。AES 支持 128、192、256 位也就是 16、24、32 字节。DES 名义上 64 位密钥但每个字节有一位校验位实际有效强度是 56 位。SM4 固定 128 位。如果你拿到的密钥字符串是 16 个字符那大概率是 AES-12832 个字符就是 AES-256。注意这里说的是字节如果密钥里有中文一个汉字占三字节UTF-8长度要按字节算不是按字符数算。工作模式。模式是否需要 IV特点常见场景ECB不需要相同明文块加密结果相同能看出数据规律老系统、教学示例CBC需要每个块先和前一密文块异或最常见绝大多数业务接口CFB / OFB / CTR需要流式处理适合不定长数据少部分移动端GCM需要带认证标签能防篡改新系统、安全要求高的场景ECB 有个非常直观的特征如果明文是重复结构比如一堆相同字符的 JSON加密后密文里会出现重复的 16 字节块。你可以在工具里把密文按 16 字节切开看如果有明显重复基本就是 ECB。这是判断模式最快的一招。初始向量 IV。CBC 模式下 IV 长度必须等于分组长度AES 是 16 字节DES 是 8 字节。IV 的常见来源有三种硬编码在代码里、和密文一起拼在开头、每次请求随机生成放在参数里。第三种最规范遇到的话你要先从参数里把 IV 切出来。填充方式。PKCS7AES 里也常写作 PKCS5是最普遍的还有 ZeroPadding用 0 补齐和 NoPadding要求明文本身就是 16 的整数倍。判断技巧如果你的密文长度不是 16 的倍数那要么不是 AES要么是流模式。解密失败时把填充方式依次试一遍是最快的排查手段。DES 和 3DES现在主要出现在老系统里。3DES 的密钥是 24 字节。遇到老系统先试 DES再试 3DES。3.4 非对称与凭证RSA 和 JWT 的解析思路RSA有两个方向必须分清公钥加密、私钥解密用于保密比如前端用公钥加密密码再提交。私钥签名、公钥验签用于防篡改和身份确认比如支付回调验签、JWT 的 RS256。密钥的格式也很讲究。PEM 格式是一段 Base64头尾有-----BEGIN PUBLIC KEY-----这样的标记。BEGIN PUBLIC KEY是 PKCS#8 格式BEGIN RSA PUBLIC KEY是 PKCS#1 格式两者不能直接混用工具里一般有格式转换功能。私钥也是同理BEGIN PRIVATE KEY对应 PKCS#8BEGIN RSA PRIVATE KEY对应 PKCS#1。还有一点RSA 单次能加密的数据长度受密钥长度限制2048 位大概只能加密 245 字节。所以真实业务里不会用 RSA 加密整个报文而是用它加密一个对称密钥这个做法叫数字信封真正的大数据交给 AES 处理。理解这一点你在抓包里看到RSA 加密的短串 AES 加密的长串就不会觉得奇怪了。JWT的结构是header.payload.signature三段之间用点分隔。前两段是 Base64URL 编码的 JSON第三段是签名。工具里拆开之后你能直接看到alg签名算法和 payload 里的业务字段。这里有个必须记住的点payload 只是 Base64 编码不是加密。任何人都能解开看内容所以里面绝对不能放敏感信息。我见过不少系统把用户手机号、内部 ID 甚至角色标识明文放进 payload这等于把信息直接摊开给人看。另外签名算法字段alg是可以被篡改的。老式的 HS256 密钥如果太弱比如就是几个字母在本地做字典比对是可行的。工具里一般会提供密钥测试功能。但请务必注意这类操作只能在你自己拥有授权的系统上做未经授权的测试是明确不能碰的。3.5 古典密码与趣味编码CTF 场景里的补充弹药这部分工具平时用得不多但在 CTF、隐写题、老式混淆脚本里出场率极高。凯撒密码是字母表位移特征是只用字母、保持词频分布。工具里通常可以直接列出所有 25 种位移结果肉眼找可读的那一行就行。栅栏密码是按行读写的换位密码常见分栏数是 2 到 8挨个试。摩斯密码是点和划长这样.... . .-.. .-.. ---。注意工具里通常支持自定义分隔符因为实际题目里分隔符可能是空格、斜杠、或者干脆没有。培根密码把每个字母映射成 5 位二进制表现为两组不同的符号比如大写/小写、A/B。特征是长度是 5 的倍数。ROT13是凯撒位移 13 的特例因为位移 13 两次会回到原文所以加密和解密是同一个操作。JS 混淆还原针对的是那些用\x、\u、eval、数组下标拼字符串的老式混淆。这类代码的特征是满屏十六进制和 Unicode 转义工具可以直接把转义部分还原成可读字符剩下的靠肉眼和格式化工具处理。这类工具的价值在于快速排除一段字符串试了凯撒、栅栏、Base64 都不对你就能安心回到现代加密的思路上而不是心里一直悬着。4. 四类高频场景的完整实操走法4.1 场景一接口 sign 签名逆推这是最常见也最耗时的一类。假设你抓到一个请求POST /api/v1/order/list Content-Type: application/json { page: 1, size: 20, userId: 10086, timestamp: 1735689600, sign: e10adc3949ba59abbe56e057f20f883e }我看到这个sign的第一反应32 位十六进制MD5 的概率很大。接下来按这个流程走第一步确定参与签名的字段。把业务参数按名字字典序排好page、size、timestamp、userId。注意sign自己肯定不参与。第二步猜拼接格式。常见的几种page1size20timestamp1735689600userId10086 page1size20timestamp1735689600userId10086 page1,size20,timestamp1735689600,userId10086第三步猜是否追加密钥。大概率是拼完之后在末尾或开头加一个固定字符串比如keyabcdef。第四步在工具的 MD5 面板里逐个试比对输出。如果都没中就换 HMAC-MD5把候选密钥填进密钥字段。几个实测经验第一数字类型的参数在拼接时可能保持原样也可能被转成字符串后加引号这是两个不同的结果。第二timestamp是秒还是毫秒很关键1735689600 是 10 位秒1735689600000 是 13 位毫秒差 1000 倍。第三输出的十六进制大小写要和服务端一致很多框架默认小写但 Java 的DigestUtils有的版本出来是大写。如果 MD5 和 HMAC 都试遍了还是不对那就去看前端 JS 了。搜索关键词sign、encrypt、CryptoJS、md5(基本都能定位到签名函数。4.2 场景二整包加密响应的解密有些系统会把整个响应体加密后返回一长串 Base64。处理流程是这样的第一步判断外层容器。拿到data字段先无脑 Base64 解一次。如果解出来是二进制乱码说明外层确实是加密数据转成十六进制看长度。如果长度是 16 的倍数AES 的可能性很大。第二步找密钥。大部分前端加密的密钥是硬编码在 JS 里的。在开发者工具里搜索key、secret、aesKey、iv这些词看到的通常是一串 16 或 32 位的字符串。第三步在工具里配置。假设拿到的是// 常见的前端写法示意 const key 1234567890abcdef; // 16 字节AES-128 const iv abcdef1234567890; // 16 字节 const mode CryptoJS.mode.CBC; const padding CryptoJS.pad.Pkcs7;对应到工具里就是算法 AES、模式 CBC、填充 PKCS7、密钥 16 字节、IV 16 字节、密文输入为 Base64、输出编码为 UTF-8。第四步验证。解出来应该是一段可读的 JSON。如果能解出部分可读、部分乱码通常是输出编码选错了试试 GBK 或 Latin-1或者 IV 取错了。这个链条里最容易出问题的是 IV 的传递方式。有一种常见做法是把 IV 拼在密文前面一起 Base64前 16 字节是 IV后面才是真正的密文。遇到这种你需要在工具里手工切一刀先把 Base64 解成十六进制取前 32 个十六进制字符作为 IV剩下的作为密文。4.3 场景三JWT 凭证的结构分析拿到一个 JWT先拆三段看看。假设是这样的eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiIxMDA4NiIsInJvbGUiOiJ1c2VyIn0.xxxxx第一段解出来是{alg:HS256,typ:JWT}第二段是{uid:10086,role:user}到这一步你就能获得很多信息了用的是 HS256对称密钥签名payload 里有uid和role。这类信息在做权限边界分析时非常关键。但同样要强调任何测试都必须在获得明确授权的范围内进行。分析 JWT 的时候有几个实用细节。一是时间字段iat签发时间、exp过期时间、nbf生效时间都是 Unix 时间戳秒级。你可以用工具箱里的时间戳转换核对一下判断凭证的有效期是否合理。二是 Base64URL 的填充问题JWT 的三段通常省略了解码时如果报错切到 Base64URL 并允许无填充模式。三是如果一个系统同时存在多种alg那说明它支持多套签名方案这本身是一个值得注意的设计点。4.4 场景四CTF 里的编码套娃CTF 的编码题基本都是套娃一层套一层。这时候工具箱里的工具就派上大用场了因为你需要来回试很多次。一个典型的多层结构可能是外层 Base64解出来是一段十六进制十六进制转字符串后发现是倒序的反转之后是一段 URL 编码URL 解码后得到一串摩斯码摩斯解码得到明文。处理这类题的策略是建一个假设清单从最外层最容易识别的开始剥结尾有、字符集含/→ Base64全是%XX→ URL 编码全是 0-9 a-f → 十六进制全是.和-→ 摩斯字母频率明显、只有字母 → 凯撒/维吉尼亚大写小写混排且长度是 5 的倍数 → 培根全是\u开头 → Unicode 转义每剥一层就用工具面板的结果转输入功能直接把上一步的输出接到下一步不要手工复制因为中间结果里经常有特殊字符手工复制十有八九会出错。5. 常见问题与排查技巧实录5.1 解密出来是乱码先查这三处第一字符编码。UTF-8 和 GBK 是最常见的两种。一个中文在 UTF-8 下是 3 字节GBK 下是 2 字节。如果你解出来的十六进制长度对不上先换编码再试。工具面板一般都有输出编码选项别一直用默认值。第二密钥或 IV 的长度。AES 的密钥必须是 16、24 或 32 字节IV 必须是 16 字节。工具里如果填了 15 个字符很多实现会自动补一个 0 或者报错结果自然是错的。我的做法是在填之前先用工具的字符串长度功能确认字节数特别是当密钥里含中文或者是从配置里复制来的时候。第三模式选错了。CBC 和 ECB 的密文长度是一样的但结果完全不同。ECB 不需要 IV如果你在 ECB 模式下填了 IV有些工具会忽略有些会报错。判断技巧前面说过看密文有没有重复的 16 字节块。5.2 摘要对不上的四个原因除了前面提到的拼接顺序、大小写、空值处理之外还有一个特别隐蔽的原因换行符。有些语言在拼接时会自动加上\n或\r\n尤其是在按行读文件或者用字符串模板的时候。你在工具里手打的字符串没有换行符算出来自然不一样。排查这个有个笨办法但很有效把服务端计算用的原始字符串猜出来之后在工具里算两次一次末尾加\n一次加\r\n看哪个能对上。这在处理老式 Java 系统时经常一击命中。还有一个原因是编码集。同一个中文字符串UTF-8 编码后做 MD5 和 GBK 编码后做 MD5结果是完全不同的。如果参数里含中文而签名又对不上八成是这里出的问题。5.3 常见问题速查表现象最可能的原因排查动作Base64 解码报错是 Base64URL或缺失填充换 Base64URL补到 4 的倍数解码出来是乱码输出编码选错UTF-8 / GBK / Latin-1 依次试AES 解密失败密钥、IV、模式、填充四者之一不对按密钥长度 → 模式 → 填充的顺序逐个确认密文里有重复块用了 ECB 模式去掉 IV确认 ECBMD5 对不上拼接顺序、分隔符、大小写、换行符逐项比对优先怀疑换行符和空值参数时间戳换算差几小时时区问题确认是 UTC 还是本地时间多数是 UTC响应体是一堆乱码被 Gzip 或 Deflate 压缩先解压再判断是否加密JWT 第三段对不上payload 被改过或密钥不对重新拆解三段核对alg6. 几个提高效率的小习惯用了这么久我攒下几个觉得真正管用的习惯顺手分享一下。第一先做编码判断再做加密判断。拿到任何一串不认识的字符第一件事永远是它是不是只是换了种写法。这一步花不了十秒钟但能避免你在错误的方向上浪费半小时。我的顺序固定是看字符集 → 试 Base64 → 试 URL → 试 Hex → 试 Gzip → 然后才考虑加密。第二算出来的中间结果一定要记下来。我习惯在工具面板旁边开一个纯文本文件每算出一个候选结果就贴进去标上第几轮、用了什么参数。签名逆推经常要试十几二十种组合不记录的话很容易重复劳动而且最后成功了也说不清是哪一组参数起的作用。第三别迷信自动识别。前面说过自动识别是靠特征猜的猜错是常态。自己心里有一张排查顺序表比任何自动功能都可靠。第四注意数据安全。这是我最想强调的一点。业务报文里可能有用户信息、订单信息、内部标识这些东西粘到公开的在线工具网站上本质上就是一次数据外泄。本地工具箱最大的价值之一就是所有计算都在你自己机器上完成。涉及真实业务数据时我基本只用本地工具。第五把常用的参数组合存成模板。如果你长期分析同一套系统它的 AES 参数、签名规则基本是固定的。第一次搞清楚之后把算法、模式、填充、密钥、IV 记下来之后每次直接从模板起步效率会高很多。最后说一个我自己踩过的坑。有一次排查一个验签失败的问题试了两个多小时最后发现是服务端返回的密钥字符串末尾带了一个看不见的空格——是运维在配置中心里复制时带上的。从那以后我拿到任何密钥的第一件事就是先看它的字节长度对不对。一个 32 字节的 AES-256 密钥变成 33 字节工具不报错但结果全错。这类问题没有任何技术含量但真的能耗掉你一整个下午。