逆向工程入门：BUUCTF RE刷题实战笔记与工具链详解

有段时间，我打开BUUCTF的RE分区，看着慢慢变长的题单，起了个很随意的标题：看心情写。在这个标题下，我攒了一堆零散的逆向笔记和脚本碎片。真正开始刷之后我发现，“看心情”其实是种被低估的学习策略——状态差的时候写点简单题热身，状态好的时候啃硬骨头，比硬着头皮按顺序往下刷效率高得多。这篇东西不打算写成系统教程，更像是我把自己的私下笔记摊开，把BUUCTF上RE题最常出现的套路、最常用的工具、以及那些我踩过的坑，按照我实际做题的顺序重新整理一遍。适合刚接触逆向、想在BUUCTF上动手刷题但不知道从哪下手的读者，也适合那些刷了几道题、卡在“看得懂但要写出flag总是差一步”阶段的朋友。

1. 这道“看心情写”的RE题单，到底在刷什么

1.1 为什么选BUUCTF当RE刷题主战场

BUUCTF最讨人喜欢的地方，是它把各个CTF比赛的历年真题收集到一个平台，不需要你满世界找附件、找远程端口。对RE来说，这意味着你能在几周内接触到不同出题风格的题目：国内高校赛的、强网杯的、各类国际赛的，全部集中在同一个网页里。做题的时候不用切换十几个平台，每道题有固定附件，有提交flag的地方，甚至有的题还有提示板块。它的题目难度分布也比较合理，从最简单的“逆向签到题”到需要花一整天慢慢调的函数级混淆题都有。

我自己的体会是，把BUUCTF当RE“专项训练场”非常合适。因为分类明确，你想练ELF就刷ELF，想练PE就刷PE，想练安卓逆向也有对应的APK题。这种分类环境能让练习有的放矢，而不是每个比赛都混着大量自己不会的题型。所以我的“看心情写”其实只解决一个问题——今天练哪方面的逆袭能力，而不是漫无目的地乱刷。

1.2 “看心情”不等于乱刷：选题的几类标准

如果真的一点章法没有，刷题效率会很低。我的做法是提前把RE题按几个粗糙标签分类：加壳题、算法题、游戏题、混淆题、迷宫题、安卓题。然后“看心情”指的是在某一类里挑当天感兴趣的一道，而不是今天随便点开哪个算哪个。

举个例子，连着做了两三道纯算法题之后，脑子对TEA、RC4这类算法模式已经比较熟，这时候我会临时切一道花指令题换换场景，让大脑换一种分析模式。这种切换本身也是逆向训练里重要的一部分，因为真实工作中你不会知道自己下一份样本是什么风格。有意识地调换题目类型，比一直死磕同一类题更容易积累全面的经验。此外，我还会设定一个硬性条件：每道题至少要写到“提取出完整的flag字符串”这一步才能算完。很多题目你感觉思路通了、脚本跑了、结果也有了，但最后提交时发现大小写搞反、少一位、编码方式理解错了，这一类细节会直接决定“会不会做”和“能不能得分”之间的差距。

2. 拿到一个RE题，前三分钟的静态侦察决定一半成败

2.1 永远从文件类型和外壳开始

我见过不少人拿到附件直接拖进IDA，然后盯着一段没有任何上下文的机器码发呆半钟头。我自己的习惯是，先做一套固定动作。

第一步永远是file，在Linux里看文件类型：

file 题目附件 # 常见结果：ELF 64-bit LSB executable # PE32 executable (console) Intel 80386 # MS-DOS executable # Java archive (JAR) # Android package (APK)

如果是一条ELF文件，就顺便看一下有没有strip、arch大小，以及PIE是否开启：

readelf -h 题目附件 | grep Type checksec --file=题目附件 # 如果你有pwntools

