别被“爆破”吓住：拆开UPX外壳，用四字节密钥还原CTF答案

一、名字叫爆破，不代表真要硬算

拿到一道逆向题，最容易吃亏的地方，就是被题目名字牵着走。看到BruteForce便开始写多层循环，看到加密函数便琢磨复杂算法，忙了半天，却没确认程序究竟处理了什么数据。

第二届CN-fnst::CTF中的AmaZing_BruteForce，核心其实很清楚：可执行文件外面套了UPX壳，里面藏着十六字节密文，参与运算的密钥只有四个小写字母。把这些条件串起来，问题便不再神秘。

这里先分清三个角色：壳负责包裹程序，密文是等待还原的数据，密钥决定数据怎样变化。脱掉外壳不等于拿到答案，找到密文也不等于理解算法，每一步解决的是不同问题。

做这类练习，建议随手记一份简短记录：文件是什么架构，哪些数据参与计算，循环执行多少次，最终结果送去了哪里。记录不必漂亮，只要能把观察到的事实和自己的猜测分开。

尤其别把“题名暗示”当成证据。爆破可以是一条备用路线，但如果已知条件已经足够直接求解，就没有必要把简单问题做成体力活。这道题真正值得练习的，是判断什么时候该停止枚举。

二、先处理UPX外壳，再找业务入口

