做接口调试和流量分析的人桌面上大概都开着五六个标签页——一个在线 Base64 解码、一个 MD5 计算、一个时间戳转换、一个 JWT 解析再加两三个自己也记不清是哪个的编码工具站。抓到一个看不懂的参数切窗口、粘贴、看结果对不上再回去翻一遍请求来回折腾十几分钟最后发现是复制的时候顺手多带了一个换行符。Spider Proxy 把二十多款常用的加解密辅助工具直接内置进了调试界面这个改动看着不起眼实际用起来是把上面这一整套来回切换的动作压缩进了同一次点击里。这篇想聊的不是工具清单而是这些加解密能力到底覆盖了哪些真实场景、每一类工具背后的关键参数该怎么理解、拿到一个加密接口之后按什么顺序往下拆以及我自己在这上面踩过的那些坑。不管你是刚接触接口调试的新手还是已经做了一段时间参数还原的老手应该都能从里面挑到几条能直接用的东西。1. 内置加解密工具到底解决了什么麻烦1.1 那些年我们来回切换的窗口先说清楚一个问题为什么把工具塞进调试器里比单独开一个工具站更值得说。做过接口联调的人都有体会一次完整的参数还原过程往往要在“看请求”和“算结果”这两件事之间来回跳。你在请求列表里看到signa1b2c3...想验证自己的拼接思路对不对就得把uid10086ts1712345678keyxxx这串东西拿到另一个地方算 MD5算完再回来比对。一次对不上就要改拼接顺序、改时间戳精度、改大小写每一步都是一次窗口切换加一次复制粘贴。十次尝试就是十次切换中间任何一次手抖多复制了一个空格结果全错而你还会以为是自己思路错了。这种摩擦成本在单次调试里看不出来但在一个需要反复试错的任务里会迅速放大。更要命的是注意力会被切碎你本来脑子里有一条清晰的推理链——“这个字段应该是按字典序拼接、密钥放最后、整体 UTF-8 编码”——结果每切一次窗口就要重新捡一次上下文。工具的物理位置其实直接影响了解题的效率。Spider Proxy 的内置工具解决的就是这个物理距离问题。请求和响应就在上面工具面板就在旁边选一段文本直接丢进去解码结果出来就能和原请求对照。省掉的不只是几次复制粘贴而是那条被打断的思路。1.2 内嵌工具和外链工具站的取舍有人可能会说在线工具站不是也能用吗为什么非要内置。这里面有几件事值得掰开说。第一是数据边界。调试过程中丢进解码框里的内容很多是带业务含义的用户标识、订单号、签名密钥片段、甚至完整的请求体。把这些东西贴到一个来路不明的站点上等于把内部数据交给了你看不见的服务器。很多公司的安全规范里这类行为是明确不允许的。内置工具在本地完成计算数据不出自己的机器这一点在处理敏感接口时是硬性要求不是偏好问题。第二是结果一致性。不同的在线工具站对同一个算法的实现细节可能不一样有的 MD5 默认输出小写有的给你大写有的 Base64 解码会自动忽略换行有的直接报错有的 URL 解码把当成空格有的当成加号本身。你在 A 站算出来的结果和 B 站不一致会平白多出一层困惑。内置工具统一了行为至少在你自己的环境里同一个输入永远得到同一个输出排错时能少一个变量。第三是链式处理。真实场景里一个参数经常是套了好几层的先 URL 编码再 Base64再压缩再加密。用在线工具站你要一层一层手动搬运而集成在调试器里的工具面板通常可以连续操作解完一层直接把结果喂给下一层。这个差别在小任务上不明显在多层嵌套的场景里就是几倍的时间差。提示不管用哪种工具处理完带密钥或者带身份信息的文本之后记得把输入框清掉。剪贴板和历史记录同样是泄露面。1.3 二十多款工具大致分成了几个谱系这二十多款工具看着杂其实归类之后思路很清楚大概能分成四个谱系理解了这个分类用的时候就不会在菜单里瞎找。谱系典型工具主要用途编码转换类Base64、Base64URL、URL 编码、Hex、Unicode 转义、HTML 实体、二进制/八进制把数据在可读文本和传输格式之间来回换摘要与校验类MD5、SHA-1、SHA-256、SHA-512、HMAC、CRC32验证签名、校验数据完整性、识别指纹加密解密类AES、DES/3DES、RC4、RSA还原被加密的请求体或响应体令牌与杂项类JWT 解析、时间戳转换、Gzip/Deflate 解压、UUID 解析、摩斯电码、凯撒密码处理结构化令牌和各类零散转换需求这个分法有个实际好处当你手上拿到一段不明文本先判断它属于哪一类基本就能确定下一步用什么工具。看到eyJ开头那是 Base64URL 编码的 JSON走 JWT 解析看到%7B%22那是 URL 编码先解 URL看到一串固定长度的十六进制先怀疑是哈希还是密文长度 32 位十六进制是 MD564 位是 SHA-256换成字节数再看是不是 AES 的块长度倍数。2. 编码与摘要类工具的原理与关键参数2.1 Base64填充、换行与 URL-safe 变体Base64 是这类工具里使用频率最高的一个也是坑最多的一个。它的原理不复杂把每 3 个字节24 位重新切成 4 组 6 位每组映射到一张 64 个字符的表上。因为 24 位正好被 4 整除所以 Base64 编码后的长度永远是 4 的倍数。如果原始数据长度不是 3 的倍数就用补齐到 4 的倍数——原来剩下 1 个字节补两个剩下 2 个字节补一个。这个规则能帮你做一件很实用的事拿到一段 Base64 字符串先看长度。长度对 4 取余等于 1这段字符串一定不是合法的 Base64说明中间被截断或者混入了别的字符。长度对 4 取余等于 2 或 3那是缺了填充符手动补上或就能解。标准 Base64 的字符表里有和/这两个字符在 URL 里是有特殊含义的会被当成空格/会被当成路径分隔符。所以出现了 URL-safe 变体把换成-把/换成_填充的通常直接省略。JWT 用的就是这个变体所以你会看到eyJhbGciOiJIUzI1NiJ9这种既没有也没有/的字符串。还有一个隐形陷阱是换行。早期邮件协议规定 MIME Base64 每 76 个字符要插入一个换行所以有些系统输出的 Base64 是带换行的多行文本。多数解码器会自动忽略空白字符但也有严格的实现会直接报错。如果你从一个日志文件里复制的 Base64 解码失败先把换行和空格去掉再试一次这一步能救回不少时间。2.2 URL 编码、Hex 与 Unicode 转义URL 编码解决的是“哪些字符能安全地出现在 URL 里”这个问题。规则是把不安全的字符转成%加上两位十六进制。这里有个容易被忽略的分歧空格的编码方式有两种%20和。在路径部分空格必须写成%20在查询字符串里application/x-www-form-urlencoded这种格式允许用表示空格。所以解码的时候把当空格还是当加号取决于这段数据原来处在什么位置。这也是为什么同一个字符串在两个工具里解出来的结果不一样——不是工具错了是默认假设不同。另外你还会碰到%u4E2D这种带u的写法这是早期 JavaScriptescape()函数留下的格式编码的是 UTF-16 码元而不是 UTF-8 字节。处理中文时用错了会得到一堆乱码因为%uXXXX里一个汉字占一组而 UTF-8 编码的汉字占三组%XX%XX%XX。Hex 编码理解起来最直白把每个字节变成两位十六进制字符。实际使用中要注意三件事大小写0A和0a是同一个值但字符串比较时不一样、有无0x前缀、有无分隔符0a0b0c和0a 0b 0c是同一份数据。做二进制分析时经常需要 Hex 和文本互转这个工具用起来简单但输入格式没对齐就会得到看起来“差一点”的结果。Unicode 转义在国内的接口里出现频率很高因为 Java 的一些序列化框架会默认把非 ASCII 字符转成\uXXXX。这里有个新手容易懵的点一个表情符号在 UTF-16 里是两个码元转义出来是两个\u序列比如\uD83D\uDE00。看到两个连续的、范围在D800–DFFF之间的转义别当成两个独立字符处理它们是一对。2.3 摘要算法MD5、SHA 家族与 HMAC 的分寸摘要类工具的核心用途是验证不是解密。哈希是单向的算出来的结果没法倒推原文所以你在工具里做的是“我猜原文是这个算一遍看看和抓到的值对不对”。MD5 输出 128 位用十六进制表示是 32 个字符。很多接口文档里会写“取 16 位 MD5”这个说法其实不准确——它指的是把 32 位结果中间的第 9 到第 24 个字符截出来本质上还是 MD5只是显示方式不同。你在工具里算的时候要确认对方用的是哪一种别看长度不对就以为算法选错了。SHA 家族常见的有 SHA-1160 位40 个十六进制字符、SHA-256256 位64 个字符、SHA-512512 位128 个字符。从长度反推算法是排查时的常用手段但也只能作为初步判断——不同算法碰上极短的输入长度特征依然是可靠的因为输出长度只由算法决定。HMAC 是在哈希基础上加了一层密钥的构造。它的参数有两个密钥和数据顺序不能反。很多人第一次用 HMAC 时会疑惑“密钥和数据到底谁在前”答案是 HMAC 的构造里两者各司其职不是简单拼接所以你只需要在工具里填对两个框不用纠结顺序。真正需要纠结的是密钥本身对方给的密钥是原始字符串还是经过 Base64 或 Hex 编码的字节序列。这两种情况算出来的结果完全不同而接口文档经常不写清楚。2.4 为什么 HMAC 不是简单的“哈希(密钥加数据)”有些人会图省事直接用 MD5(密钥 数据) 来代替 HMAC在普通场景下也能跑通但这中间有个真实存在的安全弱点值得搞清楚。MD5、SHA-1、SHA-256 这类基于 Merkle–Damgård 结构的哈希算法有一个特性知道H(secret message)的哈希值可以在不知道 secret 的情况下推算出H(secret message padding 追加内容)的哈希值。攻击者只要在原始消息后面接一段自己构造的数据再补上算法内部的填充字节就能算出一个“合法”的新签名。这就是长度扩展攻击。HMAC 通过两层嵌套内层用ipad异或密钥外层用opad异或密钥把这个结构破坏了让攻击者没法从已知结果往外推。这也是为什么在签名场景里用 HMAC 而不是拼接哈希。你在做接口还原时如果发现某个签名就是对“密钥加参数”的哈希那通常意味着这套接口有安全隐患而如果你是自己写接口别学这种写法。顺带说一个实用推论当你在还原一个签名接口、试了各种拼接顺序都对不上时考虑一下对方用的可能是 HMAC 而不是纯哈希。HMAC 的输出长度和普通哈希一样肉眼看不出来区别只能靠试。3. 对称加密与非对称工具的使用要点3.1 AES 的三个必填参数密钥、IV、模式AES 是这类工具里参数最多、最容易出错的一个。它的分组长度固定为 128 位也就是 16 个字节这一点不随密钥长度变化。密钥长度决定了 AES 的“型号”16 字节密钥是 AES-12824 字节是 AES-19232 字节是 AES-256。很多时候接口文档只写“用 AES 加密”你在工具里就得靠密钥长度去反推型号选错了会得到一堆看起来像随机字节的乱码。IV 是初始化向量长度固定 16 字节和密钥长度无关。这里有个常见误解以为 IV 长度跟密钥长度挂钩。不挂钩永远是 16 字节。IV 的作用是保证同样的明文、同样的密钥每次加密出来的密文不同避免出现“相同明文块产生相同密文块”的规律泄露。所以 IV 不需要保密但需要随机而且解密方必须拿到和加密方完全一致的 IV。实际接口里IV 经常被拼在密文前面或者作为独立字段一起传。模式是第三个必填参数常见的有 ECB、CBC、CTR、GCM。ECB 最简单也最不该用因为它不使用 IV相同明文块永远得到相同密文块加密一张有规律的图片你能直接从密文里看出轮廓。CBC 是最常见的模式前面的密文块参与后面明文块的加密需要 IV。CTR 把分组密码当流密码用不需要填充。GCM 在加密之外还提供完整性校验输出会比明文多出一段认证标签通常是 16 字节。判断模式的实用技巧如果密文长度严格是 16 的倍数且没有额外多出 16 字节倾向于 CBC 或 ECB如果密文长度和明文长度完全相等多半是 CTR 或者已经处理过填充的流式模式如果密文比明文多 16 字节考虑 GCM。这些只是线索不能替代实测但能让你的试错顺序更合理。3.2 填充方式选错解密必挂分组密码要求输入长度是分组长度的整数倍AES 是 16 字节。原文长度不够怎么办靠填充。填充方式有好几种选错了就解密失败而且失败的表现往往很含蓄——不是报错而是解出一段前面正常、后面一堆乱码的结果。PKCS#5 和 PKCS#7 在实际使用中经常被混着叫。严格来说 PKCS#5 只针对 8 字节分组PKCS#7 才是通用定义但在 AES 场景下大家说 PKCS#5 时通常指的就是 PKCS#7 的行为缺 n 个字节就补 n 个值为 n 的字节如果原文正好是分组的整数倍就额外补满一整组 16 个值为 16 的字节。所以用 PKCS#7 加密后密文长度总是严格大于明文长度且是 16 的倍数。ZeroPadding 是补零问题是解密时没法区分“补的零”和“原文末尾本来就有的零”所以容易出现结尾多出几个空字符的情况这在处理二进制数据时尤其麻烦。NoPadding 就是不管要求你自己保证输入长度是 16 的倍数接口里如果用了这个通常是调用方自己在业务层做了定长处理。工具面板里选填充方式的顺序建议是先试 PKCS#7多数语言默认再试 ZeroPadding再考虑 NoPadding。如果你拿到的是别人给的密钥和 IV直接问一下填充方式比试快得多别硬猜。3.3 RSA 与 JWT非对称体系里的两个高频工具RSA 和 AES 的区别在于它用一对密钥公钥加密、私钥解密或者反过来用私钥签名、公钥验签。在接口调试里你经常遇到的是“客户端用公钥加密一个密钥服务端用私钥解开”这种密钥交换的写法或者“服务端用私钥签名客户端用公钥验签”的防篡改写法。用 RSA 工具时有几个参数必须对上密钥格式PKCS#1 还是 PKCS#8前者以-----BEGIN RSA PRIVATE KEY-----开头后者以-----BEGIN PRIVATE KEY-----开头、填充方案PKCS#1 v1.5 还是 OAEP、以及哈希算法OAEP 需要指定 SHA-1 还是 SHA-256。还有一个硬约束RSA 能加密的数据长度受模数限制。2048 位密钥最多加密 256 字节减去填充开销PKCS#1 v1.5 大约能装 245 字节OAEP 更少。超过这个长度必须分段或者改用混合加密。很多人第一次用 RSA 加密长文本时碰到的报错就是这个原因。JWT 是另一个高频工具它的结构是三段用点分隔的字符串头部、载荷、签名。前两段是 Base64URL 编码的 JSON注意是 URL-safe 且去掉了填充。头部里alg字段告诉你签名算法HS256 是对称的用同一个密钥签名和验签RS256 是非对称的私钥签名、公钥验签。载荷里的exp是过期时间iat是签发时间都是 Unix 时间戳单位是秒10 位数字。验签对不上时按这个顺序排查第一确认你算签名时用的是原始的两段字符串拼接结果中间那个点不能少第二确认输出是 Base64URL 而不是标准 Base64和/要换成-和_末尾的要去掉第三确认密钥本身是不是被 Base64 编码过很多服务端框架的密钥配置是 Base64 字符串实际参与计算的是解码后的字节。3.4 时间戳、Gzip 这些“不算加密但天天用”的工具时间戳转换看起来最简单坑却不少。核心判断是位数10 位是秒13 位是毫秒。10 位的时间戳能表示的区间大致是 2001 年到 2038 年 1 月 19 日因为 32 位有符号整数的上限是 2147483647换算下来就是那个时间点。如果你看到一个 10 位数字落在这个区间之外那它多半不是时间戳而是别的东西。13 位毫秒戳除以 1000 就能得到秒级。时区是另一个坑。Unix 时间戳本身是 UTC 的转成本地时间要加偏移。你在工具里看到的时间如果和接口文档差 8 小时别急着怀疑算法先看时区设置。Gzip 和 Deflate 严格说不属于加密但在请求体压缩的场景里几乎天天遇到。判断是不是 Gzip 有个简单办法看开头两个字节是不是1F 8B这是 Gzip 的魔数zlib 格式Deflate 带 zlib 头通常以78开头常见的是78 9C、78 01、78 DA。当你在抓到的数据里看到这两个特征字节就可以直接上解压工具不用一层层猜。4. 四个真实场景的完整还原过程4.1 场景一接口签名参数的逆向举一个典型的签名还原过程。抓到的请求体是这样{ uid: 10086, ts: 1712345678, nonce: a7f3, sign: 3c59dc048e8850243be8079a5c74d079 }sign是 32 位十六进制长度上符合 MD5 的特征先按这个假设走。第一步确定参与签名的字段范围。sign本身肯定不参与其余三个字段都要试。第二步确定拼接规则。常见的有三种按字典序拼成查询串、按字段名加值直接首尾相连、拼成 JSON 后再哈希。第三步确定是否加盐。在工具面板里把uid10086noncea7f3ts1712345678keySECRET丢进 MD5比对结果。对不上就换顺序尝试序号拼接方式结果比对1noncea7f3ts1712345678uid10086keySECRET不匹配2uid10086noncea7f3ts1712345678keySECRET不匹配3uid10086ts1712345678noncea7f3不匹配4uid10086ts1712345678noncea7f3不匹配到这一步说明盐水的位置或者格式有问题。这时候要回头确认两件事一是时间戳参与签名时用的是秒还是毫秒很多接口内部统一用毫秒但返回给你看的是秒这个转换经常被忽略二是字符串编码。如果参数里有中文UTF-8 和 GBK 算出来的哈希完全不同而这个差异在纯数字参数上看不出来容易被误导。换一个有中文的参数再测一次往往能立刻定位问题。这里有个经验别一次性把所有变量都变了。先把顺序固定住只改编码试再固定编码只改顺序试。一次改一个变量否则你永远不知道是哪个变量起了作用。4.2 场景二AES 加密请求体的解密抓到一个响应体{ data: U2FsdGVkX18xMjM0NTY3ODkwMTIzNDU2Nzg5MGFiY2RlZmdoaWo }先把data的值做一次 Base64 解码。如果不方便手动解直接在内置工具里解一下你就会发现开头一段是Salted__后面跟 8 个字节的盐值。这是 OpenSSL 命令行工具默认的加密输出格式看到Salted__基本可以锁定来源。对应的命令行处理方式是这样# 把 Base64 解回二进制文件 echo U2FsdGVkX18xMjM0NTY3ODkwMTIzNDU2Nzg5MGFiY2RlZmdoaWo | base64 -d enc.bin # 用 OpenSSL 解密密码由 -pass 传入 openssl enc -d -aes-256-cbc -in enc.bin -pass pass:你的密码如果要在内置工具里手动处理就得从这段数据里把盐值抠出来然后按 OpenSSL 的密钥派生算法EVP_BytesToKey用 MD5 迭代算出实际的 key 和 IV。这活儿用脚本更快import hashlib from base64 import b64decode raw b64decode(U2FsdGVkX18xMjM0NTY3ODkwMTIzNDU2Nzg5MGFiY2RlZmdoaWo) assert raw[:8] bSalted__ salt raw[8:16] ciphertext raw[16:] password byour_password d d_i b while len(d) 48: d_i hashlib.md5(d_i password salt).digest() d d_i key, iv d[:32], d[32:48]算出 key 和 iv 之后把密文和这两个值填进 AES 解密工具模式选 CBC填充选 PKCS#7就能拿到明文。整个过程中最容易出错的一步是忘记Salted__这 8 个字节和 8 字节盐值也要从数据里剥掉直接拿整段解必然失败。4.3 场景三JWT 结构解析与过期排查拿到一个令牌eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOjEwMDg2LCJleHAiOjE3MTIzNDU2NzgsImlhdCI6MTcxMjI1OTI3OH0.xxxxx把前两段分别丢进 Base64URL 解码。第一段解出来是{alg:HS256,typ:JWT}第二段是{uid:10086,exp:1712345678,iat:1712259278}。alg是 HS256说明签名用的是 HMAC-SHA256对称密钥。验签的做法是把第一段、一个点、第二段原样拼起来作为待签名数据用密钥算 HMAC-SHA256再 Base64URL 编码和第三段比对。import hmac, hashlib from base64 import urlsafe_b64encode signing_input eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOjEwMDg2LCJleHAiOjE3MTIzNDU2NzgsImlhdCI6MTcxMjI1OTI3OH0 sig hmac.new(bsecret, signing_input.encode(), hashlib.sha256).digest() expected urlsafe_b64encode(sig).rstrip(b).decode() print(expected)exp是 171234567810 位秒级换算下来是 2024 年 4 月上旬。如果这个令牌已经过期服务端返回 401 是正常的不是你解密算错了。iat是签发时间两个值的差是 86399 秒也就是有效期接近一天。JWT 排查里最坑的一点是有些服务端在密钥配置里写的是 Base64 字符串代码里会先做一次 Base64 解码再当密钥用。你在工具里直接拿那串 Base64 字符当密钥算结果永远对不上。遇到验签失败又确认其他环节没问题时试试把密钥先解一次 Base64。4.4 场景四多层嵌套编码的层层剥离最后这个场景最能体现链式处理的价值。抓到一段参数%7B%22k%22%3A%22H4sIAAAAAAAACqtWKk7NycxLBwCXeQZrCwAAAA%3D%3D%22%7D第一眼看到%7B%22这是{的 URL 编码。先解 URL{k:H4sIAAAAAAAACqtWKk7NycxLBwCXeQZrCwAAAA}H4sI开头这是 Gzip 数据经过 Base64 编码的典型特征——Gzip 的魔数1F 8B在 Base64 里对应H4sI。把值取出来做 Base64 解码得到二进制再用 Gzip 解压import base64, gzip, json s H4sIAAAAAAAACqtWKk7NycxLBwCXeQZrCwAAAA raw base64.b64decode(s) print(gzip.decompress(raw))一层一层剥下来就得到了明文。这个过程里有个判断顺序值得记住先看文本特征有没有%、有没有结尾再看魔数解出来的前几个字节是什么最后才是猜算法。反过来如果看到一段没有任何特征的数据就直接上 AES大概率是在浪费时间。这里也顺便回答一个常见疑问什么时候该用内置工具什么时候该写脚本。单层的、一次性的解码用工具面板几分钟搞定像上面这种三层嵌套、或者要批量处理几百条数据的写十几行脚本更快而且可以复用。判断标准很简单——如果你发现自己在同一个操作上重复了第三次就该考虑脚本化了。5. 常见问题速查与避坑心得5.1 问题速查表现象可能原因处理方式Base64 解码直接报错含换行、含 URL-safe 字符、长度不是 4 的倍数去空白把-_换回/手动补解出来全是乱码字符集不对UTF-8 与 GBK 混用换字符集重试优先 UTF-8哈希对不上大小写不一致、末尾有换行、编码不同统一小写去掉首尾空白确认编码AES 解密失败key 或 IV 长度不对、模式选错、填充选错先核长度再换模式最后换填充解出来前半段正常后半段乱码填充方式不对或密文被截断换 PKCS#7 与 ZeroPadding 对比JWT 验签失败用了标准 Base64、密钥被 Base64 编码过换成 Base64URL密钥先解一次 Base64时间对不上秒与毫秒混淆时区没换算按位数判断注意 UTC 与本地时间差参数看起来是密文但怎么都解不开根本就不是加密而是哈希或编码先用长度和特征判断类别再动手5.2 字符集与不可见字符的坑这一类问题我踩过的次数最多值得单独说。哈希对不上九成情况下不是算法错了而是参与计算的字符串和你想的不一样。最常见的几种差异末尾多了一个换行符从日志文件里复制时会带上、中间混了全角空格、引号被替换成了中文引号、数字被格式化成了带千分位分隔符的形式。排查方法很笨但有效把待计算的字符串放进工具里先看它的长度和字节序列。比如你以为是 20 个字节实际显示 21 个那就说明多了一个字符。十六进制视图能把这个字符暴露出来0A是换行20是空格C2 A0是不间断空格——最后这个特别阴肉眼看上去和普通空格一模一样但字节不同哈希自然不同。编码层面还有一个高频坑Java 服务端默认编码在某些环境里是 GBK而你在工具里用的是 UTF-8。参数里如果没有中文两者结果一样所以你用纯数字参数测试时会觉得“我思路是对的”一旦参数里出现中文就崩了。所以验证签名逻辑时务必用带中文或者带特殊符号的参数做一次交叉验证这一步能提前发现问题。5.3 几条踩坑之后的经验第一条别一上来就假设复杂度。很多人看到加密参数第一反应是“这肯定是 AES-256-GCM”然后花两小时试参数最后发现只是 Base64。合理的顺序是先看长度和字符集特征排除编码再看是不是标准哈希长度排除摘要最后才考虑对称加密。从简单到复杂能省掉大量无用功。第二条把“能复现”看得比“能解开”更重要。你手动解开一次密文价值有限如果你能用脚本把解密过程写下来下次换个参数直接跑那才是可复用的资产。我现在的习惯是只要一个解密流程超过三步就顺手写成脚本存起来命名上写清楚是针对哪个接口的隔几个月回头看还能立刻捡起来。第三条Key 和 IV 的定位思路。它们不会凭空出现通常在请求头、查询参数、或者前一次接口的响应里。如果你在响应里看到一串长度 16 或者 32 的 Base64 字符串且每次请求都变那大概率就是 IV 或者会话密钥。判断依据是长度和变化规律固定不变的 32 字节十六进制多半是固定的 key每次请求都变、长度 16 字节多半是 IV。第四条关于工具本身的边界。内置的加解密工具适合做单点验证和快速试错但它不是万能的。处理大文件时把几兆的二进制塞进输入框会让界面卡住这种情况直接切命令行工具。需要批量处理时也一样脚本永远比手工快。工具的价值是让你在思考的时候不用被打断而不是替代所有工作。第五条记录习惯。每次成功还原一个加密流程把关键信息记下来算法、模式、填充、密钥来源、IV 来源、参与签名的字段顺序。这些信息在当时看很清晰过两周再回来基本忘光。我自己维护了一份表格按接口维度记录这些参数后来再遇到类似结构的接口直接翻表比对往往能省掉大半试错时间。