如果是Windows PE，我习惯用Exeinfo PE或者DIE（Detect It Easy）再查一下壳。DIE的界面更直观，拖进去就能看到编译器信息、是否加壳、加的是什么壳。很多时候“看似复杂的题”其实只是UPX壳，直接命令行upx -d 附件.exe能解决一大半问题。

这一步的意义在于决定后续策略。静态能看到正常代码，就不用浪费时间在动态调试上；如果发现壳，先想到脱壳而不是直接硬逆。去年有一阵子我连续几次在PE题上栽跟头，后来一查，全是没先查壳，把UPX压缩代码当成了原始逻辑去分析，白白浪费一小时。

2.2 字符串、导入表、入口点：三个最快的信息源

过完文件类型，我基本会打开IDA或者Ghidra，但第一件事不是看反汇编，而是先看字符串窗口。Shift+F12在IDA里会列出所有字符串，这一步能带给你大量信息：

• 如果程序有交互流程，比如要你“输入flag”或者“Wrong/Correct”，字符串窗口里会直接出现这些提示；
• 如果程序是从文件读入数据，你会看到文件名、打开失败等报错字符串；
• 如果程序调用了系统命令，你甚至能看到system("./getflag")这类逻辑尾巴；
• 如果题目用了加密算法，字符串里经常能找到特征常量，比如TEA的0x9E3779B9、RC4的S盒初始化所需的密钥提示、或者某个表名。

然后我会快速扫一遍导入表。Windows PE在IDA的Imports窗口里能看到调用了哪些API：如果一堆GetAsyncKeyState、SetWindowsHookEx，那多半是键盘记录类程序；如果大量CreateFile、ReadFile，这是文件读取型。Linux ELF则主要关注puts/printf/scanf/strcmp：有strcmp的题通常意味着比较逻辑藏在某个函数里，可以顺着交叉引用找关键点。

最后看一眼入口点。如果入口点不是我们常见的main、_start或者PE的WinMain，而是落在某个奇怪的地址，那就要警惕是不是有自定义启动逻辑，或者入口被混淆改写。很多时候这些“不自然”的位置恰恰是出题人藏东西的地方。

2.3 静态侦察的产出：先给题目“建档案”

把上面信息集中起来，我会在笔记里写一行“题目档案”，差不多长这样：

[jocker] PE32 | 无壳(?待确认) | 有大量花指令 | 提示字符串“Locker”“You are wrong” [snake] ELF64 | 非PIE | 游戏逻辑型 | 有关键字符串“score”“flag” [findme] PE32(MFC?) | 有大量导出函数 | 需定位主回调 | 字符串分散

建档案是给自己省时间，因为你经常会在一个晚上同时开三四个题，大脑容易混。几行字能让你快速回到之前的上下文。更重要的是，通过画像你能大致预测自己要用什么解法，比如看到“OLLVM混淆”可能就需要准备好Angr或者花时间动态跟踪；看到“算法题”就直接准备Z3和Python脚本库。不要高估自己的记忆力，RE分析中上下文切换的成本特别高，档案越清晰，切换代价越低。

3. 主逻辑拆解三板斧：F5太顺是运气，不顺才见功底

3.1 第一板斧：C裸题的直接F5

BUUCTF里有很多签到级别的题，逻辑就是C语言裸写的：读入字符串，经过一个简单函数变换，再和明文或者某个内存地址比较。这类题的IDA反编译页面非常干净，F5之后就是主函数：

int __cdecl main(int argc, const char **argv) { char input[64]; scanf("%s", input); if ( strcmp(encrypt(input), "目标串") == 0 ) puts("Right"); else puts("Wrong"); }

遇到这种题，别急着去手动模拟每个字节的逻辑。我的做法是先确定strcmp的第二个参数地址，然后在调试器里直接下断点，程序跑到strcmp时读它的参数。如果比较参数是全局数组，一种简单粗暴的方式是直接看数据段里“目标串”附近的字节，答案常常就明文躺在那里。

