1. 初见EasyProgramBUUOJ上这道题的真实开场在BUUOJ上翻密码学题单的时候EasyProgram这个名字很容易让人误判难度。附件就一个Python脚本加一个output文本从命名到体积都透着一股新手练习的气息。但实际做下来我发现它真正卡人的地方完全不在RC4算法本身而在输出文件那层看起来毫不起眼的Unicode转义上。我先说下拿到题目的第一感觉。BUUOJ作为国内免费的CTF练习平台题目分类很细密码学、逆向、杂项、Web都有新手从这类平台入门的好处是可以在一个地方刷到不同知识域的题不用到处找题源。EasyProgram被归在密码学方向附件里给的加密逻辑伪代码整理出来大概是下面这样# 题目附件中的加密核心逻辑 def KSA(key): S list(range(256)) j 0 for i in range(256): j (j S[i] key[i % len(key)]) % 256 S[i], S[j] S[j], S[i] return S def encrypt(flag, key): S KSA(key) i j 0 out [] for byte in flag: i (i 1) % 256 j (j S[i]) % 256 S[i], S[j] S[j], S[i] K S[(S[i] S[j]) % 256] out.append(byte ^ K) return bytes(out)看一眼就知道这是标准的RC4流密码前半段是密钥调度算法KSA后半段是伪随机生成算法PRGA。到了这一步很容易产生一种错觉——找到密钥把output里的内容丢进RC4解密脚本flag就出来了。但真正动手时很多人包括我都会在第一步就翻车因为output.txt里的内容根本不是普通的十六进制密文而是一串被转义过的Unicode序列。这题给我的第一个教训是解密码学题之前永远先确认你手上这份数据的真实形态是什么而不是急着复制进脚本。2. RC4算法手写一遍KSA与PRGA的每个细节虽然RC4在现在的生产环境里已经不太推荐使用了但CTF里它的出镜率依然极高。EasyProgram这道题好在它用的是教科书式的标准RC4没有改任何参数。所以只要把算法本身吃透解密就成功了一半。2.1 KSA在做一件什么事KSA做的事情可以这样理解拿一个长度通常不超过256字节的密钥去洗牌一个初始状态向量S。S的初始值是0到255按顺序排好洗牌过程就是让密钥的每个字节轮流参与一次交换。def KSA(key): S list(range(256)) j 0 for i in range(256): j (j S[i] key[i % len(key)]) % 256 S[i], S[j] S[j], S[i] return S有个细节很多新手会忽略key[i % len(key)]意味着密钥长度小于256时密钥字节会被循环使用。比如密钥是4字节那么i0到3分别用key[0]到key[3]i4时又回到key[0]。这一点在标准RC4里是固定行为但如果出题人改动了这个取模逻辑比如把len(key)写死成一个别的数那同样的密钥会生成完全不同的S表这就是RC4变体题的常见坑。2.2 PRGA生成密钥流的顺序陷阱KSA结束后S表已经是一个被打乱的排列。PRGA阶段则开始逐字节生成密钥流每生成一个字节都会同步更新S表的状态def PRGA(S): i j 0 while True: i (i 1) % 256 j (j S[i]) % 256 S[i], S[j] S[j], S[i] K S[(S[i] S[j]) % 256] yield K实现PRGA时最容易犯的错误是搞乱i和j的更新顺序。RC4的设计是必须先更新i再用更新后的i去更新j。如果把顺序写反生成出来的密钥流跟标准RC4完全对不上而且这种错误在代码层面非常隐蔽因为没有报错只是输出乱码。我个人的习惯是把PRGA写成一个generator主循环里用next(keystream)取密钥流字节。这样做的好处是状态变量的作用域被限制在函数内部不容易在多个循环之间串味。2.3 用一个极小的例子验证你的实现在写正式解密脚本之前我建议先用一个微型例子验证RC4实现是否正确。比如用密钥bKey加密明文bPlaintext然后把结果拿去跟CyberChef的RC4模块对照。如果一致说明你的KSA和PRGA写对了可以直接用于解题如果不一致就先修自己的实现不要带着错误代码去解题目。这个方法看起来很基础但能省下大量排错时间。我在EasyProgram之前有一道题就是PRGA里顺序写反导致一直解不出最后是拿标准样例对照才定位到问题。3. Unicode编码陷阱\u序列不是Unicode字符如果你把output.txt直接拖进文本编辑器会看到类似这样的内容\u00e3\u0080\u0081\u00e5\u00ad\u0097\u00e7\u00ac\u00a6...实际题目里的具体数值不同但形态完全一样这就是EasyProgram最核心的陷阱。看一眼觉得是Unicode转义字符串好像用unicode_escape解码一下就行实际上这里面的水很深。3.1 第一层误区把\u当成了Unicode字符本身最常见的错误是直接对\u00e3这类序列做Python的Unicode解码。如果执行\\u00e3.encode().decode(unicode_escape)你会得到一个字符ã。但这意味着什么意味着你把一个原本表示密文字节的转义序列转换成了一个Unicode码点然后又用UTF-8编码变成了完全不同的字节序列。\u00e3代表的原始数值是0x00e3但如果题目源程序打印的是每个密文字节的十六进制值那么它本来可能只是\u00e3对应密文字节0xE3。问题在于出题程序可能把字节高位填充补成了4位十六进制例如字节0xE3被打印成\u00e3那这里的有效值需要按低字节处理。如果盲目地解码成Unicode字符再编码回UTF-8得到的是2个甚至3个字节长度和内容全部错乱。3.2 第二层误区手动复制和肉眼整理output.txt可能有几百行甚至上千行每个\uXXXX对应一个密文字节。有人试图用记事本查找替换把\u删掉然后把十六进制数字拼起来。这个思路方向是对的但手工操作极易出错——少复制一个数字、多复制一个换行符整个十六进制串的长度就变了RC4解密出来必然乱码。正确做法永远是用脚本处理。读取原文用正则把所有\uXXXX提取出来再逐个转换成整数。3.3 正确的还原链路核心认知是\uXXXX在这里不是Unicode字符而是一种文本化的字节表示。它本质上类似于把密文以十六进制形式打印出来只不过前面加了个\u前缀。正确的还原步骤import re with open(output.txt, r, encodingutf-8) as f: content f.read().strip() hex_parts re.findall(r\\u([0-9a-fA-F]{4}), content) ciphertext bytes(int(h, 16) 0xFF for h in hex_parts)这里有两件事要注意。第一正则里的\\u匹配的是字面的反斜杠加u也就是输出文件里真实存在的字符而不是Python字符串转义后的Unicode字符。第二 0xFF是为了防止\u00e3这类超过255的数值干扰只取低8位。如果题目输出格式本身每个字节就是两位十六进制比如\uE3那正则就是\\u([0-9a-fA-F]{2})按实际情况调整即可。3.4 别忘了Python 2遗留问题的可能性BUUOJ的题目很多是从历年比赛中收录的有些题目源码年份较早可能涉及Python 2。Python 2的字符串处理跟Python 3差别很大——str是字节串unicode才是真正的Unicode字符串。如果题目脚本是Python 2写的它打印出的内容可能是对unicode对象直接repr的结果那形态又会不一样甚至可能出现\uXXXX和\xXX混用的情况。遇到这种混合形态我的处理方法是先统计所有转义序列的种类再分别处理。用正则把\\u[0-9a-fA-F]{4}和\\x[0-9a-fA-F]{2}分开提取各自转换成字节后再拼接。不要试图用一个正则匹配所有容易出边界问题。4. 完整解密脚本从字符串到Flag理清了编码陷阱解密脚本就很简单了。整条流水线可以拆成三步还原字节、密钥获取、RC4解密。4.1 密钥定位出题人把key藏在哪里题目源码里密钥一般是硬编码的。如果源码是用正常变量名写的一眼就能看到key b...之类的赋值。但有些版本的题目会做简单混淆把变量名改成a、b、c之类的无意义字母。这时有个定位技巧RC4的KSA里一定存在一个key[i % len(key)]或者类似取模引用的结构那个被引用的对象就是密钥载体找到它再往前找它的赋值语句即可。如果附件不给源码只给一个编译后的exe或pyc那就需要先做逆向还原。pyc可以用uncompyle6这类工具反编译成Python源码如果是exe用strings先扫一遍往往密钥就直接暴露在明文字符串里。EasyProgram这题给的是源码所以密钥定位没什么难度但掌握这个思路对做同类题有帮助。4.2 一站式解密脚本import re key beasyprogram # 实际密钥以题目源码为准 # KSA S list(range(256)) j 0 for i in range(256): j (j S[i] key[i % len(key)]) % 256 S[i], S[j] S[j], S[i] # 读取输出并还原字节 with open(output.txt, r, encodingutf-8) as f: content f.read().strip() hex_parts re.findall(r\\u([0-9a-fA-F]{4}), content) ciphertext bytes(int(h, 16) 0xFF for h in hex_parts) # PRGA 解密 i j 0 plaintext bytearray() for c in ciphertext: i (i 1) % 256 j (j S[i]) % 256 S[i], S[j] S[j], S[i] K S[(S[i] S[j]) % 256] plaintext.append(c ^ K) print(plaintext.decode(utf-8, errorsreplace))跑完如果顺利输出就是flag{...}。这里有一个很实用的验证技巧解密结果应该以flag{或BUUCTF{这类已知前缀开头。如果输出是一串看不懂的乱码不要继续往下看直接回到前面的排错步骤检查数据形态。4.3 排错速查表我在做RC4加编码类题目过程中总结了一个排错速查表分享出来现象可能原因排查方向输出乱码但长度正确密钥不对检查源码中key的取值、大小写、是否带b前缀输出长度偏长密文被多层转换确认是否只还原了一层转义避免二次encode输出长度偏短正则漏匹配检查输出里是否有换行、空格、非\u格式的片段解密结果是Unicode字符而非字节把\u当Unicode解码了确认是字面解析用正则提取十六进制结果前半部分是flag后面乱码RC4密钥流偏移了一位检查PRGA中i和j的更新顺序是否标准这张表不止适用于EasyProgram。任何RC4题目遇到解密异常基本都可以从这几个方向快速定位。如果确认算法没问题但结果还是不对就以标准已知明文做一次对照测试判断是否为题目在RC4实现里藏了改动。5. 复盘延伸出题人埋这个坑的用意以及同类变体解完题再回头看EasyProgram虽然名字里带Easy设计上其实很有层次。RC4算法本身人人都能搜到标准实现甚至可以直接用工具解真正拉大区分度的就是那层Unicode转义编码。5.1 为什么出题人偏爱算法加编码的组合CTF密码学题如果只给RC4密文大家用CyberChef一键就解了题目没有区分度。加上一层编码转换后工具盲解会直接翻车做题者必须真正理解每一层数据的形态转换。这种算法难度低、编码陷阱深的组合在入门题里是很常见的出题策略。它考察的不是你会不会写RC4而是你能不能识别出题目在哪个环节做了手脚。放在真实场景里也很说得通数据从A系统传输到B系统时最常见的故障源就是编码不一致。看起来一模一样的字符在UTF-8和GBK下可能是完全不同的字节。做过类似CTF题的人调试接口乱码问题时会有更强的敏感度。5.2 我见过的同类编码陷阱Base64结果又做了一次URL编码题目给的是%25E4%25B8%25AD这种双重编码形态必须先URL解码再Base64解码。十六进制字符串被写成C语言风格比如0x1F, 0x2F正则要从0x开头的模式去匹配。GBK和UTF-8互相误读导致的乱码这种在杂项题里特别多。输出文件里混了不可见字符比如零宽空格肉眼看不出来但脚本处理时长度对不上。这类编码问题我一般会借助随波逐流这个CTF编码工具先做一轮探测。它把常见的编码转换、进制转换、URL编解码都集成在一个界面里对新手尤其友好省去自己反复写Python脚本验证的时间。5.3 工具与学习资源解RC4验证结果时CyberChef是最高效的选择。把密钥放到Key栏输入按Hex格式填入选择RC4模块输出立刻可见。适合在写脚本之前先确认答案方向。如果想深入理解RC4的KSA和PRGA内部状态变化可以搜一下魔鬼凯撒的rc4茶室这个资料它对RC4的讲解比较直观用了很多实例演示密钥流生成过程。工具始终只是辅助比赛或考试时建议还是能手写一版标准RC4因为很多题目会在标准算法上做细节改动工具识别不了改过的逻辑但你自己写代码的话改一个取模或者交换顺序就能适配题目。5.4 给新手的最后经验做了这么多道CTF题EasyProgram给我留下的最深印象不是RC4而是那句先确认数据形态。我在实际解题时最开始的半小时一直在跟乱码较劲后来冷静下来把数据流画出来才找到问题原始flag - RC4加密 - 十六进制转义输出 - output.txt解密方向就是严格逆着来output.txt - 还原转义字节 - RC4解密 - flag每一层之间明确输入是str还是bytes是十六进制还是十进制是转义序列还是明文内容。只要这种思维建立起来就算不看任何现成脚本也能自己写出正确的解密逻辑。反之如果急着找flag盯着乱码瞎试十有八九会卡很久。这道题之后我做所有带编码环节的题目都会先写一行注释标明每一层的数据类型和转换函数。这个习惯帮我避开过很多看起来简单的坑也让我在BUUOJ上刷题的效率明显提升。如果你也是刚入门CTF密码学建议把这道题从头到尾手工做一遍收获会比直接看脚本答案大得多。