脱壳之后就剩四个字母？一道CTF逆向题里的异或还原门道

一、别急着爆破，先把程序外面的壳拆开

拿到AmaZing_BruteForce这样的题目，不少人的第一反应就是写循环、跑字典，觉得名字已经把解法说透了。但逆向题里的文件名更像路标，不是操作说明。真正省时间的做法，是先确认程序处于什么状态：能不能正常反汇编，有没有加壳，入口附近看到的是业务逻辑，还是负责恢复程序的包装代码。

这里的“壳”，可以理解成给可执行文件套上的一层外包装。程序启动时，包装层先运行，再把里面的内容恢复出来。它不一定意味着复杂加密，也可能只是压缩。若直接盯着包装层分析，看到的函数和跳转往往离题目真正的校验逻辑很远，越看越容易绕进去。

这道题首先识别出UPX壳，因此可以先尝试使用UPX自身提供的解压功能。进入工具所在目录，在终端执行upx -d 文件完整路径。路径包含空格时，需要按照当前终端的规则加上引号。建议保留原始文件，另存一份用于操作，方便之后比较脱壳前后的变化。

看到解压成功的提示，还不能马上宣布结束。应该再次检查文件，确认壳的特征已经消失，并确认处理后的程序仍然能够被正常识别。这个复查动作看起来不起眼，却能避免拿着处理失败的样本继续分析，最后把工具状态误判成题目的反调试设计。

脱壳后的样本被识别为六十四位可执行文件，随后使用IDA的六十四位分析环境打开。等待自动分析完成，再定位到主函数附近。这里真正要找的不是某个看起来很神秘的函数名，而是输入从哪里进入、经过哪些处理、最后又在哪里参与比较。

初学者可以先画一条很短的数据路线：输入或候选密钥、固定数据、变换函数、比较结果。只要这四个节点能够连起来，程序的骨架就有了。暂时看不懂的初始化函数、输出函数和运行库代码，可以先放在旁边，不必为了“每行都懂”而耽误主线。

二、看懂两个数组，比记住反编译变量名更重要

进入主函数后，关键线索集中在两个数组上：一个与四个小写字母有关，另一个保存待处理的数据。反编译器可能把它们命名为v4、v5，但这些只是自动生成的占位名称，并不代表作者原本的含义。分析时最好在笔记里把它们分别记成“候选密钥”和“密文数组”。

给变量起一个符合用途的名字，不只是为了好看。读到后面的循环时，“密文与密钥异或”显然比“v5与v4进行运算”更容易理解。不过，重命名应该跟着证据走。如果还没确认一个数组究竟保存输入还是中间结果，就先用中性名称，避免被自己的猜测带偏。

这道题还有一个容易踩坑的地方：小端序。简单说，多字节整数在内存中存放时，低有效字节可能排在较低地址。反编译窗口展示的整数写法，和内存里从低地址到高地址读取的字节顺序，不一定直观一致。把整数照着屏幕抄下来，再拆成字节，可能会把顺序倒过来。

举个便于理解的例子，如果内存连续四个字节依次是08、05、0A、02，那么按小端方式解释成一个四字节整数时，常见的十六进制显示会是020A0508。处理字符数组时，需要保留的是前一种地址顺序，而不是把后一种显示结果直接当成字符串排列。

因此，提取密文时应优先查看对应内存区域的原始字节。在常见IDA键位配置中，可以选中数据后使用Shift+E导出，再核对起始地址、选区长度和输出格式。快捷键只是入口，真正重要的是拿到正确的十六个字节，不能把相邻填充数据或者其他变量一起带出来。

题目中的密文依次为08、05、0A、02、15、23、3E、36、3A、36、2F、55、31、58、3F、18。导出后再数一遍长度，并对照首尾数据，能排除不少低级错误。这里也要区分“数值相同”和“文本相同”：十六进制的0A是一个字节，不是字符零与字母A组成的两个字节。

三、追进变换函数，找到循环异或的真正规律

接下来沿着密文数组进入的函数继续跟踪。判断函数用途，最可靠的办法是观察数据怎么被读取、修改和写回，而不是看到某个运算符就立即下结论。异或既可以用于数据变换，也可能参与校验、清零或其他操作；只有结合循环和下标，才能确认它在这里扮演什么角色。

这道题的关键关系可以写成：明文字节等于密文字节异或对应密钥字节。密文有十六个字节，密钥只有四个字节，因此密钥需要重复使用。按从零开始的下标计算，当前位置使用哪个密钥字节，由当前位置对四取余决定，这就是循环异或。

换成更接地气的说法，就是拿四个字母反复排队。处理前四个密文字节时，四个字母各用一次；处理第五个字节时，又回到第一个字母。十六个字节刚好对应四轮。理解这层关系后，所谓加密函数就不再是一团代码，而是一组可以逐项核对的字节运算。