这里有个小技巧：IDA里选中strcmp的调用点，按X看交叉引用，能快速确认谁是参与比较的数据。千万不要在没有搞清楚比较函数之前就去读整个程序的伪代码，那样很容易被无关变量带偏。

3.2 第二板斧：算法识别——TEA、RC4、Base64换表

签到题之外，BUUCTF最常见的一类就是算法题。出题人把flag经过某种加密变换之后存在内存里，你输入的内容也走同样变换，然后比较。常见的算法有以下几种，每个都有比较明显的特征：

识别出算法之后，解题方向就变成“翻译”脚本。比如TEA，直接把密文、密钥、delta抄进Python脚本，用标准TEA解密流程跑一遍即可。这里最容易翻车的是加密模式理解错，很多出题人会魔改轮数或者把字节序倒过来，导致你用标准库解出来全是乱码。我的经验是一边解一边看输出是否可打印，如果乱码，先尝试反转字节序，再尝试调整密文分组顺序。

3.3 第三板斧：动态调试确认关键比较点

静态分析有时候会走到死胡同，尤其是遇到动态生成密钥、解密后再比较的情况。这时候就需要上调试器。Windows平台我的主力是x64dbg，Linux就是gdb配合pwndbg插件。做法是：

1. 找到比较位置（通常以strcmp、memcmp或者逐字节循环体现）。
2. 在比较位置下断点。
3. 运行程序，随便输入一串aaaa之类的有规律内容。
4. 程序断在比较位置时，直接看寄存器或者栈上的目标地址内容，目标字符串大概率会被调试器以明文字符串展示出来。

这个技巧在很多场景下比静态推演快得多。因为程序都已经把密文或者目标串准备好了，你不需要自己再从内存里捞出来做二次解密。尤其适用于那些“解密函数写在前面、比较写在后面”的题，断点一停，内存里就是解好的明文。

3.4 用脚本把“能看懂的题”变成“能跑出flag的题”：Z3示例

有些题目逻辑不复杂，但变换过程中用到了大量位运算和数组索引，手动逆很容易出错。我会选择上Z3约束求解器。最常见的场景是：

from z3 import * flag_len = 32 flag = [BitVec(f"f{i}", 8) for i in range(flag_len)] s = Solver() for i in range(flag_len): # 常见约束：可打印字符 s.add(flag[i] >= 0x20) s.add(flag[i] <= 0x7e) # 把IDA里F5出来的运算语句翻译成z3约束 # 例如：data[i] = (flag[i] ^ 0x2a) + 7 # 那么约束就是 (flag[i] ^ 0x2a) + 7 == target[i] for i in range(flag_len): s.add((flag[i] ^ 0x2a) + 7 == target[i]) if s.check() == sat: m = s.model() print(bytes([m[flag[i]].as_long() for i in range(flag_len)]))

很多人觉得Z3很神秘，其实就是把“已知输出，求满足所有方程的输入”这个数学问题丢给求解器。逆转题的常规操作就是把IDA里的表达式逐行翻译成Z3约束，然后用check() + model()捞结果。我自己在BUUCTF上至少有五分之一的题是靠Z3跑出来的，特别是当伪代码里出现((x << 3) | (x >> 5)) + (y ^ 0x55)这种位运算时，手算绝对不如约束求解。

4. 回看几个BUUCTF题型的实战思路：jocker、snake、findme

4.1 jocker：花指令和假逻辑的挑战

我记得自己第一次刷jocker这道题时，直接被入口处的花指令劝退。程序在运行之前会对代码段做大量的修改，IDA静态F5出来的结果完全不可读，全是跳来跳去的无效分支和看起来极不自然的赋值操作。当时我犯的最大的错误是想把每一个指令都读懂再继续，结果花了一个多小时还在原地打转。

