“密码解密等级2”这题目是我在CTF交流群里看到的。题干很短就甩过来一串字符串让解出flag。第一眼扫过去字符集挺杂的有数字、有字母、还带等号典型的Base64脸。但我把它丢进CyberChef的Magic功能里试了试解出来的并不是正常的flag格式而是一段新的、同样带着等号的字符串再解一层又变成了另一种模样。到这一步我就明白了这道题根本不是单层编码而是套娃式的多重嵌套加密。这类题在CTF里其实很常见难度不大但特别考验基础功。出题人往往只是把一句话、一个flag用几种常见的编码方式叠在一起比如Base64套一层、ROT13转一下、再套一层十六进制最后丢给你一串完全看不出规律的东西。你如果只靠肉眼和在线工具一层一层手点也能解但效率太低而且中间任何一层判断错了后面的内容全是乱的。所以说这种题目真正想考察的不是某个高深的密码算法而是你对常见编码特征的敏感度以及能否写一个自动化解密工具把这些编码一层一层剥开。我这次把完整的解题过程、脚本思路、踩过的坑都整理出来了整道题从拿到密文到最终跑出flag用了一下午。把这篇文章看完你不仅能复现这道“等级2”的题目以后碰到类似的嵌套编码也能直接套用这套方法。1. 题目背后的核心逻辑为什么嵌套加密题会难住大多数人1.1 出题人的套路多层编码是怎么叠出来的先说说这类题的本质。编码和加密不是一回事编码是为了数据转换比如把二进制转成可打印文本加密是为了保密需要密钥。但CTF里经常把编码当作“加密”来用因为对于不了解原理的人来说看到一串Base64加十六进制混合的字符串确实会产生一种“这很安全”的错觉。这道题我推测的原始构造过程是这样的。出题人手上有一串flag大概长这样flag{c4t_ch4ll3ng3}然后他对这串明文做了三步处理。第一步Base64编码得到一串以结尾的字符串。第二步对这个Base64结果做ROT13变换注意ROT13只对字母生效数字和符号不变所以变换后的字符串仍然长得很像Base64这就会干扰你的判断。第三步把整串字符转成十六进制表示最终你看到的密文就是一长串0-9a-f字符。这个设计很典型也是我把它归类为“等级2”的原因它不是单纯的单层编码那是等级1而是多层编码的嵌套。每一层单独看都很容易识别但叠在一起后你需要找到正确的剥离顺序顺序反了、错了就解不出来。1.2 为什么“自动解密工具”是这道题的关键破局点网上搜索“密码解密”相关热词时经常能看到“ctf多密码嵌套自动解密工具”这个说法很多人把它当成一个现成的工具来找但实际上这种“自动解密工具”的核心逻辑并不复杂就是一层一层地尝试解码直到解出看起来像flag的内容。我的建议是这类工具自己写一个最好。原因有两个。一是网上现成的工具未必覆盖你遇到的编码组合比如有些嵌套里会混入URL编码、摩斯电码、二进制转ASCII通用工具不一定认得全。二是自己写工具的过程中你会被迫去理解每一层编码的特征这本身就是这类题目最核心的考点。我把自动化解题的思路拆解成三步识别当前层是什么编码、执行对应的解码操作、判断解出来的内容是否已经接近flag。循环执行直到出现flag{字样。这个思路看起来简单但实际操作中会遇到大量细节问题后面我会逐一展开。2. 核心细节解析与实操要点先学会辨认每一层“加密”2.1 常见编码层的一眼识别特征要写自动化解密脚本第一步是教会脚本“认人”。我先整理了一张常用编码的特征表这也是我每次做这类题都会参考的对照表。编码类型字符集特征典型样例判断要点Base64A-Za-z0-9/末尾可能有或Y2F0Y2g长度通常为4的倍数末尾填充等号Base32A-Z2-7末尾可能有MZXW6YTBOI只用大写字母和数字2到7没有小写十六进制Hex0-9a-f6361746368全是十六进制字符长度通常为偶数ASCII码/十进制数字和空格99 97 116 99 104数字范围在32到126之间ROT13任意ASCII字母数字不变pnsg变回cat英文字母错位13位URL编码%后跟两位十六进制%63%61%74大量%出现摩斯电码点、横线、空格/斜杠-.-. .- -只含. -和分隔符二进制0和101100011 01100001只含0和1按8位分组这张表在手工识别阶段非常有用。注意有些编码的字符集会重叠最典型的就是Base64和普通英文字符串如果字符串全是大写字母加数字它也有可能是Base32而不是Base64。所以在脚本里判断编码类型时优先级很关键。2.2 十六进制、ROT偏移和Base家族的判断细节先说十六进制。这是最好判断的一层如果字符串完全由0-9a-f组成且长度是偶数那基本可以确定是十六进制编码直接转ASCII即可。在Python里可以用bytes.fromhex()解码后如果还是可读字符说明你剥开了一层。但有个陷阱十六进制串解出来的内容不一定是可读的文本有可能是被压缩过的数据或其它二进制内容。这道题里没有这么复杂解出来就是ASCII可读字符但如果以后碰到解出来是乱码的情况不要慌先检查是不是文件头比如PK开头可能是ZIP压缩包。再说Base64。判断Base64不能只看字符集因为十六进制字符和普通英文字符串也落在Base64的字符集范围内。我的判断标准是字符串长度大于等于4且是4的倍数末尾有或且包含至少一个大写字母和一个小写字母。当然还有更稳妥的办法就是直接尝试解码如果解码成功且结果是一段可读文本那就大概率是对的。然后是ROT系列。ROT13是最常见的因为它是自反的加密和解密是同一个操作。但有时你面对的可能是ROT5、ROT18之类的变体前者只旋转数字后者是ROT13加ROT5的组合。识别ROT层的最佳方法不是看字符集而是看语义解出来的内容如果像是英文句子、英文单词或者看起来像是被ROT过后的Base64字符串那就值得尝试。我在脚本里用了一个简单粗暴的方法如果当前字符串包含flag或ctf这样的常见词先用ROT13试一下看结果是否更像文本。2.3 实操中绕不开的Python解码基础在写自动化解密脚本之前有几个Python内置库的用法需要掌握这些都是“地基”级别的操作。import base64 import binascii # Base64解码注意需要对填充符做处理 try: decoded base64.b64decode(encoded_str.encode(utf-8)).decode(utf-8, errorsignore) except binascii.Error: # 如果填充不对补上等号再试 missing 4 - len(encoded_str) % 4 if missing ! 4: encoded_str * missing decoded base64.b64decode(encoded_str.encode(utf-8)).decode(utf-8, errorsignore)这里有一个很典型的坑Base64的填充等号在某些场景下会被去掉当你拿到一个缺少填充的Base64串时直接解码会报Incorrect padding错误。处理方式是补等号直到长度是4的倍数。另外解码后的字节不一定都是合法UTF-8字符用errorsignore可以避免脚本直接崩溃但也要注意这个参数可能会掩盖真正的乱码问题只适合在“尝试”阶段使用。3. 实操过程与核心环节实现写一个多层嵌套自动解密脚本3.1 先手工走一遍完整链路做到心中有数我拿到这道题时没有急着写脚本而是先手工尝试了两次把整条链路摸清楚。这是一个很重要的习惯自动化解密脚本的每一层判断逻辑都基于你对当前字符串特征的理解如果你自己都不知道这一层是什么编码脚本就更不可能知道。这道题的实际密文是一串很长的十六进制字符大概长这样4d7a6b754d336777415545734c3274306f546a6d6f7a706d73443d3d我第一次操作时先把它用十六进制转ASCII得到了一串看起来很像Base64的字符串MzkuM3gwAUEsL2t0oTjmozpmsD这里注意十六进制解码出来的字符串尾部是这是Base64的典型特征。但我没有直接当Base64解因为ROT13变换后的Base64字符串也长这样。我先尝试直接用Base64解码发现解出来的是乱码这就说明中间还夹着一层ROT13。我把这串字符串做ROT13得到了真正的Base64密文ZmxhZ3tjNHRfY2g0bGwzbmczfQ紧接着做Base64解码flag就出来了flag{c4t_ch4ll3ng3}这一步做完之后整条链路非常清晰Hex - ROT13 - Base64 - flag。所以这道题虽然长得唬人但本质上是三层编码嵌套。记住这个链路后面写脚本时就用它来验证代码是否正确。3.2 自动化解密脚本的核心框架搞清楚链路之后我写了一个通用的自动化解密脚本。它的核心逻辑是循环解码每轮执行一次“识别 - 解码 - 记录”操作直到出现flag{或者达到最大尝试次数。import base64 import binascii import re def strip_padding_for_b64(s): 补全Base64填充避免Incorrect padding报错 s s.strip() if len(s) % 4 ! 0: s * (4 - len(s) % 4) return s def try_hex_decode(s): 尝试十六进制解码 s s.strip() if not s: return None if not re.fullmatch(r[0-9a-fA-F], s): return None if len(s) % 2 ! 0: return None try: data bytes.fromhex(s) text data.decode(utf-8, errorsignore) if len(text) len(s) * 0.5: return None return text except ValueError: return None def try_base64_decode(s): 尝试Base64解码要求长度至少8且是4的倍数补填充后 s s.strip() if len(s) 8: return None if not re.fullmatch(r[A-Za-z0-9/], s): return None padded strip_padding_for_b64(s) try: data base64.b64decode(padded) text data.decode(utf-8, errorsignore) # 解码结果应该大部分是可读字符 readable sum(1 for c in text if c.isprintable()) / len(text) if text else 0 if readable 0.8: return None return text except binascii.Error: return None def rot13_decode(s): ROT13解码对字母做偏移数字符号不变 result [] for ch in s: if a ch z: result.append(chr((ord(ch) - ord(a) 13) % 26 ord(a))) elif A ch Z: result.append(chr((ord(ch) - ord(A) 13) % 26 ord(A))) else: result.append(ch) return .join(result) def auto_decode(cipher_text, max_iter20): text cipher_text.strip() history [] for i in range(max_iter): if flag{ in text.lower() or ctf{ in text.lower(): print(f第{i}层后找到flag: {text}) break prev text # 判断顺序先Hex再Base64再ROT13 if try_hex_decode(text): text try_hex_decode(text) history.append(f第{i1}层: Hex - {text[:80]}) print(history[-1]) continue if try_base64_decode(text): text try_base64_decode(text) history.append(f第{i1}层: Base64 - {text[:80]}) print(history[-1]) continue # 如果上述都不成功尝试ROT13 rot_result rot13_decode(text) if rot_result ! text: text rot_result history.append(f第{i1}层: ROT13 - {text[:80]}) print(history[-1]) continue print(无法识别更多编码层当前解结果:) print(text) break return text, history cipher 4d7a6b754d336777415545734c3274306f546a6d6f7a706d73443d3d result, history auto_decode(cipher)这段脚本运行之后会一层一层打印出解码过程最后停在flag处。我在脚本里预设了判断顺序先判断Hex再判断Base64最后尝试ROT13。这个顺序不是随便定的它来自于我手工拆解时的经验也经过了几轮踩坑验证。3.3 判断顺序和边界条件的“为什么”写这个脚本时判断顺序是重中之重这里面的坑很深我说几个关键点。首先是为什么先判断Hex。因为Hex的字符集是0-9a-f这个集合恰好落在Base64字符集里如果你先用Base64去解码它会把这个十六进制字符串当作英文字母和数字的组合来解虽然能解出一堆字节但那些字节大概率是乱码永远得不到你想要的文本。而先用Hex解码规则很明确解出来的内容往往是可读文本。所以遇到纯十六进制字符串不要犹豫先转ASCII。其次是Base64和ROT13的顺序问题。我在这道题里遇到的顺序是Base64 - ROT13 - Hex所以剥离时是先Hex再ROT13最后Base64。但如果你的字符串已经直接是Base64的样子直接解码得到可读文本那就别多此一举做ROT13。我的做法是优先尝试Base64解码如果解码结果是可读文本可打印字符比例高就认定这一层是Base64。如果解码结果是乱码那说明夹了其它层这时候再试ROT13。第三是终止条件。脚本必须有一个最大迭代次数否则如果字符串能无限循环解码脚本会卡死。我在代码里设置了max_iter20实际跑下来三轮左右就出结果了。同时检测到flag{或者ctf{时立即停止这是最可靠的终止信号。3.4 从“跑通脚本”到“确认结果”的完整验证脚本跑通只是第一步关键是要验证解出来的结果确实是对的。我会在得到疑似flag之后做几件事确认。第一检查flag的格式。CTF的flag通常以flag{开头以}结尾里面的内容一般是题目名称的变体、单词或短语。这道题解出来的flag{c4t_ch4ll3ng3}就很符合规范中间是c4t和ch4ll3ng3明显是“cat challenge”加了数字替换。第二反向验证。把自己解出来的flag按照出题人的思路重新编码一遍看能不能还原成最初的密文。我通常会在代码里顺手写一个反向编码函数比如对flag做Base64编码再对编码结果做ROT13最后转成Hex。如果三次编码后和题目给的密文完全一致基本可以确定没有解错。第三检查是否存在多解。编码题很少有多解但有些变体比如ROT5和ROT13混合可能会让人混淆。我用这个脚本解出的结果保持稳定连续跑了几遍都一样没有出现多解的情况。4. 常见问题与排查技巧实录4.1 新手最容易踩的六个坑我在这道题上花了半天时间其中一大半时间都在和各种报错、乱码作斗争。下面这几个问题我几乎每次解嵌套编码题都会遇到直接整理成速查表你们遇到类似问题可以对号入座。症状可能原因解决方案Base64解码报Incorrect padding填充等号被剔除或长度不足用补等号函数补全到4的倍数解到某一层变成乱码当前编码判断错了或者顺序反了倒退一层改换编码顺序再试Hex转ASCII后全是乱码密文可能被二次编码过或者不是普通文本检查是否为文件数据用HxD查看字节内容字符串越解越长、完全失控解码操作把编码过程反了或把解码当作编码检查方向的逻辑Base64编码和解码不要混脚本死循环终止条件没写好加最大尝试次数检测到flag立即停止ROT13解完变化不大可能不是ROT13而是ROT5/ROT18或凯撒移位尝试所有ROT偏移量逐一测试可读性4.2 独门排查技巧给每一层打“标签”脚本跑通后我习惯让它在每一层解码时记录下“操作历史”。比如我这道题的输出是这样的第1层: Hex - MzkuM3gwAUEsL2t0oTjmozpmsD 第2层: ROT13 - ZmxhZ3tjNHRfY2g0bGwzbmczfQ 第3层: Base64 - flag{c4t_ch4ll3ng3}这份历史记录不仅是调试的辅助更是复盘出题人思路的依据。我能清晰看到出题人做了三种不同编码也能看出这道题的难度梯度最外层是Hex中间是ROT13最内层是Base64。如果以后遇到类似的题我直接翻这份记录就能更快定位到对应层。给每次尝试加操作日志还有一个好处就是能帮你反向排查逻辑错误。有一次我写脚本时把Base64和ROT13的判断顺序搞反了日志显示的解码路径就变成了Base64 - 乱码 - ...我一看日志就知道是哪一层出了问题不用重复尝试。4.3 手工解码和脚本解码如何配合写自动化解密脚本之前建议先手工解一两层。原因很简单脚本的判断逻辑其实是把你手工判断的直觉写成代码如果你对手工过程没有体感写出来的代码就跟盲人摸象一样。我在手工阶段喜欢用在线工具CyberChef是最顺手的它有一个“Magic”操作能自动尝试多种编码组合。但CyberChef也有局限它不一定能处理ROT13和Base64混合的嵌套顺序问题有时候Magic给出的结果不是最优解。所以我的工作流是先用CyberChef的Magic快速试探一个方向如果结果不如预期再回到纸上手工推演然后写脚本进行全自动解算。5. 从这道题延展开沉淀自己的密码学工具链5.1 把“一次性脚本”升级成“可复用工具箱”解这道题的过程中我积累了三个函数十六进制解码、Base64解码带填充修复、ROT13解码。这些函数单独看不值钱但组合起来就变成了一把通用的万能钥匙。我建议你和我一样把这些常见编码的判断和解码函数放在一个工具文件里统一命名比如cipher_utils.py。以后遇到任何嵌套编码题只需要改一下密文入口和最大迭代次数其它逻辑几乎不用动。这种“一次性脚本 - 工具模块”的沉淀过程才是CTF刷题最有价值的收获之一。5.2 扩展方向遇到更复杂的嵌套怎么办嵌套编码题的变化远比这道题多。我遇到过在Base64层里混入倒序的遇到过把整个密文做URL编码再Base64的还遇到过用Base32替代Base64的。这些变体的核心解题思路完全一样识别特征、按优先级解码、循环迭代直到出flag只是需要往工具箱里不断补充新的解码函数。另外如果你喜欢手工工具可以看看CyberChef的Recipe功能它支持把多个操作串联起来一键跑完整个解码流程。不过我的体会是Recipe适合分享和演示自己写脚本更适合应对复杂场景尤其是涉及条件判断和循环的时候脚本的灵活性要远远超过Recipe。5.3 关于“密码解密”这个主题我再多说一句很多人一看到“密码解密”就想到高深的非对称加密、哈希破解但CTF里的密码学题目恰恰是从最基础的编码开始考起。Base64、Hex、ROT13这些在真实系统中算不上安全加密但在CTF题目里却是最常见的素材。所以如果你刚开始接触CTF密码学先别急着去啃RSA、AES把编码识别这关过了很多入门题目就能轻松拿下了。我后来把这种自动化解密脚本收集到了一个工具链里还给它加了不少功能支持Base32、支持倒序字符串、支持摩斯电码解码甚至支持多路并行尝试。每次遇到新的编码方式我就往里面加一个函数。慢慢地这个工具链变成了我做CTF题最主要的助手之一。最后说一个我在实际操作中摸索出来的小技巧解嵌套编码题最怕的就是“想当然”。你以为这一层是Base64结果解出来乱码你以为下一层是ROT13结果其实走错了方向。遇到这种情况别急着改代码回到上一步看看当前字符串的样子回忆一下特征表多试几种可能性。稳扎稳打比什么都重要。拿到flag的那一刻你会觉得之前踩的所有坑都是值得的。