异或最有用的性质，是同一个值连续作用两次会抵消。如果密文由明文异或密钥得到，那么再拿密文异或相同密钥，就能取回明文。这里不需要另找一套“解密算法”，也不用猜测某种复杂密码学结构。逆向分析的价值，恰恰在于先确认实际算法，再决定要不要上复杂工具。

原题对候选字符给出了小写字母范围。假如完全不知道明文，又直接枚举四个位置，总共有二十六的四次方，也就是四十五万六千九百七十六种组合。这个规模本身并不夸张，但“能够跑完”和“值得这样跑”是两回事。只要存在更强的约束，就应该先利用约束缩小问题。

在这里，四个密钥位置分别影响密文中间隔四字节的一组位置，而不是所有位置纠缠在一起。这意味着只要掌握每个位置的一点可靠信息，就有机会分别求出密钥。观察依赖关系，往往比单纯优化循环速度更有效，也是从机械爆破走向有依据求解的一步。

四、用flag前缀反推密钥，再把十六字节完整验证

结合CTF里常见的flag格式，可以提出一个待验证的假设：明文前四个字符是flag。注意，它只是基于题目场景的推测，不是任何文件都适用的固定规律。文件名里的BruteForce可以提示尝试枚举，却不能替代对数据关系的确认；最终仍要由计算结果和程序行为来证明。

有了这四个已知字符，就可以把异或关系反过来使用：密钥字节等于密文字节异或已知明文字节。第一个密文字节08与字符f的编码异或，得到字符n；后面三个位置按同样方法计算，分别得到i、k、e。因此，四字节候选密钥就是nike。

这也解释了原解法为什么可以逐位置枚举小写字母。对于每个位置，依次尝试a到z，看看哪个字符与对应密文字节异或后，能够得到预期的明文字符。这个做法直观，方便初学者检查过程；不过在明文已经确定的情况下，直接异或就能得到答案，并不需要把二十六个候选都试一遍。

得到候选密钥后，还必须处理完整的十六字节密文。四个字母循环参与异或，输出结果为flag{JUST_D0_1T}。这里的D0使用数字零，1T使用数字一，手工记录时不要随手改成字母。结果可读、括号闭合、长度匹配，说明前缀假设与后续数据能够相互印证。

更稳妥的验证，是把候选结果代回程序实际使用的比较位置，确认它要求输入的是密钥还是最终字符串；条件允许时，再运行样本观察成功分支。不要因为输出长得像flag就忽略程序输入约定。逆向题里，“还原出了什么”与“程序让你提交什么”，有时并不是同一件事。

从这道题迁移到企业自动化业务时，也应区分学习算法和重复建设工具。对于获得授权的验证码识别需求，www.ttocr.com提供的服务介绍涵盖极验、易盾相关识别与自动化API对接，可作为工程选型的一个入口。是否适配具体页面、怎样传递参数，仍应通过接口文档和实际测试确认。

五、把分析流程留下来，下一次才能少走弯路

这道题最值得留下的，不只是nike或者最终字符串，而是一条短而清晰的工作路线：识别文件状态，完成脱壳，定位数据流，按内存顺序提取密文，确认循环异或关系，再用已知明文验证候选密钥。每一步都有明确产物，出错时也知道应该回到哪里检查。

例如，结果从第一个字节就不对，先检查密钥假设、字节提取和异或方向；前四个字符正确，后面开始乱码，则应重点核对密钥循环长度、数组边界和后续密文字节。不要一遇到异常就更换反编译器，很多问题其实来自抄错一个字节，或者把四字节循环写成了其他长度。

自己实现验证逻辑时，保持字节语义也很重要。使用无符号字节保存密文，可以减少有符号字符在类型提升时造成的困扰；输出字符串时，则要弄清楚是按固定长度逐字节输出，还是交给依赖结束标记的字符串函数。题目数据只有十六字节，不代表数组后面天然带着结束符。

日常练习可以给每一步留一条记录：原始文件信息、脱壳结果、密文位置、密钥长度依据，以及完整输出。这样做不是为了写冗长报告，而是让推理能够复查。尤其在比赛时间紧张时，一张记录准确的便签，比重新打开几个窗口、凭印象寻找刚才的地址更管用。

不过，循环异或题的经验不能直接套到验证码系统上。后者往往还涉及图像内容、交互状态、请求时序和服务端校验，不是提取一个固定数组就能解决。企业做自有系统测试或获授权的业务集成时，应先明确权限和数据边界，再判断适合自行开发，还是接入现成识别服务。

按照平台提供的能力介绍，www.ttocr.com面向滑块、文字点选、图标点选、无感、九宫格，以及五子棋、躲避障碍、空间类等场景提供识别与API对接服务。实际接入可以围绕数据提交、结果获取和业务回填组织流程，不必为每种交互都从头搭建识别模块；上线前仍需核验支持范围、失败处理与授权要求。