后来我的做法换了方向：先不管花指令，直接动调。用x64dbg打开程序，让它跑起来，看它输出了什么，输入点什么。jocker这道题让人印象深刻的地方是它有一个“locker”的概念，程序最开始会对你输入的字符串做一个假的校验，让你以为逻辑在这里；而真正的校验藏在一堆被混淆过的代码后面。动态跟的过程中，我直接把断点下在比较函数上，一路放行，程序跑到真正比较输入缓冲区的位置时，周围的内存里就出现了处理后的字符串。再把这个字符串和我的输入联系到一起，很快就能发现函数真正的逻辑只是某种旋转加异或，根本不是刚开始F5看到的那一坨“天书”。

这种题给我最大的教训是：静态看不懂，不代表动调也看不懂。混淆代码常常只骗静态分析，运行时真实路径很清晰。看心情刷题的时候遇到这种题千万别赌气跟它死磕，先把动态跑起来，程序自己会告诉你答案在哪。

4.2 snake：游戏题要找的不是“高分”，是隐藏的flag触发条件

snake这道题，我最早以为要手动玩贪吃蛇，玩到某个分数才能爆flag。后来发现自己想多了。这类游戏题的通用解法很简单：程序主循环一直在处理蛇的移动、食物生成、分数更新，但flag通常藏在某个全局变量或者分支里。你要做的事情是搜索关卡、分数、蛇身长度相关的变量，然后顺藤摸瓜找到那个“一旦满足条件就输出flag”的分支。

我当时是先找到游戏的渲染循环，然后在更新分数的代码处下断点。通过观察寄存器，找出食物坐标、蛇头坐标、分数变量存储的位置。接下来就是修改内存：直接把分数改成极大值，或者直接把“是否通关”的布尔变量改成1，看程序有没有跳转到输出flag的路径。很多游戏题都是这种设计：你不需要真正通关，只需要让通关条件为真。

这里我要多说一句：游戏题的逆向思路比具体某道题更重要。因为恶意软件分析里经常遇到类似场景，比如一个程序向服务器请求授权，如果服务器返回特定值才解密核心逻辑。逆向者需要绕过验证函数，而不是真的把服务器部署一遍。多刷几道游戏题，对这种“绕过验证点”的敏感度会提高很多。

4.3 findme：在函数海洋里精准定位主逻辑

提到findme这种题，我心里浮现的画面就是IDA的Functions窗口一拉到底的滚动条。它不像snake那样整体是游戏循环，而是把所有代码塞在很多小函数里，每个函数看起来都像在算东西，但真正涉及flag可能只有其中几个。遇到这种结构，最忌讳的就是从头到尾逐个F5。

我的方法是先搜字符串。程序大概率会在某个地方输出“flag”或者读取文件，通过对这些字符串的交叉引用，一层层往回跳，往往能定位到最外层主逻辑。如果字符串不可见，就搜“错误提示”“输入”这类交互提示词。再不行，就看可能参与比较的表数据：比如有一块256字节的S盒、一块64字节的Base64表，顺着数据的引用，也能找到函数。

如果交叉引用太多太乱，我会退一步用Ghidra。Ghidra的“函数调用图”视图很直观，能看出哪些函数是核心节点。findme这类题通常只有一两个核心中枢，函数调用图上大量函数都指向它，你用拓扑视角扫一眼就能找出可疑对象。定位目标函数，比理解所有函数重要得多，这是所有“函数海洋”型题目共同的核心原则。

4.4 顺带聊隔壁分类：zips这类和RE互通的杂项题

BUUCTF上有个让我印象深刻的题是[GUET-CTF2019]zips，严格来说它被归到杂项（MISC）分类，但做题过程充满了RE元素。很多人看到zip附件就开始爆破密码，爆破一轮发现碰了壁，最后发现其实要通过分析压缩包内部某个Python脚本或者数据块，逆向出真正的密码或者拼接方式。

