CyberChef实战：我是如何用它快速排查一个‘加密后中文变乱码’的线上Bug的
CyberChef实战：我是如何用它快速排查一个‘加密后中文变乱码’的线上Bug的
那天下午，警报突然响起——生产环境中的订单系统出现了数据异常。用户反馈提交的中文地址在后台显示为乱码，导致物流配送信息错误。作为当值工程师，我立即展开了排查。这是一次典型的数据加密传输问题，而CyberChef这个"瑞士军刀"般的工具，成了我解决问题的关键武器。
1. 问题复现与初步分析
首先需要确认问题是否可复现。我在测试环境模拟了用户操作流程：
- 前端使用AES-256-CBC加密用户输入的"北京市朝阳区建国路88号"
- 将加密后的数据通过Base64编码传输
- 后端解码后解密得到结果
测试发现解密后的输出确实出现了乱码："北京市望阳区建国路88å·"
关键观察点：
- 英文字符和数字正常显示
- 只有中文字符出现乱码
- 加密/解密使用的密钥和IV一致
这提示问题可能出在字符编码处理环节。我立即打开CyberChef，准备进行更深入的诊断。
2. 使用CyberChef构建诊断工作流
CyberChef的强大之处在于可以自由组合各种数据处理"配方"。针对这个问题，我构建了以下分析流程：
Input -> From Base64 -> AES Decrypt -> 检查输出具体参数设置：
- AES模式：CBC
- 密钥长度：256位
- 密钥格式：Hex
- IV：与加密端一致
执行后确实得到了相同的乱码结果。这说明问题不是简单的配置错误，需要更系统的排查。
3. 编码问题的系统性排查
3.1 检查加密前的编码
首先确认前端加密前的文本编码。在CyberChef中：
"北京市朝阳区建国路88号" -> To Hex得到16进制表示：
e58c97 e4baac e5b882 e69c9d e998b3 e58cba e5bbb6 e59bbd e8b7af 3838 e58fb7这是标准的UTF-8编码，说明加密前的处理没有问题。
3.2 分析解密后的数据
将乱码结果"北京市望阳区建国路88å·"转换为Hex：
c3a5 c5 d6 c2 c3a4 c2 ba c2 ac c3a5 c2 b8 c2 82 c3a6 c2 bc c2 9b c3a9 c2 93 c2 a3 c3a5 c5 d6 c2 ba c3a5 c2 bb c2 9a c3a5 c2 9d c2 ½ c3a8 c2 b7 c2 af 3838 c3a5 c2 b7 c2对比发现，原始中文字符的UTF-8编码被错误地解释为了Latin-1编码后又转换成了UTF-8。这是典型的"双重编码"问题。
4. 问题定位与解决方案
4.1 根本原因
经过逐步排查，发现问题出在解密后的输出处理上：
- 后端解密库默认将输出视为Latin-1编码的字节流
- 系统又将这些字节作为UTF-8再次解码
- 导致中文字符出现双重编码错误
4.2 CyberChef验证方案
在CyberChef中验证解决方案：
- 先用AES解密，输出格式选择"Raw"
- 然后添加"To Hex"操作查看原始字节
- 确认这些字节直接对应原始UTF-8编码
- 最后添加"From UTF-8"操作正确解码
完整配方：
From Base64 -> AES Decrypt -> To Hex -> From UTF-8执行后正确显示："北京市朝阳区建国路88号"
5. 实际修复与经验总结
基于CyberChef的分析结果，我们采取了以下修复措施：
- 修改后端解密代码，显式指定输出编码为UTF-8
- 在加密/解密流程中添加编码验证步骤
- 更新文档明确编码处理要求
关键经验：
- 加密前后的编码处理同样重要
- 工具链各环节的编码假设必须一致
- CyberChef是验证编码问题的利器
这次事件也让我更加认识到，在数据处理流程中，编码问题往往比算法本身更容易引发故障。而像CyberChef这样的可视化工具，能够帮助开发者直观地理解数据在各个处理阶段的变化，快速定位问题根源。