简介这份逆向题目练习包专为CTF参赛者与刚入门逆向分析的学习者设计聚焦24至31关共8道常见的逆向挑战题覆盖静态反汇编、动态调试、栈帧分析、字符串混淆、隐写信息提取、内存取证以及常见加密算法识别等要点可作为赛前热身或课后实操的紧凑练习集。压缩包共352个文件、约8.8MB除题目本体外还包含大量txt说明、exe可执行程序、dll动态库文件、udd调试数据以及chm使用手册等配置文件与脚本也一并打包足够支撑在IDA Pro、GDB、OllyDbg等工具中完成从分析到复现的完整流程。目前已有2492人学习适合不同阶段的逆向爱好者反复揣摩。通过这8道题目可以系统训练反汇编代码阅读、跟踪程序执行路径、从图片或文件中提取隐藏信息、分析二进制结构并进行针对性解密配套存档与目录文件也能帮助核对每一步分析结果是一份小而精的CTF逆向实战资料。1. 几个CTF逆向题为什么值得花一个周末死磕第一次接触CTF逆向题的人多半是被一道叫“反调试”的题折磨到凌晨三点最后发现只是把ptrace调用的返回值和预期比反了。这不是个例。CTF逆向题玩得转的人不是数学天才而是见过足够多套路的人静态分析卡住就上动态调试动态被反调试拦了就 patch 二进制patch 完发现还有混淆那就用 Unicorn 模拟执行硬着头皮跑。这套循环下来你对程序的理解深度远超普通业务开发。这类题能解决的问题很实际恶意样本分析、老系统二进制维护、竞品协议破解合法范围内、以及日常排查崩溃时的 call stack 解读能力。适合谁刚入门想找题感的学生、想转安全方向的开发、以及被“会写代码但看不懂汇编”困扰的爱好者。本文会讲清楚常见题型的识别、工具链的选型、可复现的解题脚本以及新手最常踩的坑。读完你至少能独立啃下一道中低难度的逆向题。2. 先认清战场常见题型与工具链的最小必备集2.1 几类高频题型的特征与难度梯队逆向题虽然花样多但绝大部分能归进几个类型。先说识别特征这个能力比会某个工具更重要——看到题目文件先判断它是哪种题型基本决定了你接下来的思路。第一类是“逻辑还原题”。特征是程序不大没有反调试主逻辑全在几个函数里。常见做法是把main和关键函数逆向成伪代码找出校验函数再写脚本反推输入。这类题适合热身也是新手建立信心的起点。第二类是“加密/编码算法识别题”。程序里会有明显的常量表比如0x3C开头的S盒、0x9E3779B9这样的魔数或者base64的字符表被打乱过。识别特征靠两点搜常量、看循环结构。拿到特征后直接查表定性不用从零分析算法。第三类是“虚拟机/解释器题”。特征是程序主体是一个巨大的switch外加一个字节码数组。这种题看着吓人但本质就是把指令集还原出来然后写脚本模拟执行。它的难不在于单条指令而在于指令多了之后的状态跟踪。第四类是“反调试/混淆题”。这类题会检查ptrace、校验/proc/self/status里的TracerPid或者用花指令干扰静态分析。识别特征是程序里有一堆“看起来没用”的代码或者运行环境一不对就直接退出。难度梯队上逻辑还原 算法识别 反调试 虚拟机。这个排序不是绝对的但在中低难度区间基本成立。建议新手从第一类开始不要一上来就挑战虚拟机容易挫败。2.2 工具链选型哪些必须装哪些等到需要时再装工具不是越多越好装一堆插件但不会用反而拖慢节奏。我建议的最小集是一个反汇编器、一个动态调试器、一个十六进制编辑器、一个脚本语言环境。反汇编器选 IDA 或 Ghidra。注意如果你用的是某些低版本 IDA对较新编译器的产物支持可能不理想但这不是常见的坑。Ghidra 的优势在免费和反编译质量尚可缺点是首次分析慢、界面略卡。新手我反而推荐先用 Ghidra省去授权烦恼等真需要插件生态了再转不迟。动态调试器就是 gdb 加 pwndbg 插件或者用调试器里带的反汇编窗口。这条建议没什么争议gdb是绕不开的pwndbg 只是让显示更友好。会b main、r、ni、x/20i $pc几个命令就够起步了。十六进制编辑器用hexedit或010 Editor都行。它的核心用途只有一个改字节。改完跳转、改完标志位、改完加密表都靠它。脚本环境强推 Python 3 加 pwntools。pwntools 不只用于写 exploit它的asm()、disasm()、pack()、unpack()对逆向分析同样好用。提示装 pwntools 时注意 Python 版本兼容性推荐在虚拟环境里装避免污染系统环境。2.3 从拿到文件到第一次确认逻辑一个最小工作流拿到一道题先不要急着拖进反汇编器。先做三件事file看类型、strings看线索、checksec看保护。这三步花两分钟能在后面省两小时。file challenge.bin # 输出challenge.bin: ELF 64-bit LSB executable, x86-64 strings challenge.bin | grep -i flag\|key\|usage # 输出Usage: %s key\n 以及 Correct! / Wrong! 字样 checksec --filechallenge.bin # 输出Arch: amd64-64-little, RELRO: Full, Stack: Canary found, NX: enabled, PIE: enabledfile确认架构和位数这决定了你用 32 位还是 64 位寄存器名。strings找提示性字符串很多题的入口就藏在报错信息里。checksec告诉你保护开没开开了 PIE 的话动态调试里的地址每次加载都不一样patched 时也要注意偏移计算。这个工作流不管你遇到什么题先跑一遍大部分逻辑还原题到这里就已经能猜出大概结构了。3. 逐个击破三类常见题型的实战拆解3.1 逻辑还原题从 main 函数到逆向脚本这种题的标准模板是“读输入 → 做个变换 → 与某个常量比较”。用一段典型伪代码来说明你看到的结构通常是int main(int argc, char *argv[]) { if (argc ! 2) return 1; char *input argv[1]; for (int i 0; i strlen(input); i) { input[i] ^ 0x23; // 每字节异或 input[i] (input[i] 3) 0xFF; // 再加 3 } if (memcmp(input, target, 0x20) 0) puts(Correct!); }我们的目标是把这个变换逆过来。如果正向是异或再加逆向就是先减再异或。写脚本时注意strlen的位置——如果长度比较在变换之后那长度本身就是约束条件先确定长度再逆变换如果长度没查那输入长度可以任意但比较函数会用固定长度多了少了都会失败。target bytes.fromhex(4A 4F 48 4E 2A 4B 3C 4D) # 正向c ((input ^ 0x23) 3) 0xff # 逆向input ((target - 3) 0xff) ^ 0x23 flag bytes([((c - 3) 0xFF) ^ 0x23 for c in target]) print(flag.decode()) # 输出CTF{...}逆变换的顺序必须反向这个最容易被忽略。先加后异或的逆向就要先异或再减。为什么因为异或和加法不交换。很多新手卡在这一步是直接在原函数上做数学变换而不是在逆路径上做。还有一个隐含小坑加了 0xFF说明每个字节在0-255范围内循环逆运算也要保留这个位宽限制否则会得到负数和预期不符。遇到这类循环变换最高效的验证方式是把脚本跑出来的结果再正向变换一遍能对上target就说明逆向写对了。3.2 算法识别题靠常量表定位加密函数这一类题的最大特征是它有“锚点”——因为加密算法基本都有固定常量或固定轮数。比如 TEA 系列算法的delta是0x9E3779B9AES 的S盒开头是0x63 0x7C 0x77 0x7BBase64 的字典是可见字符表。用搜索功能直接找这些锚点定位函数之后剩下的就是拿标准实现去比对。# 在二进制里搜索 TEA 的 delta 常量小端序 python3 -c import struct; print(hex(struct.unpack(I, bytes.fromhex(B9 79 37 9E))[0])) # 输出0x9e3779b9说明这题用的是 TEA 家族加密如果是 TEA 或 XTEA关键参数有几个轮数、delta、密钥长度、以及加密的是 64 位块还是 128 位块。定位到常量后直接找轮数——通常是个循环次数在反编译代码里表现为for (i 0; i 32; i)或for (i 0; i 64; i)这种结构。轮数不同算法不同千万别拿 XTEA 的解密流程去解 TEA 的结果肯定会得到乱码。# XTEA 解密脚本模板32 轮 import struct def xtea_decrypt(cipher, key): delta 0x9E3779B9 mask 0xFFFFFFFF v0, v1 struct.unpack(2I, cipher) # 注意解密时 sum 要从加密结束时的值往回推 # 加密 32 轮结束后 sum delta * 32所以解密从 delta*32 开始每轮递减 delta total (delta * 32) mask for _ in range(32): v1 (v1 - (((v0 4) ^ (v0 5)) v0 ^ total key[(total 11) 3])) mask total (total - delta) mask v0 (v0 - (((v1 4) ^ (v1 5)) v1 ^ total key[total 3])) mask return struct.pack(2I, v0, v1)写这类脚本时我一般先把标准算法实现抄过来跑通再改参数。如果解密结果的前几个字节是CTF{这类可打印字符基本就成功了八成。需要重点检查的是total的初值很多实现从0开始加密所以解密前要先算出加密结束时的total值。轮数也是一样不匹配时解密结果看着像乱码但里面会有部分可读字符这个信号说明轮数或密钥顺序不对。3.3 虚拟机题识别主分派循环与还原指令语义虚拟机题看着难但大部分是“伪虚拟机”——指令集就十来个操作码字节码几十字节跑两三秒就结束。恐惧来源于未知拆开看其实就两件事找分发循环、还原每个操作码做了什么。// 虚拟机的主循环反编译后长这样 while (1) { opcode bytecode[pc]; switch (opcode) { case 0x01: regs[0] bytecode[pc]; break; // 立即数加载 case 0x02: regs[0] regs[1]; break; // 加法 case 0x03: regs[0] ^ regs[2]; break; // 异或 case 0x04: if (regs[0] 0) pc bytecode[pc]; break; // 条件跳转 case 0xFF: return regs[0]; // 结束 } }还原操作码不是目的目的是知道程序对输入做了什么。所以比起单步调试每条指令更高效的做法是把 opcode 到语义的映射抄下来写一个 Python 模拟器。模拟器最核心的数据结构是寄存器数组、程序计数器pc和字节码。寄存器怎么分配从反编译的 case 分支里看每个操作码操作了几号寄存器哪些是输入、哪些是临时量。import sys bytecode bytes.fromhex(sys.argv[1]) pc 0 regs [0] * 16 INPUT_INDEX 0 # 输入值在初始时放入 0 号寄存器 while True: op bytecode[pc]; pc 1 if op 0x01: regs[bytecode[pc]] bytecode[pc1] pc 2 elif op 0x02: regs[0] regs[1] elif op 0x03: regs[0] ^ regs[2] elif op 0x04: # 这里要注意跳转目标可能是绝对地址也可能是相对偏移 target bytecode[pc] if regs[0] 0: pc target else: pc 1 elif op 0xFF: print(result:, regs[0]) break跑模拟器的时候你会发现自己最常改的是指令长度——每条指令占几字节。立即数若是 2 字节pc加的量就不同。字节码数组里如果嵌入了输入长度或校验值还要额外拆分出来。遇到条件跳转要注意目标值到底是字节码序号还是字节码偏移量这俩差一个下标就很让人困惑。模拟器的意义在于你可以快速验证对每条指令的理解是否一致而不是靠脑子去遍历几十层循环。跑通模拟器之后逆向题就变成了“读模拟器的输出逻辑”这种更简单的任务。4. 动态调试与 Patch逆不了的逻辑就改掉4.1 用调试器在运行时确认猜想静态分析卡住时动态调试是打破僵局最直接的方式。启动程序到关键函数入口观察寄存器和内存的变化比盯着反编译代码猜要快得多。gdb ./challenge.bin # 在 main 入口断点 b main r test_input # 单步到关键比较指令附近 ni # 查看寄存器与反汇编 info registers x/5i $pc # 如果已经在比较函数里查看比较的两块内存 x/s $rdi x/s $rsi断点不要随便打在入口处先静态分析找出可疑的比较函数在函数地址下断点然后用特定输入跑进去看它到底把输入变成了什么。这一步最常用于两种情况输入变换过程的中间值、最终比较时用的目标常量。有些题的反编译代码会对常量做多种运算导致你无法直接看出来目标是什么但动态调试时x/s $rdi和x/s $rsi一打印问题就解决了。还有一个比较实用的细节程序开了 PIE 的话需要先运行一下才能确定加载基址然后断点用b *($baseoffset)。之前checksec看到PIE: enabled就要有这个意识否则断点会报“无法解析地址”的错误。这个不算技术问题但能浪费你一根烟的时间。4.2 Patch 二进制改跳转、改标志位、改目标值有些题卡在最后一步——你算出答案了但程序只接受它自己算出来的那个字符串而你必须输入一个让它校验通过的字符串。这时候不如直接改二进制让校验通过。最常见的 patch 点是条件跳转指令。比如jz相等则跳改成jnz不等则跳或者直接改成jmp无条件跳。一条指令的显式字节就那么几个用十六进制编辑器改起来很快# 取出原指令字节 objdump -d challenge.bin | grep je # 输出示例4005c7: 74 1e je 4005e7 check0x17 # 正确判断的分支是 4005e7现在想反跳把 74je 的 opcode改成 75jne # 用 python 直接改文件字节 python3 -c import sys path challenge.bin data bytearray(open(path, rb).read()) # 假设 0x5c7 是文件偏移这里简化实际需要转换虚拟地址到文件偏移 data[0x5c7] 0x75 open(path _patched, wb).write(data) 一个关键点虚拟地址不等于文件偏移。用objdump看到的地址是虚拟地址但 ELF 文件里代码段通常离文件起始偏移有一段 gap。最稳妥的方式是readelf -l challenge.bin查看段的Offset和VirtAddr算出差值再修改。或者简单点直接用支持地址跳转的十六进制编辑器比如 010 Editor 加载 ELF 模板后可以直接定位地址修改。另一种 patch 是改标志位程序把一个函数返回值当作“是否通过”的标志你可以把它从0改到1也可以改成mov eax, 1这样强制返回成功。这种方法在程序逻辑复杂、输入校验分散在多个地方时更快。4.3 用 pwntools 把调试和攻击脚本化手工敲 gdb 命令的问题是没法复用而且每道题都要重来。pwntools 的价值在于把启动、交互、发送输入全部脚本化你只需要管逻辑from pwn import * # 本地执行 io process(./challenge.bin) # 远程连接如果有远程靶机 # io remote(127.0.0.1, 9999) # 发送输入并接收输出 payload bABCDEFGHIJKLMNOP io.sendline(payload) resp io.recvall() print(resp) print(exit status:, io.poll())这一小段脚本最大的好处是方便跑多组输入把候选 key 列表循环发送看哪一组返回的字符串不同就能快速验证你的判断。想配合调试器时还可以用gdb.attach(io)在脚本运行时拉起来附加调试器比手工开 gdb 再输入attach pid方便。注意如果程序做了反调试检测process 启动没有加特殊参数时有可能会自动退出。处理方案是把求解目标反过来——不接受现场而是改成离线模拟计算绕开运行环境。5. 避坑手册逆向题常见的 6 个真实教训5.1 符号执行一跑就爆不是工具的问题现象用符号执行工具想直接求解结果跑了半小时没出结果内存也吃满了。原因符号执行对路径爆炸非常敏感。目标程序里只要有一个循环次数超过 20 的循环分支数量就会指数级增长。不是什么题目都能硬求解的。解决符号执行不是开头用的而是把逻辑缩小到关键校验函数后再用。先用静态分析找到校验函数把它的输入输出抽象成简单模型再对这个模型做符号执行。不然就是拿个大炮打蚊子一开炮自己先倒了。5.2strlen的坑它会改变比较目标的内存布局现象你推断出输入长度是 12 字节逆变换脚本也写好了但结果不对而且输出尾部有奇怪的额外字节。原因有些程序不是拿输入去和一个固定常量比而是拿输入变换后的结果当作字符串下一步的函数会对这个结果求strlen。如果你的变换结果里恰好有0x00strlen会在那儿截断后续比较就错位了。解决在没有保护的情况下检查输入每个字节变换后是否为 0。如果存在映射到 0 的可能说明输入字符集被做了额外约束。这种题一般会在变换之前对输入做一次合法性判断比如只允许可打印字符。看清楚主逻辑里字符串函数的调用对象再写脚本不要默认它只处理原始输入。5.3 TEA 解密出来是部分可读乱码轮数或密钥顺序错了现象解密结果前 4 字节是CTF{后面全乱。原因分组密码的逐块之间是有依赖的。前 4 字节正确说明密钥和算法对上了但后续乱码通常有两个来源一是你只解密了第一个 64 位块而原文超过 8 字节需要按块连续解密并链接二是加密时做过 CBC/ECB 之类的模式变化不只是裸的块加密。解决先看是 ECB 还是 CBC。如果是 CBC需要在解密下一块时把上一块的密文或明文参与异或。把分组模式补齐结果就全对了。这类题一般会顺手在循环里实现分组模式反编译后留意异或操作的对象是谁。5.4 花指令导致 Ghidra 反编译失败直接放弃是对的现象Ghidra 反编译出来一堆undefined指令代码跳转像是乱飞。原因程序插入了花指令——一些永远不会执行的字节序列故意让线性反汇编算法走到错误位置。这不是你的问题也不是反编译器的问题。解决先看程序有没有明显的“垃圾代码区域”一般是jmp跳到call内部、或者jz跳转目标极其诡异等模式。不要浪费时间在原本的函数上分析直接找统一入口动态调试从入口逐步跟会快得多。等你熟练了可以再学着把花指令的字节用 NOP 填充再进反编译器但那个技巧属于进阶不必第一次就掌握。5.5 Patch 后发现程序崩溃多半是改坏了校验和或长度字段现象patch 完运行程序直接段错误或在启动阶段就退出。原因ELF 文件头里有 checksum 或某些字段保护不过并不常见更常见的其实是改错了位置——你改的虚拟地址没有正确换算成文件偏移结果把另外一段代码的字节改了。解决改完以后先objdump -d看一下改的那个地址的指令是否符合预期再运行验证。另外留意 string 长度字段所在的只读数据区有些程序会把校验逻辑放在加载的时候执行patch 前先确认你不影响它的启动序列。建议每次 patch 都保留原文件的备份这样对比出问题时方便回退。5.6 远程环境跑不通本地却正常现象本地脚本跑得好好的发到远程靶机上就失败要么没回显要么直接超时。原因远程靶机不一定和你本地环境一致常见差异有 libc 版本、指令集优化差异、程序在服务端被包装了一层比如 xinetd 转发或 socat 转发。解决先确认远程端口后面跑的是不是同一个二进制。然后是输入结束符的问题很多远程程序需要显式发送 EOF 或者等待特定回显再发送下一段脚本里要用sendlineafter而不是sendline加sleep。这类问题排查最快的方式是把本地程序绑到同一个端口测一遍用同样的脚本跑看能否复现。6. 把解题脚本变成你的永久武器库6.1 建一个按算法分类的脚本仓库等你解了十道题以后会发现大量时间花在重复写逆变换、重复调 TEA、重复搭模拟器上。真正提升效率的方法不是把每道题单独存一个脚本而是按算法和数据结构分类整理形成自己的工具库。比如tea/目录下放 TEA、XTEA、XXTEA 的加解密脚本base64/放自定义字典的编码解码vm/放通用模拟器骨架——只需要改指令表就能适配新的虚拟机题。这样做的直接好处是新题出现时先用特征去匹配你已有的脚本。匹配不上再动手分析匹配上了直接改参数。很多题的边界坑你已经踩过一遍了脚本里留下的注释就是你的笔记比重新翻官方文档快得多。# 以 base64 变种为例这类题最常见的改动是打乱字典 import base64 STANDARD_ALPHABET ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789/ CUSTOM_ALPHABET ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcba9876543210/ def custom_b64decode(data): trans str.maketrans(CUSTOM_ALPHABET, STANDARD_ALPHABET) return base64.b64decode(data.translate(trans))这个脚本的思路是“把自定义字典翻译回标准字典复用标准库的 base64 解码”。遇到颠倒字序的变种比如反射 base64就不是改字典能搞定的需要先反转输入字符串或输出字节序。一般出题人喜欢在前端做个split和reverse之类的操作你再翻翻程序逻辑就能定位。6.2 一个值得保留的压箱底技巧用 Unicorn 模拟而不是调试真机碰到反调试难以绕过时还有一个不那么为人熟知但特别有用的办法不运行真程序而是用 Unicorn 引擎只模拟执行你要分析的那段函数代码。它的好处是直接从指定地址开始跑避开所有环境检测。缺点是需要手动初始化栈和寄存器代码样例在这里from unicorn import * from unicorn.x86_const import * BASE 0x400000 CODE_OFFSET 0x1150 # 目标函数虚拟地址相对于 BASE 的偏移 STACK_ADDR 0x7f0000000000 STACK_SIZE 0x10000 # 加载二进制并定位目标函数字节简化示意实际需用 readelf 定位段偏移 code open(challenge.bin, rb).read() mu Uc(UC_ARCH_X86, UC_MODE_64) mu.mem_map(BASE, 0x10000) mu.mem_map(STACK_ADDR, STACK_SIZE) mu.mem_write(BASE, code[:0x10000]) mu.reg_write(UC_X86_REG_RSP, STACK_ADDR STACK_SIZE - 0x100) mu.reg_write(UC_X86_REG_RDI, 0x7fffffff0000) # 模拟输入指针 mu.emu_start(BASE CODE_OFFSET, BASE 0x11D0) # 第二个参数是结束地址6.3 每天的坚持就是验证自己的一个小小的习惯我的习惯是解完一道题后把这道题的两个关键信息写进笔记特征用什么常量、什么结构、什么反调试和解法一两个关键步骤。下次遇到完全没头绪的题先翻笔记做特征匹配比对成功就直接用旧解法做参考。这个方法让我从“每道题都从零开始分析”变成“大部分题都能快速命中相似套路”省下不少力气。一旦你在本地搭好了这套脚本库和笔记库再遇到新的逆向题节奏会完全不一样。它从“这个东西好陌生、怎么下手”变成“哦这里有个 TEA 的特征先试试那个脚本”。这种积累是有复利的你第一次写脚本可能需要两小时但第二次遇到类似题只需十分钟。开始前让你有点仪式感把笔记放在脚本同目录下用README记录每道题的特征和突破口。希望帮到你。本文还有配套的精品资源点击获取