我的看法是：RE能力实际上是一种跨分类的底层能力。MISC里的隐写、流量、压缩包伪加密，经常会在某个环节里藏着一个需要你逆向的算法；PWN题里的shellcode分析也需要你读懂机器码。所以在看心情刷RE题的过程中，偶尔点开一道MISC题不会亏，反而能帮你把“分析型思维”磨得更圆。RE的核心不是会用某个工具，而是能在陌生二进制里快速建立假设并验证，这个能力放到MISC、PWN甚至漏洞分析里全部通用。

5. 看心情刷题最容易踩的坑，我基本都踩了一遍

5.1 UPX脱壳和手动修复的坑

先说结论：PE加UPX壳，九成情况下会想到用upx -d一键脱壳，但成功率没有想象中那么高。很多BUUCTF题故意使用修改过的UPX，或者主程序头部被改过，导致官方脱壳工具直接报错“Invalid UPX header”。这时候就要手动脱。

手动脱的第一步是找原始入口点，最常用的方法是ESP定律，或者在x64dbg里对栈顶下硬件断点，利用程序解压完代码段后执行push指令跳回OEP（Original Entry Point）的瞬间，拦截到真正的入口。到了OEP之后，把进程完整dump下来，再用Scylla或者ImportREC修复IAT。修复IAT的时候要特别注意：程序可能有多个IAT区块，Scylla如果只解析出一张表，要检查导入函数是否完整，缺了的话运行起来就直接蹦“无法定位程序输入点”之类的错误。

我自己脱壳失败的原因，十有八九是dump时机太早，代码段还没解密完。判断时机是否正确的技巧是：在跳到OEP时，检查一下.text段头所在地址附近的字节是否已经是真实代码特征（比如连续的push ebp; mov ebp, esp或者sub rsp, xxx），如果看起来像随机字节，说明还没解完，不要急着dump。

5.2 反调试和OLLVM混淆：别跟花指令较劲

BUUCTF的RE题里有一批题目喜欢上OLLVM，尤其是控制流平坦化（flatten）功能。经过平坦化后，伪代码会变成一堆switch-case的分发结构，看半天也看不出原来的条件分支在哪。我记得自己第一次遇到时心想“这程序是疯了吧”，差点直接放弃。

后来我学到几个实用技巧：

• 不要试图在伪代码里重建原始逻辑，而是找数据流。看哪些变量被赋值后一直存活到最后参与比较，顺藤摸瓜就够。
• 如果遇到底层只有一堆mov eax, xxx; jmp switch的模板，直接跳过中间过程，只关心关键函数的输入输出。
• 使用Angr或者Triton这类符号执行工具直接跑，很多平坦化题目在这种工具面前等于没混淆。Angr最常用的接口是：

import angr p = angr.Project("./题目") state = p.factory.entry_state() simgr = p.factory.simulation_manager(state) # 寻找包含目标地址的分支 simgr.explore(find=0x目标地址, avoid=0x错误地址) if simgr.found: print(simgr.found[0].posix.dumps(0))

不过要提醒一句，Angr处理简单混淆题可以，遇到能膨胀几万条指令的复杂样本时，符号执行也很容易被路径爆炸拖死。所以正确顺序是：先试着动态看懂，再看能不能用z3模拟，最后才上Angr。工具是用来辅助理解的，不是用来逃避理解的，这句话我在刷OLLVM题时反复对自己说。

5.3 环境坑：glibc、dll缺失、架构差异

有一类坑和题目逻辑无关，但特别消耗做题心情。比如下载的ELF题在本地跑不起来，报GLIBC_2.34 not found；或者Windows程序在自己的Win11纯净环境里缺几个VC运行库；还有的题是32位程序，需要你有32位运行库支持。

我现在的常规处理是配一个专门用来做题的Linux虚拟机，系统保持在Debian或者Ubuntu长期支持版，并在里面装好gcc-multilib、g++-multilib，确保32位ELF能跑。Windows的题目则统一用Windows 10虚拟机里的x64dbg和IDA，避免在真实工作机里装一堆来路不明的运行库。如果deploy到一个临时容器里跑题，比如GLIBC版本不匹配，最省事的选择是直接用题目自带的Dockerfile启动环境，很多高版本CTF题都会附带容器配置。