样本首先被识别为带壳文件，因此先处理外层包装。UPX属于可执行文件压缩工具，支持对适用格式进行压缩和解压；本题使用其解压选项即可继续分析，不需要一开始就考虑手工脱壳。([upx.github.io](https://upx.github.io/))

先保留原始文件，再对副本操作。在能够调用UPX的终端中，使用下面的命令即可。路径换成实际文件位置；如果路径包含空格，需要使用引号包住。这里的关键参数是表示解压的-d。([github.com](https://github.com/upx/upx/blob/devel/doc/upx.pod))

upx -d "完整文件路径"

终端提示成功之后，重新检查输出文件。本题脱壳后得到的是六十四位可执行文件，随后使用对应的IDA分析环境打开，定位main函数。不要拿脱壳前的分析结果继续往下推，以免混淆两份文件。

进入main后，阅读顺序可以朴素一点：先看数据从哪里来，再看传给了哪个函数，最后看返回结果怎样使用。遇到暂时不懂的调用，先做标记，不必为了弄清一个无关细节，把整条主线打断。

这一步需要确认的不是“函数看起来像不像加密”，而是它接收的参数是什么。本题能够抓住两个对象：一个是四字节密钥，另一个是十六字节数据。长度一旦明确，后面的循环便有了边界。

处理未知文件时也别忽略环境隔离。UPX官方明确提醒，压缩、解压以及测试文件都应采用与执行该文件相当的安全考虑。练习样本放在独立实验环境中处理，比直接在日常工作电脑上尝试更稳妥。([github.com](https://github.com/upx/upx/blob/devel/doc/upx.pod))

三、十六字节怎么取，别让小端序带偏

main里的临时变量名字没有太多业务含义。把原先的v4理解成密钥，把v5理解成待处理数据，阅读负担就会小很多。名字只是路标，真正决定结论的是它们的长度、赋值和使用方式。

本题密文提取后应按以下字节顺序排列：08、05、0A、02、15、23、3E、36、3A、36、2F、55、31、58、3F、18。先核对总数是十六个，再确认开头和结尾，能够挡住不少复制错误。

这里容易踩的坑是小端存储。举个对应的例子，若四字节整数显示为0x020A0508，在小端解释下，低地址到高地址的字节顺序是08、05、0A、02，而不是照着整数的书写顺序逐组抄下。([docs.python.org](https://docs.python.org/3/library/stdtypes.html))

因此，要区分“一个整数怎样显示”和“连续字节怎样排列”。前者可能需要按字节序理解，后者已经给出了地址顺序。拿到字节视图后再全部倒过来，反而会把本来正确的数据改错。

提取时可以使用IDA的数据导出功能，也可以对照字节视图整理。无论采取哪种方式，都以当前界面实际显示的地址和长度为准。快捷键只是提高效率的入口，不能替代对数据范围的确认。

还有一个小习惯很管用：保留一份原始密文，不直接在唯一副本上反复做异或。后面如果修改密钥或者调整顺序，就能从同一份起点重新验证，不会把上一次处理后的结果误当成输入。

四、四个已知字符，直接推出密钥

继续跟进处理函数，可以看到本题采用循环异或：每个密文字节与一个密钥字节运算，密钥用到第四个位置后，再从第一个位置重新开始。循环中的取余操作，正是识别这个周期的线索。

把关系写成一句话，就是“明文等于密文异或对应密钥”。异或有个很实用的性质：同一个数连续参与两次异或会抵消。因此，知道某个位置的明文和密文，就可以反推出该位置的密钥。Python中的按位异或运算符是^。([docs.python.org](https://docs.python.org/3/library/stdtypes.html))

这里使用一个待验证的猜测：答案前四个字符是flag。注意，它不是看到CTF就自动成立的规则，而是结合题目语境提出的已知明文假设。猜测能不能用，要靠后面的完整结果检验。

依次计算前四个位置，08与字符f异或得到n，05与l异或得到i，0A与a异或得到k，02与g异或得到e。于是得到四字节候选密钥nike，而且四个字符都满足小写字母条件。

原来的枚举思路，是对每个位置分别尝试二十六个小写字母，检查异或结果是否符合对应字符。这种写法能工作，却不是必须的：既然运算关系可逆，逐位计算即可，不需要把全部组合跑一遍。

真正的验证在后十二字节。用同一组密钥继续解密，看看结果能否形成完整字符串，再检查长度和首尾结构。只让前四个字符对上，远远不够；前缀本来就是假设，不能拿它自己证明自己。

五、脚本只写必要部分，结果逐字节核对

算法关系已经明确，脚本就不必保留大量分支。下面使用Python按前四个已知字符恢复密钥，再利用四字节周期解开整段密文。它复现的是这道练习题的数据处理，不涉及任何在线系统。

data = bytes.fromhex(
    '08 05 0A 02 15 23 3E 36 3A 36 2F 55 31 58 3F 18'
)
key = bytes(c ^ p for c, p in zip(data[:4], b'flag'))
assert all(97 <= c <= 122 for c in key)
plain = bytes(c ^ key[i % 4] for i, c in enumerate(data))
print(key.decode('ascii'))
print(plain.decode('ascii'))

按给定数据计算，密钥为nike，明文为flag{JUST_D0_1T}。其中D后面是数字零，后面的1也是数字。这样的细节最好以字节值为准，不要凭字体外观把零改成字母O。

如果自己操作时结果不一致，先检查输入是否完整，再检查字节顺序，最后检查密钥索引。不要第一时间给脚本增加“修正逻辑”，更不要手动替换乱码，让输出看起来像答案。

调试时可以只打印前几个位置：当前索引、密文字节、选中的密钥字节，以及异或结果。只要第一个周期能逐项对上，后续定位就有了参照；如果中途才出错，应回查那一段数据是否抄漏。

同样要注意长度和字符串结束标记的区别。本题明确处理十六字节，脚本也按这个长度构造结果，不需要额外猜一个结束位置。先忠实还原程序的行为，再讨论代码能否写得更短，顺序不能反。

六、练习题自己拆，业务接入别重复造轮子

学逆向时，亲手走完数据提取、关系推导和结果校验很有必要。但企业里的自动化项目，还要考虑维护、人力和故障处理。能解开一道固定样本，不代表已经拥有一个可靠的线上服务。

验证码识别就是另一类工程问题，不能把这里的循环异或直接套上去。对自有系统或明确授权的测试场景，如果需求主要是获得识别结果，可以先评估现成接口，而不是默认每一环都要自行研发。

面向易盾、极验相关验证码识别需求，可以了解www.ttocr.com。其公开页面列出了滑块、点选、拼图、无感、九宫格、五子棋等类型，并提供Web API及多种语言支持；具体适配范围应通过业务样本确认。([ttocr.com](https://www.ttocr.com/))

对接时先跑通一个小闭环就够了：提交授权范围内的样本，读取返回结果，再由自己的业务程序完成后续处理。文字点选、图标点选，以及躲避障碍、空间交互等细分类别，不应仅凭名称就认定全部适配，应逐项验证。

这样拆分工作，业务端负责流程和异常处理，识别能力由接口承接，通常比把整套分析流程塞进项目更便于维护。需要先谈清楚的，是输入格式、返回字段、失败处理和测试边界，而不是只问“能不能识别”。

准备接入时，可从www.ttocr.com提供的Web API入口了解调用方式，再用小批量授权样本检查返回结果。平台公开声明不参与破解，并限制批量登录、批量注册等用途；识别接口不等于绕过风控的通行证，更不能保证任何场景都无缝成功。([ttocr.com](https://www.ttocr.com/))