另外提一句，安卓RE题也会踩环境坑。APK解包之后如果要动态调试，得用合适的模拟器或真机，Android SDK版本和架构经常不一致。这些坑在“看心情刷题”的语境下尤其烦人，因为你本来只是想随手做一道题放松一下，结果花半天配环境。所以我建议把环境调试当成一次性的基础设施投入：把自己常用的镜像、依赖、插件先装好，之后所有题都用同一套环境，问题会少很多。

6. 给同样“看心情”的RE新手：一份精简工具与心态备忘

6.1 我最终留下的工具链

反复折腾之后，我现在的RE工具链精简到以下几样：

• IDA Pro：主力静态分析，F5伪代码对做题效率提升极大。
• Ghidra：免费替代，当IDA许可证不在手边时主力使用，函数调用图分析很舒服。
• x64dbg / gdb+pwndbg：Windows和Linux动态调试器。x64dbg的界面比OllyDbg现代，插件生态也够用。
• DIE / Exeinfo PE：查壳，DIE的识别精度高，界面直观。
• UPX：一键脱壳工具，遇到简单壳直接秒解。
• Python + z3-solver + angr + pwntools：脚本化求解三件套。Z3解约束，Angr跑符号执行，pwntools处理ELF/远程交互。
• 010 Editor：看二进制文件结构、hex流，修文件头时非常有用。
• Frida：移动端动态插桩，偶尔刷安卓题时用。

这套工具链覆盖了PE、ELF、APK三类最常见题型的全部环节。不要再额外装一堆“看起来很厉害”的工具，工具越少越好，你才能越用越熟。尤其是新手，我见过有人电脑里装了十几种逆向工具，结果每种都用得半生不熟，遇到题目反而不知道该选哪个。

6.2 心态和刷题顺序建议

最后想聊点跟技术无关但特别重要的东西。RE刷题和做数学题很像，状态的起伏非常明显。看心情写这个标题之所以能成立，是因为逆向工程真的需要“心流状态”：你掉进一个混淆函数的兔子洞里，如果心态崩了，手会开始乱点，断点会乱下，看伪代码会越看越烦躁。所以我给自己定了几个规矩：

第一，卡住超过四十分钟就暂停。去喝水、散步、甚至换一道题，让大脑后台继续处理。很多时候你回来两分钟就发现了刚才漏掉的一个小细节。第二，每道题做完都写一行复盘，不管是解题思路还是踩的坑。这个习惯看起来很简单，但真到了三个月后你回头看自己写过的东西，会发现过去的“坑”已经变成肌肉记忆。第三，不要妄想每道题都能独立做出来。有些题目确实需要看WriteUp才能补上知识盲区。看WriteUp不是丢人的事，关键是看完之后要能自己手动复现一遍，而不是脑中“懂了”就翻页。

6.3 把“看心情”变成可持续的刷题节奏

我理想的刷题节奏是：一周抽三四个晚上，每次一道题，状态好就加一道。选题目时参考上面的分类，哪类弱就补哪类。遇到明显超出当前水平的难题，先记下来，放到一个月后再回来试。这样做的好处是，知识盲区会在时间间隔中被其他题目自然填充，等回头再看那道难题时，你可能会突然发现自己的工具栈已经能覆盖它了。

BUUCTF的RE题单其实很耐刷。有些题我隔了大半年重新拿起来，仍能榨出以前没注意到的新知识点。这也是为什么我坚持维护那个“看心情写”题单的原因——逆向上限不取决于你把自己逼得多紧，而取决于你能否在一个个“看着头疼”的函数里，养成“先分析、再怀疑、后验证”的固定动作。动作对了，心情自然会顺。希望这篇杂乱但实用的笔记，能成为你也在BUUCTF上打开第一道RE题时的一点底气。